Anthropic 的多智能体系统到底怎么做的？90% 性能提升背后的工程真相

📰 科技要闻

• 小鹏机器人步态调整专利公布：小鹏汽车公开了一项仿人机器人步态调整方法专利，涉及脚部目标采样点的动态控制，进一步加码具身智能布局。

• 美团 AI 底座战略：美团王莆中表示将建设"物理世界 AI 底座"，目标是让每个商家都能用上专属的 AI 助理，AI 与本地生活服务融合提速。

• 魅族手机转型：做车机还是做 AI：老牌手机品牌魅族宣布主机业务收缩，核心资源转向车机系统和 AI 产品方向，硬件厂商的 AI 转型分化加剧。

前段时间 Anthropic 发了一篇技术博客，标题叫《How we built our multi-agent research system》，讲的是他们 Claude.ai 上那个"深度研究"功能背后的完整工程实现。说实话，我反复看了两遍，越看越觉得这不像一篇公关软文，更像是他们内部复盘之后决定对外公开的工程总结——数据、坑点、权衡都写得挺真实。

其中有一个数据让我印象特别深：同样是 Claude Opus 4，多智能体系统比单智能体在复杂查询上的性能高出 90.2%。不是 10%，不是 20%，是 90%。这是什么概念？几乎是翻倍的效果。

这篇文章我就来把这套系统拆开来聊聊，重点不是"多智能体很厉害"的结论——大家都知道——而是它为什么厉害、代价是什么、工程上怎么做到的。

为什么单个 Agent 不够用

我们先想清楚一个前提：单 LLM 的上下文窗口是有上限的。Claude 现在是 200,000 tokens，看起来很大，但做一个"研究型任务"——比如让它帮你综合分析某个技术领域的现状、比较多篇论文、同时还要引用来源——这个窗口很快就会塞满。

更大的问题是：上下文窗口里塞越多东西，模型的注意力越分散，推理质量越差。这不是直觉，有很多研究都验证过"lost in the middle"问题。你把 200,000 tokens 全塞进去，模型对中间部分的关注度会显著下降。

Anthropic 的发现也印证了这点：他们发现，80% 的性能差异来自 Token 使用量。多智能体系统之所以效果好，核心机制不是什么魔法，就是：每个子智能体都有自己独立的、干净的上下文窗口，它只需要关注自己那一小块任务，注意力不分散，推理更准确。

多智能体 = 用空间换质量。代价是 Token 消耗约为普通对话的 15 倍，但对于复杂任务来说，这个代价是值得的。

编排者-执行者架构：没你想的那么简单

"编排者-执行者"（Orchestrator-Worker）这个模式本身不新鲜，分布式系统里早就这么玩了。Anthropic 的实现里有几个细节值得细看。

主导智能体（Lead Agent）做什么

主导智能体负责三件事：拆解任务、派发子智能体、汇总结果。但有一个很重要的细节：它会把自己的计划写入外部存储，不只是放在自己的上下文里。

为什么？因为 200,000 tokens 的窗口看着大，长任务跑下来也可能被截断。把计划落地到外部存储，就像给自己留了备忘录，即使上下文被截断，它也能"想起来"自己要做什么。这个设计挺有工程素养的，不是为了炫技，是防御性编程。

子智能体（Subagent）做什么

子智能体有点像"智能过滤器"——它不只是执行搜索，还要评估工具返回的结果质量，只把精炼后的信息返回给主导智能体。这样主导智能体的上下文里拿到的都是已经筛过的高质量信息，不会被垃圾数据污染。

子智能体通过 MCP（Model Context Protocol） 服务器访问外部工具。对，就是 Anthropic 自己推的那个 MCP 协议。这里用 MCP 主要是为了标准化工具调用接口，让不同类型的工具（搜索、数据库、代码执行）都能以统一方式被调用，也方便追踪和审计。

并行化：把时间压缩 90%

主导智能体会同时启动 3-5 个子智能体，每个子智能体里又会并行调用 3 个以上工具。这种双层并行让整个研究时间缩短了高达 90%。

我当时看到这个数字的时候有点不相信，但想想确实合理：如果串行跑 15 个工具调用，每个 2 秒，就是 30 秒。全并行的话理论上就是单个工具的时间。当然实际没有这么理想，但量级上的提升是真实的。

