我们如何构建多-agent研究系统

Claude 现在具备了 Research 能力，可以在 web、Google Workspace 以及任何集成中进行搜索，以完成复杂任务。

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

本文拆解了对我们有效的原则——希望你在构建自己的 multi-agent system 时也能用上。

multi-agent system 的优势

研究工作涉及开放式问题，很难提前预测所需步骤。你无法为探索复杂主题硬编码一条固定路径，因为这个过程本质上是动态且路径依赖的。人在进行研究时，往往会根据发现不断更新方法，沿着调查过程中出现的线索继续深入。

这种不可预测性使 AI agent 特别适合研究任务。研究需要随着调查展开而灵活转向，或探索相关但非主线的联系。模型必须在许多轮次中自主运行，并根据中间发现决定追踪哪些方向。线性的 one-shot pipeline 无法处理这类任务。

搜索的本质是压缩：从海量语料中提炼洞见。Subagent 通过并行运行并拥有各自的 context window 来促进压缩，它们同时探索问题的不同方面，然后为主研究 agent 压缩出最重要的 token。每个 subagent 也提供了关注点分离——不同的 tool、prompt 和探索轨迹——这减少了路径依赖，并支持彻底、独立的调查。

一旦 intelligence 达到某个阈值，multi-agent system 就会成为扩展性能的重要方式。例如，尽管过去 100,000 年里个体人类变得更加聪明，但在人类社会进入信息时代后，由于我们的_集体_ intelligence 和协调能力，人类社会的能力呈_指数级_增长。即使是一般智能 agent，作为个体运行时也会面临限制；agent 群体能够完成更多事情。

我们的内部评估显示，multi-agent research system 尤其擅长需要同时追踪多个独立方向的 breadth-first 查询。我们发现，在内部 research eval 中，以 Claude Opus 4 作为 lead agent、Claude Sonnet 4 作为 subagent 的 multi-agent system，比单 agent 的 Claude Opus 4 高出 90.2%。例如，当被要求识别 Information Technology S&P 500 中所有公司的董事会成员时，multi-agent system 通过将任务分解给 subagent 找到了正确答案，而 single-agent system 由于缓慢的顺序搜索，未能找到答案。

multi-agent system 之所以有效，主要是因为它们有助于花费足够的 token 来解决问题。在我们的分析中，有三个因素解释了 BrowseComp 评估中 95% 的性能差异（该评估测试浏览 agent 定位难找信息的能力）。我们发现，仅 token 使用量就解释了 80% 的差异，tool call 数量和模型选择是另外两个解释因素。这一发现验证了我们的架构：通过把工作分发给拥有独立 context window 的 agent，增加并行推理的容量。最新的 Claude 模型会成为 token 使用的大幅效率乘数，因为升级到 Claude Sonnet 4 带来的性能提升，大于在 Claude Sonnet 3.7 上将 token 预算翻倍。对于超出单个 agent 限制的任务，multi-agent 架构能够有效扩展 token 使用量。

也有一个缺点：在实践中，这类架构消耗 token 很快。在我们的数据中，agent 通常使用的 token 约为 chat 交互的 4×，而 multi-agent system 使用的 token 约为 chat 的 15×。从经济可行性看，multi-agent system 需要任务本身的价值足够高，能够为提升的性能付费。此外，一些需要所有 agent 共享同一 context，或 agent 之间存在大量依赖的领域，目前并不适合 multi-agent system。例如，大多数 coding 任务中真正可以并行化的部分少于研究任务，而 LLM agent 目前还不擅长实时协调并委派任务给其他 agent。我们发现，multi-agent system 擅长高价值任务，尤其是那些涉及大量并行化、信息量超出单个 context window、并需要与众多复杂 tool 交互的任务。

Research 的架构概览

我们的 Research 系统采用带有 orchestrator-worker 模式的 multi-agent 架构，其中 lead agent 负责协调流程，同时将任务委派给并行运行的专门 subagent。

multi-agent 架构的运行方式：用户查询流经 lead agent，后者创建专门的 subagent，并行搜索不同方面的信息。

