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