BestBlogs早报·06-07｜Emergent多智能体编排破亿ARR，Chrome DevTools设计MCP工具，缓存失效面治理

一句话结论

Agent 系统的可靠性靠什么支撑，今天的精讲三篇给出三个互相咬合的答案：编排层（Emergent 多智能体协同加定制容器，六个月做到一亿美元 ARR）、接口层（Chrome DevTools 为 MCP 设计的四条工程支柱）、成本层（缓存命中率——OpenClacky 两代架构失败后总结的七项决策）。三者合读，覆盖 Agent 工程从编排、接口到经济性的完整底座。

导语

本期聚焦智能体时代的「工程底层」：一家从零出发、六个月内靠多智能体编排拿到一亿美元 ARR 的公司，揭示了把「全部软件工程自动化」当作单一赌注的可行路径；Chrome DevTools 团队在为 MCP 构建 Agent 接口的过程中，发现了 AI 协作界面设计与传统 UX 的本质裂缝。缓存失效、上下文窗口、工具 schema 稳定性，三篇文章指向同一个问题：Agent 系统的可靠性到底靠什么支撑。

今日速览：三篇精讲深度内容、七条快讯速览、十条补充阅读，带你掌握智能体工程最新动态。

精讲一：Emergent——六个月 AI 折腾，如何催生一家一亿美元 ARR 公司

Emergent 的故事，从一次失业开始。

在此之前，创始人 Mukun 在印度超本地配送独角兽 Dunzo 深耕多年。Dunzo 融资约五亿美元，拥有近百万合同骑手，每月处理超过一千万单配送，是一家骨子里由物流、运营和真实世界摩擦驱动的公司。2023 年底，Mukun 从 Dunzo 离职，陷入创始人特有的疲惫期。

他给自己放了半年假。这段时间里，他在笔记本上随意写代码，摸索早期的 GPT-4 和开源音频架构，没有目标，也没有压力。正是这种无结构的探索，给了他一个冷静的基线判断：当时大多数开发团队还在做「代码补全插件（Copilot）」，但指数级增长的深度学习模型意味着全系统自动化完全可行。

他的原话是：「我们持有一个非常宏观的判断——AI 能力将指数级增长，我们永远顺着 AI 的方向构建……要么一次性自动化全部软件工程，要么就别做。」这个判断，对比「逐功能替换」的主流路线，是一个极其激进的单点押注。

技术底层：多智能体编排与定制容器

Emergent 的竞争对手大多从生成静态原型或前端 UI 入手，本质上是「演示软件」。Emergent 的目标更高：构建能直接被用户商业化的全栈应用。这要求他们走出「一个提示词调一次大模型」的简单模式，进入复杂的基础设施架构。

多智能体编排工作区方面，Emergent 协调多个专用自主 AI 智能体，包括设计智能体、代码生成智能体和自动化测试智能体。这些智能体通过一个多层分布式记忆网络同步工作区。平台上每个应用构建的成功组件，都会被抽象并索引回这个全局记忆核心，持续驱动平台迭代改进。

定制容器架构方面，由于多个 AI 实体需要动态交互源文件，同时不能互相覆盖执行状态，标准虚拟环境远远不够。团队为此设计了专有容器模式：状态快照（自建内存快照框架，支持对运行中的应用进程做即时分叉）、快照路由（设计磁盘快照阵列，允许不同评估智能体并发测试替代功能实现）、动态强化学习流水线（实现与实时执行输出挂钩的本地强化学习循环）。

为了跟上基础模型的跨越式升级（例如 Anthropic 的 Opus 级模型），Emergent 采用了一个反直觉的策略：主动删除稳定的生产组件，从零重建内部智能体框架。这一策略在不到九个月内导致了三次完整的平台架构重写。

登顶代码基准的三个月冲刺

在正式对外发布之前，Emergent 投入三个月时间，专攻代码生成基准排行榜，最终登顶第一位。这并非为了排名本身，而是为了在融资和推广之前建立技术可信度——团队的原话是「我们需要一个可验证的第三方信号，证明我们的系统是真实的。排行榜是我们能找到的最直接的证明方式」。

结果与意义

上线不到九个月，Emergent 达到一亿美元 ARR，覆盖一百九十个国家、八百五十万用户，其中大多数是没有任何编程背景的普通用户，他们用 Emergent 构建可直接投入使用的商业应用。