当用户提交查询时，lead agent 会分析查询、制定策略，并生成 subagent 同时探索不同方面。如上图所示，subagent 通过迭代使用 search tool 收集信息，充当智能过滤器。在这个例子中，它们搜索 2025 年的 AI agent 公司，然后将公司列表返回给 lead agent，由其编写最终答案。

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

流程图展示了我们的 multi-agent Research 系统的完整 workflow。当用户提交查询时，系统会创建一个 LeadResearcher agent，并进入迭代研究过程。LeadResearcher 首先思考研究方法，并将计划保存到 Memory 中以持久化 context，因为如果 context window 超过 200,000 token，它会被截断，而保留计划很重要。然后，它会创建带有具体研究任务的专门 Subagent（这里展示了两个，但数量可以任意）。每个 Subagent 独立执行 web 搜索，使用 interleaved thinking 评估 tool 结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果，并决定是否需要更多研究——如果需要，它可以创建额外的 subagent，或完善自己的策略。一旦收集到足够信息，系统就会退出研究循环，并将所有发现传递给 CitationAgent，后者处理文档和研究报告，以识别引用的具体位置。这确保所有 claim 都能正确归因到来源。最终的研究结果会包含完整引用，并返回给用户。

面向 research agent 的 prompt engineering 和评估

multi-agent system 与 single-agent system 有关键差异，其中包括协调复杂度的快速增长。早期 agent 会犯一些错误，例如为简单查询生成 50 个 subagent，在 web 上无休止地搜寻并不存在的来源，以及用过多更新互相干扰。由于每个 agent 都由 prompt 引导，prompt engineering 是我们改进行为的主要杠杆。以下是我们在为 agent 编写 prompt 时学到的一些原则：

1. **像你的 agent 一样思考。**要迭代 prompt，你必须理解它们的效果。为帮助我们做到这一点，我们使用 Console 构建了模拟环境，其中包含系统中的准确 prompt 和 tool，然后逐步观察 agent 工作。这立即暴露了失败模式：agent 在已有足够结果时仍继续搜索，使用过于冗长的搜索查询，或选择错误的 tool。有效的 prompting 依赖于建立准确的 agent 心智模型，这能让最有影响力的修改变得显而易见。
2. 教会 orchestrator 如何委派。 在我们的系统中，lead agent 会将查询分解为子任务，并描述给 subagent。每个 subagent 都需要一个目标、输出格式、关于应使用 tool 和来源的指导，以及清晰的任务边界。没有详细的任务描述，agent 会重复工作、留下缺口，或找不到必要信息。起初，我们允许 lead agent 给出简单、简短的指令，例如“研究半导体短缺”，但发现这些指令往往过于模糊，导致 subagent 误解任务，或执行与其他 agent 完全相同的搜索。例如，一个 subagent 探索 2021 年汽车芯片危机，而另外 2 个则重复调查当前 2025 年供应链，没有形成有效分工。
3. **根据查询复杂度调整投入。**Agent 很难判断不同任务所需的合适投入，因此我们在 prompt 中嵌入了扩展规则。简单的事实查找只需要 1 个 agent 和 3-10 次 tool call，直接比较可能需要 2-4 个 subagent、每个 10-15 次 call，而复杂研究可能使用超过 10 个 subagent，并明确划分职责。这些显式指南帮助 lead agent 高效分配资源，避免对简单查询过度投入，这是我们早期版本中的常见失败模式。
4. **Tool 设计和选择至关重要。**Agent-tool interface 与 human-computer interface 一样重要。使用正确的 tool 很高效——很多时候，它是严格必要的。例如，如果某个 context 只存在于 Slack 中，agent 却在 web 上搜索，从一开始就注定失败。有了让模型访问外部 tool 的 MCP server，这个问题会进一步放大，因为 agent 会遇到此前未见过的 tool，而这些 tool 的描述质量差异很大。我们给 agent 提供了明确的启发式规则：例如，先检查所有可用 tool，根据用户意图匹配 tool 使用方式，用 web search 做广泛的外部探索，或优先使用专门 tool 而不是通用 tool。糟糕的 tool 描述可能把 agent 带到完全错误的路径上，因此每个 tool 都需要明确的用途和清晰的描述。
5. 让 agent 改进自己。我们发现 Claude 4 模型可以成为优秀的 prompt engineer。当给定一个 prompt 和一个失败模式时，它们能够诊断 agent 失败的原因并提出改进。我们甚至创建了一个 tool-testing agent——当给它一个有缺陷的 MCP tool 时，它会尝试使用该 tool，然后重写 tool 描述以避免失败。通过数十次测试 tool，这个 agent 找到了关键细节和 bug。这个改进 tool ergonomics 的过程，使未来使用新描述的 agent 的任务完成时间减少了 40%，因为它们能够避免大多数错误。
6. 先拓宽，再收窄。 搜索策略应当模仿专家的人类研究方式：先探索整体格局，再深入具体细节。Agent 往往默认使用过长、过具体的查询，导致返回结果很少。我们通过 prompting 来抵消这种倾向，让 agent 从简短、宽泛的查询开始，评估可用信息，然后逐步缩小关注范围。
7. 引导思考过程。Extended thinking mode 会让 Claude 在可见的思考过程中输出额外 token，可作为可控的 scratchpad。lead agent 使用 thinking 来规划方法，评估哪些 tool 适合任务，判断查询复杂度和 subagent 数量，并定义每个 subagent 的角色。我们的测试显示，extended thinking 提高了指令遵循、推理和效率。Subagent 也会先规划，然后在 tool 结果之后使用 interleaved thinking 来评估质量、识别缺口，并完善下一次查询。这让 subagent 在适应任何任务时更有效。
8. 并行 tool calling 会改变速度和性能。 复杂研究任务天然需要探索许多来源。我们的早期 agent 执行顺序搜索，速度非常慢。为了提升速度，我们引入了两类并行化：（1）lead agent 并行启动 3-5 个 subagent，而不是串行启动；（2）subagent 并行使用 3 个以上 tool。这些改动让复杂查询的研究时间最多减少 90%，使 Research 能够在几分钟内完成更多工作，而不是耗费数小时，同时覆盖比其他系统更多的信息。