提示词工程：8条让我重新审视自己做法的原则

Anthropic 总结了 8 条提示词策略，这部分是整篇博客我觉得最有干货的地方。我挑几条我觉得最值得说的。

1. 模拟与内省：先跑一遍再优化

他们的做法是：通过控制台手动模拟智能体执行步骤，观察它在哪里"过度搜索"、在哪里"选错了工具"。听起来土，但这种土方法往往最有效。

我自己做 Agent 开发的时候也有过类似的体会：你不去手动跑一遍，根本不知道模型在某个节点会产生什么样的奇怪行为。特别是长链路的 Agent，中间某一步的偏差会被后续放大，等到最终输出才发现，根本不知道哪儿出了问题。

2. 根据复杂度动态扩展投入

提示词里嵌入"规模规则"：简单任务 1 个 Agent + 少量工具调用；复杂任务 10 个以上 Agent 协同。这个设计很有意思——不是一刀切地用最重的配置跑所有任务。

这对成本控制很关键。前面说了多智能体的 Token 消耗是普通对话的 15 倍，如果所有任务都按最重的配置跑，成本会爆掉。让模型自己根据任务复杂度决定"出动多少兵力"，是个务实的设计。

3. 先广度后深度

引导智能体先做短、广的查询，摸清楚整体格局，然后再逐步缩小范围做深度搜索。这其实是人类研究者的直觉，但很多 Agent 默认行为是一上来就死磕某个方向，容易钻进死胡同。

💡 工程启示：这条原则对任何搜索增强的 RAG 系统都适用。别上来就精确匹配，先用宽泛查询摸清数据分布，再做精准检索。

4. 用 Claude 自己来修提示词

这条有点递归的意思：他们用 Claude 4 来诊断 Agent 的失效模式，然后让它重写提示词或工具描述。结果是后续 Agent 的任务完成时间缩短了 40%。

说实话，我最开始对"用 LLM 优化 LLM 提示词"这件事是有点半信半疑的，感觉有点玄学。但 40% 这个数字让我开始认真对待这个方向了。提示词本质上是自然语言，而 LLM 对自然语言的理解和改写能力本来就是它的强项，用它来做提示词的迭代优化在逻辑上说得通。

评估：你以为的和实际的差距有多大

评估多智能体系统是一件比评估单模型要复杂得多的事情，主要原因是过程的非确定性。同一个查询，每次跑的子智能体路径可能不同，用的工具不同，最终结果也可能不同。

小样本起步，不要迷信大规模评估集

Anthropic 的做法是：初期只用约 20 个代表性查询做测试。他们的理由是：多智能体系统的改进效果通常很显著（比如成功率从 30% 跳到 80%），所以小样本就能给出有效反馈，不需要一开始就搞几千条测试集。

这个观点挺反直觉的，但有道理。大规模评估集的价值在于捕捉边缘 case 和细微的性能差异，在系统还很粗糙的阶段，用 20 条精心挑选的查询快速迭代，效率更高。先把大问题解决了，再去抠细节。

LLM-as-Judge 的正确使用方式

他们用 LLM 做自动评估，评分维度包括：事实准确性、引用精度、完整性、来源质量、工具效率。关键细节是：采用单一 LLM 调用给出 0-1 分及胜负判定，这比让多个模型投票或者分多次调用要稳定得多。

但他们也承认，自动评估有盲区：比如"Agent 会偏好 SEO 优化的网站，而不是权威学术来源"——这种偏差自动评估很难发现，需要人工来校验。这个坑不少人踩过，如果你的评估集本身也是由 LLM 生成的，很可能会形成"自我幻觉闭环"，评估结果看起来很好，实际质量却没提升。

生产环境的三个工程硬挑战

这部分是我觉得整篇博客最有价值的地方——聊的是把多智能体系统从 Demo 推向生产时踩的坑。

挑战一：状态管理和断点续传

Agent 任务运行时间长，动辄几分钟甚至更久。这期间工具可能失败、网络可能中断、模型可能超时。系统必须具备断点续传能力（Checkpoints），不能因为中间某一步失败就把整个任务重头跑。

而且 Anthropic 特别强调：利用模型智能来处理工具失效，而不是简单重启。意思是，工具调用失败了，不要直接 retry，让模型判断一下：这次失败是偶然的（网络问题，可以重试）还是系统性的（这个工具根本找不到结果，应该换另一个工具或者换个查询策略）？让模型参与这个判断，比写死的重试逻辑要健壮得多。

