BestBlogs 早报 · 06-07｜多智能体编排、MCP 接口设计、缓存命中率 · AI HOT
‹ 返回
ginobefun @hongming731 60
2026-06-07 07:43 ·8天前
AI 摘要 本期聚焦三大Agent工程议题：1）Emergent通过多智能体编排+定制容器，6个月实现1亿美元ARR，覆盖190国850万无编程背景用户；2）Chrome DevTools团队为MCP设计Agent接口，提出Token燃油效率、错误自愈、工具Schema设计和三层信任边界；3）OpenClacky创始人指出每个Agent功能都是一个缓存失效面，第一代RAG架构因90%召回率不足和嵌入成本高而失效。
智能体 MCP/工具 现象/趋势 编码
← 返回
ginobefun @hongming731 · X 60
2026-06-07 07:43 · 8天前
AI 摘要 本期聚焦三大Agent工程议题：1）Emergent通过多智能体编排+定制容器，6个月实现1亿美元ARR，覆盖190国850万无编程背景用户；2）Chrome DevTools团队为MCP设计Agent接口，提出Token燃油效率、错误自愈、工具Schema设计和三层信任边界；3）OpenClacky创始人指出每个Agent功能都是一个缓存失效面，第一代RAG架构因90%召回率不足和嵌入成本高而失效。
在正式对外发布之前，Emergent 投入 3 个月时间，专攻代码生成基准排行榜，最终登顶第一位。这并非为了排名本身，而是为了在融资和推广之前建立技术可信度。
> 「我们需要一个可验证的第三方信号，证明我们的系统是真实的。排行榜是我们能找到的最直接的证明方式。」
上线不到 9 个月，Emergent 达到 1 亿美元 ARR，覆盖 190 个国家、850 万用户，其中大多数是没有任何编程背景的普通用户，他们用 Emergent 构建可直接投入使用的商业应用。
Emergent 的故事揭示了一条在 AI 时代独特的增长路径：选择一个足够大的单点赌注（全部软件工程自动化），在底层技术上做出真正的工程创新（多智能体编排 + 定制容器），用可验证的第三方基准积累信任，最终撬动规模化的大众市场。这与传统 SaaS 的功能渐进式迭代路线截然不同。
对于今天思考「AI 能做什么」的工程师和创业者来说，这篇访谈提供的不只是一个成功案例，更是一套思考框架：不要问 AI 能辅助哪个环节，而是问 AI 能否一次性接管整个流程。
## 为智能体构建界面：Chrome DevTools 设计 MCP 工具的经验
Chrome DevTools 团队在为 MCP（Model Context Protocol）构建 Agent 接口时，踩过一个几乎所有人都会踩的坑：把 Agent 当成「自动化后端」来设计。
人类和 Agent 可能拥有完全相同的目标，比如诊断并修复一个有 bug 的网页。但它们的认知局限、处理习惯和交互需求截然不同。传统 UX 设计的核心原则是「减少摩擦」，但在 Agent 界面中，这条原则有时反而会制造安全漏洞。
团队最初尝试把标准的性能追踪日志直接传给 Agent。一份典型的性能分析报告包含超过 5 万行复杂 JSON，体积达数 MB。
结果显而易见：Agent 会立即耗尽上下文窗口，陷入所谓的「数据倾倒区（Dump Zone）」，完全失去有效处理能力。
解决方案是主动做信息过滤。Chrome DevTools for Agents 剔除了视觉布局需求和过于密集的文件，改为返回清晰的 Markdown 文件和语义摘要，只突出最关键的性能指标（如最大内容渲染时间 LCP）。让模型直接看到关键句子，而不是被迫阅读整本书。
团队引入了一个核心效率指标：「每次成功完成的 Token 消耗数（Tokens per Successful Outcome）」：
这个指标衡量 Agent 接口的「燃油效率」：功能完整性（有效性）与 Token 用量及调用时长（效率）之间的平衡。针对 Token 消耗，团队采用了三项优化措施：工具分类（将扩展调试等冷门操作从默认上下文中隐藏）、精简模式（仅暴露三个核心工具）、命令行管道化（让 Agent 在本地完成数据转换，而非占用模型上下文窗口）。
每次执行报错都会迫使 Agent 消耗额外 Token 进行诊断重试。解决思路是构建「描述性错误消息」，在错误信息中嵌入明确的上下文。例如，将一个导航失败错误更新为追加说明「未找到要导航的历史条目」，Agent 就能立即自主修复，无需人工干预。
将单体端点拆分为细粒度工具组合会引入发现问题。当 Agent 面对数十个微工具时，可能难以找到正确工具。团队的做法是把 API Schema 当作「LLM 的 UI」来精心设计，为每个工具标注精确的激活条件，明确说明何时调用、何时不调用。
这篇来自 Chrome DevTools 团队的一手经验，对今天所有在构建 MCP 工具或 Agent 接口的工程师都有直接价值：
- 不要把 Agent 当成「更快的人类」，它需要专为其认知模式设计的接口。
- Schema 质量直接影响 Agent 的调用成功率，文档写给 LLM 看，不是写给人看。
- 信息密度控制是 Token 经济学的核心，传得越多不等于 Agent 理解得越好。
- 安全边界在 Agent 场景下需要重新设计，传统「减少摩擦」的原则在此可能适得其反。
OpenClacky 创始人 Yafei Lee 在这篇文章开头给出了一个简洁但深刻的核心命题：
> 「每个 Agent 功能都是一个缓存失效面。技能加载新的系统上下文；子智能体工作流分叉前缀；浏览器自动化添加易变的工具输出；压缩重写历史；模型切换会碎片化缓存命名空间--如果你的缓存命中率远低于预期，这很可能就是原因。」
这不是一篇讲如何调用 LLM 的文章，也不是讲如何增加工具的文章。它讲的是：在一个功能不断迭代的 Agent 系统中，如何保持缓存前缀稳定。
第一代（2024 年至 2025 年初）：RAG 一切
第一代架构是教科书式的 RAG 系统：嵌入用户代码库、文档和对话历史到向量存储，每次查询经过混合检索、重排序和查询改写后再进入 LLM。
- 嵌入成本持续攀升，且数据始终是过时的。每次代码库更新都需要重新嵌入，实时同步不可靠，向量存储的索引一直落后于真实代码。
- 90% 的召回率远远不够。每 10 次检索就有 1 次返回错误上下文，对于多步骤链式 Agent 来说，错误会快速复合累积。团队估计，97% 的召回率可能才是 Agent 产生净正面价值的最低门槛。
最终结论：对于在本地代码库上工作的编码 Agent，彻底废弃 RAG，不用嵌入，不用向量数据库，不用检索流水线。需要上下文就直接读文件或用 grep 搜索。
第二代架构来自 SWEBench 排行榜的灵感：规划智能体 + 编码智能体 + 审查智能体 + 测试智能体，通过消息总线协调，每个智能体有专属提示词。
- 每次智能体切换都是缓存未命中。每个子智能体有自己的系统提示和缓存命名空间。在智能体之间传递上下文意味着将状态序列化为消息，而每次切换都会清空接收智能体的缓存前缀。
- 4 分钟任务变成了 14 分钟。协调开销是真实存在的：智能体相互等待，重新读取上一个智能体已处理的上下文，偶尔还会做出相互矛盾的决策。
- 成本高出 6 倍。四个独立的缓存命名空间、四套系统提示、持续的状态序列化。「让专家分工」的直觉在人类团队中有效，但不适用于 LLM--单个前沿模型本身已经是通才，拆分只是在乘以开销。
经历两代失败架构后，团队在第三代架构中总结出七项核心工程决策：
1. 双缓存标记（滚动双缓冲）：在系统提示和对话历史之间维护两个独立的缓存前缀，确保最稳定的部分始终被缓存。
2. 冻结系统提示：系统提示只包含静态内容，所有动态信息（当前文件状态、工具调用结果）都注入对话消息而非系统提示，保持系统提示前缀永远不变。
3. 单 meta-tool 收敛所有扩展能力：用一个统一的 meta-tool 封装所有扩展功能，而非暴露大量细粒度工具，避免工具列表变化导致缓存失效。
4. 固定 16 个工具稳定 schema：工具集固定在 16 个，不随功能迭代增减，保持工具 schema 的绝对稳定。
5. Insert-then-Compress 策略：先将所有历史完整插入上下文，再在后台压缩，把压缩事件的缓存命中率从 0% 拉到 95%。
6. 模型特定状态隔离：模型相关的状态绝不写入系统提示，保证切换模型时不会碎片化缓存命名空间。
7. 会话级缓存预热：在会话开始时主动预热最常用的上下文块，减少冷启动开销。
这篇文章与精讲一的 Emergent 和精讲二的 Chrome DevTools MCP 工具设计形成了一个完整的三角：Emergent 解决的是「如何编排多个 Agent 协同工作」，Chrome DevTools 解决的是「如何设计 Agent 能高效消费的接口」，而 OpenClacky 则深入到更底层，解决的是「Agent 系统在持续演进中如何保持经济可行性」。
对于今天在生产环境中运行 Agent 系统、发现成本失控或响应速度下降的工程师，这篇文章提供的不是理论框架，而是经过两代失败验证的具体工程决策。
1. OpenAI 推理模型如何破解 Erdős 80 年悬而未决的数学难题 阅读原文 →
OpenAI 推理团队成员 Alexander Wei、Hunging Wu 和 Lee J Chen 解释了 test-time compute 如何让通用模型推翻保罗·埃尔德什（Paul Erdős）于 1946 年提出的「单位距离猜想」，这是一个困扰离散几何领域近 80 年的核心开放问题。与传统大语言模型即时输出不同，推理模型会在给定的计算预算内「思考」：生成内部思维链、尝试不同求解策略、通过代码执行验证数学逻辑。菲尔兹奖得主蒂莫西·高尔斯（Timothy Gowers）评价，这项工作「具有划时代意义」，达到了顶级数学期刊《数学年刊》的录用水准。这次突破标志着 AI 在数学发现领域的质变：从辅助工具到能独立解决百年难题的研究系统。
2. 全球互联网上智能体流量已超越人类流量 阅读原文 →
SemiAnalysis 援引 Cloudflare Radar 数据称，全球范围内 HTML 网页的 AI 智能体流量已超过人类流量。这一数据点意义深远：互联网的主要消费者正在从人类切换为 AI Agent，这将对网站架构、内容策略乃至商业模式产生根本性影响。与精讲二中 Chrome DevTools 为 Agent 设计专属接口的讨论相互印证：专为 Agent 优化的 web 界面，将成为未来基础设施的重要组成部分。
AI 架构师 Mert 分析了前沿实验室从「预测下一个 token」到「预测世界的下一个状态」的范式转移。目前存在两个竞争方向：渲染像素（pixel prediction）vs 预测抽象状态（abstract state prediction）。世界模型是让 AI 真正理解物理世界、进行因果推理的关键，也是 Agent 从「执行指令」升级为「理解后果」的技术前提。
4. Context Engineering：从概念框架到工程实现 阅读原文 →
作者整合 Matt Pocock 的 Context Engineering 框架和 Michal Cichra 的 Loop 实现，提出完整的 Agent 上下文工程体系：ADR（架构决策记录）记录原因、PRD 记录功能、BDD 记录验证、Loop 强制执行。这与精讲三中 OpenClacky 的缓存工程决策形成互补：精讲三解决的是「如何让上下文保持稳定」，这里讲的是「如何组织上下文使 Agent 做出正确决策」。
5. SpaceX 与谷歌签署每月 9.2 亿美元的云服务协议 阅读原文 →
SpaceX 与谷歌签署了一项庞大的云服务协议，从 2026 年 10 月到 2029 年 6 月，每月支付约 9.2 亿美元，获得包括约 11 万块 NVIDIA GPU 在内的算力资源。这是近期最能说明 AI 基础设施军备竞赛烈度的单笔交易：马斯克旗下公司以近百亿年均规模押注谷歌云和 NVIDIA GPU，折射出大规模 AI 训练和推理对算力需求的量级。
6. DeepSeek V4 做数学证明，500 倍成本优势 阅读原文 →
普林斯顿大学团队提出 Goedel-Architect 框架，以 DeepSeek-V4-Flash 为核心模型，在 PutnamBench（672 道普特南大学生数学竞赛题）上实现形式化定理证明，通过率 75.6%，花费 294 美元。对比：谷歌 Gemini 2.5 Pro 驱动的 Hilbert 系统解同样测试集花费约 17 万美元，通过率 70%。约 500 倍的成本差异，配合更高的通过率，是本周最具震撼性的效率数据点。与速览第 1 条 OpenAI 推理模型破解 Erdős 猜想形成呼应：AI 正在从不同方向快速逼近数学研究的核心难度。
这篇文章通过多起真实案例，聚焦一个没有轻松答案的问题：当拥有 3 亿月活的国民级 AI 应用制造幻觉、误导用户时，谁来负责？河北李先生因信任豆包的退票建议损失 600 元，进而被 AI 引导起诉 AI，最终当然败诉，因为「AI 不具有民事主体资格，赔偿承诺不具法律效力」。文章揭示了三层系统性矛盾：拟人化设计（让用户过度信任）、流量分发（AI 可能被 GEO 优化），以及免责声明（法律零责任）之间的结构性张力。随着 AI 渗透率持续攀升，这个问题只会更难回避。
Legora 如何从 YC 走到 18 个月 1 亿美元 ARR 阅读原文 →
又一个 18 个月 1 亿美元 ARR 的故事，法律 AI 赛道。Legora 结合激进的企业销售、创始人主导的招聘和智能体工作流策略，甚至签下 Jude Law 拍摄品牌广告打破法律科技营销刻板印象。与精讲一 Emergent 对比阅读，看两种 B2C 和 B2B 路径的异同。
超越转录：构建真正理解对话的 Voice AI 阅读原文 →
Herve Bredin 解释了 pyannote 说话人分离模型如何让 Voice AI 从「识别说了什么」进化到「识别谁在何时说话」。对在构建会议记录、客服分析或多人语音 Agent 的工程师有直接参考价值。
AVGO 财报后分析：300 亿美元 AI 订单与 3 倍积压 阅读原文 →
Teng Yan 分析博通（Broadcom）财报：300 亿美元 AI 订单 vs 108 亿美元出货量，3 倍积压，可见度延伸至 2028 年。关注 AI 基础设施供应链的读者不可错过，可与 SpaceX-Google 云协议（速览第 5 条）一起阅读，构建算力市场的完整图景。
OpenClaw 的暗工厂：AI 编码智能体如何把发版速度推到读不完 Diff 阅读原文 →
Vincent Koc 分享 OpenClaw 如何以每天 3000 次提交的速度运转，把工程师变成「工厂管理者」。与精讲一 Emergent 的多智能体编排形成对照：一个是帮非技术用户构建应用，一个是帮工程师团队极速交付代码。
从树到流再回归：统一决策树与扩散模型 阅读原文 →
建立层次化决策树与扩散过程之间的数学对应关系，通过共享优化原则 GTSM（全局轨迹得分匹配）将两者统一。适合对机器学习理论感兴趣、希望理解「树与流」这两类模型背后共同数学结构的读者。
ABF 基板危机：隐藏的垄断与二阶危机 阅读原文 →
Teng Yan 揭示 ABF 基板短缺背后的二阶瓶颈：T 玻璃和微薄铜箔领域的近乎垄断，可能卡住 CoWoS 封装产能。AI 算力扩张的瓶颈往往藏在最不起眼的供应链环节，这篇是很好的案例。
Intel 18A 良率问题深度分析 阅读原文 →
对 Intel 内部人士关于 18A 制程良率问题评论的批判性分析，质疑其过去说法与当前进展之间的一致性。关注半导体代工格局的读者，可与 AVGO 分析一同阅读。
Builder 角色崛起：AI 正在将工程、产品、设计熔为一个角色 阅读原文 →
作者通过 Cursor 招聘 Design Engineers、Claude Design 画 SVG、OpenAI Sites 等信号，论证 AI 正在将工程、产品、设计三个传统角色熔合成「Builder」角色。与精讲一 Emergent 的「全部软件工程自动化」愿景形成有趣的角色层面呼应。
LessWrong 上一篇反直觉的 AI 安全思考：「可纠正的 AI」并非无条件的优点，可纠正性可能助长不良行为者，并制造心理不稳定的心智。适合对 AI 安全有深度兴趣、愿意认真考察主流假设的读者，带着批判性眼光阅读效果更佳。
编码 Agent 已经很强了，但对大型软件组织的实际影响，受到上下文管理、技术债务累积、协调开销和认知衰退等根本性瓶颈的制约。与精讲一 Emergent（乐观视角）和精讲三 OpenClacky（工程视角）一起读，构成对「软件工程自动化」这一命题更立体的认知。
1. 精讲三：每个 AI 智能体功能都是一个缓存失效面（链接）：如果你今天只能读一篇，读这篇。它把 Agent 工程中最隐蔽、最普遍的成本问题讲清楚了，七项工程决策可以直接用于生产环境排查。
1. 精讲二：为智能体构建界面--Chrome DevTools 设计 MCP 工具的经验（链接）：如果你在构建任何 MCP 工具或 Agent 调用的接口，这篇是目前为止最有一手价值的实践总结。Token 燃油效率、Schema 设计、信任边界三个框架，够用很久。
1. 精讲一：Emergent 破亿 ARR 的路径（链接）：作为战略视角的补充。Emergent 的故事不只是一个 ARR 数字，它是「AI 时代是否值得做颠覆式赌注」这一问题的一个真实样本。对比精讲三的工程保守主义，两种思路之间的张力本身就很值得思考。
ginobefun@hongming731 · X