我们的 prompting 策略侧重于灌输良好的启发式方法，而不是僵硬规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码进 prompt 中——例如将困难问题分解为更小任务，仔细评估来源质量，根据新信息调整搜索方法，并判断何时应关注深度（详细调查一个主题）而不是广度（并行探索许多主题）。我们还通过设置明确的 guardrail 主动缓解意外副作用，防止 agent 失控。最后，我们重点建立了包含可观测性和测试用例的快速迭代循环。

对 agent 进行有效评估

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

从小样本开始立即评估。在 agent 开发早期，改动往往影响很大，因为有大量低垂果实。一次 prompt 调整可能把成功率从 30% 提高到 80%。当 effect size 这么大时，只需少量测试用例就能发现变化。我们从大约 20 个代表真实使用模式的查询开始。测试这些查询通常让我们能够清楚看到改动的影响。我们经常听到 AI 开发团队推迟创建 eval，因为他们认为只有包含数百个测试用例的大型 eval 才有用。然而，最好立刻用少量示例开始小规模测试，而不是等到能构建更全面的 eval 时再开始。

LLM-as-judge 评估在做得好时可以扩展。 Research 输出很难通过程序评估，因为它们是自由形式文本，而且很少只有一个正确答案。LLM 天然适合为输出评分。我们使用一个 LLM judge，根据 rubric 中的标准评估每个输出：事实准确性（claim 是否与来源一致？）、引用准确性（引用来源是否支持 claim？）、完整性（是否覆盖了所有请求方面？）、来源质量（是否优先使用 primary source，而不是质量较低的 secondary source？）、tool 效率（是否以合理次数使用了正确 tool？）。我们尝试使用多个 judge 来评估各个组件，但发现单个 LLM call、使用单个 prompt 输出 0.0-1.0 的分数和 pass-fail 等级，最一致，也最符合人类判断。当 eval 测试用例_确实_有明确答案时，这种方法尤其有效，我们可以使用 LLM judge 简单检查答案是否正确（即它是否准确列出了 R&D 预算前三的制药公司？）。使用 LLM 作为 judge 让我们能够可扩展地评估数百个输出。

