Anthropic: 如何构建多智能体研究系统

TL;DR

这篇来自 Anthropic 的文章，系统性地阐述了其 Multi-Agent 研究系统的构建历程，为构建高级 AI Agent 提供了清晰的路线图。其核心内容可归纳为三点：

1. 1. 为何选择多智能体： 明确了其在处理开放式、动态研究任务上的优越性。通过并行化与任务分解（Orchestrator-Worker 模式），系统能投入更多有效算力（Tokens），在广度搜索等任务上性能远超单个顶级模型。
2. 2. 如何构建与评估： 分享了极具参考价值的工程方法论。这不仅包括架构设计，更深入到以启发式和协作为导向的 Prompt 工程、以清晰高效为目标的 Tool 设计，以及一套应对非确定性的高级评估范式（如小样本快迭代、LLM-as-judge、人工评估互补）。
3. 3. 生产中的现实挑战： 揭示了从原型到可靠生产系统的巨大鸿沟。文章坦诚地讨论了高昂的 Token 消耗、有状态系统带来的错误累积、非确定性调试的困难，以及复杂的部署策略等现实问题。

如上，本文不仅是一份技术分享，更是一份宝贵的工程实践蓝图，对任何致力于将 Agentic AI 产品化的团队都具有重要的指导意义。

我们的 Research 功能使用多个 Claude agent 来更有效地探索复杂主题。我们分享了构建此系统时遇到的工程挑战和学到的经验教训。

Claude 现在具备了 Research 功能，使其能够跨网络、Google Workspace 以及任何集成进行搜索，以完成复杂的任务。

这个 multi-agent 系统从原型到生产的历程，教给了我们在系统架构、tool 设计和 prompt 工程方面的关键经验。一个 multi-agent 系统由多个 agent（在循环中自主使用 tool 的 LLM）协同工作组成。我们的 Research 功能涉及一个 agent，它根据用户查询规划研究流程，然后使用 tools 创建并行的 agents 来同时搜索信息。多 agent 系统在 agent 协调、评估和可靠性方面引入了新的挑战。

本文将分解对我们有效的原则——我们希望您在构建自己的 multi-agent 系统时会发现它们很有用。

multi-agent 系统的好处

研究工作涉及开放式问题，在这种问题中，很难预先预测所需的步骤。您无法为探索复杂主题硬编码一个固定的路径，因为这个过程本质上是动态和路径依赖的（path-dependent）。当人们进行研究时，他们倾向于根据发现不断更新自己的方法，跟随调查过程中出现的线索。

这种不可预测性使得 AI agents 特别适合研究任务。研究要求在调查展开时具有灵活性，能够转向或探索切题的联系。模型必须自主运行多个回合，根据中间发现来决定追求哪个方向。线性的、一次性的流水线无法处理这些任务。

搜索的本质是压缩：从庞大的语料库中提炼见解。Subagents 通过在各自的 context window 中并行操作来促进压缩，它们同时探索问题的不同方面，然后将最重要的 tokens 浓缩给主导研究的 agent。每个 subagent 还提供了关注点分离（separation of concerns）——即拥有独特的 tools、prompts 和探索轨迹——这减少了路径依赖，并实现了彻底、独立的调查。

一旦智能达到一个阈值，multi-agent 系统就成为扩展性能的重要途径。例如，尽管在过去 10 万年里，单个人的智力变得更高，但人类社会在信息时代的能力却呈指数级增长，这得益于我们的集体智慧和协调能力。即使是通用智能的 agents，在作为个体运作时也会面临限制；agent 群体可以完成更多的工作。

我们的内部评估显示，multi-agent 研究系统尤其擅长处理广度优先（breadth-first）的查询，这些查询涉及同时探索多个独立的方向。我们发现，在一个内部研究评估中，以 Claude Opus 4 为主导 agent、以 Claude Sonnet 4 为 subagents 的 multi-agent 系统，其性能比单个 Claude Opus 4 agent 高出 90.2%。例如，当被要求找出信息技术标准普尔 500 指数中所有公司的董事会成员时，multi-agent 系统通过将任务分解给 subagents 找到了正确答案，而 single-agent 系统则因缓慢的顺序搜索而未能找到答案。