Emergent 的故事揭示了一条在 AI 时代独特的增长路径：选择一个足够大的单点赌注（全部软件工程自动化），在底层技术上做出真正的工程创新（多智能体编排加定制容器），用可验证的第三方基准积累信任，最终撬动规模化的大众市场。对于今天思考「AI 能做什么」的工程师和创业者，这套框架的启示是：不要问 AI 能辅助哪个环节，而是问 AI 能否一次性接管整个流程。

精讲二：为智能体构建界面——Chrome DevTools 设计 MCP 工具的经验

Chrome DevTools 团队在为 MCP（模型上下文协议）构建 Agent 接口时，踩过一个几乎所有人都会踩的坑：把 Agent 当成「自动化后端」来设计。他们很快意识到，这个假设从根本上就是错的。

人类和 Agent 可能拥有完全相同的目标，比如诊断并修复一个有缺陷的网页。但它们的认知局限、处理习惯和交互需求截然不同。传统 UX 设计的核心原则是「减少摩擦」，但在 Agent 界面中，这条原则有时反而会制造安全漏洞。

「数据倾倒区」：上下文窗口的陷阱

团队最初尝试把标准的性能追踪日志直接传给 Agent。一份典型的性能分析报告包含超过五万行复杂 JSON，体积达数兆字节。结果显而易见：Agent 会立即耗尽上下文窗口，陷入所谓的「数据倾倒区」，完全失去有效处理能力。

解决方案是主动做信息过滤。Chrome DevTools for Agents 剔除了视觉布局需求和过于密集的文件，改为返回清晰的 Markdown 文件和语义摘要，只突出最关键的性能指标（如最大内容渲染时间 LCP）。让模型直接看到关键句子，而不是被迫阅读整本书。

四个工程支柱

第一根支柱是 Token 燃油效率。团队引入了一个核心效率指标——「每次成功完成的 Token 消耗数」：总 Token 使用量除以成功任务完成次数。这个指标衡量 Agent 接口的「燃油效率」：功能完整性与 Token 用量及调用时长之间的平衡。针对 Token 消耗，团队采用了三项优化措施：工具分类（将扩展调试等冷门操作从默认上下文中隐藏）、精简模式（仅暴露三个核心工具）、命令行管道化（让 Agent 在本地完成数据转换，而非占用模型上下文窗口）。

第二根支柱是错误自愈。每次执行报错都会迫使 Agent 消耗额外 Token 进行诊断重试。解决思路是构建「描述性错误消息」，在错误信息中嵌入明确的上下文。例如，将一个导航失败错误更新为追加说明「未找到要导航的历史条目」，Agent 就能立即自主修复，无需人工干预。

第三根支柱是工具可发现性与 Schema 设计。将单体端点拆分为细粒度工具组合会引入发现问题——当 Agent 面对数十个微工具时，可能难以找到正确工具。团队的做法是把 API Schema 当作「大模型的 UI」来精心设计，为每个工具标注精确的激活条件，明确说明何时调用、何时不调用。

第四根支柱是三层信任边界。Agent 面对的信任边界不同于人类用户：本地环境（开发者自用工具，权限可以宽松）、持续集成环境（自动化流水线，需要受控权限）、公网环境（未知来源调用，需要严格沙箱）。

对 Agent 工程的启示

这篇来自 Chrome DevTools 团队的一手经验，对所有在构建 MCP 工具或 Agent 接口的工程师都有直接价值：不要把 Agent 当成「更快的人类」，它需要专为其认知模式设计的接口；Schema 质量直接影响 Agent 的调用成功率，文档写给大模型看，不是写给人看；信息密度控制是 Token 经济学的核心，传得越多不等于 Agent 理解得越好；安全边界在 Agent 场景下需要重新设计，传统「减少摩擦」的原则在此可能适得其反。

精讲三：每个 AI 智能体功能都是一个缓存失效面

OpenClacky 创始人 Yafei Lee 在这篇文章开头给出了一个简洁但深刻的核心命题：「每个 Agent 功能都是一个缓存失效面。技能加载新的系统上下文；子智能体工作流分叉前缀；浏览器自动化添加易变的工具输出；压缩重写历史；模型切换会碎片化缓存命名空间——如果你的缓存命中率远低于预期，这很可能就是原因。」

这不是一篇讲如何调用大模型的文章，也不是讲如何增加工具的文章。它讲的是：在一个功能不断迭代的 Agent 系统中，如何保持缓存前缀稳定。

两代失败架构的完整复盘