人工评估能发现自动化遗漏的问题。 测试 agent 的人会发现 eval 漏掉的边界情况。这些包括异常查询上的幻觉答案、系统故障，或微妙的来源选择偏差。在我们的案例中，人工测试者注意到，我们早期 agent 总是选择经过 SEO 优化的内容农场，而不是更权威但排名较低的来源，例如学术 PDF 或个人博客。将来源质量启发式规则加入 prompt 后，有助于解决这个问题。即使在自动化评估的世界中，人工测试仍然必不可少。

multi-agent system 会出现 emergent behavior（涌现行为），它们不是通过特定编程产生的。例如，对 lead agent 的小改动，可能会以不可预测的方式改变 subagent 的行为。成功需要理解交互模式，而不只是单个 agent 的行为。因此，这些 agent 的最佳 prompt 不只是严格指令，而是用于协作的框架，定义分工、问题解决方法和投入预算。要把这件事做好，需要谨慎的 prompting 和 tool 设计、可靠的启发式规则、可观测性，以及紧密的反馈循环。可参考 我们 Cookbook 中的开源 prompt，其中包含来自我们系统的示例 prompt。

生产可靠性和工程挑战

在传统软件中，一个 bug 可能会破坏某个功能、降低性能或导致故障。在 agentic system 中，小改动会级联成巨大的行为变化，这使得为必须在长时间运行过程中保持状态的复杂 agent 编写代码变得非常困难。

**Agent 是有状态的，错误会累积。**Agent 可以运行很长时间，并在许多 tool call 之间保持状态。这意味着我们需要持久地执行代码，并在过程中处理错误。如果没有有效缓解，小的系统故障可能会对 agent 造成灾难性影响。发生错误时，我们不能简单地从头重启：重启代价高，也会让用户沮丧。相反，我们构建了能够从 agent 发生错误的位置继续执行的系统。我们还利用模型的 intelligence 来优雅处理问题：例如，当某个 tool 失败时告知 agent，并让它自行适应，效果出人意料地好。我们将基于 Claude 构建的 AI agent 的适应性，与 retry logic 和定期 checkpoint 等确定性 safeguard 结合起来。

**Debugging 受益于新方法。**Agent 会做动态决策，并且即使 prompt 相同，不同运行之间也具有非确定性。这让 debugging 更难。例如，用户会报告 agent“没有找到显而易见的信息”，但我们无法看到原因。是 agent 使用了糟糕的搜索查询？选择了差的来源？遇到了 tool 故障？加入完整的生产 tracing 后，我们得以诊断 agent 失败原因，并系统性地修复问题。除了标准可观测性之外，我们还监控 agent 决策模式和交互结构——同时不监控单个对话内容，以保护用户隐私。这种高层级可观测性帮助我们诊断根因、发现意外行为，并修正常见失败。

部署需要谨慎协调。 Agent 系统是高度有状态的 prompt、tool 和执行逻辑网络，几乎持续运行。这意味着每当我们部署更新时，agent 可能正处于流程中的任意位置。因此，我们需要防止出于善意的代码变更破坏现有 agent。我们不能同时把每个 agent 都更新到新版本。相反，我们使用 rainbow deployment 来避免干扰正在运行的 agent，方法是在旧版本和新版本同时运行的同时，逐步将流量从旧版本迁移到新版本。

同步执行会产生瓶颈。 目前，我们的 lead agent 同步执行 subagent，会等待每一组 subagent 完成后再继续。这简化了协调，但在 agent 之间的信息流中产生了瓶颈。例如，lead agent 无法引导 subagent，subagent 无法协调，而整个系统可能会在等待某个 subagent 完成搜索时被阻塞。异步执行可以带来额外并行性：agent 并发工作，并在需要时创建新的 subagent。但这种异步性会给结果协调、状态一致性和 subagent 间错误传播带来挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能收益将证明这些复杂性是值得的。

