# BestBlogs 早报 · 06-07|多智能体编排、MCP 接口设计、缓存命中率 - 来源：ginobefun (@hongming731) - 发布时间：2026-06-07 07:43 - AIHOT 分数：60 - AIHOT 链接：https://aihot.virxact.com/items/cmq30yv6j02x8sl97e7uoayeh - 原文链接：https://x.com/hongming731/status/2063406382964215864 ## AI 摘要 本期聚焦三大Agent工程议题：1）Emergent通过多智能体编排+定制容器，6个月实现1亿美元ARR，覆盖190国850万无编程背景用户；2）Chrome DevTools团队为MCP设计Agent接口，提出Token燃油效率、错误自愈、工具Schema设计和三层信任边界；3）OpenClacky创始人指出每个Agent功能都是一个缓存失效面，第一代RAG架构因90%召回率不足和嵌入成本高而失效。 ## 正文 http://x.com/i/article/2063404046279692288 # BestBlogs 早报 · 06-07|多智能体编排、MCP 接口设计、缓存命中率 在线阅读每日早报：https://www.bestblogs.dev/explore/brief/2026-06-07 ## 导语 欢迎阅读 BestBlogs 每日早报 EP80。 本期聚焦智能体时代的「工程底层」：一家从零出发、6 个月内靠多智能体编排拿到 1 亿美元 ARR 的公司，揭示了把「全部软件工程自动化」当作单一赌注的可行路径；Chrome DevTools 团队则在为 MCP 构建 Agent 接口的过程中，发现了 AI 协作界面设计与传统 UX 的本质裂缝。缓存失效、上下文窗口、工具 schema 稳定性，三篇文章指向同一个问题：Agent 系统的可靠性到底靠什么支撑。 今日速览：3 篇精讲深度内容、7 条快讯速览、10 条补充阅读，带你掌握智能体工程最新动态。 ## Emergent：六个月 AI 折腾，如何催生一家 1 亿美元 ARR 公司 阅读原文 → 从 Dunzo 到 Emergent：一次彻底的认知重建 Emergent 的故事，从一次失业开始。 在此之前，创始人 Mukun 在印度超本地配送独角兽 Dunzo 深耕多年。Dunzo 融资约 5 亿美元，拥有近百万合同骑手，每月处理超过 1000 万单配送，是一家骨子里由物流、运营和真实世界摩擦驱动的公司。2023 年底，Mukun 从 Dunzo 离职，陷入创始人特有的疲惫期。 他给自己放了半年假。这段时间里，他在笔记本上随意写代码，摸索早期的 GPT-4 和开源音频架构，没有目标，也没有压力。正是这种无结构的探索，给了他一个冷静的基线判断：当时大多数开发团队还在做「代码补全插件（Copilot）」，但指数级增长的深度学习模型意味着全系统自动化完全可行。 > 「我们持有一个非常宏观的判断：AI 能力将指数级增长，我们永远顺着 AI 的方向构建……要么一次性自动化全部软件工程，要么就别做。」 这个判断，对比「逐功能替换」的主流路线，是一个极其激进的单点押注。 技术底层：多智能体编排与定制容器 Emergent 的竞争对手大多从生成静态原型或前端 UI 入手，本质上是「演示软件」。Emergent 的目标更高：构建能直接被用户商业化的全栈应用。这要求他们走出「一个 Prompt 调一次 LLM」的简单模式，进入复杂的基础设施架构。 多智能体编排工作区 Emergent 协调多个专用自主 AI 智能体，包括设计智能体、代码生成智能体和自动化测试智能体。这些智能体通过一个多层分布式记忆网络同步工作区。平台上每个应用构建的成功组件，都会被抽象并索引回这个全局记忆核心，持续驱动平台迭代改进。 定制容器架构 由于多个 AI 实体需要动态交互源文件，同时不能互相覆盖执行状态，标准虚拟环境远远不够。团队为此设计了专有容器模式： - 状态快照：自建内存快照框架，支持对运行中的应用进程做即时分叉（fork）。 - 快照路由：设计磁盘快照阵列，允许不同评估智能体并发测试替代功能实现。 - 动态 RL 流水线：实现与实时执行输出挂钩的本地强化学习循环。 极端工程灵活性 为了跟上基础模型的跨越式升级（例如 Anthropic 的 Opus 级模型），Emergent 采用了一个反直觉的策略：主动删除稳定的生产组件，从零重建内部智能体框架。这一策略在不到 9 个月内导致了三次完整的平台架构重写。 登顶代码基准的 3 个月冲刺 在正式对外发布之前，Emergent 投入 3 个月时间，专攻代码生成基准排行榜，最终登顶第一位。这并非为了排名本身，而是为了在融资和推广之前建立技术可信度。 > 「我们需要一个可验证的第三方信号，证明我们的系统是真实的。排行榜是我们能找到的最直接的证明方式。」 结果与意义 上线不到 9 个月，Emergent 达到 1 亿美元 ARR，覆盖 190 个国家、850 万用户，其中大多数是没有任何编程背景的普通用户，他们用 Emergent 构建可直接投入使用的商业应用。 Emergent 的故事揭示了一条在 AI 时代独特的增长路径：选择一个足够大的单点赌注（全部软件工程自动化），在底层技术上做出真正的工程创新（多智能体编排 + 定制容器），用可验证的第三方基准积累信任，最终撬动规模化的大众市场。这与传统 SaaS 的功能渐进式迭代路线截然不同。 对于今天思考「AI 能做什么」的工程师和创业者来说，这篇访谈提供的不只是一个成功案例，更是一套思考框架：不要问 AI 能辅助哪个环节，而是问 AI 能否一次性接管整个流程。 ## 为智能体构建界面：Chrome DevTools 设计 MCP 工具的经验 阅读原文 → 核心问题：Agent 是一种全新的用户类型 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）。让模型直接看到关键句子，而不是被迫阅读整本书。 四个工程支柱 1. Token 燃油效率 团队引入了一个核心效率指标：「每次成功完成的 Token 消耗数（Tokens per Successful Outcome）」： 这个指标衡量 Agent 接口的「燃油效率」：功能完整性（有效性）与 Token 用量及调用时长（效率）之间的平衡。针对 Token 消耗，团队采用了三项优化措施：工具分类（将扩展调试等冷门操作从默认上下文中隐藏）、精简模式（仅暴露三个核心工具）、命令行管道化（让 Agent 在本地完成数据转换，而非占用模型上下文窗口）。 2. 错误自愈 每次执行报错都会迫使 Agent 消耗额外 Token 进行诊断重试。解决思路是构建「描述性错误消息」，在错误信息中嵌入明确的上下文。例如，将一个导航失败错误更新为追加说明「未找到要导航的历史条目」，Agent 就能立即自主修复，无需人工干预。 3. 工具可发现性与 Schema 设计 将单体端点拆分为细粒度工具组合会引入发现问题。当 Agent 面对数十个微工具时，可能难以找到正确工具。团队的做法是把 API Schema 当作「LLM 的 UI」来精心设计，为每个工具标注精确的激活条件，明确说明何时调用、何时不调用。 4. 三层信任边界 Agent 面对的信任边界不同于人类用户： - 本地环境：开发者自用工具，权限可以宽松。 - CI 环境：自动化流水线，需要受控权限。 - 公网环境：未知来源调用，需要严格沙箱。 对 Agent 工程的启示 这篇来自 Chrome DevTools 团队的一手经验，对今天所有在构建 MCP 工具或 Agent 接口的工程师都有直接价值： - 不要把 Agent 当成「更快的人类」，它需要专为其认知模式设计的接口。 - Schema 质量直接影响 Agent 的调用成功率，文档写给 LLM 看，不是写给人看。 - 信息密度控制是 Token 经济学的核心，传得越多不等于 Agent 理解得越好。 - 安全边界在 Agent 场景下需要重新设计，传统「减少摩擦」的原则在此可能适得其反。 ## 每个 AI 智能体功能都是一个缓存失效面 阅读原文 → 真正的架构问题 OpenClacky 创始人 Yafei Lee 在这篇文章开头给出了一个简洁但深刻的核心命题： > 「每个 Agent 功能都是一个缓存失效面。技能加载新的系统上下文；子智能体工作流分叉前缀；浏览器自动化添加易变的工具输出；压缩重写历史；模型切换会碎片化缓存命名空间--如果你的缓存命中率远低于预期，这很可能就是原因。」 这不是一篇讲如何调用 LLM 的文章，也不是讲如何增加工具的文章。它讲的是：在一个功能不断迭代的 Agent 系统中，如何保持缓存前缀稳定。 两代失败架构的完整复盘 第一代（2024 年至 2025 年初）：RAG 一切 第一代架构是教科书式的 RAG 系统：嵌入用户代码库、文档和对话历史到向量存储，每次查询经过混合检索、重排序和查询改写后再进入 LLM。 听起来合理，实际上问题重重： - 嵌入成本持续攀升，且数据始终是过时的。每次代码库更新都需要重新嵌入，实时同步不可靠，向量存储的索引一直落后于真实代码。 - 90% 的召回率远远不够。每 10 次检索就有 1 次返回错误上下文，对于多步骤链式 Agent 来说，错误会快速复合累积。团队估计，97% 的召回率可能才是 Agent 产生净正面价值的最低门槛。 最终结论：对于在本地代码库上工作的编码 Agent，彻底废弃 RAG，不用嵌入，不用向量数据库，不用检索流水线。需要上下文就直接读文件或用 grep 搜索。 第二代（2025 年中期）：多智能体编排 第二代架构来自 SWEBench 排行榜的灵感：规划智能体 + 编码智能体 + 审查智能体 + 测试智能体，通过消息总线协调，每个智能体有专属提示词。 SWEBench 分数还不错，产品体验却很糟糕： - 每次智能体切换都是缓存未命中。每个子智能体有自己的系统提示和缓存命名空间。在智能体之间传递上下文意味着将状态序列化为消息，而每次切换都会清空接收智能体的缓存前缀。 - 4 分钟任务变成了 14 分钟。协调开销是真实存在的：智能体相互等待，重新读取上一个智能体已处理的上下文，偶尔还会做出相互矛盾的决策。 - 成本高出 6 倍。四个独立的缓存命名空间、四套系统提示、持续的状态序列化。「让专家分工」的直觉在人类团队中有效，但不适用于 LLM--单个前沿模型本身已经是通才，拆分只是在乘以开销。 七项工程决策，实现 90%+ 缓存命中率 经历两代失败架构后，团队在第三代架构中总结出七项核心工程决策： 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 界面，将成为未来基础设施的重要组成部分。 3. AI 的下一阶段：世界模型 阅读原文 → 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 正在从不同方向快速逼近数学研究的核心难度。 7. 豆包不用负责 阅读原文 → 这篇文章通过多起真实案例，聚焦一个没有轻松答案的问题：当拥有 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 时代是否值得做颠覆式赌注」这一问题的一个真实样本。对比精讲三的工程保守主义，两种思路之间的张力本身就很值得思考。