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