How we built our multi-agent research system

Claude 现已具备 研究功能，能够跨网页、Google Workspace 以及任何集成进行搜索，以完成复杂任务。

这个多智能体系统从原型到生产环境的历程，让我们在系统架构、工具设计和提示工程方面获得了关键的经验教训。多智能体系统由多个协同工作的智能体（在循环中自主使用工具的 LLM）组成。我们的研究功能包含一个根据用户查询规划研究过程的智能体，随后使用工具创建并行智能体来同时搜索信息。多智能体系统在智能体协调、评估和可靠性方面带来了新的挑战。

本文详细阐述了对我们行之有效的原则——希望您在构建自己的多智能体系统时会发现它们同样有用。

多智能体系统的优势

研究工作涉及开放性问题，很难提前预测所需的步骤。你无法为探索复杂主题硬编码一条固定路径，因为这一过程本质上是动态的且依赖于路径。人们在开展研究时，往往会根据发现不断更新自己的方法，追随调查过程中浮现的线索。

这种不可预测性使 AI 智能体特别适合研究任务。研究要求随着调查的展开，具备灵活转向或探索边缘关联的灵活性。模型必须自主运行多个回合，根据中间发现来决定要追寻哪些方向。线性的单次执行流水线无法处理这些任务。

搜索的本质是压缩：从海量语料中提炼洞见。子智能体通过在各自的上下文窗口中并行运行来促进压缩，同时探索问题的不同方面，然后将最重要的 token 浓缩后交给主导研究的智能体。每个子智能体还提供了关注点分离——各自拥有不同的工具、提示和探索轨迹——这减少了路径依赖，并使深入、独立的研究成为可能。

一旦智能达到某个阈值，多智能体系统就成为提升性能的重要途径。例如，尽管在过去的 10 万年里，人类个体变得更聪明，但在信息时代，由于我们的集体智能和协调能力，人类社会的能力呈指数级增长。即使是具备通用智能的智能体，作为个体运作时也会面临限制；智能体群体可以完成远超个体的工作。

我们的内部评估显示，多智能体研究系统在涉及同时追寻多个独立方向的广度优先查询方面表现尤为出色。我们发现，以 Claude Opus 4 为主导智能体、Claude Sonnet 4 为子智能体的多智能体系统，在我们的内部研究评估中比单智能体 Claude Opus 4 高出 90.2%。例如，当被要求找出 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 系统采用多智能体架构和编排者-工作者（orchestrator-worker）模式，由一个主智能体协调整个过程，并将任务委派给并行运行的专门化子智能体。

当用户提交查询时，主智能体会对其进行分析、制定策略，并生成子智能体来同时探索不同的方面。如上图所示，子智能体充当智能过滤器，通过迭代使用搜索工具来收集信息（在本例中是关于 2025 年 AI 智能体公司的信息），然后将公司列表返回给主智能体，由它来汇总出最终答案。

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

研究智能体的提示工程与评估

多智能体系统与单智能体系统存在关键差异，其中包括协调复杂度的快速增长。早期智能体犯过一些错误，比如为简单查询生成 50 个 subagent、无休止地在网上搜寻不存在的来源，以及用过多的更新互相干扰。由于每个智能体都由提示词引导，提示工程是我们改善这些行为的主要手段。以下是我们学到的一些智能体提示原则：

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

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

对智能体进行有效评估

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

立即用小样本开始评估。在智能体开发的早期阶段，改动往往会带来显著影响，因为随处可见唾手可得的改进空间。一次提示词微调就可能将成功率从 30% 提升到 80%。在效应量如此之大的情况下，只需几个测试用例就能发现变化。我们从一组约 20 个代表真实使用模式的查询开始。测试这些查询通常能让我们清楚地看到改动的影响。我们经常听到 AI 开发团队迟迟不创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好的做法是立即用少量示例开始小规模测试，而不是拖到能够构建更全面的评估时才开始。

