企业技术博客通常只报喜。Anthropic 在 2025 年 6 月发的这篇多智能体系统复盘，先报了喜：让 Claude Opus 4 当主管、多个 Sonnet 4 当工人的架构，在内部研究评估上比单个 Opus 4 高出 90.2%。然后它做了一件少见的事，亲手把这个数字拆穿：性能方差的 80% 由 token 用量单独解释。翻译成人话，多智能体没什么魔法，它主要是一种把"多花 token"组织起来的方式。账单也直说了，普通聊天的约 15 倍。
架构本身不复杂。用户提问后，主管智能体先制定策略，把计划存进外部记忆，再派出多个子智能体，各自带着独立的上下文窗口并行去搜，最后由一个专职的引用核对智能体给每条论断找出处。适用边界文中划得很清楚：任务能高度并行、信息量超出单个上下文窗口、值得烧这份钱的，才上；子任务强耦合、需要共享同一份上下文的不适合，当时还特意点名了大多数编码任务。
对写代码的人，文中八条提示工程经验里我挑两条印象最深的。一是分活质量决定系统上限，他们观察到三个子智能体重复调查同一件事的失败案例，归纳出派任务必须写清四要素：目标、输出格式、工具指引、边界。二是工具描述值得当接口工程来做，让智能体自己试用工具再重写工具说明，任务完成时间降了 40%。评估那节也很解渴：别评它走了哪条路，评它到没到终点；20 条代表性用例就能起步，好过攒几百条永远不开始。生产章节干脆全用分布式系统的老词汇在写，检查点恢复、全链路追踪、彩虹部署，立场藏在用词里：智能体系统首先是分布式系统，其次才是 AI。
自曝短板让剩下的主张升值，这是这篇博客给我的第一层触动。第二层是它没做的那个实验。既然 token 用量解释了 80% 的方差，最关键的对照组应该是"单智能体加等量 token 预算"，比如让一个智能体搜更多轮、用更长上下文，文章没有公布这组数据。后来学界补了刀，有研究发现等预算下单智能体在多跳推理任务上未必输。90.2% 这个被引用最多的数字，恰好是全文唯一无法外部验证的数字，引用时得打个引号。
同期还有一场好看的对垒。Devin 的开发商 Cognition 发了篇立场相反的文章，主张别建多智能体，理由是子智能体之间没法充分共享上下文，各自拿着不完整信息做的决策会互相打架。两篇后来成了 agent 架构讨论的标准正反教材，行业慢慢调和出的共识是：读密集、可并行的任务适合多智能体，写密集、强一致的任务适合单智能体。有趣的是这条线和 Anthropic 自己划的边界基本重合，连"编码不适合"的判断松动的方式都被说中了，年底各家把子智能体引进编码流程时，用的正是读操作并行、写操作收敛到主干的折中。
我的收口是一笔账：上多智能体之前，先确认收益来自架构，别只是来自算力堆量；预算里给追踪和回放留出工程量，它们不是可选项。原型到生产的距离占了旅程的大半，这句话放在整个 agent 领域都成立。
原文: How we built our multi-agent research system, 作者 Anthropic, 发布于 2025-06