第一代（2024 年至 2025 年初）是教科书式的 RAG 系统：嵌入用户代码库、文档和对话历史到向量存储，每次查询经过混合检索、重排序和查询改写后再进入大模型。听起来合理，实际上问题重重：嵌入成本持续攀升，且数据始终是过时的——每次代码库更新都需要重新嵌入，实时同步不可靠，向量存储的索引一直落后于真实代码；百分之九十的召回率远远不够——每十次检索就有一次返回错误上下文，对于多步骤链式 Agent 来说，错误会快速复合累积。团队估计，百分之九十七的召回率可能才是 Agent 产生净正面价值的最低门槛。最终结论：对于在本地代码库上工作的编码 Agent，彻底废弃 RAG——不用嵌入，不用向量数据库，不用检索流水线，需要上下文就直接读文件或用文本搜索。

第二代（2025 年中期）来自软件工程基准排行榜的灵感：规划智能体加编码智能体加审查智能体加测试智能体，通过消息总线协调，每个智能体有专属提示词。基准分数还不错，产品体验却很糟糕：每次智能体切换都是缓存未命中——每个子智能体有自己的系统提示和缓存命名空间，在智能体之间传递上下文意味着将状态序列化为消息，而每次切换都会清空接收智能体的缓存前缀；四分钟的任务变成了十四分钟——协调开销是真实存在的，智能体相互等待，重新读取上一个智能体已处理的上下文，偶尔还会做出相互矛盾的决策；成本高出六倍——四个独立的缓存命名空间、四套系统提示、持续的状态序列化。「让专家分工」的直觉在人类团队中有效，但不适用于大模型——单个前沿模型本身已经是通才，拆分只是在乘以开销。

七项工程决策，实现九成以上缓存命中率

经历两代失败架构后，团队在第三代架构中总结出七项核心工程决策：一是双缓存标记（滚动双缓冲），在系统提示和对话历史之间维护两个独立的缓存前缀，确保最稳定的部分始终被缓存；二是冻结系统提示，系统提示只包含静态内容，所有动态信息（当前文件状态、工具调用结果）都注入对话消息而非系统提示，保持系统提示前缀永远不变；三是用单个元工具收敛所有扩展能力，避免工具列表变化导致缓存失效；四是固定十六个工具的稳定 schema，不随功能迭代增减；五是「先插入再压缩」策略，先把所有历史完整插入上下文，再在后台压缩，把压缩事件的缓存命中率从零拉到百分之九十五；六是模型特定状态隔离，模型相关的状态绝不写入系统提示，保证切换模型时不会碎片化缓存命名空间；七是会话级缓存预热，在会话开始时主动预热最常用的上下文块，减少冷启动开销。

这篇文章与精讲一的 Emergent 和精讲二的 Chrome DevTools 形成了一个完整的三角：Emergent 解决的是「如何编排多个 Agent 协同工作」，Chrome DevTools 解决的是「如何设计 Agent 能高效消费的接口」，而 OpenClacky 则深入到更底层，解决的是「Agent 系统在持续演进中如何保持经济可行性」。对于在生产环境中运行 Agent 系统、发现成本失控或响应速度下降的工程师，这篇文章提供的不是理论框架，而是经过两代失败验证的具体工程决策。

速览

OpenAI 推理模型如何破解 Erdos 八十年悬而未决的数学难题 OpenAI 推理团队成员解释了测试时计算如何让通用模型推翻保罗·埃尔德什于 1946 年提出的「单位距离猜想」，这是一个困扰离散几何领域近八十年的核心开放问题。与传统大语言模型即时输出不同，推理模型会在给定的计算预算内「思考」：生成内部思维链、尝试不同求解策略、通过代码执行验证数学逻辑。菲尔兹奖得主蒂莫西·高尔斯评价，这项工作「具有划时代意义」，达到了顶级数学期刊的录用水准。这次突破标志着 AI 在数学发现领域的质变：从辅助工具到能独立解决百年难题的研究系统。

全球互联网上智能体流量已超越人类流量 这是一条值得每个做产品和增长的人记住的信号：网络流量结构正在发生代际更替，面向智能体的内容分发与面向人类的分发正在成为两条并行的赛道。

AI 的下一阶段：世界模型 关于世界模型作为大模型下一演进方向的系统性论述，适合关注模型技术路线的读者。

Context Engineering：从概念框架到工程实现 上下文工程从概念讨论走向工程落地的完整梳理，与今日精讲二的接口设计经验互为补充。

SpaceX 与谷歌签署每月 9.2 亿美元的云服务协议 SpaceX 与谷歌的算力合作细节：约十一万块英伟达 GPU，2026 年 10 月至 2029 年 6 月执行。可与补充阅读中的博通订单分析一起，拼出 AI 算力市场的完整图景。

