我们如何构建多智能体研究系统

Claude 现在具备了研究能力，能够搜索整个网络、Google Workspace 以及任何集成，以完成复杂任务。

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

本文将剖析对我们有效的原则——希望你在构建自己的多智能体系统时能发现它们的用处。

研究工作涉及开放式问题，很难提前预测所需的步骤。你无法为探索复杂主题硬编码一条固定路径，因为过程本质上是动态且路径依赖的。当人们进行研究时，他们倾向于根据发现不断调整方法，顺着调查过程中出现的线索前进。

这种不可预测性使得 AI 智能体特别适合研究任务。研究需要灵活性，以便在调查展开时转向或探索横向联系。模型必须自主运行多个回合，根据中间发现决定要探索的方向。线性的、一次性的流水线无法处理这些任务。

搜索的本质是压缩：从海量语料中提炼洞见。子智能体通过并行运行各自的上下文窗口来促进压缩，同时探索问题的不同方面，然后为首席研究智能体浓缩最重要的 token。每个子智能体还提供了关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖性，并实现了彻底、独立的调查。

一旦智能达到某个阈值，多智能体系统就成为扩展性能的关键方式。例如，尽管个体人类在过去 10 万年间变得更聪明，但人类社会在信息时代的能力却呈指数级增长，这得益于我们的集体智慧和协调能力。即使是通用智能体，在作为个体运行时也面临限制；智能体群体可以完成更多任务。

我们的内部评估显示，多智能体研究系统特别擅长广度优先的查询，这些查询涉及同时追求多个独立方向。我们发现，以 Claude Opus 4 作为首席智能体、Claude Sonnet 4 作为子智能体的多智能体系统，在我们的内部研究评估中比单智能体 Claude Opus 4 高出 90.2%。例如，当被要求找出标普 500 信息技术板块所有公司的董事会成员时，多智能体系统通过将任务分解给子智能体找到了正确答案，而单智能体系统则因缓慢的顺序搜索而未能找到答案。

多智能体系统之所以有效，主要是因为它们能花费足够的 token 来解决问题。在我们的分析中，三个因素解释了 BrowseComp 评估（测试浏览智能体定位难以找到信息的能力）中 95% 的性能差异。我们发现，token 使用量本身解释了 80% 的差异，工具调用次数和模型选择是另外两个解释因素。这一发现验证了我们的架构，该架构将工作分布到具有独立上下文窗口的智能体上，以增加并行推理的容量。最新的 Claude 模型充当了 token 使用的大型效率倍增器，因为升级到 Claude Sonnet 4 带来的性能提升比在 Claude Sonnet 3.7 上加倍 token 预算更大。多智能体架构有效地扩展了超出单智能体限制的任务的 token 使用量。

但有一个缺点：在实践中，这些架构会快速消耗 token。在我们的数据中，智能体通常比聊天交互多使用约 4 倍的 token，而多智能体系统比聊天多使用约 15 倍的 token。为了经济可行性，多智能体系统需要任务的价值足够高，以支付性能提升的成本。此外，某些要求所有智能体共享相同上下文或涉及智能体之间大量依赖关系的领域，目前并不适合多智能体系统。例如，大多数编码任务涉及的可真正并行化的任务比研究少，而且 LLM 智能体在实时协调和委派给其他智能体方面还不够出色。我们发现，多智能体系统擅长那些涉及大量并行化、信息超出单个上下文窗口以及需要与众多复杂工具交互的高价值任务。

我们的研究系统使用了一种多智能体架构，采用编排器-工作者模式，其中首席智能体协调流程，同时将任务委派给并行运行的专业子智能体。

当用户提交查询时，首席智能体分析它，制定策略，并生成子智能体同时探索不同方面。如上图所示，子智能体通过迭代使用搜索工具收集信息（本例中是关于 2025 年的 AI 智能体公司），然后向首席智能体返回公司列表，以便其编译最终答案。

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

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

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

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

立即用小样本开始评估。在早期智能体开发中，变化往往会产生巨大影响，因为有很多唾手可得的成果。一个提示调整可能会将成功率从 30% 提升到 80%。由于效果如此显著，你只需几个测试用例就能发现变化。我们从一组大约 20 个代表实际使用模式的查询开始。测试这些查询通常能让我们清楚地看到变化的影响。我们经常听到 AI 开发团队推迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有用。然而，最好立即用少量示例开始小规模测试，而不是等到能构建更全面的评估时才做。

LLM 作为评判者的评估方法如果做得好，可以规模化。研究输出很难通过编程方式评估，因为它们是自由格式的文本，很少有单一正确答案。LLM 自然适合对输出进行评分。我们使用了一个 LLM 评判者，根据评分标准中的标准评估每个输出：事实准确性（声明是否与来源匹配？）、引用准确性（引用的来源是否与声明匹配？）、完整性（是否涵盖了所有要求方面？）、来源质量（是否使用了主要来源而非质量较低的次要来源？）和工具效率（是否合理次数地使用了正确的工具？）。我们尝试了多个评判者来评估每个组件，但发现使用单个 LLM 调用、单个提示输出 0.0-1.0 的分数和及格-不及格等级是最一致且与人类判断最相符的。当评估测试用例确实有明确答案时，这种方法特别有效，我们可以使用 LLM 评判者简单地检查答案是否正确（例如，它是否准确列出了研发预算前三大的制药公司？）。使用 LLM 作为评判者使我们能够可规模化地评估数百个输出。

人工评估能捕捉到自动化遗漏的问题。测试智能体的人会发现评估遗漏的边缘情况。这些包括对异常查询的幻觉答案、系统故障或微妙的来源选择偏差。在我们的案例中，人工测试者注意到我们的早期智能体始终选择 SEO 优化的内容农场，而不是权威性更高但排名较低的来源，如学术 PDF 或个人博客。在我们的提示中添加来源质量启发式方法有助于解决这个问题。即使在自动化评估的世界里，手动测试仍然至关重要。

多智能体系统具有涌现行为，这些行为无需特定编程就会出现。例如，对首席智能体的微小更改可能会不可预测地改变子智能体的行为。成功需要理解交互模式，而不仅仅是单个智能体的行为。因此，这些智能体的最佳提示不仅仅是严格的指令，而是定义分工、问题解决方法和努力预算的协作框架。要正确做到这一点，依赖于仔细的提示和工具设计、可靠的启发式方法、可观测性和紧密的反馈循环。请参阅我们 Cookbook 中的开源提示，以了解我们系统中的示例提示。

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

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

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

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

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

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

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

作者：Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford。这项工作反映了 Anthropic 多个团队的集体努力，他们使研究功能成为可能。特别感谢 Anthropic 应用工程团队，他们的奉献精神将这个复杂的多智能体系统带入了生产环境。我们也感谢早期用户提供的出色反馈。

以下是针对多智能体系统的一些额外杂项提示。

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

长周期对话管理。生产环境中的智能体经常参与跨越数百轮的对话，需要仔细的上下文管理策略。随着对话的延长，标准的上下文窗口变得不足，需要智能的压缩和记忆机制。我们实现了这样的模式：智能体总结已完成的工作阶段，并在进入新任务之前将关键信息存储在外部记忆中。当上下文限制接近时，智能体可以生成具有干净上下文的新子智能体，同时通过仔细的交接保持连续性。此外，它们可以从记忆中检索存储的上下文（如研究计划），而不是在达到上下文限制时丢失之前的工作。这种分布式方法可以防止上下文溢出，同时在扩展的交互中保持对话的连贯性。

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