做得好的 LLM-as-judge（LLM 评判）评估是可以规模化的。研究产出难以通过程序化方式评估，因为它们是自由格式的文本，且很少有唯一正确答案。LLM 天然适合为输出打分。我们使用了一个 LLM 评判者，依据评分标准（rubric）中的准则对每个输出进行评估：事实准确性（论断是否与来源相符？）、引用准确性（所引用的来源是否与论断相符？）、完整性（是否覆盖了所有要求的内容？）、来源质量（是否优先使用一手来源而非质量较低的二手来源？）以及工具使用效率（是否以合理的次数使用了正确的工具？）。我们尝试过用多个评判者分别评估每个组成部分，但发现单次 LLM 调用配合单个提示词、输出 0.0-1.0 的分数及通过/不通过的等级，是最稳定且最符合人类判断的方式。当评估测试用例确实有明确答案时，这种方法尤为有效，我们可以直接用 LLM 评判者检查答案是否正确（例如：它是否准确列出了研发（R&D）预算排名前 3 的制药公司？）。使用 LLM 作为评判者让我们得以规模化地评估数百个输出。

人工评估能发现自动化遗漏的问题。测试智能体的人员能发现评估遗漏的边缘情况，包括对异常查询产生幻觉答案、系统故障，或微妙的来源选择偏差。在我们的案例中，人工测试人员注意到，我们的早期智能体总是选择经过 SEO 优化的内容农场，而不选权威但排名较低的来源，例如学术 PDF 或个人博客。在提示词中加入来源质量启发式规则有助于解决这一问题。即使在自动化评估的时代，人工测试仍然不可或缺。

多智能体系统具有涌现行为，这些行为并非通过特定编程产生。例如，对主导智能体（lead agent）的微小改动可能会不可预测地改变子智能体的行为方式。成功的关键在于理解交互模式，而不仅仅是个体智能体的行为。因此，针对这些智能体的最佳提示词不仅仅是严格的指令，而是协作框架，定义了分工、解决问题的方式以及工作量预算。要做好这一点，需要精心的提示词和工具设计、可靠的启发式规则、可观测性以及紧密的反馈闭环。 请参阅我们 Cookbook 中的开源提示词，获取我们系统的示例提示词。

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

在传统软件中，一个 bug 可能会破坏某项功能、降低性能或导致宕机。而在智能体系统中，微小的改动会级联引发巨大的行为变化，这使得为必须在长时间运行的进程中维持状态的复杂智能体编写代码变得异常困难。

智能体是有状态的，错误会不断累积。智能体可以长时间运行，并在多次工具调用之间保持状态。这意味着我们需要持久地执行代码，并在过程中处理错误。如果没有有效的缓解措施，微小的系统故障对智能体来说可能是灾难性的。当错误发生时，我们不能简单地从头重启：重启代价高昂，也会让用户感到沮丧。因此，我们构建了能够从错误发生时智能体所处的位置恢复运行的系统。我们还利用模型的智能来优雅地处理问题：例如，让智能体知道某个工具正在失败并让它自行调整，效果出奇地好。我们将基于 Claude 构建的 AI 智能体的适应性与重试逻辑和定期检查点等确定性保障措施相结合。

调试受益于新方法。智能体会做出动态决策，即使提示词完全相同，每次运行之间也存在非确定性。这使得调试变得更加困难。例如，用户会报告智能体“找不到明显的信息”，但我们看不到原因。是智能体使用了糟糕的搜索查询？选择了不佳的信息来源？还是遇到了工具故障？添加完整的生产环境追踪让我们能够诊断智能体失败的原因，并系统地修复问题。除了标准的可观测性之外，我们还监控智能体的决策模式和交互结构——这一切都不会监控单个对话的内容，以维护用户隐私。这种高层级的可观测性帮助我们诊断根本原因、发现意外行为并修复常见故障。

部署需要仔细协调。 智能体系统是由提示词、工具和执行逻辑构成的高度有状态的网络，几乎不间断地运行。这意味着每当我们部署更新时，智能体可能正处于其进程中的任何位置。因此，我们需要防止我们出于善意的代码更改破坏现有的智能体。我们无法同时将每个智能体更新到新版本。相反，我们使用 彩虹部署 来避免干扰正在运行的智能体，即在保持新旧版本同时运行的情况下，逐步将流量从旧版本转移到新版本。

