深度解读《How we built our multi-agent research system》

渣渣苏

471人浏览 · 2026-05-23 19:51:36

渣渣苏 · 2026-05-23 19:51:36 发布

Anthropic 工程实录：多智能体研究系统的设计哲学与工程真相🔍

本文基于 Anthropic 官方工程博客《How we built our multi-agent research system》（2025年6月13日）深度解读，原文地址：anthropic.com/engineering/multi-agent-research-system

前言：一篇不同寻常的工程博客📝

AI 公司发布技术博客，大多是"我们做了什么，效果多好"的公关文案。Anthropic 这篇文章不同——它讲的是失败、权衡与真实的工程代价⚖️。

文章揭示了 Claude 的 Research 功能背后的多智能体架构🏗️，但更珍贵的是：它诚实地说出了这套系统哪里很难做、哪里仍有局限，以及从原型走向生产系统有多远的路🛣️。

这篇博客将带你逐层拆解原文的核心思想，提炼出对每个在做 AI Agent 系统的工程师都有价值的洞见💡。

一、为什么需要多智能体？—— 单 Agent 的天花板🚧

文章开篇就回答了一个根本问题：为什么不用一个强大的 Agent 搞定一切？

1.1 研究任务的本质是"路径依赖的探索"🗺️

<原文核心观点>
传统的 RAG（检索增强生成）是静态的：给定查询，取最相似的文档块，生成回答。但真正的研究不是这样工作的——它是动态的、自适应的🔄：每一个发现都可能改变下一步的方向。

单 Agent 面对这类任务有两个硬伤：

上下文窗口限制：复杂研究任务轻松超出 200k token 的上下文📊
串行搜索太慢：一条线索接一条线索地查，既低效又容易陷入局部最优⏳

多 Agent 的本质优势是压缩📦：子 Agent 各自在独立的上下文窗口中并行探索，将海量信息蒸馏为关键洞见，再汇聚给 Lead Agent。

1.2 那个 90.2% 的数字意味着什么📈

文章提到：以 Claude Opus 4 为 Lead Agent、Claude Sonnet 4 为子 Agent 的多智能体系统，在内部研究评测中比单 Agent Claude Opus 4 高出 90.2%。

这不只是一个漂亮数字。背后的分析更有价值：

在 BrowseComp 评测中，三个因素解释了 95% 的性能差异：

Token 用量：单独解释了 80% 的性能方差

工具调用次数🔧

模型选择🤖

结论：多智能体系统有效，根本原因是它能花更多 Token 解决问题。这是一个朴素但深刻的洞见——智能不是魔法，是计算资源的有效分配🖥️。

1.3 代价：Token 消耗的现实💰

文章很诚实地给出了数据：

Agent 模式 vs 普通对话：约 4 倍 Token 用量
多智能体 vs 普通对话：约 15 倍 Token 用量

这意味着多智能体系统的适用场景是有限的——任务价值必须足够高，才能匹配这份成本。

不适合多智能体的场景❌：

需要所有 Agent 共享同一上下文的任务（如大多数编码任务）
Agent 之间存在大量依赖关系、难以真正并行的任务

二、架构设计：Orchestrator-Worker 模式🎛️

2.1 三角色分工👥

系统由三类角色构成，职责清晰：

用户查询
    ↓
LeadResearcher（Lead Agent）
├── 分析查询，制定策略📋
├── 将策略存入 Memory（防止上下文截断时丢失计划）
├── 并行派发 N 个 Subagent
│   ├── Subagent 1：独立上下文 + 工具 + 探索路径
│   ├── Subagent 2：独立上下文 + 工具 + 探索路径
│   └── ...
├── 综合各 Subagent 结果，决定是否需要继续研究
└── 将完整发现传给 CitationAgent
    ↓
CitationAgent
└── 处理文档，精确定位引用来源📑
    ↓
最终报告（含完整引用）✅

2.2 Memory 的关键作用💾

一个容易忽视的设计细节：LeadResearcher 会在开始时将研究计划存入外部 Memory。

为什么？因为复杂研究任务可能产生超过 200k Token 的上下文，超出后会被截断。如果计划没有持久化，Agent 会"失忆"，从头开始探索。这个设计体现了工程的务实——在模型能力的边界处，用系统设计来弥补🛠️。

2.3 Interleaved Thinking：子 Agent 的内置"反思"🤔