DeepSeek V4 做数学证明，500 倍成本优势

普林斯顿大学团队提出 Goedel-Architect 框架，以 DeepSeek-V4-Flash 为核心模型，在 PutnamBench（672 道普特南大学生数学竞赛题）上实现形式化定理证明，通过率百分之七十五点六，花费二百九十四美元。对比：谷歌 Gemini 2.5 Pro 驱动的 Hilbert 系统解同样测试集花费约十七万美元，通过率百分之七十。约五百倍的成本差异，配合更高的通过率，是本周最具震撼性的效率数据点。与速览第一条 OpenAI 推理模型破解 Erdos 猜想形成呼应：AI 正在从不同方向快速逼近数学研究的核心难度。

豆包不用负责 关于智能体产品责任边界的一次讨论——当 AI 智能体开始执行真实任务，出错时谁来负责，这是 Agent 产品化绕不开的问题。

补充阅读

Legora 如何从 YC 走到 18 个月 1 亿美元 ARR 又一个十八个月一亿美元 ARR 的故事，法律 AI 赛道。Legora 结合激进的企业销售、创始人主导的招聘和智能体工作流策略。与精讲一 Emergent 对比阅读，看两种面向消费者和面向企业路径的异同。

超越转录：构建真正理解对话的 Voice AI pyannote 说话人分离模型如何让语音 AI 从「识别说了什么」进化到「识别谁在何时说话」。对在构建会议记录、客服分析或多人语音 Agent 的工程师有直接参考价值。

AVGO 财报后分析：300 亿美元 AI 订单与三倍积压 对博通财报的算力订单分析：三百亿美元 AI 订单对比一百零八亿美元出货量，三倍积压，可见度延伸至 2028 年。

OpenClaw 的暗工厂：AI 编码智能体如何把发版速度推到读不完 Diff OpenClaw 如何以每天三千次提交的速度运转，把工程师变成「工厂管理者」。与精讲一 Emergent 的多智能体编排形成对照：一个是帮非技术用户构建应用，一个是帮工程师团队极速交付代码。

从树到流再回归：统一决策树与扩散模型 建立层次化决策树与扩散过程之间的数学对应关系，通过共享优化原则将两者统一。适合对机器学习理论感兴趣的读者。

ABF 基板危机：隐藏的垄断与二阶危机 ABF 基板短缺背后的二阶瓶颈：T 玻璃和微薄铜箔领域的近乎垄断，可能卡住先进封装产能。AI 算力扩张的瓶颈往往藏在最不起眼的供应链环节。

Intel 18A 良率问题深度分析 对 Intel 内部人士关于 18A 制程良率问题评论的批判性分析，可与博通分析一同阅读。

Builder 角色崛起：AI 正在将工程、产品、设计熔为一个角色 通过 Cursor 招聘 Design Engineers、AI 设计工具画矢量图、AI 建站等信号，论证 AI 正在将工程、产品、设计三个传统角色熔合成「Builder」角色。

反对可纠正性 一篇反直觉的 AI 安全思考：「可纠正的 AI」并非无条件的优点，可纠正性可能助长不良行为者。适合对 AI 安全有深度兴趣的读者。

为什么软件自动化如此困难 编码 Agent 已经很强了，但对大型软件组织的实际影响，受到上下文管理、技术债务累积、协调开销和认知衰退等根本性瓶颈的制约。与精讲一（乐观视角）和精讲三（工程视角）一起读，构成对「软件工程自动化」这一命题更立体的认知。

今日阅读路径

时间有限？推荐优先读这三篇：

• 精讲三：每个 AI 智能体功能都是一个缓存失效面——如果你今天只能读一篇，读这篇。它把 Agent 工程中最隐蔽、最普遍的成本问题讲清楚了，七项工程决策可以直接用于生产环境排查。
• 精讲二：为智能体构建界面——Chrome DevTools 设计 MCP 工具的经验——如果你在构建任何 MCP 工具或 Agent 调用的接口，这篇是目前为止最有一手价值的实践总结。Token 燃油效率、Schema 设计、信任边界三个框架，够用很久。
• 精讲一：Emergent 破亿 ARR 的路径——作为战略视角的补充。它不只是一个 ARR 数字，而是「AI 时代是否值得做颠覆式赌注」这一问题的一个真实样本。对比精讲三的工程保守主义，两种思路之间的张力本身就很值得思考。

原文信息

原文地址：

• 作者：BestBlogs（@hongming731），BestBlogs.dev 主理人，AI 驱动内容精选服务
• 发布时间：2026-06-06
• 来源：X Article