同步执行会造成瓶颈。目前，我们的主智能体同步执行子智能体，需要等待每组子智能体完成后才能继续。这简化了协调，但在智能体之间的信息流中造成了瓶颈。例如，主智能体无法引导子智能体，子智能体之间无法协调，而整个系统可能因等待单个子智能体完成搜索而被阻塞。异步执行将带来额外的并行性：多个智能体并发工作，并在需要时创建新的子智能体。但这种异步性在结果协调、状态一致性以及子智能体间的错误传播方面带来了挑战。随着模型能够处理更长、更复杂的研究任务，我们预期性能上的提升将足以证明这种复杂性的合理性。

结语

构建 AI 智能体时，最后一英里往往占据整个旅程的大部分。在开发者机器上能正常运行的代码库，需要大量工程工作才能成为可靠的生产系统。智能体系统中错误的复合性意味着，对传统软件而言的小问题可能会让智能体完全偏离轨道。一步失败就可能导致智能体探索完全不同的轨迹，产生不可预测的结果。出于本文所述的所有原因，原型与生产之间的差距往往比预期更大。

尽管存在这些挑战，多智能体系统已被证明对开放式研究任务很有价值。用户表示，Claude 帮助他们发现了未曾考虑过的商业机会、处理复杂的医疗保健选择、解决棘手的技术漏洞，并通过发现他们独自无法找到的研究关联节省了多达数天的工作时间。通过精心的工程、全面的测试、注重细节的提示词和工具设计、稳健的运维实践，以及对当前智能体能力有深刻理解的研究、产品和工程团队之间的紧密协作，多智能体研究系统可以在大规模下可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。

致谢

本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。这项工作凝聚了 Anthropic 多个团队的集体努力，正是他们使 Research 功能成为可能。特别感谢 Anthropic 应用工程团队，他们的辛勤付出将这个复杂的多智能体系统推向了生产环境。我们还要感谢早期用户提供的宝贵反馈。

附录

以下是一些关于多智能体系统的其他杂项技巧。

对多轮改变状态的智能体进行终态评估。评估在多轮对话中修改持久状态的智能体具有独特的挑战。与只读研究任务不同，每个操作都可能改变后续步骤的环境，产生传统评估方法难以处理的依赖关系。我们发现，专注于终态评估而非逐轮分析是行之有效的。与其判断智能体是否遵循了特定流程，不如评估它是否达到了正确的最终状态。这种方法承认智能体可能找到通往同一目标的其他路径，同时仍能确保它们交付预期结果。对于复杂的工作流，可将评估分解为若干离散的检查点——在这些节点上应该发生特定的状态变化——而不是试图验证每一个中间步骤。

长程对话管理。生产环境的智能体常常进行跨越数百轮的对话，这需要精心的上下文管理策略。随着对话不断延长，标准的上下文窗口变得不够用，这就需要智能的压缩与记忆机制。我们实现了一些模式：智能体在开始新任务之前，会总结已完成的工作阶段，并将关键信息存储到外部记忆中。当接近上下文限制时，智能体可以生成拥有干净上下文的全新子智能体，同时通过细致的交接保持连续性。此外，它们可以从记忆中检索已存储的上下文（如研究计划），而不是在达到上下文限制时丢失之前的工作。这种分布式方法既避免了上下文溢出，又在长时间交互中保持了对话的连贯性。

将子智能体输出写入文件系统，以尽量减少“传话游戏”。对于某些类型的结果，子智能体的直接输出可以绕过主协调器，从而同时提升保真度和性能。与其要求子智能体将所有内容都通过主管智能体传达，不如实现工件（artifact）系统，让专门的智能体可以创建能够独立持久化的输出。子智能体调用工具将其工作存储到外部系统中，然后向协调器传回轻量级引用。这可以防止多阶段处理过程中的信息丢失，并减少在对话历史中复制大型输出所带来的 token 开销。这一模式尤其适用于代码、报告或数据可视化等结构化输出，因为子智能体的专用提示词比经由通用协调器过滤能产生更好的结果。