我们如何构建 multi-agent research system
原文: English original · Anthropic/OpenAI 官方
我们如何构建 multi-agent research system
发布于 2025 年 6 月 13 日
我们的 Research 功能使用多个 Claude agents，更高效地探索复杂主题。本文将分享我们构建这一系统时遇到的工程挑战，以及从中得到的经验。
Claude 现在具备 Research 能力，可以跨 Web、Google Workspace 以及任意集成进行搜索，从而完成复杂任务。
这个 multi-agent 系统从原型走向生产的过程，让我们在系统架构、工具设计和 prompt engineering 方面学到了关键经验。一个 multi-agent 系统由多个 agents 组成，也就是多个 LLM 以循环方式自主使用工具，并彼此协作。我们的 Research 功能包含一个 agent，它会根据用户查询规划研究流程，然后使用工具创建并行 agents，同时搜索信息。
由多个 agents 组成的系统，会在 agent 协调、评测和可靠性方面带来新的挑战。
本文将拆解对我们有效的原则。我们希望这些原则也能帮助你构建自己的 multi-agent 系统。
Multi-agent 系统的收益
研究工作通常面对开放式问题，很难提前预测所需步骤。探索复杂主题时，你无法硬编码一条固定路径，因为这个过程天然是动态的，并且依赖路径。人在做研究时，往往会根据新发现持续调整方法，顺着调查过程中出现的线索继续深入。
这种不可预测性让 AI agents 特别适合研究任务。研究需要灵活性，必须能够随着调查展开而转向，或探索旁支关联。模型需要自主运行很多轮，并根据中间发现决定接下来追踪哪些方向。线性的、一次性的流水线无法处理这类任务。
搜索的本质是压缩：从庞大的语料中提炼洞见。Subagents 拥有各自的 context windows，可以并行探索问题的不同方面，然后把最重要的 tokens 压缩后交给 lead research agent，从而帮助完成压缩。每个 subagent 也提供了关注点分离：不同的工具、prompt 和探索轨迹。这会降低路径依赖，并支持彻底、独立的调查。
一旦智能达到某个阈值，multi-agent 系统就会成为扩展性能的重要方式。举例来说，尽管单个人类在过去 10 万年里变得更聪明，但人类社会在信息时代的能力呈指数级提升，原因在于我们的集体智能和协调能力。即便是 generally-intelligent agents，作为个体运行时也会遇到限制；由 agents 组成的群体能完成更多事情。
我们的内部评测显示，multi-agent research systems 尤其擅长 breadth-first queries，也就是需要同时追踪多个独立方向的查询。我们发现，在内部研究评测中，由 Claude Opus 4 担任 lead agent、Claude Sonnet 4 担任 subagents 的 multi-agent 系统，比 single-agent Claude Opus 4 高出 90.2%。
例如，当系统被要求找出 Information Technology S&P 500 公司所有董事会成员时，multi-agent 系统会把问题拆解成多个任务交给 subagents，因此找到了正确答案；而 single-agent 系统只能缓慢地顺序搜索，最终没能找到答案。
Multi-agent 系统之所以有效，主要是因为它们能帮助投入足够多的 tokens 来解决问题。在我们的分析中，有三个因素解释了 BrowseComp 评测中 95% 的性能方差。BrowseComp 测试 browsing agents 定位难找信息的能力。我们发现，仅 token 用量本身就解释了 80% 的方差，另外两个解释因素是 tool calls 数量和模型选择。
这一发现验证了我们的架构：通过带有独立 context windows 的 agents 分发工作，从而增加并行推理容量。最新的 Claude 模型会显著放大 token 使用效率，因为升级到 Claude Sonnet 4 带来的性能收益，大于把 Claude Sonnet 3.7 的 token budget 翻倍。对于超出单个 agent 限制的任务，multi-agent 架构可以有效扩展 token 使用量。
但它也有代价：实践中，这类架构消耗 tokens 很快。在我们的数据中，agents 通常使用的 tokens 大约是聊天交互的 4 倍，而 multi-agent 系统使用的 tokens 大约是聊天的 15 倍。要在经济上可行，multi-agent 系统需要用于那些任务价值足以覆盖性能提升成本的场景。
此外，有些领域要求所有 agents 共享同一上下文，或者 agents 之间存在大量依赖，这些领域目前并不适合 multi-agent 系统。例如，大多数编码任务里真正可并行化的任务少于研究任务，而 LLM agents 还不太擅长实时协调并委派其他 agents。
我们发现，multi-agent 系统最适合这类高价值任务：需要大量并行化，信息量超出单一 context window，并且需要和大量复杂工具交互。
Research 的架构概览
我们的 Research 系统采用 multi-agent 架构，使用 orchestrator-worker pattern：lead agent 协调整个流程，同时把任务委派给并行运行的专门 subagents。
当用户提交查询时，lead agent 会分析查询、制定策略，并生成 subagents 同时探索不同方面。如上图所示，subagents 作为智能过滤器，迭代使用搜索工具收集信息。在这个例子中，它们围绕 2025 年的 AI agent 公司进行搜索，然后把公司列表返回给 lead agent，由它汇总最终答案。
传统的 Retrieval Augmented Generation（RAG）方法使用静态检索。也就是说，它们会抓取一组和输入查询最相似的 chunks，并用这些 chunks 生成响应。相比之下，我们的架构使用多步骤搜索，动态发现相关信息，适应新的发现，并分析结果，以形成高质量答案。
流程图展示了我们的 multi-agent Research 系统的完整 workflow。当用户提交查询时，系统会创建一个 LeadResearcher agent，进入迭代研究流程。LeadResearcher 首先思考方法，并把计划保存到 Memory，以持久化上下文，因为如果 context window 超过 200,000 tokens 就会被截断，而保留计划非常重要。
随后，它会创建专门的 Subagents，图中展示了两个，但实际可以是任意数量，并给出具体研究任务。每个 Subagent 独立执行 Web 搜索，使用 interleaved thinking 评估工具结果，然后把发现返回给 LeadResearcher。LeadResearcher 综合这些结果，并判断是否需要更多研究；如果需要，它可以创建更多 subagents 或优化策略。
一旦收集到足够信息，系统就会退出研究循环，并把所有发现交给 CitationAgent。CitationAgent 会处理文档和研究报告，识别引用应指向的具体位置。这可以确保所有主张都有适当来源。最后，带有完整引用的研究结果会返回给用户。
Research agents 的 prompt engineering 与评测
Multi-agent 系统和 single-agent 系统有关键差异，其中包括协调复杂度的快速增长。早期 agents 会犯一些错误，例如为简单查询生成 50 个 subagents、无休止地搜索并不存在的来源，以及用过多更新互相干扰。由于每个 agent 都由 prompt 引导，prompt engineering 是我们改善这些行为的主要杠杆。下面是我们在为 agents 编写 prompt 时学到的一些原则：
- 像你的 agents 一样思考。要迭代 prompt，你必须理解 prompt 的效果。为此，我们使用 Console 构建了模拟环境，并使用系统中的真实 prompt 和工具，然后逐步观察 agents 如何工作。这立刻暴露了失败模式：agents 明明已经有足够结果却继续搜索，使用过于冗长的搜索查询，或者选择了错误工具。
有效的 prompt 依赖于对 agent 建立准确的心智模型；一旦模型准确，最有影响力的改动往往会变得显而易见。
- 教会 orchestrator 如何委派。在我们的系统中，lead agent 会把查询拆成子任务，并向 subagents 描述这些任务。每个 subagent 都需要目标、输出格式、关于工具和来源使用方式的指导，以及清晰的任务边界。如果缺少详细任务描述，agents 会重复工作、留下缺口，或者找不到必要信息。
一开始，我们允许 lead agent 给出简单、简短的指令，例如“研究半导体短缺”。但我们发现，这些指令经常太模糊，导致 subagents 误解任务，或者执行和其他 agents 完全一样的搜索。例如，一个 subagent 探索 2021 年汽车芯片危机，另外 2 个 subagents 则重复调查当前 2025 年供应链，没有形成有效分工。
- 让投入匹配查询复杂度。Agents 很难判断不同任务需要多少投入，因此我们在 prompt 中嵌入了规模调节规则。简单事实查找只需要 1 个 agent 和 3-10 次 tool calls；直接比较可能需要 2-4 个 subagents，每个执行 10-15 次 calls；复杂研究可能需要超过 10 个 subagents，并明确划分职责。
这些明确指南帮助 lead agent 高效分配资源，并防止在简单查询上过度投入。过度投入是我们早期版本中的常见失败模式。
- 工具设计和选择至关重要。Agent-tool interfaces 和人机界面一样关键。使用正确工具非常高效，而且往往是严格必要的。例如，一个 agent 如果在 Web 上搜索只存在于 Slack 里的上下文，从一开始就注定失败。随着 MCP servers 让模型能够访问外部工具，这个问题会进一步放大，因为 agents 会遇到以前没见过的工具，而这些工具描述的质量差异极大。
我们给 agents 提供了明确启发式规则：例如，先检查所有可用工具，让工具使用方式匹配用户意图；广泛外部探索时搜索 Web；优先使用专门工具，而不是通用工具。糟糕的工具描述可能把 agents 带到完全错误的路径上，因此每个工具都需要有独特用途和清晰描述。
- 让 agents 改进自己。我们发现 Claude 4 模型可以成为优秀的 prompt engineers。当给它们一个 prompt 和一个失败模式时，它们能够诊断 agent 失败的原因，并提出改进建议。我们甚至创建了一个 tool-testing agent：当给它一个有缺陷的 MCP tool 时，它会尝试使用这个工具，然后重写工具描述以避免失败。通过测试这个工具数十次，这个 agent 发现了关键细微差别和 bug。
这种改进工具易用性的流程，让未来 agents 在使用新描述时，任务完成时间降低了 40%，因为它们能够避开大多数错误。
先广后窄。搜索策略应该像专家做人类研究一样：先探索整体格局，再钻入细节。Agents 经常默认使用过长、过具体的查询，返回结果很少。我们通过 prompt 抵消这种倾向，要求 agents 先使用简短、宽泛的查询，评估可获得内容，然后逐步收窄焦点。
引导思考过程。Extended thinking mode 会让 Claude 在可见思考过程中输出额外 tokens，它可以作为可控草稿纸。Lead agent 使用 thinking 来规划方法，评估哪些工具适合任务，判断查询复杂度和 subagent 数量，并定义每个 subagent 的角色。我们的测试显示，extended thinking 改善了指令遵循、推理和效率。
Subagents 也会先规划，然后在工具结果之后使用 interleaved thinking 来评估质量、识别缺口，并优化下一次查询。这让 subagents 能更有效地适应任何任务。
- 并行工具调用会改变速度和性能。复杂研究任务天然需要探索许多来源。我们的早期 agents 会顺序执行搜索，速度慢得令人痛苦。为了提升速度，我们引入了两类并行化：（1）lead agent 会并行启动 3-5 个 subagents，而不是串行启动；（2）subagents 会并行使用 3 个以上工具。
这些改动让复杂查询的研究时间最多减少 90%，使 Research 能够在几分钟内完成更多工作，而不是耗费数小时，同时覆盖的信息也超过其他系统。
我们的 prompt 策略专注于灌输良好的启发式方法，而不是僵硬规则。我们研究了熟练研究者如何处理研究任务，并把这些策略编码进 prompt 中：把困难问题拆解成更小任务，谨慎评估来源质量，根据新信息调整搜索方法，以及识别什么时候应该关注深度，也就是详细调查一个主题，什么时候应该关注广度，也就是并行探索多个主题。
我们也通过设置明确 guardrails，主动缓解意外副作用，防止 agents 失控地螺旋推进。最后，我们专注于一个带有可观测性和测试用例的快速迭代循环。
有效评测 agents
好的评测对于构建可靠 AI 应用至关重要，agents 也不例外。不过，评测 multi-agent 系统会带来独特挑战。传统评测通常假设 AI 每次都遵循相同步骤：给定输入 X，系统应该沿路径 Y 产出输出 Z。但 multi-agent 系统并不是这样工作的。即使起点完全相同，agents 也可能走上完全不同但同样有效的路径来达成目标。
一个 agent 可能搜索三个来源，另一个可能搜索十个来源；它们也可能使用不同工具找到同一个答案。因为我们并不总是知道正确步骤是什么，所以通常不能只检查 agents 是否遵循了我们预先规定的“正确”步骤。相反，我们需要灵活的评测方法，既判断 agents 是否达成了正确结果，也判断它们是否遵循了合理流程。
从小样本开始，立即进行评测。在 agent 开发早期，改动往往会产生巨大影响，因为有很多容易摘取的低垂果实。一次 prompt 微调可能把成功率从 30% 提升到 80%。在效果量这么大的情况下，只需少量测试用例就能发现变化。我们一开始使用约 20 个查询组成的集合，这些查询代表真实使用模式。测试这些查询通常能让我们清楚看到改动的影响。
我们经常听到 AI 开发团队推迟创建评测，因为他们认为只有包含数百个测试用例的大型评测才有用。然而，最好的做法是立刻用少量示例开始小规模测试，而不是等到可以构建更完整的评测才开始。
LLM-as-judge 评测如果做得好，可以规模化。Research 输出很难用程序化方式评估，因为它们是自由格式文本，而且很少只有一个正确答案。LLM 非常适合给输出打分。
我们使用了一个 LLM judge，根据 rubric 中的标准评估每个输出：事实准确性，主张是否匹配来源；引用准确性，被引用来源是否匹配主张；完整性，是否覆盖所有请求方面；来源质量，是否优先使用一手来源而不是低质量二手来源；工具效率，是否以合理次数使用了正确工具。
我们曾尝试用多个 judges 分别评估每个组件，但发现单次 LLM 调用、使用单个 prompt 输出 0.0-1.0 分数和 pass-fail 评级，最稳定，也最符合人类判断。当评测测试用例确实有明确答案时，这种方法尤其有效，我们可以使用 LLM judge 直接检查答案是否正确，例如它是否准确列出了 R&D 预算最高的前三家制药公司。
把 LLM 用作 judge，让我们能够规模化评估数百个输出。
人工评测会捕捉自动化遗漏的问题。测试 agents 的人会发现评测漏掉的边缘情况。其中包括在异常查询上的幻觉答案、系统故障，或者微妙的来源选择偏差。在我们的案例中，人工测试者注意到，我们的早期 agents 会持续选择 SEO 优化的内容农场，而不是更权威但排名较低的来源，例如学术 PDF 或个人博客。向 prompt 添加来源质量启发式规则帮助解决了这个问题。
即使在自动化评测的世界里，手动测试仍然必不可少。
Multi-agent 系统会出现涌现行为，这些行为并不是由特定程序直接写出来的。例如，对 lead agent 的小改动，可能以不可预测的方式改变 subagents 的行为。成功需要理解交互模式，而不只是理解单个 agent 的行为。因此，给这些 agents 的最佳 prompt 并不只是严格指令，而是协作框架：定义分工、问题解决方法和投入预算。
把这些做好，依赖谨慎的 prompt 和工具设计、扎实的启发式规则、可观测性，以及紧密反馈循环。你可以查看我们 Cookbook 中的开源 prompt，那里有来自我们系统的 prompt 示例。
生产可靠性与工程挑战
在传统软件中，一个 bug 可能会破坏某个功能、降低性能，或造成故障。在 agentic 系统中，微小改动会级联成巨大的行为变化，这使得为复杂 agents 编写代码变得格外困难，因为它们必须在长期运行的过程中维护状态。
Agents 是有状态的，而且错误会复合。Agents 可以长时间运行，在许多 tool calls 之间维护状态。这意味着我们需要持久地执行代码，并在过程中处理错误。没有有效缓解措施时，小型系统故障对 agents 可能是灾难性的。发生错误时，我们不能只是从头重启：重启成本高，也会让用户沮丧。相反，我们构建了可以从 agent 出错位置恢复的系统。
我们也使用模型的智能来优雅处理问题：例如，当工具失败时告知 agent，并让它自行适应，效果出人意料地好。我们把基于 Claude 构建的 AI agents 的适应能力，与重试逻辑和定期 checkpoint 这类确定性 safeguard 结合起来。
调试需要新的方法。Agents 会做出动态决策，而且即使 prompt 完全相同，不同运行之间也具有非确定性。这让调试更困难。例如，用户会报告 agents “找不到显而易见的信息”，但我们看不到原因。是 agents 使用了糟糕的搜索查询？选择了低质量来源？还是遇到了工具故障？加入完整生产 tracing 后，我们就能诊断 agents 失败的原因，并系统性修复问题。
除了标准可观测性之外，我们还监控 agent 决策模式和交互结构，同时不监控单个对话的内容，以维护用户隐私。这种高层级可观测性帮助我们诊断根因、发现意外行为，并修复常见失败。
部署需要谨慎协调。Agent 系统是高度有状态的网络，由 prompt、工具和执行逻辑组成，几乎持续运行。这意味着每次部署更新时，agents 可能处在流程中的任何位置。因此，我们需要防止出于好意的代码改动破坏现有 agents。我们无法同时把每个 agent 更新到新版本。
相反，我们使用 rainbow deployments，逐步把流量从旧版本切到新版本，同时让两者并行运行，从而避免打扰正在运行的 agents。
同步执行会制造瓶颈。目前，我们的 lead agents 同步执行 subagents，会等每一组 subagents 完成之后再继续。这简化了协调，但也在 agents 之间的信息流中制造了瓶颈。例如，lead agent 无法引导 subagents，subagents 无法互相协调，整个系统也可能在等待某一个 subagent 完成搜索时被阻塞。
异步执行可以带来额外并行性：agents 并发工作，并在需要时创建新的 subagents。但这种异步性也会在结果协调、状态一致性，以及跨 subagents 的错误传播上增加挑战。随着模型能够处理更长、更复杂的研究任务，我们预计性能收益会证明这些复杂性是值得的。
结论
构建 AI agents 时，最后一公里常常会变成大半段旅程。在开发者机器上能运行的代码库，要成为可靠生产系统，需要大量工程工作。Agentic 系统中错误会复合，这意味着对传统软件来说很小的问题，也可能让 agents 完全偏离轨道。一步失败就可能让 agents 探索完全不同的轨迹，导致不可预测的结果。
出于本文所述的所有原因，原型和生产之间的差距往往比预想更大。
尽管存在这些挑战，multi-agent 系统已经证明自己对开放式研究任务很有价值。用户反馈说，Claude 帮助他们发现了从未考虑过的商业机会、应对复杂医疗保健选择、解决棘手技术 bug，并通过揭示他们独自无法找到的研究关联，节省了最多数天工作。
通过谨慎工程、全面测试、注重细节的 prompt 和工具设计、健壮的运营实践，以及对当前 agent 能力有深刻理解的研究、产品和工程团队之间的紧密协作，multi-agent research systems 可以在规模化场景中可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。
这张 Clio embedding plot 展示人们今天使用 Research 功能的最常见方式。排名靠前的用例类别包括：跨专业领域开发软件系统（10%）、开发并优化专业和技术内容（8%）、制定业务增长和收入生成策略（8%）、协助学术研究和教育材料开发（7%），以及研究和验证关于人物、地点或组织的信息（5%）。
致谢
作者：Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford。这项工作体现了 Anthropic 多个团队的共同努力，他们让 Research 功能成为可能。特别感谢 Anthropic apps engineering team，他们的投入把这个复杂的 multi-agent 系统带到了生产环境。我们也感谢早期用户提供的出色反馈。
附录
下面是一些关于 multi-agent 系统的其他杂项建议。
对多轮中改变状态的 agents 进行终态评测。评测那些在多轮对话中修改持久状态的 agents，会带来独特挑战。不同于只读研究任务，每个动作都可能改变后续步骤的环境，产生传统评测方法难以处理的依赖。我们发现，专注于终态评测而不是逐轮分析更有效。
与其判断 agent 是否遵循了某个特定流程，不如评估它是否达到了正确最终状态。这种方法承认 agents 可能找到通往同一目标的替代路径，同时仍然确保它们交付了预期结果。对于复杂流程，可以把评测拆成离散 checkpoints，要求某些具体状态变化已经发生，而不是试图验证每个中间步骤。
长周期对话管理。生产 agents 经常参与跨越数百轮的对话，因此需要谨慎的上下文管理策略。随着对话延长，标准 context windows 会变得不够用，需要智能压缩和记忆机制。我们实现了一些模式，让 agents 在进入新任务之前，总结已经完成的工作阶段，并把关键信息存入外部 memory。
当接近上下文限制时，agents 可以生成带有干净上下文的新 subagents，并通过谨慎 handoffs 保持连续性。此外，它们可以从 memory 中检索已存储上下文，例如研究计划，而不是在达到上下文限制时丢失之前的工作。这种分布式方法可以防止上下文溢出，同时在长时间交互中保持对话连贯性。
让 subagent 输出到 filesystem，以尽量减少“传话游戏”。对于某些类型的结果，直接的 subagent 输出可以绕过主协调器，同时提升保真度和性能。与其要求 subagents 把所有内容都通过 lead agent 传递，不如实现 artifact systems，让专门 agents 能够创建独立持久化的输出。Subagents 调用工具，把自己的工作存入外部系统，然后把轻量引用传回协调器。
这可以防止多阶段处理中的信息损失，并减少通过对话历史复制大型输出带来的 token 开销。这种模式尤其适合结构化输出，例如代码、报告或数据可视化。在这些场景中，subagent 的专门 prompt 往往比通过通用协调器过滤后产生更好的结果。