夜雨聆风来源：Anthropic Engineering原文：How we built our multi-agent research system发布时间：2025-06-13
简介
这篇文章讲的是 Claude Research 背后的多 Agent 系统（关注公众号，回复”agent“，获取完整原文文档）。
它不是在讲一个抽象框架，而是在讲 Anthropic 把一个多 Agent 研究产品从 prototype 做到 production 时遇到的真实工程问题：怎样分工、怎样调度、怎样设计工具、怎样做 prompt、怎样评估、怎样恢复错误、怎样部署一个长时间运行且状态不断变化的 agent 系统。
Research 为什么适合多 Agent
Claude 的 Research 功能可以跨网页、Google Workspace 和其他集成工具搜索信息，用来完成复杂研究任务。
这里的“多 Agent 系统”，指的是多个 LLM Agent 一起工作。每个 Agent 都可以在循环中自主使用工具。Claude Research 里的核心结构是：一个主 Agent 根据用户问题规划研究过程，再调用工具创建多个并行 Agent，让它们同时搜索不同方向的信息。
这种系统比单 Agent 多了几个新问题：
• Agent 之间怎样协调。 • 怎样评估不同 Agent 的结果。 • 系统怎样保持可靠。 • 出错之后怎样恢复，而不是直接从头再来。
研究任务天然是开放式的，很难提前写死步骤。
比如一个研究问题一开始看起来是在问公司名单，搜索过程中可能发现子行业、时间范围、数据源质量、定义口径都需要调整。人做研究时也是这样：先看大方向，再根据新发现不断修正路径。
线性的一次性流程不适合这类任务。
多 Agent 更适合，因为它可以把一个大问题拆成多个方向，每个 subagent 用自己的上下文窗口独立探索，再把压缩后的重要信息交回 lead agent。
原文有一句很关键的话：搜索的本质是压缩。
这里的意思是，搜索不是把所有网页都塞进上下文，而是从庞大语料里提炼出最有用的信息。Subagent 的价值就在这里：
• 它们可以并行探索不同方面。 • 每个 subagent 有自己的 context window。 • 每个 subagent 可以有不同工具、prompt 和探索路径。 • 它们最后把最重要的信息压缩给 lead agent。
这样可以减少路径依赖。单 Agent 如果一开始走错方向，后续搜索会被前面的判断带偏。多个 subagent 分头探索，可以增加独立性。
多 Agent 的收益和代价
Anthropic 的内部评估显示，多 Agent Research 系统特别适合 breadth-first queries，也就是需要同时追多个独立方向的广度型问题。
他们使用 Claude Opus 4 做 lead agent，Claude Sonnet 4 做 subagents。这个多 Agent 系统在内部 research eval 上，比单 Agent Claude Opus 4 高出 90.2%。
文章举了一个例子：识别 S&P 500 信息技术公司里的所有董事会成员。
多 Agent 系统可以把问题拆给多个 subagent 分头查找；单 Agent 则需要顺序搜索，速度慢，也更容易失败。
Anthropic 还分析了 BrowseComp 评测。BrowseComp 测的是浏览型 Agent 找到难找信息的能力。他们发现，三个因素解释了 95% 的性能差异：
1. token 使用量。 2. 工具调用次数。 3. 模型选择。
其中，仅 token 使用量就解释了 80% 的差异。
这说明一个很现实的点：多 Agent 系统之所以有效，很大一部分原因是它能为问题“花更多有效 token”。
每个 subagent 都有独立上下文窗口。把工作拆出去，本质上是在增加并行推理容量。模型升级也很重要。Anthropic 发现，把 Claude Sonnet 3.7 升到 Claude Sonnet 4 带来的收益，比把 token budget 翻倍还大。
但这不是免费午餐。
他们的数据里，普通 Agent 通常比聊天多用约 4 倍 token；多 Agent 系统比聊天多用约 15 倍 token。
所以，多 Agent 只有在任务价值足够高时才经济合理。它不适合所有任务。
文章明确说，有些领域现在并不适合多 Agent：
• 所有 Agent 必须共享同一上下文的任务。 • Agent 之间有大量强依赖关系的任务。 • 大多数编码任务，因为真正能并行的部分比研究少。 • 需要 Agent 实时高质量协调和委派的任务，因为当前 LLM Agent 还不擅长这一点。
Anthropic 的经验是，多 Agent 更适合这类任务：
• 可以高度并行。 • 信息量超过单个上下文窗口。 • 需要连接许多复杂工具。 • 单 Agent 顺序探索会太慢或太窄。
Research 的架构：orchestrator-worker
Claude Research 使用的是 orchestrator-worker 模式。
Lead agent 是 orchestrator，也就是协调者。它分析用户问题，制定研究策略，然后创建多个专门的 subagents，让它们并行搜索不同方面。
Subagents 是 workers。它们像智能过滤器一样，用搜索工具、MCP 工具和自己的上下文窗口去探索信息，再把结果返回给 lead agent。
这个结构和传统 RAG 很不一样。
传统 RAG 更像静态检索：给定一个输入问题，系统取回一组最相似的 chunks，再用这些 chunks 生成答案。
Claude Research 的架构是多步搜索：
1. 根据用户问题制定策略。 2. 创建 LeadResearcher。 3. LeadResearcher 先思考研究方法，并把计划保存到 Memory。 4. 创建多个专门 subagent。 5. Subagents 分别执行搜索。 6. Subagents 在拿到工具结果后继续思考，判断质量、缺口和下一步。 7. Subagents 把发现返回给 LeadResearcher。 8. LeadResearcher 综合结果，判断是否还需要继续研究。 9. 如果需要，就创建更多 subagents 或调整策略。 10. 信息足够后，进入 CitationAgent。 11. CitationAgent 处理文档和研究报告，找到具体引用位置。 12. 最终把带引用的研究结果返回给用户。
这里 Memory 很重要。因为上下文窗口超过 200,000 tokens 时可能会被截断，所以研究计划需要保存到外部 Memory，避免长任务中丢失关键上下文。
CitationAgent 也很重要。Research 不是只要写出一段看起来合理的回答，而是要把主张和来源绑定起来。CitationAgent 专门负责给报告里的 claims 找到对应来源位置。
Prompt engineering：多 Agent 系统的主要调节杆
多 Agent 和单 Agent 最大的区别之一，是协调复杂度增长很快。
Anthropic 早期系统里出现过这些问题：
• 简单问题也创建 50 个 subagents。 • 为了不存在的来源在网页里无止境搜索。 • Agent 之间用过多状态更新互相干扰。 • Subagents 任务描述太模糊，导致重复搜索。 • Lead agent 不知道什么时候应该停。
因为每个 Agent 都由 prompt 驱动，所以 prompt engineering 是他们改善行为的主要手段。
1. 像你的 Agent 一样思考
要改 prompt，必须先理解 prompt 对 Agent 行为的实际影响。
Anthropic 用 Console 搭了模拟环境，使用和生产系统相同的 prompts 和 tools，逐步观察 Agent 工作。
这个过程马上暴露了很多失败模式：
• 已经有足够结果了，Agent 还继续搜索。 • 搜索 query 太长、太具体，导致结果很少。 • 选错工具。 • 对任务复杂度判断错误。
只有建立起对 Agent 的准确心智模型，才知道改哪里最有效。
2. 教会 orchestrator 怎样委派
Lead agent 要把用户问题拆成子任务，再描述给 subagents。
每个 subagent 的任务说明需要包含：
• objective：目标是什么。 • output format：输出格式是什么。 • tools and sources：应该用哪些工具和来源。 • task boundaries：边界在哪里，不要做什么。
如果说明太短，subagents 就会重复工作、漏掉关键方面，或者误解任务。
文章举了一个例子。早期系统允许 lead agent 给出很短的指令，比如“research the semiconductor shortage”。结果一个 subagent 去研究 2021 年汽车芯片危机，另外两个 subagents 又重复查 2025 年供应链。分工没有建立起来。
后来他们把委派说明写得更具体，让不同 subagent 有清楚边界。
3. 按问题复杂度分配 effort
Agent 不擅长自己判断任务该投入多少资源。
所以 Anthropic 把 effort scaling 规则写进 prompt：
• 简单事实查找：1 个 Agent，3 到 10 次工具调用。 • 直接比较类问题：2 到 4 个 subagents，每个 10 到 15 次调用。 • 复杂研究：超过 10 个 subagents，并且职责要明确拆开。
这些规则可以防止简单问题过度投入，也能让复杂问题拿到足够资源。
4. 工具设计和工具选择很关键
Agent-tool interface 和 human-computer interface 一样重要。
工具选错了，Agent 再聪明也会失败。比如需要 Slack 里的上下文，却让 Agent 去网页搜索，它一开始就走错了。
MCP 让模型能接入更多外部工具，但也会放大这个问题，因为 Agent 会遇到很多从未见过的工具，而工具描述质量参差不齐。
Anthropic 给 Agent 写了显式启发式规则：
• 先检查所有可用工具。 • 根据用户意图匹配工具。 • 广泛外部探索时用 web search。 • 有专门工具时优先用专门工具，而不是泛用工具。
坏的工具描述会把 Agent 带到完全错误的路径上。所以每个工具都需要清晰目的和明确描述。
5. 让 Agent 改进自己
Claude 4 模型可以做很好的 prompt engineering。
Anthropic 发现，当给 Claude 一个 prompt 和一个失败模式时，它能诊断 Agent 为什么失败，并提出改进建议。
他们甚至创建了一个 tool-testing agent。它拿到一个有问题的 MCP 工具后，会尝试使用工具，再改写工具描述，避免后续 Agent 失败。
这个 agent 会测试工具几十次，找出细节和 bug。
结果是，未来 Agent 使用新描述完成任务的时间减少了 40%。原因不是工具本身变了，而是工具的人机界面变清楚了。
6. 先宽后窄
搜索策略应该接近专家研究方式：先看全局，再深入细节。
Agent 经常默认写很长、很具体的查询，结果反而少。
Anthropic 通过 prompt 让 Agent：
1. 先用短而宽的 query。 2. 看看信息空间里有什么。 3. 再逐步收窄焦点。
这比一上来就写一个过度精确的搜索句更稳定。
7. 引导 thinking process
Extended thinking mode 可以作为可控 scratchpad。
Lead agent 用 thinking 来规划方法，包括：
• 哪些工具适合这个任务。 • 查询复杂度是多少。 • 需要多少 subagents。 • 每个 subagent 承担什么角色。
测试显示，extended thinking 改善了 instruction-following、reasoning 和 efficiency。
Subagents 也会先规划，然后在工具结果之后使用 interleaved thinking，评估结果质量、识别缺口、调整下一次搜索。
这让 subagent 能随着任务进展不断适应。
8. 并行工具调用改变速度和性能
复杂研究任务往往要探索很多来源。
早期 Agent 顺序执行搜索，非常慢。
Anthropic 加了两层并行：
1. Lead agent 同时创建 3 到 5 个 subagents，而不是串行创建。 2. Subagents 自己也并行调用 3 个以上工具。
这些改动让复杂查询的研究时间最多减少 90%。Research 可以在几分钟里完成原本要几小时的工作，同时覆盖更多信息。
总的来说，Anthropic 的 prompting 不是写死规则，而是灌入好的启发式方法。它们研究熟练人类怎样做研究，再把这些策略写进 prompt：
• 把难问题拆成小任务。 • 认真评估来源质量。 • 根据新信息调整搜索。 • 判断什么时候应该做 depth，什么时候应该做 breadth。
同时，他们也设置 guardrails，防止 Agent 失控，并保持快速迭代、可观察性和测试用例。
怎样评估多 Agent 系统
可靠的 AI 应用离不开 eval，多 Agent 也一样。
但多 Agent 的评估更难。
传统 eval 往往假设系统会用同样步骤解决问题：输入 X，系统走路径 Y，得到输出 Z。
多 Agent 系统不是这样。
同一个问题，两次运行可能都有效，但路径完全不同。一次可能查 3 个来源，一次可能查 10 个来源；工具选择也可能不同。
所以评估重点不能只看“有没有走预设路径”，而要看：
• 最终结果是否达成目标。 • 过程是否合理。 • 来源是否可靠。 • 工具使用是否有效率。
从小样本立刻开始评估
Anthropic 建议：Agent 开发早期就开始 eval，不要等大规模测试集准备好。
早期改动通常影响很大。一个 prompt tweak 可能把成功率从 30% 提到 80%。这种大效果，用少量样本就能看出来。
他们一开始用了约 20 个真实使用模式的问题。经常只用这些问题，就能清楚看到改动效果。
很多团队会推迟 eval，因为觉得只有几百个测试用例才有意义。Anthropic 的经验相反：先用少量真实例子快速跑起来，比等待完美 eval 更好。
LLM-as-judge 可以扩展，但要有 rubric
Research 输出是自由文本，很难程序化评估，而且通常没有唯一正确答案。
所以 LLM judge 很适合这类任务。
Anthropic 用一个 rubric 评估输出：
• factual accuracy：事实是否和来源一致。 • citation accuracy：引用来源是否支撑对应 claim。 • completeness：用户要求的方面是否覆盖。 • source quality：是否优先使用一手来源，而不是低质量二手来源。 • tool efficiency：是否使用了合适工具，调用次数是否合理。
他们试过多个 judge 评估不同组件，但最后发现：单个 LLM call、单个 prompt、输出 0.0 到 1.0 分数和 pass/fail，最稳定，也最贴近人类判断。
当测试问题有明确答案时，这种方法尤其有效。比如问题是“是否准确列出研发预算最高的 3 家药企”，LLM judge 可以直接判断答案对不对。
LLM judge 让他们可以评估数百个输出。
人工评估仍然必要
自动化 eval 覆盖不了所有边角。
人工测试发现过这些问题：
• 特殊问题上产生幻觉答案。 • 系统级失败。 • 来源选择偏差。
一个具体例子是，早期 Agent 经常选择 SEO 优化过的内容农场，而不是排名较低但更权威的学术 PDF 或个人博客。
后来 Anthropic 把 source quality heuristics 加进 prompt，改善了这个问题。
即使有自动化评估，手工测试仍然必要。
多 Agent 有涌现行为
多 Agent 系统会出现不是直接写进代码的行为。
例如，lead agent 的一个小改动，可能会以不可预测的方式改变 subagents 行为。
所以评估不能只看单个 Agent，要看 Agent 之间的交互模式。
好的 prompt 不只是严格指令，而是协作框架。它要定义：
• 分工方式。 • 解决问题的方法。 • effort budget。 • 什么时候继续。 • 什么时候停止。
做好这一点依赖 prompt、工具设计、启发式规则、可观察性和快速反馈循环。
生产可靠性和工程挑战
传统软件里，一个 bug 可能破坏一个功能，或者造成性能下降。
Agentic system 里，小变化可能级联成大行为变化。因为 Agent 会长期运行，持续维护状态，并且每一步错误都会影响后续路径。
Agent 是有状态的，错误会累积
Agent 会跨很多工具调用保持状态。
所以系统需要 durable execution，也就是能可靠执行并在中途出错时恢复。
如果没有恢复机制，一个小系统故障可能让 Agent 全部失败。直接从头重启也不现实，因为重启代价高，用户体验差。
Anthropic 的做法是：让系统能从 Agent 出错的位置继续。
他们也会利用模型智能处理问题。比如告诉 Agent 某个工具正在失败，让它自己调整策略。这出乎意料地有效。
同时，他们也用确定性保护措施，比如 retry logic 和 regular checkpoints。
Debugging 需要新方法
Agent 会动态决策，即使相同 prompt，两次运行也可能不一样。
这让 debug 更难。
用户可能报告“Agent 找不到明显信息”，但工程师不知道原因：
• 是搜索 query 写得差吗？ • 是来源选得不好吗？ • 是工具失败了吗？ • 是 subagent 分工不对吗？
Anthropic 加了完整生产 tracing，才能系统地诊断失败。
除了标准可观察性，他们还监控 Agent 的 decision patterns 和 interaction structures。为了保护用户隐私，他们不监控单个对话内容，而是看高层行为结构。
这种可观察性帮助他们找到根因、发现意外行为、修复常见失败。
部署需要谨慎协调
Agent 系统是高度有状态的 prompts、tools 和执行逻辑网络，而且几乎一直在运行。
这意味着发布更新时，某些 Agent 可能正在流程中的任何位置。
一个善意代码改动，可能破坏正在运行的 Agent。
Anthropic 不能把所有 Agent 同时切到新版本。他们使用 rainbow deployments：新旧版本同时运行，逐步把流量从旧版本切到新版本，避免打断运行中的 Agent。
同步执行会造成瓶颈
当前系统里，lead agents 同步执行 subagents。也就是说，lead agent 会等待一组 subagents 完成，再继续下一步。
这样协调更简单，但会造成信息流瓶颈：
• lead agent 不能在 subagent 执行中途继续指导。 • subagents 之间不能协调。 • 如果一个 subagent 搜索很慢，整个系统会被卡住。
异步执行可以带来更多并行能力：多个 Agent 同时工作，并在需要时创建新的 subagents。
但异步也更复杂：
• 结果协调更难。 • 状态一致性更难。 • 错误传播更难处理。
Anthropic 的判断是，随着模型能处理更长、更复杂的研究任务，异步执行带来的性能收益会逐渐值得这份复杂度。
附录：更多多 Agent 系统建议
原文附录给了几个额外建议。
1. 对会修改状态的 Agent 做 end-state evaluation
有些 Agent 不只是读信息，还会在多轮对话中修改持久状态。
这类评估更难，因为每个动作都会改变后续环境。传统 turn-by-turn 评估很难处理这种依赖。
Anthropic 更推荐 end-state evaluation：不要逐步检查 Agent 是否走了某条固定路径，而是看最终状态是否正确。
对复杂工作流，可以拆成几个离散 checkpoint。每个 checkpoint 检查某些状态变化是否发生，而不是验证所有中间步骤。
这承认了 Agent 可能用不同路径达成同一个目标。
2. 长程对话需要管理上下文
生产 Agent 可能进行几百轮对话。
普通 context window 不够，需要压缩和 memory 机制。
Anthropic 的模式是：Agent 把已完成阶段总结起来，把必要信息存入外部 memory，再进入新阶段。
当接近 context limit 时，Agent 可以创建有干净上下文的新 subagent，并通过 handoff 保持连续性。
它也可以从 memory 取回研究计划，而不是因为上下文截断丢失前面的工作。
这种分布式上下文方式可以避免 context overflow，同时保持长任务连贯。
3. 让 subagent 直接把输出写到文件系统
如果所有 subagent 输出都必须经由主协调者转述，就会出现“传话游戏”问题：信息在多级传递中丢失、变形，还浪费 token。
Anthropic 建议，某些结果可以让 subagent 直接写到外部系统，比如文件、报告、结构化数据或可视化产物。
Subagent 只把轻量引用返回给 coordinator。
这样有两个好处：
• 减少信息损失。 • 减少把大段输出复制进 conversation history 的 token 开销。
这个模式特别适合结构化输出，比如代码、报告、数据可视化。因为专门 subagent 的 prompt 可能比通用 coordinator 更适合产出这类结果。
关键术语说明
• Multi-agent system：多个 LLM Agent 一起工作，每个 Agent 可以自主使用工具并循环执行。 • Lead agent：主协调 Agent，负责理解用户问题、制定策略、拆分任务、创建 subagents、汇总结果。 • Subagent：被 lead agent 创建出来执行具体子任务的 Agent。 • Orchestrator-worker pattern：一个协调者分派任务给多个工作者，再汇总结果的架构模式。 • Breadth-first query：需要同时探索多个独立方向的问题。 • BrowseComp：测试浏览型 Agent 找到难找信息能力的评测。 • MCP tools：通过 Model Context Protocol 接入的外部工具。 • Extended thinking：让 Claude 输出更多可见思考 token，用作规划和推理 scratchpad。 • Interleaved thinking：工具调用之间的思考，用来评估结果质量并调整下一步。 • LLM-as-judge：用大模型按 rubric 给输出打分或判断通过与否。 • Durable execution：长时间任务中可恢复、可继续的执行机制。 • Rainbow deployment：新旧版本同时运行并逐步切流，避免打断正在运行的任务。 • CitationAgent：专门负责把研究报告中的 claims 和具体引用来源对应起来的 Agent。
使用场景和注意点
这篇资料适合三类人重点学习。
第一，正在做研究型 Agent 的团队。
如果任务需要跨很多来源、多个工具、多个方向同时探索，多 Agent 可能比单 Agent 更适合。
第二，正在做 Agent 平台或内部自动化系统的人。
这篇文章最有价值的部分不是“多 Agent 更强”，而是生产化细节：prompt、tool interface、eval、tracing、checkpoint、deployment，每一层都影响稳定性。
第三，正在评估是否要上多 Agent 的团队。
文章给了一个很清楚的边界：多 Agent 成本高，token 消耗大，不适合强依赖、必须共享上下文、难以并行的任务。不要因为架构听起来高级就默认使用。
实际使用时，最重要的注意点有三个：
• 先判断任务是否真的能并行。 • 先用小样本 eval 快速验证，不要等完美评测集。 • 把工具描述、任务边界、effort budget 写清楚，否则多 Agent 很容易变成重复搜索和资源浪费。
可复习要点
1. 多 Agent Research 有效，主要因为它能用多个上下文窗口并行探索和压缩信息。 2. 它最适合开放式、广度优先、信息量大、工具复杂、可并行的问题。 3. Lead agent 的委派说明必须包含目标、输出格式、工具来源和任务边界。 4. Agent eval 不能只检查固定路径，要评估最终结果和过程合理性。 5. 生产级 Agent 系统必须处理状态、恢复、tracing、部署和长程上下文管理。