Multi-agent 系统之所以有效，主要是因为它们有助于投入足够的 tokens 来解决问题。在我们的分析中，三个因素解释了 BrowseComp 评估（该评估测试浏览 agent 定位难找信息的能力）中 95% 的性能差异。我们发现，token 使用量本身解释了 80% 的差异，而 tool calls 的数量和模型选择是另外两个解释性因素。这一发现验证了我们的架构，该架构将工作分配给具有独立 context window 的 agents，以增加并行推理的能力。最新的 Claude 模型在 token 使用上起到了巨大的效率倍增器作用，因为升级到 Claude Sonnet 4 带来的性能提升比在 Claude Sonnet 3.7 上将 token 预算翻倍还要大。Multi-agent 架构有效地扩展了 token 的使用，以应对超出单个 agent 限制的任务。

但有一个缺点：在实践中，这些架构会快速消耗 tokens。在我们的数据中，agents 通常比聊天交互多使用约 4 倍的 tokens，而 multi-agent 系统比聊天多使用约 15 倍的 tokens。为了在经济上可行，multi-agent 系统要求任务的价值足够高，以支付其带来的性能提升。此外，一些需要所有 agents 共享相同上下文或 agents 之间存在许多依赖关系的领域，目前并不适合 multi-agent 系统。例如，大多数编码任务涉及的真正可并行的任务比研究要少，而且 LLM agents 在实时协调和委派任务给其他 agents 方面还不够出色。我们发现，multi-agent 系统在那些涉及大量并行化、信息量超出单个 context window、以及与众多复杂 tools 交互的高价值任务上表现出色。

Research 功能的架构概述

我们的 Research 系统采用了一种带有 orchestrator-worker 模式的 multi-agent 架构，其中一个主导Agent(Lead Agent) 协调整个流程，同时将任务委派给并行的、专门的 subagents。

当用户提交查询时，主导 agent 会分析查询，制定策略，并生成 subagents 以同时探索不同方面。如上图所示，subagents 充当智能过滤器，通过迭代使用搜索 tools 收集信息（此例中是关于 2025 年的 AI agent 公司），然后将公司列表返回给主导 agent，以便其汇编最终答案。

使用 Retrieval Augmented Generation (RAG) 的传统方法采用静态检索。也就是说，它们获取与输入查询最相似的一组文本块，并用这些文本块生成响应。相比之下，我们的架构使用多步搜索，动态地查找相关信息，适应新的发现，并分析结果以形成高质量的答案。

研究型 agent 的 Prompt 工程与评估

multi-agent 系统与 single-agent 系统有关键区别，其中包括协调复杂性的迅速增长。早期的 agents 会犯一些错误，比如为简单查询生成 50 个 subagents，无休止地在网上搜索不存在的来源，以及因过多的更新而互相干扰。由于每个 agent 都由一个 prompt 指导，prompt 工程是我们改进这些行为的主要手段。以下是我们学到的一些关于 prompting agents 的原则：