子 Agent 在每次工具调用后使用 Interleaved Thinking——在收到工具结果后，先思考结果的质量、识别信息缺口、再决定下一步查询方向。这让每个子 Agent 不是机械执行查询，而是真正在"思考"自己的搜索策略。

三、Prompt 工程：八条血泪经验📜

这是文章最有价值的部分。Anthropic 团队总结了从失败中提炼的 8 条 Prompt 工程原则。

原则一：像你的 Agent 一样思考🧠

“要迭代 Prompt，必须先理解它的效果。”

团队在 Console 中构建仿真环境，使用与生产完全相同的 Prompt 和工具，逐步观察 Agent 的行为。这立刻暴露了典型失败模式：已有足够答案时继续搜索、使用过于冗长的搜索词、选择错误工具……

实践建议：构建可观测的 Agent 仿真环境是 Prompt 工程的前提，不是可选项🔬。

原则二：教 Orchestrator 如何委派📤

早期系统让 Lead Agent 给出简短指令，如"研究半导体短缺"——结果是子 Agent 之间大量重复工作，或者理解偏差。

解决方案：每个子 Agent 的任务描述必须包含：

明确目标🎯
输出格式📄
使用哪些工具/来源的指导
清晰的任务边界

反面教材：指令含糊时，三个子 Agent 可能分别研究"2021汽车芯片危机"和两次重复调查"2025供应链现状"，没有有效分工。

原则三：按查询复杂度伸缩资源📏

Agent 天然不擅长判断该为任务投入多少资源。Anthropic 的解法是在 Prompt 中内嵌缩放规则：

查询类型	Agent 数	工具调用次数
简单事实查找🔎	1	3-10
直接比较⚖️	2-4	10-15
复杂研究📚	10+	各自明确分工

原则四：工具设计与工具选择同等重要⚙️

Agent-工具接口和人机界面一样关键。

一个描述模糊的工具会把 Agent 引入歧途。团队专门构建了一个工具测试 Agent：给它一个有缺陷的 MCP 工具，让它尝试使用，然后重写工具描述以避免失败。通过数十次测试，这个 Agent 能发现关键细节和 Bug。

结果：使用新描述后，后续 Agent 的任务完成时间减少了 **40%**⏱️。

原则五：让 Agent 自我改进✨

Claude 4 模型可以当出色的 Prompt 工程师。给它一个 Prompt 和失败案例，它能诊断原因并提出改进。

这是一个递归的、优雅的设计：用 AI 改进 AI 的提示词🔁。

原则六：先宽后窄🔍

Expert 人类研究员的策略：先探索全貌，再深入细节。

Agent 的默认倾向是使用过于具体的长查询词，返回结果稀少。对策是明确提示 Agent 从短的、宽泛的查询开始，评估可用信息后再逐步收窄。

原则七：引导思考过程✍️

Extended Thinking 是可控的草稿纸。

Lead Agent 用 Extended Thinking 规划：评估哪些工具适合、判断查询复杂度、定义每个子 Agent 的角色。测试显示，Extended Thinking 显著改善了指令遵循、推理质量和效率。

原则八：并行工具调用改变游戏规则🚀

早期 Agent 是顺序执行搜索，慢且不够用。引入两层并行后：

Lead Agent 同时启动 3-5 个子 Agent
每个子 Agent 同时调用 3+ 个工具

结果：复杂查询的研究时间减少最多 90%。

四、评测的困境与解法📊

多智能体系统的评测比单 Agent 难得多——相同的输入，不同的运行可能走完全不同的路径，都是正确的。

4.1 小样本也要立刻开始评测📌

很多团队推迟建评测，认为"要有足够多的测试用例才值得"。Anthropic 的经验是：早期只需 20 个代表性查询就够了，因为这个阶段的改进效果往往非常显著（成功率从 30% 跳到 80%），用小样本完全可以看出来。

不要等待完美的评测体系，立刻开始🏃。

4.2 LLM-as-Judge 的正确用法⚖️

研究输出是自由文本，难以程序化评测。团队使用 LLM 评判，按照以下维度打分：

事实准确性✅
引用准确性📖
完整性📋
来源质量⭐
工具效率⚡

关键发现：多个 Judge 并不比单个精心设计的 Prompt更准确，反而单 Judge 输出 0-1 分数 + 通过/不通过的方式最稳定，与人工判断最一致。

4.3 人工测试发现自动化遗漏的问题👀