结论

在构建 AI agent 时，最后一公里往往会变成旅程的大部分。能在开发者机器上运行的 codebase，需要大量工程工作才能成为可靠的生产系统。agentic system 中错误的复合性质意味着，传统软件中的小问题也可能让 agent 完全偏离轨道。一个步骤失败，就可能导致 agent 探索完全不同的轨迹，从而产生不可预测的结果。基于本文所述的所有原因，原型和生产之间的差距往往比预期更大。

尽管存在这些挑战，multi-agent system 已证明对开放式研究任务很有价值。用户表示，Claude 帮他们发现了此前未考虑过的商业机会，梳理复杂的医疗选项，解决棘手的技术 bug，并通过发现他们独自无法找到的研究联系，节省最多数天的工作量。通过谨慎的工程实现、全面测试、注重细节的 prompt 和 tool 设计、稳健的运营实践，以及对当前 agent 能力有深刻理解的 research、product 和 engineering 团队之间的紧密协作，multi-agent research system 可以在规模化场景下可靠运行。我们已经看到这些系统在改变人们解决复杂问题的方式。

一个 Clio embedding 图，展示了人们目前使用 Research 功能的最常见方式。排名靠前的用例类别包括：跨专业领域开发软件系统（10%）、开发并优化专业和技术内容（8%）、制定业务增长和收入生成策略（8%）、协助学术研究和教育材料开发（7%），以及研究并验证有关人物、地点或组织的信息（5%）。

致谢

作者为 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford。这项工作体现了 Anthropic 内多个团队的共同努力，他们使 Research 功能成为可能。特别感谢 Anthropic apps engineering 团队，他们的投入让这个复杂的 multi-agent system 得以进入生产。我们也感谢早期用户提供的优秀反馈。

附录

以下是一些关于 multi-agent system 的额外零散建议。

**对多轮中会改变状态的 agent 进行终态评估。**评估在多轮对话中修改持久状态的 agent，会带来独特挑战。不同于只读的研究任务，每个动作都可能改变后续步骤的环境，从而产生传统评估方法难以处理的依赖关系。我们发现，关注终态评估而不是逐轮分析会更有效。不要判断 agent 是否遵循了某个特定过程，而应评估它是否达到了正确的最终状态。这种方法承认 agent 可能找到通往同一目标的替代路径，同时仍然确保它们交付了预期结果。对于复杂 workflow，可将评估拆分为离散 checkpoint，在这些 checkpoint 上应当已经发生特定状态变化，而不是试图验证每一个中间步骤。

**长周期对话管理。**生产中的 agent 常常参与跨越数百轮的对话，因此需要谨慎的 context 管理策略。随着对话延长，标准 context window 会变得不够用，需要智能压缩和 memory 机制。我们实现了一些模式，让 agent 总结已完成的工作阶段，并在继续新任务之前，将关键信息存入外部 memory。当接近 context 限制时，agent 可以生成具有干净 context 的新 subagent，同时通过谨慎交接保持连续性。此外，它们可以从 memory 中检索已存储的 context，例如研究计划，而不是在达到 context limit 时丢失先前工作。这种分布式方法在保留长时间交互中的对话连贯性的同时，避免了 context overflow。

**让 subagent 输出到 filesystem，以减少“传话游戏”。**对于某些类型的结果，直接的 subagent 输出可以绕过主协调器，从而同时提升保真度和性能。不要要求 subagent 通过 lead agent 传达所有内容，而应实现 artifact system，让专门 agent 可以创建独立持久化的输出。Subagent 调用 tool 将工作存储在外部系统中，然后将轻量级引用传回协调器。这可以防止多阶段处理中的信息丢失，并减少通过对话历史复制大型输出所产生的 token 开销。这个模式尤其适合结构化输出，例如代码、报告或数据可视化，因为 subagent 的专门 prompt 往往能比经过通用协调器过滤产生更好的结果。