1. 1. 像你的 agent 一样思考。要迭代 prompts，你必须理解它们的效果。为了帮助我们做到这一点，我们使用我们的 Console，利用系统中的确切 prompts 和 tools 建立了模拟，然后一步步观察 agents 的工作。这立即揭示了失败模式：agents 在已经有足够结果时仍继续工作，使用过于冗长的搜索查询，或选择不正确的 tools。有效的 prompting 依赖于建立一个准确的 agent 心智模型，这能让最有影响力的改变变得显而易见。
2. 2. 教会 orchestrator 如何委派任务。在我们的系统中，主导 agent 将查询分解为子任务，并向 subagents 描述这些任务。每个 subagent 需要一个目标、一个输出格式、关于使用哪些 tools 和来源的指导，以及明确的任务边界。没有详细的任务描述，agents 会重复工作、留下空白，或找不到必要的信息。我们开始时允许主导 agent 给出简单的、短小的指令，如“研究半导体短缺”，但发现这些指令常常模糊不清，导致 subagents 误解任务或执行与其他 agents 完全相同的搜索。例如，一个 subagent 探索了 2021 年的汽车芯片危机，而另外两个则重复工作，调查当前的 2025 年供应链，没有有效的劳动分工。
3. 3. 根据查询复杂度调整投入。Agents 很难判断不同任务的适当投入量，所以我们在 prompts 中嵌入了扩展规则。简单的事实查找只需要 1 个 agent 进行 3-10 次 tool calls，直接比较可能需要 2-4 个 subagents，每个进行 10-15 次 calls，而复杂的研究可能会使用超过 10 个 subagents，并明确划分责任。这些明确的指导方针帮助主导 agent 有效地分配资源，并防止在简单查询上过度投入，这是我们早期版本中常见的失败模式。
4. 4. Tool 设计和选择至关重要。 Agent-tool 接口与人机界面同样关键。使用正确的 tool 效率高——通常，这是绝对必要的。例如，一个在网上搜索只存在于 Slack 中的上下文的 agent 从一开始就注定要失败。在使用 MCP 服务器让模型访问外部 tools 时，这个问题会更加复杂，因为 agents 会遇到描述质量参差不齐的未知 tools。我们为 agents 提供了明确的启发式规则：例如，首先检查所有可用的 tools，将 tool 的使用与用户意图匹配，为广泛的外部探索搜索网络，或优先选择专门的 tools 而不是通用的。糟糕的 tool 描述会把 agents 引向完全错误的道路，所以每个 tool 都需要一个明确的目的和清晰的描述。
5. 5. 让 agent 自我改进。我们发现 Claude 4 模型可以是出色的 prompt 工程师。当给定一个 prompt 和一个失败模式时，它们能够诊断出 agent 失败的原因并提出改进建议。我们甚至创建了一个 tool 测试 agent——当给定一个有缺陷的 MCP tool 时，它会尝试使用该 tool，然后重写 tool 描述以避免失败。通过数十次测试该 tool，这个 agent 发现了关键的细微差别和 bug。这个改进 tool 人体工程学的过程，使得未来使用新描述的 agents 的任务完成时间减少了 40%，因为它们能够避免大多数错误。
6. 6. 先从广泛开始，再逐步收窄。搜索策略应该模仿专家的人类研究：在深入具体细节之前先探索整体情况。Agents 常常默认使用过长、过于具体的查询，导致返回结果很少。我们通过 prompting agents 从简短、宽泛的查询开始，评估可用信息，然后逐步收窄焦点来纠正这种倾向。
7. 7. 引导思考过程。extended thinking 模式会引导 Claude 在一个可见的思考过程中输出额外的 tokens，可以作为一个可控的草稿纸。主导 agent 使用思考来规划其方法，评估哪些 tools 适合任务，确定查询复杂度和 subagent 数量，并定义每个 subagent 的角色。我们的测试表明，extended thinking 提高了指令遵循、推理和效率。Subagents 也会进行规划，然后在 tool 结果出来后使用 interleaved thinking 来评估质量、识别差距并优化它们的下一个查询。这使得 subagents 在适应任何任务时都更加有效。
8. 8. 并行 tool 调用改变速度和性能。复杂的研究任务自然涉及探索许多来源。我们早期的 agents 执行顺序搜索，速度慢得令人痛苦。为了提速，我们引入了两种并行化：（1）主导 agent 并行启动 3-5 个 subagents，而不是串行启动；（2）subagents 并行使用 3 个以上的 tools。这些改变使复杂查询的研究时间缩短了高达 90%，让 Research 功能能在几分钟内完成更多工作，而不是几小时，同时覆盖比其他系统更多的信息。

我们的 prompting 策略专注于灌输良好的启发式规则，而非僵化的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码到我们的 prompts 中——例如将困难问题分解为更小的任务，仔细评估来源质量，根据新信息调整搜索方法，以及识别何时应专注于深度（详细调查一个主题）与广度（并行探索多个主题）。我们还通过设置明确的护栏来主动减轻意外的副作用，以防止 agents 失控。最后，我们专注于一个具有可观察性和测试用例的快速迭代循环。

agent 的有效评估

好的评估对于构建可靠的 AI 应用至关重要，agent 也不例外。然而，评估 multi-agent 系统带来了独特的挑战。传统评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 产生输出 Z。但 multi-agent 系统并非如此运作。即使起点完全相同，agents 也可能采取完全不同的有效路径来达到目标。一个 agent 可能搜索三个来源，而另一个可能搜索十个，或者它们可能使用不同的 tools 来找到相同的答案。因为我们并不总是知道正确的步骤是什么，我们通常不能仅仅检查 agents 是否遵循了我们预先规定的“正确”步骤。相反，我们需要灵活的评估方法，既能判断 agents 是否达到了正确的结果，又能判断它们是否遵循了合理的过程。