人工测试者发现了评测体系难以捕捉的问题：早期 Agent 系统性地偏向 SEO 优化的内容农场，而非学术 PDF 或专家博客等权威来源。在 Prompt 中加入来源质量启发式规则后，这个偏差得到修正。

五、生产可靠性：从原型到产品有多远🏭

这是文章最"接地气"的部分，直接讲了在生产中遇到的工程挑战。

5.1 状态性与错误的复合效应⚠️

Agent 是有状态的长期运行进程。一个小错误不是简单地让某个功能挂掉，而是可能让整个研究方向跑偏——Agent 此后的每一步都建立在错误的基础上。

解决方案：

构建可以从失败点恢复（而非重启）的系统🔄
利用模型的智能优雅处理错误（告知 Agent 工具失败，让它自行适应）
组合 AI 的自适应性与确定性的重试逻辑、定期 Checkpoint📍

5.2 调试非确定性系统🔎

用户报告"Agent 找不到明显的信息"——但工程师看不见内部发生了什么。是搜索词不好？来源选择差？工具失败？

解决方案：完整的生产 Tracing——但不是监控对话内容（隐私保护🔒），而是监控决策模式和交互结构。这种高层可观测性帮助诊断根本原因，而不侵犯用户隐私。

5.3 Rainbow Deployment🌈

Agent 系统几乎持续运行，随时可能有 Agent 处于执行过程中。部署新版本时不能强行切换所有 Agent。

解决方案：使用 Rainbow Deployment（彩虹部署）——新旧版本同时运行，流量逐渐从旧版迁移至新版，不中断正在运行的 Agent。

5.4 同步执行的瓶颈——未解的问题❓

当前系统中，Lead Agent 等待所有子 Agent 完成后才能继续。这个同步执行模型简单，但有明显瓶颈：整个系统被最慢的子 Agent 阻塞；Lead Agent 无法实时引导子 Agent；子 Agent 之间也无法协调。

异步执行会更好，但复杂度大幅上升——状态一致性、错误传播……Anthropic 坦言这个问题尚未完全解决，预期随着模型能力提升，性能收益会证明这份复杂度值得。

六、附录中的工程宝藏💎

文章附录包含三个值得单独展开的模式：

末态评测（End-state Evaluation）：对于会改变持久状态的 Agent，不要逐步评判执行过程，而是评判最终状态是否正确✅。将复杂工作流拆分为离散检查点，而非试图验证每一个中间步骤。

长周期对话管理：对于跨越数百轮对话的 Agent，在上下文接近上限时，让 Agent 总结已完成的工作阶段并存入外部 Memory，然后派生带有干净上下文的新子 Agent，通过精心的交接维持连续性🔗。

子 Agent 输出到文件系统：避免"电话游戏"（Telephone Game）中的信息失真📤——子 Agent 将结果直接写入外部存储，只向 Lead Agent 传递轻量引用，而非复制全部内容。这减少了 Token 开销，也保持了信息保真度。

七、最重要的元认知：原型与生产之间的鸿沟🌉

文章结尾有一段话，是整篇文章最值得反复读的部分：

“构建 AI Agent 时，最后一公里往往变成了整段旅程。在开发机上运行良好的代码库，需要大量工程才能成为可靠的生产系统。Agent 系统中错误的复合效应，意味着传统软件中的小问题可以完全让 Agent 脱轨。”

这不是悲观主义，而是一种专业诚实📐。多智能体系统的边界不在于模型能力，而在于系统设计、可观测性、错误恢复和运维实践。

总结：值得带走的核心洞见📌

多智能体的本质是 Token 的有效分配，不是神奇的涌现能力。80% 的性能差异由 Token 用量解释。
Prompt 工程不是写好一段文字，而是理解 Agent 的心智模型。要逐步观察 Agent，构建对其行为的准确预测。
工具设计和 Prompt 设计同等重要。一个描述不清的工具，会让 Agent 在错误的方向上越跑越远。
立刻开始小规模评测，不要等待完美的评测体系。早期的大效果改进，20 个测试用例就能看见。
生产可靠性需要专门的工程投入：状态管理、错误恢复、Rainbow Deployment、可观测性——每一项都是独立的工程挑战。
多智能体不是万能药💊。有大量 Agent 间依赖关系的任务（如大多数编码任务）并不适合这个架构。适合的是高价值、高度可并行、信息量超出单上下文窗口的任务。