这让我想到 Android 里的 WorkManager——在后台任务的场景下，你也需要区分"暂时性失败"（网络抖动）和"永久性失败"（服务器 4xx），不能一套策略走天下。Agent 系统的错误处理哲学和这个类似。

挑战二：全链路追踪，追的是结构而不是内容

多智能体系统的调试很痛苦，因为问题往往不是报错，而是"逻辑上走偏了"。你问它一个问题，它花了 5 分钟，给你一个看起来有道理但实际上完全答非所问的结果。

Anthropic 的做法是：监控决策模式和交互结构，而不是对话内容本身。具体来说，就是看：主导智能体启动了几个子智能体？每个子智能体调用了哪些工具？调用顺序是什么？哪个环节花的时间最长？

这个思路很有意思——在不看内容的前提下，通过结构化的行为模式来诊断问题。这对于敏感数据场景尤其重要，因为你可能根本不能把对话内容打到日志里。

挑战三：彩虹部署（Rainbow Deployments）

这个概念我第一次看到是在这篇博客里，后来发现这名字是他们自己起的。问题的本质是：Agent 是长程运行的，一个任务可能跑 5 分钟、10 分钟。如果你这时候部署了新版本，正在跑的老版本 Agent 怎么处理？

他们的方案是：逐渐切换流量，老版本 Agent 跑完当前任务后自然退出，新流量全部打到新版本。不是强制切换，不是重启，是让老 Agent "善终"。这在分布式系统里叫 Graceful Shutdown，但应用到 Agent 场景需要额外处理：你需要知道每个 Agent 实例的状态，知道它何时完成任务，才能在正确时机退出。

从 RAG 到 Agentic Search：不只是加了几个工具

这套系统代表的是一种架构范式的转移，从传统的静态 RAG（一次检索 + 一次生成）转向动态、多步、有自我调节能力的自主搜索流程。

传统 RAG 的问题很明显：你把问题向量化，从向量库里捞几段相关内容，然后喂给模型生成答案。这在问题明确、文档齐全的场景下还凑合，但遇到"开放式研究任务"就不行了——因为你在提问的时候，根本不知道你需要什么信息，也不知道从哪里找。

Agentic Search 的逻辑是：先做探索性查询摸清领域，根据返回结果动态调整搜索策略，发现新的相关方向时递归深入，最终汇总成一个有引用的研究报告。整个过程是自适应的，不是预设好的流水线。

这是质的差异，不只是"加了几个工具调用"那么简单。

我的几点判断

说几个我自己的看法，不一定对，但这是我看完之后的真实想法：

• Token 成本是目前最大的制约：15 倍的 Token 消耗，在当前的模型定价下，多智能体系统只适合"高价值任务"。Anthropic 自己也说了这点。对于普通的问答场景，用单模型绰绰有余，别为了用 Agent 而用 Agent。

• 编排层的设计比模型能力更重要：在同等模型下，编排策略、提示词设计、任务拆解方式决定了系统最终的效果上限。这意味着"AI 工程师"这个岗位的核心竞争力不是懂某个模型，而是懂系统设计。

• 评估是最难啃的硬骨头：不管你的 Agent 系统设计得多漂亮，没有可靠的评估体系，你就是在盲目飞行。这件事做起来比写代码难多了，因为它需要领域知识、数据、和对"好答案"的清晰定义。

• MCP 正在成为事实标准：从这篇博客的描述来看，Anthropic 内部也在用 MCP 作为工具调用的标准接口。加上各大 IDE 和工具链都在接入 MCP，这个协议的生态正在快速形成。如果你在做任何 AI 工具集成的工作，现在了解 MCP 正是时候。

最后我还在想一个问题：这套架构对于 Android/移动端的 AI 应用场景有没有借鉴价值？毕竟端侧模型的上下文窗口更小，限制更多。如果端侧也能跑类似的多智能体协作——哪怕是本地 small model 做 Worker、云端 large model 做 Orchestrator 的混合模式——会是什么体验？这个方向我最近一直在想，下次有机会深聊。

如果这篇对你有帮助，欢迎转发给有需要的同学。 有不同意见或补充欢迎留言，技术问题没有标准答案。