立即用小样本开始评估。在 agent 开发的早期，改变往往会产生巨大的影响，因为有大量唾手可得的改进空间。一个 prompt 的微调可能会将成功率从 30% 提高到 80%。在效应如此之大的情况下，你只需几个测试用例就能发现变化。我们从大约 20 个代表真实使用模式的查询集开始。测试这些查询常常能让我们清楚地看到变化的影响。我们经常听说 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好是立即用几个例子开始小规模测试，而不是等到你能建立更全面的评估时再动手。

LLM-as-judge评估如果做得好，可以很好地扩展。研究的输出很难以编程方式评估，因为它们是自由格式的文本，并且很少有单一的正确答案。LLMs 很自然地适合评分输出。我们使用了一个 LLM 评委，它根据一个评分标准来评估每个输出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖了所有被要求的方面？）、来源质量（是否使用了主要来源而非质量较低的次要来源？），以及 tool 效率（是否以合理的次数使用了正确的 tools？）。我们尝试了多个评委来评估每个部分，但发现单个 LLM 调用、单个 prompt、输出 0.0-1.0 的分数和一个通过/失败的等级，这种方式最一致，且与人类判断最吻合。当评估的测试用例确实有明确答案时，这种方法尤其有效，我们可以用 LLM 评委简单地检查答案是否正确（例如，它是否准确列出了研发预算前三的制药公司？）。使用 LLM 作为评委使我们能够可扩展地评估数百个输出。

人工评估能发现自动化遗漏的问题。测试 agent 的人能发现评估遗漏的边缘案例。这些包括在不寻常查询上的幻觉答案、系统故障或微妙的来源选择偏见。在我们的案例中，人工测试员注意到，我们早期的 agents 总是选择经过 SEO 优化的内容农场，而不是像学术 PDF 或个人博客这样权威但排名较低的来源。在我们的 prompts 中加入来源质量的启发式规则帮助解决了这个问题。即使在自动化评估的世界里，手动测试仍然至关重要。

Multi-agent 系统具有涌现行为，这些行为是在没有特定编程的情况下产生的。例如，对主导 agent 的微小改变可能会不可预测地改变 subagents 的行为。成功需要理解交互模式，而不仅仅是单个 agent 的行为。因此，这些 agents 的最佳 prompts 不仅仅是严格的指令，而是定义了劳动分工、解决问题的方法和投入预算的协作框架。要做到这一点，依赖于仔细的 prompting 和 tool 设计、可靠的启发式规则、可观察性以及紧密的反馈循环。可以参阅我们 Cookbook 中的开源 prompts^[1] 来查看我们系统中的示例 prompts。

生产环境的可靠性与工程挑战

在传统软件中，一个 bug 可能会破坏一个功能、降低性能或导致服务中断。在 agentic 系统中，微小的变化会级联成巨大的行为变化，这使得为必须在长期运行的进程中保持状态的复杂 agents 编写代码变得异常困难。

Agent 是有状态的（stateful），错误会累积。Agents 可以长时间运行，在多次 tool calls 之间保持状态。这意味着我们需要持久地执行代码并在此过程中处理错误。没有有效的缓解措施，微小的系统故障对 agents 来说可能是灾难性的。当错误发生时，我们不能简单地从头开始：重新启动对用户来说既昂贵又令人沮丧。相反，我们构建了可以从 agent 发生错误的地方恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，让 agent 知道某个 tool 正在失灵并让它自行适应，效果出奇地好。我们将基于 Claude 构建的 AI agents 的适应性与重试逻辑和定期检查点等确定性保障措施相结合。

调试受益于新方法。Agents 做出动态决策，并且即使使用相同的 prompts，每次运行之间也是不确定的。这使得调试更加困难。例如，用户会报告 agents “找不到明显的信息”，但我们看不出原因。是 agents 使用了糟糕的搜索查询？选择了差的来源？还是遇到了 tool 故障？增加全链路的生产环境追踪让我们能够诊断 agents 失败的原因并系统地修复问题。除了标准的可观察性，我们还监控 agent 的决策模式和交互结构——所有这些都在不监控单个对话内容的情况下进行，以维护用户隐私。这种高层次的可观察性帮助我们诊断根本原因，发现意外行为，并修复常见故障。

部署需要谨慎协调。Agent 系统是由 prompts、tools 和执行逻辑构成的高度有状态的网络，几乎是连续运行的。这意味着每当我们部署更新时，agents 可能处于其流程的任何位置。因此，我们需要防止我们善意的代码更改破坏现有的 agents。我们不能同时将所有 agents 更新到新版本。相反，我们使用 rainbow deployments^[2] 来避免中断正在运行的 agents，通过逐步将流量从旧版本转移到新版本，同时保持两者同时运行。

