Agent 工程化的全面落地 · AI HOT
ginobefun @hongming731 64
2026-05-15 15:59 ·48天前
AI 摘要 近期AI领域焦点从模型能力转向Agent工程化落地。Anthropic发布Claude Code实践，强调放弃RAG索引，采用Agentic Search导航大型代码库，并推出管理并行会话的Agent View及Computer Use最佳实践。OpenAI的Codex推出独立光标的Computer Use功能，解决了Windows平台沙箱安全问题，其负责人指出Codex正演变为可执行长期自主任务的本地Agent。国内厂商如阿里、腾讯等也在同步推进Multi-Agent实战，标志着AI Agent进入全面工程化应用阶段。
ginobefun @hongming731 · X 2026-05-15 15:59 · 48天前
在 X 看原推 · x.com AI 摘要 近期AI领域焦点从模型能力转向Agent工程化落地。Anthropic发布Claude Code实践，强调放弃RAG索引，采用Agentic Search导航大型代码库，并推出管理并行会话的Agent View及Computer Use最佳实践。OpenAI的Codex推出独立光标的Computer Use功能，解决了Windows平台沙箱安全问题，其负责人指出Codex正演变为可执行长期自主任务的本地Agent。国内厂商如阿里、腾讯等也在同步推进Multi-Agent实战，标志着AI Agent进入全面工程化应用阶段。
Skills：通过渐进式加载机制，把专业领域知识做成「按需触发」的能力包，避免每个会话都被无关 expertise 撑满 Plugins & MCP servers：接入外部工具和数据 LSP integrations + Subagents：锦上添花的两块拼图 文章给出了三条关键模式：第一是分层的 CLAUDE.md 文件，第二是接入 LSP 拿到准确的引用关系，第三是明确的团队所有权。第三点我特别认同：AI 工具在大组织里能不能用起来，技术问题只占一半，另一半是谁负责维护这套规约。如果 CLAUDE.md 没人 own，3 个月后就会变成一份谁也不敢动、也没人相信的文件。这套思路其实就是 Agent Engineering 最具体的样子。Anthropic 在自己产品的官方博客上正式给出了答案。
→ 阅读原文：https://www.bestblogs.dev/article/243d2340
同期发的第二篇是 Claude Code Agent View，简单说就是把多会话并行管理这件事终于做成了产品。以前你同时跑几个 Claude Code 会话，需要开几个终端窗口、或者用 tmux 切分屏，再加上你自己脑子里那张哪个还在等输入、哪个已经跑完的表。现在 Agent View 在命令行里就给你一个统一面板，谁需要你回话、谁还在干活、谁已经把 PR 提了，一眼看清楚。你甚至可以直接用 claude --bg 【task】，把任务直接丢到后台，左箭头返回总览。我自己最近在跑很多并行 Agent，这个东西出来之后确实顺手很多。
→ 阅读原文：https://www.bestblogs.dev/article/e8c4364d
第三篇是 Claude 团队整理的 Computer Use 和 Browser Use 完整最佳实践。重点其实是一个特别容易被忽略的细节：截图分辨率。Claude 4.6 系列有 1568 像素长边上限，Opus 4.7 提到了 2576 像素。如果你给模型送的截图超过这个限制，API 内部会自动降采样，但你的代码还在用原图的坐标系，结果模型基于一个失真的图判断点击位置，整条工作流直接塌。这种坑你不踩一次基本不会知道。文章还讲了努力度参数怎么选、提示注入怎么防御、上下文怎么管理（缓存断点、滚动缓冲区、LLM 压缩三件套）这套组合拳，是真正能拿来打底的工程清单。
→ 阅读原文：https://www.bestblogs.dev/article/94694e50
然后是 OpenAI 这边的 Codex 三连发，跟 Anthropic 的节奏几乎是对称的。
第一篇是 Codex 的 Computer Use 上线，特点是 Codex 在你电脑里有一个自己的独立光标，不抢用户的控制权。Codex 可以一边在 UTM 里开虚拟机给你测环境，一边你自己继续在 Mac 上写东西，互不打扰。底层是多模态视觉加上系统辅助功能框架的混合：视觉负责定位坐标，辅助功能框架负责拿到每个 UI 元素的文本描述，甚至屏幕外的内容也能看见。他们专门提了一个叫 Spark 的模型，可以完全跳过视觉直接走辅助功能框架，跑出他们说的「超人速度」。隐私这块用每应用权限隔离，没授权的应用 Codex 完全看不见。Mac 已经可用，Windows 即将跟上。
→ 阅读原文：https://www.bestblogs.dev/video/cc94ab1
跟 Windows 这件事强相关的，是同周发的另一篇技术博客，专门讲怎么在 Windows 上为 Codex 做沙箱。这篇文章特别工程，作者直接说：Windows 长期没有像 macOS 那样的原生沙箱接口，给 Codex 上线时只剩两个糟糕选项：每条命令都问用户，或者干脆完全放行。他们的解决方案是从一个非提权的原型迭代到一个带防火墙的提权方案，用专用的用户账户隔离 Codex 进程，再叠加防火墙规则封住网络出口。这套方案不损失开发体验，安全性又接近 macOS 沙箱。我读完最大的感受是，安全这件事在 Agent 时代会变得越来越像系统级工程，不是写几个 Prompt 防御就完事。
→ 阅读原文：https://www.bestblogs.dev/article/36e502e0
第三篇是 Codex 负责人 Tibo Sio 在 OpenAI Forum 上的一段访谈，这个我建议大家有时间真去听一下，因为他直接讲了 Codex 下一步要去哪儿。他的判断是，Codex 已经不再是开发者工具，而是一个本地长周期的 Agent，能跑数小时甚至数天的自主任务。最有意思的演示是他用一句语音 prompt 让 Codex 给自己生成了一个定制电子表格，还有一张按价格和质量过滤的旧金山面包房地图。他给这种东西起了一个名字叫 「家常软件」，意思是非技术用户也可以为自己做工具。然后他预告了两个能力：Slash Goal，让你说一句高层意图 Agent 就执行；Auto Review，让一个次级 AI 在主 Agent 干活的时候充当裁判审计它的行为。我觉得这两个东西如果都做出来，Coding Agent 这个范式就真的可以让位给通用 AI 队友了。
→ 阅读原文：https://www.bestblogs.dev/video/e310426
这六篇放在一起看，整个 Coding 工具的工程化底座就清晰了：模型层暂时没大动，但围绕模型怎么用、怎么管、怎么让它接管真实计算机，这一周一次性给了一份相对完整的答案。
二、把 Agent 推到生产必须先过的两道关：评估与长时运行 第二条主线，是把 Agent 真正推到真实工作流必须先过的两道关：评估和长时运行，以及它们共同的协议层 Agent Skill 标准。
先说评估。Towards Data Science 这周发的一篇文章，标题就说基于 100 多次企业部署沉淀出 12 项指标框架。作者一开头讲了一个故事：他们给一个医疗 AI 客户做了三个月的项目，眼看就要上线，客户的合规官问他们一句：「你怎么知道你的 Agent 没在编造病人症状？」这个团队当时哑口无言。然后他们花了六周补完了一套 12 项评估指标，项目才上线。
这套指标分三个层面，作者还额外加了一组生产侧指标：
检索层（Retrieval，4 项）：Context Relevance > 0.85、Context Recall > 0.90、Context Precision > 0.80、Retrieval Latency < 200ms p95 生成层（Generation，3 项）：Answer Faithfulness > 0.95、Answer Relevance > 0.90、Hallucination Rate < 2% Agent 行为层（Agent，3 项）：Tool Selection Accuracy > 0.92、Tool Execution Success、Task Completion 生产侧（Production，2 项）：成本、P99 Latency < 3s 作者还把「为什么大多数团队跳过评估」拆成了三种典型反模式：「先 MVP 再加评估」（结果回填要 4-6 周，损失不可逆）、「准确率够了就行」（基准 95% 的 RAG 在真实流量上 30% 在幻觉）、「人工抽检就够」（每天 100 条还行，10000 条直接崩）。他给的结论非常硬：评估基础设施绕不过去，它直接决定项目能不能上线。检索质量不行，下游再多 prompt 工程都救不回来，这是我看完后印象最深的一句。
如果你正准备把 Agent 推到真实场景，这是开工前应该先打印出来贴在墙上的清单。
→ 阅读原文：https://www.bestblogs.dev/article/ed72fe59
跟评估并列的另一道关是长时运行。Google ADK 团队这周发了一个非常具体的教程，主角是一个新员工入职流程的协调 Agent。他们一上来就说：真实企业工作流主要由「空闲时间」构成，HR 入职跨两周，发票纠纷拖几天，销售跟进延绵一个月。一个无状态的 chatbot 容器一重启就忘光了所有上下文，根本撑不住这种节奏。
结构化的记忆 schema：替代往向量数据库里扔 JSON 这种粗暴做法 事件驱动的休眠门：替代轮询或者阻塞线程，让 Agent 在等待签字的时候真的休眠 多智能体委派：替代一个巨型 Prompt 包打天下 完整源码在 GitHub 上，这是把 Agent 真正搬进企业流水线之前必须先看的一篇。
→ 阅读原文：https://www.bestblogs.dev/article/7be5372c
然后是 Agent Skill 这件事。Anthropic 去年 12 月把 Agent Skill 作为开放标准发布，半年时间过去了，已经有 33+ 个 Agent 产品接入：Claude Code、Codex、GitHub Copilot、VS Code、Cursor、Gemini CLI、Kiro，全部都在用同一个叫 SKILL.md 的协议。阿里云开发者这周发了一篇深度解析，把规范字段、三层渐进式加载机制、模型驱动触发逻辑讲得特别透。
我最喜欢里面那句总结：Skill 围绕任务、工具、流程和输出边界做结构化行为设计，比单纯堆 Prompt 更靠谱。他还提到了一个非常实操的判断：description 字段的质量直接决定 Skill 能不能被正确触发。你以为 description 只是给人看的，其实模型先读这个字段决定要不要打开 Skill。我觉得 Agent Skill 是这一波最有可能成为长期基础设施的标准之一，因为它已经跨厂商了。
→ 阅读原文：https://www.bestblogs.dev/article/ad38855c
三、国内厂商的多智能体 Harness 三连发 第三条主线，国内厂商的 Multi-Agent Harness 实战集中爆发。这周一口气来了三篇，分别从数据库、运行时和 Java 生态三个角度切入。
第一篇来自 PingCAP 的联合创始人黄东旭，他复盘了 TiDB Cloud 怎么成为 Kimi K2.6 Agent 的数据库后端。这件事的背景很有意思：Kimi K2.6 让普通用户用一句话就能造出一个端到端的在线应用，挑战根本不在代码生成那一段，而在后面的 hosting 成本。
你算一笔账：如果每个用户的 Agent 应用都给它配一个 Supabase 实例，百万级动态创建小站直接成本爆炸。如果用一个大 PG 实例多 schema 隔离，单实例到了大约一万租户就崩了。TiDB Cloud 的做法是给每个租户提供一个虚拟数据库界面，下面跑统一的存储和计算资源，把单租户成本压到订阅模式还能算账的水平。
黄东旭还给出了 Kimi × TiDB 这套合作能跑通的三个核心战略决策，每一条都很有借鉴价值：
最小化 Agent 使用 Infra 工具时的摩擦：每个任务和站点独立隔离，由 Agent 创建。Agent 一秒拿到一个 fully prepared 的数据库实例（TiDB Warm Pool + Scale-to-zero）。如果 provisioning 要花几分钟，Agent 就得自己写 retry / poll / wait，那是 Agent 不该扛的负担 技术栈尽可能统一：人类工程师觉得「方便」，对 LLM 就是直接决定代码生成成功率的因素。少跨一个系统就少一类 bug，Skill 里跑过的脚手架比每次抽卡更稳 极致的低成本：放弃 Supabase 那种「每个用户一个真实实例」的分配模式，TiDB 引入虚拟数据库界面层。「事实上没有请求的事情，是不需要真实分配数据库实例的」。平台只需要一个常驻 DB Session Gateway 服务维持连接，其他都是弹性的 黄东旭对这一波的判断非常清晰：「以前一个产品扛亿级用户，一个 app 扛亿级会话。现在一个用户身边可能有 10 个甚至 100 个 Agent 在跑，每个都需要自己的状态和数据。」很多 AI Agent 团队的架构正在收敛到同一个范式：one agent， one sandbox， one storage， one database。
这是 Agent Native 时代数据基础设施竞争的第一个真案例。以前我们讨论数据库的扩展性更多是单点性能，现在的问题变成了：几百万个独立租户里每一个都很小，怎么把单位成本做下去。
→ 阅读原文：https://www.bestblogs.dev/article/70ea435c
第二篇来自腾讯云开发者，这是一篇真正意义上的长文，把生产级 Multi-Agent Harness 的全景图画出来了。作者一上来就指出一个关键的误区：很多团队以为多智能体系统能不能落地，取决于模型够不够强，或者 Prompt 够不够精妙。真正决定落地的，往往是常被忽略的 Harness。Harness 这个词翻译过来叫挽具，但在 Agent 领域它就是 Agent 的操作系统。
他给出的生产级原则只有一句话：Agent 负责局部智能，Harness 负责全局控制。然后他详细说了 Orchestrator 必须独占的五项决策权：
每一条他都讲了具体怎么做，配了 PlantUML 图。国内能把多智能体工程化讲得这么完整的文章并不多见，建议有相关项目的朋友收藏。
→ 阅读原文：https://www.bestblogs.dev/article/878057b5
第三篇是阿里发布的 AgentScope Java 1.1，把他们前几个月开源的 OpenClaw 那套 Harness Engineering 范式正式带到了 Java 生态里。这是国内首个 Java Harness Framework，对企业级开发意义很大，因为大量传统行业的服务还是跑在 Spring 上的，Python 那套 Agent 框架没法直接搬。
工作区驱动的运行时：把 Agent 的人格、知识、技能、记忆、子 Agent 规格全部沉淀在一个结构化工作区里 可插拔的抽象文件系统：本地磁盘、远端共享存储、隔离沙箱用同一套接口操作，同一份 Agent 逻辑不用改代码就能从个人开发环境搬到企业分布式部署 内置的上下文管理：对话压缩、双层记忆沉淀和全文检索 子 Agent 编排和隔离执行：支持多租户场景的会话和用户维度隔离 如果你公司主要技术栈是 Java，这个框架值得认真试一下。
→ 阅读原文：https://www.bestblogs.dev/article/321aed16
跟这三篇可以放在一起读的，还有大淘宝技术团队发的 AI-Generated UI 技术深度解析。这篇文章把 v0.dev、Bolt.new、Cursor、Windsurf 这一批产品背后的全栈技术梳了一遍：从 SSE 协议、fetch + ReadableStream 这些基础设施，到 Vercel AI SDK、WebContainers 这些开源核心，再到流式代码、流式 Markdown、流式 JSON 三大增量解析挑战。如果你想做出 v0 那样的 AI 生成 UI 体验，这是补全技术地图最干净的起点。
→ 阅读原文：https://www.bestblogs.dev/article/42f8648f
这周国内厂商一次性给了多智能体工程化的四块拼图：数据库、运行时全景、Java 落地、流式 UI 渲染。这种密度，未来一年都不一定再见到。
四、AI Native 时代的组织、商业模式与三场访谈 第四条主线，把视角从工程化往后退一步，去看组织、商业模式、以及一线人物对这件事的不同回响。
先说阿里技术发的那篇《AI Native 时代研发组织何去何从》，这一篇建议大家直接收藏起来反复读。他们对内部深度使用 AI 的工程师做了访谈，结果是这样的：
作者紧接着提出了一个判断，让我读了之后愣了好一会儿：AI 是一种新的协作主体。所有过去以人形约束为前提设计的组织规则，比如康威定律、管理跨度、年度评价制，前提开始失效了。他观察到正在做 AI Native 的团队（包括 Anthropic 和阿里内部的一些先锋小组），都出现了一种共同形态：两层结构。下面是高度结构化的 Harness 层，上面是高度松散的 Hive Mind 层，两层的运作逻辑甚至是相反的。
关于「人既是瓶颈也是兜底」。作者在访谈里写道：「之前的模式一个工作需要拉入很多人来做模块划分，功能上需要相互协议和对齐目标，消除理解的不一致性。」过去几十年我们抱怨的「会议太多、对齐成本高、信息上下传递失真」，所有矛头都指向人。但与此同时，一份不完整的需求、一段没注释的代码、一个不一致的 API 约定、一段口头传达的潜规则，这些缺陷之所以系统能正常运转，是因为人在用自己的灵活性、推理能力、社会沟通能力悄悄把缺口补上。「开个会问一下、走过去问老王、凭经验猜一下」，这些动作发生得太自然，自然到我们不再把它看作「工作」。但它们就是工作。当 AI 接管执行之后，这一面就翻过来了。AI 没有「猜」和「问老王」的能力，它需要的是结构化、可查询、可执行、确定性的信息。新瓶颈落在系统的信息形态上。
关于 Execution Graph 替代 Org Chart。作者给出了一个具体的、可衡量的判断：传统 reorg 周期常常是 6 到 12 个月（计划几个月、执行几个月、重建信任又几个月），因为旧组织的最小单元是「人 + 长期关系网」，粘性极高。Execution Graph 把组织最小单元从「人 + 关系网」换成「任务 + 上下文 + 权限 + 工具」，里面大部分依赖是机器可读的 artifact，所以重组成本可以从季度级压到 week 级，这是数量级的跃迁。从公司层面看，这可能是 AI Native 转型最被低估的红利：适应性速度本身的升级，远比「组织能更高效」更值钱。
关于 Architect 这个新角色。文章用 CREAO 的 CTO Peter Pang 做案例：他自己两个月前还有 60% 时间在管人，现在不到 10%。但作者强调，管理在塌缩，也在重新选择它的位置。新出现的最关键角色叫 Architect，设计教 AI 怎么工作的人：他不写代码，不堆功能，为整个 Execution Graph 设计架构、定义系统能力的边界、设计 SOP、建立测试基础设施、定义「什么叫好」。
这三段读完，我觉得这是本周最值得反复读的一篇。它把整个组织视角的思考做实了。
→ 阅读原文：https://www.bestblogs.dev/article/8c2c877a
跟这个组织议题完美对仗的，是 Eric Ries 在 Lenny's Podcast 上聊他的新书 Incorruptible。Eric Ries 是精益创业的作者，这次他要解决的问题是：成功的公司为什么会逐渐被拖向平庸。他指出的症结，是一种他叫「财务引力」 的东西，是公司治理结构的天然产物。
他用了一个特别好的比喻：公司治理需要「不锈钢螺栓」，就是结构上防腐蚀的东西。他列了三类：
信托治理：Anthropic 的独立受托人模式，监督关乎使命的关键决策 基础所有权：Novo Nordisk 由非营利基金会控股的模式 如果你也在思考你的公司怎么长期不被外部财务力量吃掉，这是一篇稀缺的具体路径讨论。
→ 阅读原文：https://www.bestblogs.dev/video/2efe03f
第一场：Stripe 的 AI Boom 系列采访 Manus AI 的张涛。Manus 这个产品很多人听过：八个月做到 1 亿美元 ARR，几乎全部是有机增长。他们的核心架构叫「大脑与手」：大模型是大脑，Agent 需要一只手，他们就给每个 Agent 配一个虚拟机沙箱让它自己浏览、写代码、跑命令，更侧重输出完成任务，文本只是中间产物。张涛分享的最有意思的产品决策，是把 Agent 内部的过程做成「会话回放」给用户看。本以为透明会让用户怀疑，结果反而换来了信任。他对未来的判断：AI 之后，人的瓶颈从「解决问题」转向「定义问题」。
→ 阅读原文：https://www.bestblogs.dev/video/cf1fb78
第二场：Sequoia 访谈 Suno CEO Mikey Shulman。Suno 这个公司你即便不做音乐也值得听听他们的思路。他们的技术路线不走 12 平均律和 MIDI 那套西方音乐理论，把音乐建模成 48 kHz 采样的连续声波，相当于第一性原理重做音乐生成。这种做法让一些原本不存在的形态自然涌现，比如「带西塔琴的 trap」，比如微分音音乐。但他给的最反直觉的发现是：Suno 用户里有 90% 每天都在创作，消费占少数。AI 一边把「地板」抬高了（人人能做音乐），一边也把「天花板」抬高了（专业音乐人拿到了新工具）。
→ 阅读原文：https://www.bestblogs.dev/video/c6a585f
第三场：张小珺 4 小时对话姚顺宇。姚顺宇前后在 Anthropic 和 Google DeepMind 出任过研究科学家，参与过 Claude 3.7、4.5、Gemini 3 的训练。这场访谈直白到罕见，姚顺宇本人在物理学（非厄米系统、量子物理、高能物理）深耕九年后毅然转行 AI，自言「总想挑战一些自己不太会的事」。访谈里他几句话特别戳人：
「AI 个人英雄主义的时代已经过去了，所以也没有什么英雄，有时候甚至觉得旧时代英雄有点蠢。」 「现在大家都是冲浪的人，本质上是那个浪，冲浪的人反而没那么重要。」 「AI 这个事，本来也不太需要脑子。真的不太需要脑子。这个行业最重要的特质，就是靠谱，就是做事细，对自己做的事情负责任。」 「你不用太担心因为自己的观点而惹到什么人。只要你的观点是自洽的，不是说随便喷人，你是有一套自己的理解。最终你在这个领域做的怎样，是有客观评价标准的。大家是会尊重你的。」
4 小时的内容覆盖两个 Shunyu Yao（清华同一届的姚顺雨和姚顺宇）、Pre-train 没到头、Coding 爆发、字节豆包、机器人技术预测、AI 个人英雄主义的终结、集体主义胜利。在描述自己的研究时，姚顺宇又异常审慎：「我自己对那个事没那么重要，更多的是我很幸运，有机会在那个时候加入了一个重要的项目，做了一些事」。
我看完最大的感触是：新一代 AI 工程师的工作伦理变了，集体主义、靠谱、做事细正在取代个人天才主义。这场访谈是少数能从一线训练者口中拿到的真正内幕。
→ 阅读原文：https://www.bestblogs.dev/podcast/a4391a3
最后一个亮点，是 AI 在真实产业现场的两种姿态。
一种是李想这边的宏大愿景。罗永浩这周对话李想，理想汽车带来了全新旗舰 SUV L9 Livis。这车搭载理想自研的马赫 M100 芯片，算力达到 2560 TOPS，配的是全球首个完全体全线控底盘，还有 800V 主动悬架。这场访谈三个小时，李想本人完成了从汽车公司创始人到「AI + 具身智能公司」创始人的角色切换。
→ 阅读原文：https://www.bestblogs.dev/podcast/177bfb5
另一种姿态是 flomo 的少楠在腾讯研究院 AI 跃迁者调研里给出的真实困境。少楠是 11 年没写过代码的产品经理，现在每天用 Claude Code 在真实数据库里跑 3 个小时的需求验证，他公司 70-80% 代码已经由 AI 贡献，开发周期从按月变成按小时。但他给出了一个反直觉的观察：效率上去了，用户价值没跟上。
他的原话是：「以前工程师烦死产品经理觉得需求太多，现在是产品经理不好意思提需求了。」他还说了一句让我特别有共鸣的话：只有原来优秀的人变得更优秀了，因为 AI 无法回答一句话：『我不知道』。16 人团队的协作重构，比工具升级难得多。
→ 阅读原文：https://www.bestblogs.dev/article/6af09fd5
李想那条线是宏大愿景，flomo 这条线是真实困境，把这两条放在一起，可能比任何技术分析都更接近 AI 这一年的真实样子。
本周关键词 这周没有什么模型发布，但跟模型相关的工程化、组织化、产品化的答案，一次性给得特别多。下周我会重点关注国内厂商在 Agent 工程化的后续动作，看看这周的密度能不能延续。
20 篇文章的完整链接都在上方各章节里，如果哪一篇特别戳到你，建议直接读原文。
关于 BestBlogs BestBlogs.dev 是 AI 驱动的个性化高质量阅读工作流，「我的早报」 会基于你关注的源、阅读行为与兴趣画像，每天为你生成一份真正属于你的精选 brief，让你以最少的时间触达本周最值得读的内容。
完成新用户三步引导即送 7 天 Pro 试用；现有 Pro 用户每邀请 1 位朋友双方各得 7 天 Pro（单人上限 28 天）；5 月 9 日之前注册的老用户别错过 5 月 15 日至 5 月 31 日的 14 天 Pro 限时赠送，到 bestblogs.dev/promo 一键领取。
让高质量内容找到对的人。欢迎来体验，也欢迎推荐给身边热爱阅读的朋友。
在开始正文之前，也想用一段说说 BestBlogs 自己的几个变化。我们的新版三步引导这周正式上线，从「先选兴趣」反转成「先选公共信源、再加你自己的 RSS、最后选兴趣方向」，每一步都立刻保存，完成引导直接送 7 天 Pro 试用。同时文章、播客、视频、推文四类详情页对所有人开放，访客不登录也能读全文。还有一件事是邀请功能正式重启，每邀请 1 位新朋友双方都能各得 7 天 Pro，单人累计上限 28 天。如果你是 5 月 9 号之前注册的老用户，5 月 15 日到 5 月 31 日还有一次性 14 天 Pro 限时赠送，到 bestblogs.dev/promo 一键领取就行。希望大家多体验，也欢迎把 BestBlogs 推荐给身边热爱阅读的朋友。
一、Coding 工具走出编辑器：Anthropic 与 OpenAI 的同步答卷 第一条主线，也是这周最清晰的趋势：Coding 工具正在走出编辑器，走向整个计算机。
Anthropic 这周一口气发了三篇关于 Claude Code 的文章，三篇都是工程化实践，没有一篇是模型层的事。
第一篇讲 Claude Code 在大型代码库里到底是怎么用的。这里说的大型代码库，指的是百万行的 monorepo、十年遗留系统、几十个微服务跨仓，百行千行规模不在讨论范围内。Anthropic 的核心结论挺反直觉的，他们直接说，放弃 RAG 嵌入式索引，改走 Agentic Search 路线，让 Claude 像工程师一样用 grep 跨引用导航。原因是嵌入式索引在大团队里很容易滞后。你两周前重命名的一个函数，索引可能还在返回老名字。Agentic Search 不依赖索引，每次都从最新的代码状态出发。
不过 Anthropic 自己也明确承认：Agentic Search 也有边界。「如果你让它在十亿行代码库里寻找一个模糊模式的所有实例，你会在工作开始之前就撞上上下文窗口的上限」。代码库本身的可导航性才是 Claude Code 性能的天花板，所以 Anthropic 把「Harness 和模型一样重要」放在文章最关键的位置。这套 Harness 由五个扩展点组成：
CLAUDE.md：Claude 每次会话自动读取的上下文文件，根目录放整体架构，子目录放局部约定。因为每次都加载，CLAUDE.md 必须「窄而聚焦」，过于宽泛反而拖累性能 Hooks：大多数团队把 hooks 当成「防止 Claude 干坏事」的脚本，但 Anthropic 强调它最有价值的用法是自我改进。一个 stop hook 可以在会话结束时回顾整段交互、自动提议 CLAUDE.md 更新；start hook 则可以根据开发者当前所在模块动态加载团队上下文 Skills：通过渐进式加载机制，把专业领域知识做成「按需触发」的能力包，避免每个会话都被无关 expertise 撑满 Plugins & MCP servers：接入外部工具和数据 LSP integrations + Subagents：锦上添花的两块拼图 文章给出了三条关键模式：第一是分层的 CLAUDE.md 文件，第二是接入 LSP 拿到准确的引用关系，第三是明确的团队所有权。第三点我特别认同：AI 工具在大组织里能不能用起来，技术问题只占一半，另一半是谁负责维护这套规约。如果 CLAUDE.md 没人 own，3 个月后就会变成一份谁也不敢动、也没人相信的文件。这套思路其实就是 Agent Engineering 最具体的样子。Anthropic 在自己产品的官方博客上正式给出了答案。
→ 阅读原文：https://www.bestblogs.dev/article/243d2340
同期发的第二篇是 Claude Code Agent View，简单说就是把多会话并行管理这件事终于做成了产品。以前你同时跑几个 Claude Code 会话，需要开几个终端窗口、或者用 tmux 切分屏，再加上你自己脑子里那张哪个还在等输入、哪个已经跑完的表。现在 Agent View 在命令行里就给你一个统一面板，谁需要你回话、谁还在干活、谁已经把 PR 提了，一眼看清楚。你甚至可以直接用 claude --bg 【task】，把任务直接丢到后台，左箭头返回总览。我自己最近在跑很多并行 Agent，这个东西出来之后确实顺手很多。
→ 阅读原文：https://www.bestblogs.dev/article/e8c4364d
第三篇是 Claude 团队整理的 Computer Use 和 Browser Use 完整最佳实践。重点其实是一个特别容易被忽略的细节：截图分辨率。Claude 4.6 系列有 1568 像素长边上限，Opus 4.7 提到了 2576 像素。如果你给模型送的截图超过这个限制，API 内部会自动降采样，但你的代码还在用原图的坐标系，结果模型基于一个失真的图判断点击位置，整条工作流直接塌。这种坑你不踩一次基本不会知道。文章还讲了努力度参数怎么选、提示注入怎么防御、上下文怎么管理（缓存断点、滚动缓冲区、LLM 压缩三件套）这套组合拳，是真正能拿来打底的工程清单。
→ 阅读原文：https://www.bestblogs.dev/article/94694e50
然后是 OpenAI 这边的 Codex 三连发，跟 Anthropic 的节奏几乎是对称的。
第一篇是 Codex 的 Computer Use 上线，特点是 Codex 在你电脑里有一个自己的独立光标，不抢用户的控制权。Codex 可以一边在 UTM 里开虚拟机给你测环境，一边你自己继续在 Mac 上写东西，互不打扰。底层是多模态视觉加上系统辅助功能框架的混合：视觉负责定位坐标，辅助功能框架负责拿到每个 UI 元素的文本描述，甚至屏幕外的内容也能看见。他们专门提了一个叫 Spark 的模型，可以完全跳过视觉直接走辅助功能框架，跑出他们说的「超人速度」。隐私这块用每应用权限隔离，没授权的应用 Codex 完全看不见。Mac 已经可用，Windows 即将跟上。
→ 阅读原文：https://www.bestblogs.dev/video/cc94ab1
跟 Windows 这件事强相关的，是同周发的另一篇技术博客，专门讲怎么在 Windows 上为 Codex 做沙箱。这篇文章特别工程，作者直接说：Windows 长期没有像 macOS 那样的原生沙箱接口，给 Codex 上线时只剩两个糟糕选项：每条命令都问用户，或者干脆完全放行。他们的解决方案是从一个非提权的原型迭代到一个带防火墙的提权方案，用专用的用户账户隔离 Codex 进程，再叠加防火墙规则封住网络出口。这套方案不损失开发体验，安全性又接近 macOS 沙箱。我读完最大的感受是，安全这件事在 Agent 时代会变得越来越像系统级工程，不是写几个 Prompt 防御就完事。
→ 阅读原文：https://www.bestblogs.dev/article/36e502e0
第三篇是 Codex 负责人 Tibo Sio 在 OpenAI Forum 上的一段访谈，这个我建议大家有时间真去听一下，因为他直接讲了 Codex 下一步要去哪儿。他的判断是，Codex 已经不再是开发者工具，而是一个本地长周期的 Agent，能跑数小时甚至数天的自主任务。最有意思的演示是他用一句语音 prompt 让 Codex 给自己生成了一个定制电子表格，还有一张按价格和质量过滤的旧金山面包房地图。他给这种东西起了一个名字叫 「家常软件」，意思是非技术用户也可以为自己做工具。然后他预告了两个能力：Slash Goal，让你说一句高层意图 Agent 就执行；Auto Review，让一个次级 AI 在主 Agent 干活的时候充当裁判审计它的行为。我觉得这两个东西如果都做出来，Coding Agent 这个范式就真的可以让位给通用 AI 队友了。
→ 阅读原文：https://www.bestblogs.dev/video/e310426
这六篇放在一起看，整个 Coding 工具的工程化底座就清晰了：模型层暂时没大动，但围绕模型怎么用、怎么管、怎么让它接管真实计算机，这一周一次性给了一份相对完整的答案。
二、把 Agent 推到生产必须先过的两道关：评估与长时运行 第二条主线，是把 Agent 真正推到真实工作流必须先过的两道关：评估和长时运行，以及它们共同的协议层 Agent Skill 标准。
先说评估。Towards Data Science 这周发的一篇文章，标题就说基于 100 多次企业部署沉淀出 12 项指标框架。作者一开头讲了一个故事：他们给一个医疗 AI 客户做了三个月的项目，眼看就要上线，客户的合规官问他们一句：「你怎么知道你的 Agent 没在编造病人症状？」这个团队当时哑口无言。然后他们花了六周补完了一套 12 项评估指标，项目才上线。
这套指标分三个层面，作者还额外加了一组生产侧指标：
检索层（Retrieval，4 项）：Context Relevance > 0.85、Context Recall > 0.90、Context Precision > 0.80、Retrieval Latency < 200ms p95 生成层（Generation，3 项）：Answer Faithfulness > 0.95、Answer Relevance > 0.90、Hallucination Rate < 2% Agent 行为层（Agent，3 项）：Tool Selection Accuracy > 0.92、Tool Execution Success、Task Completion 生产侧（Production，2 项）：成本、P99 Latency < 3s 作者还把「为什么大多数团队跳过评估」拆成了三种典型反模式：「先 MVP 再加评估」（结果回填要 4-6 周，损失不可逆）、「准确率够了就行」（基准 95% 的 RAG 在真实流量上 30% 在幻觉）、「人工抽检就够」（每天 100 条还行，10000 条直接崩）。他给的结论非常硬：评估基础设施绕不过去，它直接决定项目能不能上线。检索质量不行，下游再多 prompt 工程都救不回来，这是我看完后印象最深的一句。
如果你正准备把 Agent 推到真实场景，这是开工前应该先打印出来贴在墙上的清单。
→ 阅读原文：https://www.bestblogs.dev/article/ed72fe59
跟评估并列的另一道关是长时运行。Google ADK 团队这周发了一个非常具体的教程，主角是一个新员工入职流程的协调 Agent。他们一上来就说：真实企业工作流主要由「空闲时间」构成，HR 入职跨两周，发票纠纷拖几天，销售跟进延绵一个月。一个无状态的 chatbot 容器一重启就忘光了所有上下文，根本撑不住这种节奏。
结构化的记忆 schema：替代往向量数据库里扔 JSON 这种粗暴做法 事件驱动的休眠门：替代轮询或者阻塞线程，让 Agent 在等待签字的时候真的休眠 多智能体委派：替代一个巨型 Prompt 包打天下 完整源码在 GitHub 上，这是把 Agent 真正搬进企业流水线之前必须先看的一篇。
→ 阅读原文：https://www.bestblogs.dev/article/7be5372c
然后是 Agent Skill 这件事。Anthropic 去年 12 月把 Agent Skill 作为开放标准发布，半年时间过去了，已经有 33+ 个 Agent 产品接入：Claude Code、Codex、GitHub Copilot、VS Code、Cursor、Gemini CLI、Kiro，全部都在用同一个叫 SKILL.md 的协议。阿里云开发者这周发了一篇深度解析，把规范字段、三层渐进式加载机制、模型驱动触发逻辑讲得特别透。
我最喜欢里面那句总结：Skill 围绕任务、工具、流程和输出边界做结构化行为设计，比单纯堆 Prompt 更靠谱。他还提到了一个非常实操的判断：description 字段的质量直接决定 Skill 能不能被正确触发。你以为 description 只是给人看的，其实模型先读这个字段决定要不要打开 Skill。我觉得 Agent Skill 是这一波最有可能成为长期基础设施的标准之一，因为它已经跨厂商了。
→ 阅读原文：https://www.bestblogs.dev/article/ad38855c
三、国内厂商的多智能体 Harness 三连发 第三条主线，国内厂商的 Multi-Agent Harness 实战集中爆发。这周一口气来了三篇，分别从数据库、运行时和 Java 生态三个角度切入。
第一篇来自 PingCAP 的联合创始人黄东旭，他复盘了 TiDB Cloud 怎么成为 Kimi K2.6 Agent 的数据库后端。这件事的背景很有意思：Kimi K2.6 让普通用户用一句话就能造出一个端到端的在线应用，挑战根本不在代码生成那一段，而在后面的 hosting 成本。
你算一笔账：如果每个用户的 Agent 应用都给它配一个 Supabase 实例，百万级动态创建小站直接成本爆炸。如果用一个大 PG 实例多 schema 隔离，单实例到了大约一万租户就崩了。TiDB Cloud 的做法是给每个租户提供一个虚拟数据库界面，下面跑统一的存储和计算资源，把单租户成本压到订阅模式还能算账的水平。
黄东旭还给出了 Kimi × TiDB 这套合作能跑通的三个核心战略决策，每一条都很有借鉴价值：
最小化 Agent 使用 Infra 工具时的摩擦：每个任务和站点独立隔离，由 Agent 创建。Agent 一秒拿到一个 fully prepared 的数据库实例（TiDB Warm Pool + Scale-to-zero）。如果 provisioning 要花几分钟，Agent 就得自己写 retry / poll / wait，那是 Agent 不该扛的负担 技术栈尽可能统一：人类工程师觉得「方便」，对 LLM 就是直接决定代码生成成功率的因素。少跨一个系统就少一类 bug，Skill 里跑过的脚手架比每次抽卡更稳 极致的低成本：放弃 Supabase 那种「每个用户一个真实实例」的分配模式，TiDB 引入虚拟数据库界面层。「事实上没有请求的事情，是不需要真实分配数据库实例的」。平台只需要一个常驻 DB Session Gateway 服务维持连接，其他都是弹性的 黄东旭对这一波的判断非常清晰：「以前一个产品扛亿级用户，一个 app 扛亿级会话。现在一个用户身边可能有 10 个甚至 100 个 Agent 在跑，每个都需要自己的状态和数据。」很多 AI Agent 团队的架构正在收敛到同一个范式：one agent， one sandbox， one storage， one database。
这是 Agent Native 时代数据基础设施竞争的第一个真案例。以前我们讨论数据库的扩展性更多是单点性能，现在的问题变成了：几百万个独立租户里每一个都很小，怎么把单位成本做下去。
→ 阅读原文：https://www.bestblogs.dev/article/70ea435c
第二篇来自腾讯云开发者，这是一篇真正意义上的长文，把生产级 Multi-Agent Harness 的全景图画出来了。作者一上来就指出一个关键的误区：很多团队以为多智能体系统能不能落地，取决于模型够不够强，或者 Prompt 够不够精妙。真正决定落地的，往往是常被忽略的 Harness。Harness 这个词翻译过来叫挽具，但在 Agent 领域它就是 Agent 的操作系统。
他给出的生产级原则只有一句话：Agent 负责局部智能，Harness 负责全局控制。然后他详细说了 Orchestrator 必须独占的五项决策权：
每一条他都讲了具体怎么做，配了 PlantUML 图。国内能把多智能体工程化讲得这么完整的文章并不多见，建议有相关项目的朋友收藏。
→ 阅读原文：https://www.bestblogs.dev/article/878057b5
第三篇是阿里发布的 AgentScope Java 1.1，把他们前几个月开源的 OpenClaw 那套 Harness Engineering 范式正式带到了 Java 生态里。这是国内首个 Java Harness Framework，对企业级开发意义很大，因为大量传统行业的服务还是跑在 Spring 上的，Python 那套 Agent 框架没法直接搬。
工作区驱动的运行时：把 Agent 的人格、知识、技能、记忆、子 Agent 规格全部沉淀在一个结构化工作区里 可插拔的抽象文件系统：本地磁盘、远端共享存储、隔离沙箱用同一套接口操作，同一份 Agent 逻辑不用改代码就能从个人开发环境搬到企业分布式部署 内置的上下文管理：对话压缩、双层记忆沉淀和全文检索 子 Agent 编排和隔离执行：支持多租户场景的会话和用户维度隔离 如果你公司主要技术栈是 Java，这个框架值得认真试一下。
→ 阅读原文：https://www.bestblogs.dev/article/321aed16
跟这三篇可以放在一起读的，还有大淘宝技术团队发的 AI-Generated UI 技术深度解析。这篇文章把 v0.dev、Bolt.new、Cursor、Windsurf 这一批产品背后的全栈技术梳了一遍：从 SSE 协议、fetch + ReadableStream 这些基础设施，到 Vercel AI SDK、WebContainers 这些开源核心，再到流式代码、流式 Markdown、流式 JSON 三大增量解析挑战。如果你想做出 v0 那样的 AI 生成 UI 体验，这是补全技术地图最干净的起点。
→ 阅读原文：https://www.bestblogs.dev/article/42f8648f
这周国内厂商一次性给了多智能体工程化的四块拼图：数据库、运行时全景、Java 落地、流式 UI 渲染。这种密度，未来一年都不一定再见到。
四、AI Native 时代的组织、商业模式与三场访谈 第四条主线，把视角从工程化往后退一步，去看组织、商业模式、以及一线人物对这件事的不同回响。
先说阿里技术发的那篇《AI Native 时代研发组织何去何从》，这一篇建议大家直接收藏起来反复读。他们对内部深度使用 AI 的工程师做了访谈，结果是这样的：
作者紧接着提出了一个判断，让我读了之后愣了好一会儿：AI 是一种新的协作主体。所有过去以人形约束为前提设计的组织规则，比如康威定律、管理跨度、年度评价制，前提开始失效了。他观察到正在做 AI Native 的团队（包括 Anthropic 和阿里内部的一些先锋小组），都出现了一种共同形态：两层结构。下面是高度结构化的 Harness 层，上面是高度松散的 Hive Mind 层，两层的运作逻辑甚至是相反的。
关于「人既是瓶颈也是兜底」。作者在访谈里写道：「之前的模式一个工作需要拉入很多人来做模块划分，功能上需要相互协议和对齐目标，消除理解的不一致性。」过去几十年我们抱怨的「会议太多、对齐成本高、信息上下传递失真」，所有矛头都指向人。但与此同时，一份不完整的需求、一段没注释的代码、一个不一致的 API 约定、一段口头传达的潜规则，这些缺陷之所以系统能正常运转，是因为人在用自己的灵活性、推理能力、社会沟通能力悄悄把缺口补上。「开个会问一下、走过去问老王、凭经验猜一下」，这些动作发生得太自然，自然到我们不再把它看作「工作」。但它们就是工作。当 AI 接管执行之后，这一面就翻过来了。AI 没有「猜」和「问老王」的能力，它需要的是结构化、可查询、可执行、确定性的信息。新瓶颈落在系统的信息形态上。
关于 Execution Graph 替代 Org Chart。作者给出了一个具体的、可衡量的判断：传统 reorg 周期常常是 6 到 12 个月（计划几个月、执行几个月、重建信任又几个月），因为旧组织的最小单元是「人 + 长期关系网」，粘性极高。Execution Graph 把组织最小单元从「人 + 关系网」换成「任务 + 上下文 + 权限 + 工具」，里面大部分依赖是机器可读的 artifact，所以重组成本可以从季度级压到 week 级，这是数量级的跃迁。从公司层面看，这可能是 AI Native 转型最被低估的红利：适应性速度本身的升级，远比「组织能更高效」更值钱。
关于 Architect 这个新角色。文章用 CREAO 的 CTO Peter Pang 做案例：他自己两个月前还有 60% 时间在管人，现在不到 10%。但作者强调，管理在塌缩，也在重新选择它的位置。新出现的最关键角色叫 Architect，设计教 AI 怎么工作的人：他不写代码，不堆功能，为整个 Execution Graph 设计架构、定义系统能力的边界、设计 SOP、建立测试基础设施、定义「什么叫好」。
这三段读完，我觉得这是本周最值得反复读的一篇。它把整个组织视角的思考做实了。
→ 阅读原文：https://www.bestblogs.dev/article/8c2c877a
跟这个组织议题完美对仗的，是 Eric Ries 在 Lenny's Podcast 上聊他的新书 Incorruptible。Eric Ries 是精益创业的作者，这次他要解决的问题是：成功的公司为什么会逐渐被拖向平庸。他指出的症结，是一种他叫「财务引力」 的东西，是公司治理结构的天然产物。
他用了一个特别好的比喻：公司治理需要「不锈钢螺栓」，就是结构上防腐蚀的东西。他列了三类：
信托治理：Anthropic 的独立受托人模式，监督关乎使命的关键决策 基础所有权：Novo Nordisk 由非营利基金会控股的模式 如果你也在思考你的公司怎么长期不被外部财务力量吃掉，这是一篇稀缺的具体路径讨论。
→ 阅读原文：https://www.bestblogs.dev/video/2efe03f
第一场：Stripe 的 AI Boom 系列采访 Manus AI 的张涛。Manus 这个产品很多人听过：八个月做到 1 亿美元 ARR，几乎全部是有机增长。他们的核心架构叫「大脑与手」：大模型是大脑，Agent 需要一只手，他们就给每个 Agent 配一个虚拟机沙箱让它自己浏览、写代码、跑命令，更侧重输出完成任务，文本只是中间产物。张涛分享的最有意思的产品决策，是把 Agent 内部的过程做成「会话回放」给用户看。本以为透明会让用户怀疑，结果反而换来了信任。他对未来的判断：AI 之后，人的瓶颈从「解决问题」转向「定义问题」。
→ 阅读原文：https://www.bestblogs.dev/video/cf1fb78
第二场：Sequoia 访谈 Suno CEO Mikey Shulman。Suno 这个公司你即便不做音乐也值得听听他们的思路。他们的技术路线不走 12 平均律和 MIDI 那套西方音乐理论，把音乐建模成 48 kHz 采样的连续声波，相当于第一性原理重做音乐生成。这种做法让一些原本不存在的形态自然涌现，比如「带西塔琴的 trap」，比如微分音音乐。但他给的最反直觉的发现是：Suno 用户里有 90% 每天都在创作，消费占少数。AI 一边把「地板」抬高了（人人能做音乐），一边也把「天花板」抬高了（专业音乐人拿到了新工具）。
→ 阅读原文：https://www.bestblogs.dev/video/c6a585f
第三场：张小珺 4 小时对话姚顺宇。姚顺宇前后在 Anthropic 和 Google DeepMind 出任过研究科学家，参与过 Claude 3.7、4.5、Gemini 3 的训练。这场访谈直白到罕见，姚顺宇本人在物理学（非厄米系统、量子物理、高能物理）深耕九年后毅然转行 AI，自言「总想挑战一些自己不太会的事」。访谈里他几句话特别戳人：
「AI 个人英雄主义的时代已经过去了，所以也没有什么英雄，有时候甚至觉得旧时代英雄有点蠢。」 「现在大家都是冲浪的人，本质上是那个浪，冲浪的人反而没那么重要。」 「AI 这个事，本来也不太需要脑子。真的不太需要脑子。这个行业最重要的特质，就是靠谱，就是做事细，对自己做的事情负责任。」 「你不用太担心因为自己的观点而惹到什么人。只要你的观点是自洽的，不是说随便喷人，你是有一套自己的理解。最终你在这个领域做的怎样，是有客观评价标准的。大家是会尊重你的。」
4 小时的内容覆盖两个 Shunyu Yao（清华同一届的姚顺雨和姚顺宇）、Pre-train 没到头、Coding 爆发、字节豆包、机器人技术预测、AI 个人英雄主义的终结、集体主义胜利。在描述自己的研究时，姚顺宇又异常审慎：「我自己对那个事没那么重要，更多的是我很幸运，有机会在那个时候加入了一个重要的项目，做了一些事」。
我看完最大的感触是：新一代 AI 工程师的工作伦理变了，集体主义、靠谱、做事细正在取代个人天才主义。这场访谈是少数能从一线训练者口中拿到的真正内幕。
→ 阅读原文：https://www.bestblogs.dev/podcast/a4391a3
最后一个亮点，是 AI 在真实产业现场的两种姿态。
一种是李想这边的宏大愿景。罗永浩这周对话李想，理想汽车带来了全新旗舰 SUV L9 Livis。这车搭载理想自研的马赫 M100 芯片，算力达到 2560 TOPS，配的是全球首个完全体全线控底盘，还有 800V 主动悬架。这场访谈三个小时，李想本人完成了从汽车公司创始人到「AI + 具身智能公司」创始人的角色切换。
→ 阅读原文：https://www.bestblogs.dev/podcast/177bfb5
另一种姿态是 flomo 的少楠在腾讯研究院 AI 跃迁者调研里给出的真实困境。少楠是 11 年没写过代码的产品经理，现在每天用 Claude Code 在真实数据库里跑 3 个小时的需求验证，他公司 70-80% 代码已经由 AI 贡献，开发周期从按月变成按小时。但他给出了一个反直觉的观察：效率上去了，用户价值没跟上。
他的原话是：「以前工程师烦死产品经理觉得需求太多，现在是产品经理不好意思提需求了。」他还说了一句让我特别有共鸣的话：只有原来优秀的人变得更优秀了，因为 AI 无法回答一句话：『我不知道』。16 人团队的协作重构，比工具升级难得多。
→ 阅读原文：https://www.bestblogs.dev/article/6af09fd5
李想那条线是宏大愿景，flomo 这条线是真实困境，把这两条放在一起，可能比任何技术分析都更接近 AI 这一年的真实样子。
本周关键词 这周没有什么模型发布，但跟模型相关的工程化、组织化、产品化的答案，一次性给得特别多。下周我会重点关注国内厂商在 Agent 工程化的后续动作，看看这周的密度能不能延续。
20 篇文章的完整链接都在上方各章节里，如果哪一篇特别戳到你，建议直接读原文。
关于 BestBlogs BestBlogs.dev 是 AI 驱动的个性化高质量阅读工作流，「我的早报」 会基于你关注的源、阅读行为与兴趣画像，每天为你生成一份真正属于你的精选 brief，让你以最少的时间触达本周最值得读的内容。
完成新用户三步引导即送 7 天 Pro 试用；现有 Pro 用户每邀请 1 位朋友双方各得 7 天 Pro（单人上限 28 天）；5 月 9 日之前注册的老用户别错过 5 月 15 日至 5 月 31 日的 14 天 Pro 限时赠送，到 bestblogs.dev/promo 一键领取。
让高质量内容找到对的人。欢迎来体验，也欢迎推荐给身边热爱阅读的朋友。
ginobefun@hongming731 · X