同步执行（Synchronous execution）会造成瓶颈。目前，我们的主导 agents 同步执行 subagents，等待每组 subagents 完成后才继续。这简化了协调，但在 agents 之间的信息流中造成了瓶颈。例如，主导 agent 无法引导 subagents，subagents 无法相互协调，整个系统可能会因为等待单个 subagent 完成搜索而被阻塞。异步执行（Asynchronous execution）将实现额外的并行性：agents 同时工作，并在需要时创建新的 subagents。但这种异步性在结果协调、状态一致性和跨 subagents 的错误传播方面增加了挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能的提升将证明这种复杂性是值得的。

结论

在构建 AI agent 时，最后一英里往往占据了旅程的大部分。在开发人员机器上能工作的代码库，需要大量的工程工作才能成为可靠的生产系统。agentic 系统中错误的复合性质意味着，对于传统软件来说的小问题可能会让 agents 完全脱轨。一个步骤的失败可能导致 agents 探索完全不同的轨迹，从而导致不可预测的结果。出于本文所述的所有原因，原型与生产之间的差距往往比预期的要大。

尽管存在这些挑战，multi-agent 系统已被证明在开放式研究任务中非常有价值。用户表示，Claude 帮助他们找到了他们未曾考虑过的商业机会，驾驭了复杂的医疗保健选项，解决了棘手的技术 bug，并通过揭示他们自己找不到的研究联系，节省了长达数天的工作时间。通过精心的工程设计、全面的测试、注重细节的 prompt 和 tool 设计、稳健的运营实践，以及对当前 agent 能力有深刻理解的研究、产品和工程团队之间的紧密协作，multi-agent 研究系统可以在生产规模上可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。

附录

以下是一些关于 multi-agent 系统的额外杂项技巧。

对多轮交互中会改变状态的 agent 进行终态评估 (end-state evaluation)。评估那些在多轮对话中会修改持久化状态（persistent state）的 agent，会面临独特的挑战。与只读（read-only）的研究任务不同，每一步操作都会改变后续步骤的环境，从而产生传统评估方法难以处理的依赖关系。我们发现，成功的关键在于专注于终态评估（end-state evaluation），而非逐轮分析（turn-by-turn analysis）。与其判断 agent 是否遵循了特定的流程，不如评估它是否达到了正确的最终状态。这种方法认可了 agent 可能会通过不同路径（alternative paths）达成同一目标，同时仍能保证交付预期的结果。对于复杂的工作流，可以将评估分解为多个离散的检查点（discrete checkpoints），在这些点上检查特定的状态变化是否已经发生，而不是试图去验证每一个中间步骤。

长周期对话管理。生产环境中的 agents 经常进行跨越数百轮的对话，需要精心的上下文管理策略。随着对话的延长，标准的 context window 变得不足，需要智能的压缩和记忆机制。我们实现了一些模式，其中 agents 会总结已完成的工作阶段，并将基本信息存储在外部内存中，然后再继续新任务。当接近 context limit 时，agents 可以生成具有干净上下文的新 subagents，同时通过精心的交接保持连续性。此外，它们可以从内存中检索存储的上下文（如研究计划），而不是在达到 context limit 时丢失之前的工作。这种分布式方法可以防止上下文溢出，同时在长时间的对话中保持连贯性。

将 subagent 的输出保存到文件系统，以最大限度地减少“传话游戏”带来的信息失真。 对于某些类型的结果，直接的 subagent 输出可以绕过主协调器，从而提高保真度和性能。与其要求 subagents 通过主导 agent 交流所有内容，不如实施一个工件（artifact）系统，让专门的 agents 可以创建独立持久化的输出。Subagents 调用 tools 将其工作存储在外部系统中，然后将轻量级的引用传回协调器。这可以防止在多阶段处理过程中的信息丢失，并减少因在对话历史中复制大型输出而产生的 token 开销。这种模式特别适用于结构化输出，如代码、报告或数据可视化，因为 subagent 的专门化 prompt 产生的结果比通过通用协调器过滤要好。

原文链接：https://www.anthropic.com/engineering/built-multi-agent-research-system

引用链接

[1] Cookbook 中的开源 prompts: https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents/prompts
[2] `rainbow deployments`: https://brandon.dimcheff.com/2018/02/rainbow-deploys-with-kubernetes