本文翻译自 Anthropic 官方博客：How we built our multi-agent research system
译者注：本文是 Anthropic Agent 开发最佳实践系列的重要组成部分，详细介绍了多智能体研究系统的构建过程。
Claude 现在具备了研究能力，可以在网络、Google Workspace 和任何集成中进行搜索，以完成复杂任务。
这个多智能体系统从原型到生产的过程，教会了我们关于系统架构、工具设计和提示工程的关键经验。多智能体系统由多个智能体（在循环中自主使用工具的 LLM）协同工作组成。我们的 Research 功能涉及一个基于用户查询规划研究流程的智能体，然后使用工具创建并行搜索信息的子智能体。具有多个智能体的系统在智能体协调、评估和可靠性方面带来了新挑战。
本文分解了对我们有效的原则——我们希望您在构建自己的多智能体系统时能发现它们有用。
多智能体系统的优势
研究工作涉及开放性问题，很难提前预测所需步骤。您无法为探索复杂主题硬编码固定路径，因为该过程本质上是动态的和路径依赖的。当人们进行研究时，他们倾向于根据发现不断更新方法，遵循调查过程中出现的线索。
这种不可预测性使 AI 智能体特别适合研究任务。研究需要根据调查的展开进行转向或探索切线连接的灵活性。模型必须自主运行许多轮次，基于中间发现决定追求哪些方向。线性、一次性管道无法处理这些任务。
搜索的本质是压缩：从大量语料库中提取洞察。子智能体通过在自己的上下文窗口中并行操作来促进压缩，同时探索问题的不同方面，然后将最重要的 token 压缩给主要研究智能体。每个子智能体还提供关注点分离——不同的工具、提示和探索轨迹——这减少了路径依赖并实现了彻底、独立的调查。
一旦智能达到阈值，多智能体系统就成为扩展性能的重要方式。例如，虽然单个人类在过去 100,000 年中变得更聪明，但人类社会在信息时代变得指数级更有能力，因为我们的集体智能和协调能力。即使一般智能智能体在单独操作时也面临限制；智能体组可以完成更多工作。
我们的内部评估显示，多智能体研究系统特别擅长涉及同时追求多个独立方向的广度优先查询。我们发现，使用 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 智能体尚不擅长实时与其他智能体协调和委派。我们发现，多智能体系统擅长涉及大量并行化、超过单个上下文窗口的信息以及与众多复杂工具交互的有价值任务。
Research 的架构概述
我们的 Research 系统使用多智能体架构，采用协调器-工作器模式，其中一个主导智能体协调流程，同时委派给并行操作的专用子智能体。
多智能体架构的实际应用：用户查询流经主导智能体，该智能体创建专门的子智能体并行搜索不同方面。
当用户提交查询时，主导智能体分析它，制定策略，并生成子智能体同时探索不同方面。如上图所示，子智能体充当智能过滤器，通过迭代使用搜索工具收集信息（在本例中是 2025 年的 AI 智能体公司），然后将公司列表返回给主导智能体，以便它可以编译最终答案。
使用检索增强生成（RAG）的传统方法使用静态检索。也就是说，它们获取与输入查询最相似的一组块，并使用这些块生成响应。相反，我们的架构使用多步搜索，动态查找相关信息，适应新发现，并分析结果以制定高质量答案。
流程图显示我们多智能体 Research 系统的完整工作流程。当用户提交查询时，系统创建一个 LeadResearcher 智能体，该智能体进入迭代研究过程。LeadResearcher 首先通过方法思考，并将其计划保存到 Memory 以持久化上下文。然后它创建具有特定研究任务的专门子智能体。每个子智能体独立执行网络搜索，使用交错思考评估工具结果，并将发现返回给 LeadResearcher。LeadResearcher 综合这些结果，并决定是否需要更多研究。一旦收集了足够的信息，系统退出研究循环并将所有发现传递给 CitationAgent，该智能体处理文档和研究报告以识别引用的具体位置。
研究智能体的提示工程和评估
多智能体系统与单智能体系统有关键区别，包括协调复杂性快速增长。早期的智能体犯了一些错误，例如为简单查询生成 50 个子智能体，无休止地搜索网络以寻找不存在的源，并用过多的更新分散彼此的注意力。由于每个智能体都由提示驱动，提示工程是我们改进这些行为的主要杠杆。以下是我们学到的关于提示智能体的一些原则：
像您的智能体一样思考。 要迭代提示，您必须了解它们的效果。为了帮助我们做到这一点，我们使用 Console 中的确切提示和工具构建模拟，然后逐步观察智能体工作。这立即揭示了失败模式：智能体在已有足够结果时继续，使用过于冗长的搜索查询，或选择错误的工具。有效的提示依赖于开发智能体的准确心理模型，这可以使最有影响力的变化变得明显。
教导协调器如何委派。 在我们的系统中，主导智能体将查询分解为子任务并描述给子智能体。每个子智能体需要目标、输出格式、关于使用的工具和源的指导以及清晰的任务边界。没有详细的任务描述，智能体会重复工作、留下差距或未能找到必要信息。我们最初允许主导智能体给出简单、简短的指令，如"研究半导体短缺"，但发现这些指令通常足够模糊，以至于子智能体误解了任务或执行与其他智能体完全相同的搜索。例如，一个子智能体探索 2021 年汽车芯片危机，而另外两个重复工作调查当前 2025 年供应链，没有有效的分工。
根据查询复杂性扩展工作。 智能体难以判断不同任务的适当工作量，因此我们在提示中嵌入了扩展规则。简单的事实查找只需要 1 个智能体进行 3-10 次工具调用，直接比较可能需要 2-4 个子智能体，每个进行 10-15 次调用，而复杂研究可能使用超过 10 个具有明确划分职责的子智能体。这些明确的指南帮助主导智能体有效地分配资源，并防止对简单查询的过度投资，这是我们早期版本中的常见失败模式。
工具设计和选择至关重要。 智能体-工具接口与人类-计算机接口一样关键。使用正确的工具是高效的——通常，它是严格必要的。例如，一个在网络中搜索仅存在于 Slack 中的上下文的智能体从一开始就注定失败。随着为模型提供外部工具访问权限的 MCP 服务器，这个问题复合了，因为智能体遇到未见过的工具，其描述质量差异很大。我们给智能体明确的启发式方法：例如，首先检查所有可用的工具，将工具使用与用户意图匹配，在网络中搜索广泛的外部探索，或更喜欢专用工具而不是通用工具。糟糕的工具描述可能会让智能体完全走错路，因此每个工具都需要独特的目的和清晰的描述。
让智能体自我改进。 我们发现 Claude 4 模型可以是出色的提示工程师。当给出提示和失败模式时，它们能够诊断智能体失败的原因并建议改进。我们甚至创建了一个工具测试智能体——当给出有缺陷的 MCP 工具时，它尝试使用该工具，然后重写工具描述以避免失败。通过测试工具几十次，该智能体发现了关键细微差别和错误。这个改进工具工效学的过程导致未来使用新描述的智能体任务完成时间减少了 40%，因为它们能够避免大多数错误。
先宽后窄。 搜索策略应反映专家人类研究：在钻入细节之前探索景观。智能体通常默认于过长、具体的查询，返回的结果很少。我们通过提示智能体开始时使用简短、广泛的查询，评估可用的内容，然后逐步缩小重点来抵消这种趋势。
指导思考过程。 扩展思考模式使 Claude 在可见的思考过程中输出额外的 token，可以作为可控的草稿本。主导智能体使用思考来规划其方法，评估哪些工具适合任务，确定查询复杂性和子智能体数量，并定义每个子智能体的角色。我们的测试表明，扩展思考改进了指令遵循、推理和效率。子智能体也规划，然后在工具结果后使用交错思考来评估质量、识别差距并完善其下一个查询。这使得子智能体更有效地适应任何任务。
并行工具调用改变速度和性能。 复杂的研究任务自然涉及探索许多源。我们的早期智能体执行顺序搜索，这非常慢。为了提高速度，我们引入了两种并行化：（1）主导智能体并行而不是串行启动 3-5 个子智能体；（2）子智能体并行使用 3+ 个工具。这些变化将复杂查询的研究时间减少了多达 90%，允许 Research 在几分钟而不是几小时内完成更多工作，同时覆盖比其他系统更多的信息。
我们的提示策略专注于灌输良好的启发式方法，而不是严格的规则。我们研究了熟练的人类如何处理研究任务，并将这些策略编码在我们的提示中——策略如将困难问题分解为更小的任务，仔细评估源的质量，根据新信息调整搜索方法，以及识别何时专注于深度（详细调查一个主题）与广度（并行探索许多主题）。我们还通过设置明确的防护栏主动减轻意外的副作用，以防止智能体失控。最后，我们专注于具有可观察性和测试用例的快速迭代循环。
有效的智能体评估
良好的评估对于构建可靠的 AI 应用程序至关重要，智能体也不例外。然而，评估多智能体系统带来了独特的挑战。传统的评估通常假设 AI 每次都遵循相同的步骤：给定输入 X，系统应遵循路径 Y 以产生输出 Z。但多智能体系统不是这样工作的。即使有相同的起点，智能体也可能采取完全不同的有效路径来达到目标。一个智能体可能搜索三个源，而另一个搜索十个，或者它们可能使用不同的工具来找到相同的答案。因为我们并不总是知道正确的步骤是什么，所以我们通常不能只是检查智能体是否遵循了我们预先规定的"正确"步骤。相反，我们需要灵活的评估方法来判断智能体是否实现了正确的结果，同时也遵循了合理的过程。
立即开始评估，使用小样本。 在早期智能体开发中，变化往往产生巨大影响，因为有丰富的低挂果实。提示调整可能会将成功率从 30% 提高到 80%。有了这么大的效果大小，您只需几个测试用例就可以发现变化。我们从大约 20 个代表真实使用模式的查询开始。经常测试这些查询使我们能够清楚地看到变化的影响。我们经常听到 AI 开发团队延迟创建评估，因为他们认为只有具有数百个测试用例的大型评估才有用。但是，最好立即开始使用几个示例进行小规模测试，而不是延迟直到您可以构建更彻底的评估。
LLM 作为判断的评估在做得好时扩展。 研究输出难以通过编程评估，因为它们是自由形式的文本，很少有一个正确的答案。LLM 自然适合对输出进行分级。我们使用了一个 LLM 判断者，根据标准评估每个输出：事实准确性（声明是否与源匹配？）、引用准确性（引用的源是否与声明匹配？）、完整性（是否涵盖了所有请求的方面？）、源质量（它是否使用主要源而不是低质量的次要源？）和工具效率（它是否合理次数地使用了正确的工具？）。我们尝试了多个判断者来评估每个组件，但发现单个 LLM 调用使用单个提示输出 0.0-1.0 的分数和通过/失败等级是最一致的，并与人类判断一致。当评估测试用例确实有明确答案时，这种方法特别有效，我们可以使用 LLM 判断者简单地检查答案是否正确（即，它是否准确列出了研发预算前 3 大的制药公司？）。使用 LLM 作为判断者使我们能够可扩展地评估数百个输出。
人类评估捕获自动化遗漏的内容。 测试智能体的人员发现评估遗漏的边缘情况。这些包括异常查询上的幻觉答案、系统故障或微妙的源选择偏差。在我们的案例中，人类测试人员注意到我们的早期智能体始终选择 SEO 优化的内容农场而不是权威但排名较低的源，如学术 PDF 或个人博客。向我们的提示添加源质量启发式帮助解决了这个问题。即使在自动化评估的世界中，手动测试仍然至关重要。
多智能体系统具有紧急行为，这些行为在没有特定编程的情况下出现。例如，对主导智能体的小变化可能会不可预测地改变子智能体的行为。成功需要理解交互模式，而不仅仅是单个智能体行为。因此，这些智能体的最佳提示不仅仅是严格的指令，而是定义分工、解决问题方法和工作量预算的协作框架。正确地做到这一点依赖于仔细的提示和工具设计、可靠的启发式方法、可观察性和紧密的反馈循环。请参阅我们的 Cookbook 中的开源提示，了解我们系统中的示例提示。
生产可靠性和工程挑战
在传统软件中，错误可能会破坏功能、降低性能或导致中断。在智能体系统中，微小的变化会级联成大的行为变化，这使得为必须在长时间运行过程中保持状态的复杂智能体编写代码变得异常困难。
智能体是有状态的，错误会复合。 智能体可以运行很长时间，在许多工具调用中保持状态。这意味着我们需要持久地执行代码并沿途处理错误。没有有效的缓解措施，微小的系统故障对智能体可能是灾难性的。当错误发生时，我们不能只是从头重新开始：重新启动既昂贵又令用户沮丧。相反，我们构建了可以从智能体发生错误时恢复的系统。我们还使用模型的智能优雅地处理问题：例如，让智能体知道工具何时失败并让它适应效果出奇地好。我们将基于 Claude 构建的 AI 智能体的适应性与确定性保障措施（如重试逻辑和定期检查点）结合起来。
调试受益于新方法。 智能体做出动态决策，在运行之间是非确定性的，即使有相同的提示。这使得调试更难。例如，用户会报告智能体"没有找到明显信息"，但我们无法看到原因。智能体是否使用了糟糕的搜索查询？选择了糟糕的源？遇到工具失败？添加完整的生产追踪使我们能够诊断智能体失败的原因并系统地修复问题。除了标准的可观察性之外，我们还监控智能体决策模式和交互结构——所有这些都不监控单个对话的内容，以维护用户隐私。这种高级可观察性帮助我们诊断根本原因、发现意外行为并修复常见故障。
部署需要仔细协调。 智能体系统是高度有状态的提示、工具和执行逻辑的网络，几乎连续运行。这意味着每当我们部署更新时，智能体可能处于其过程的任何位置。因此，我们需要防止我们好意的代码更改破坏现有的智能体。我们不能同时将每个智能体更新到新版本。相反，我们使用彩虹部署来避免破坏正在运行的智能体，通过逐步将流量从旧版本转移到新版本，同时保持两者同时运行。
同步执行造成瓶颈。 目前，我们的主导智能体同步执行子智能体，等待每组子智能体完成后再继续。这简化了协调，但在智能体之间的信息流中造成瓶颈。例如，主导智能体无法引导子智能体，子智能体无法协调，整个系统可能在等待单个子智能体完成搜索时被阻止。异步执行将实现额外的并行性：智能体并发工作并在需要时创建新的子智能体。但这种异步性增加了结果协调、状态一致性和跨子智能体的错误传播的挑战。随着模型可以处理更长和更复杂的研究任务，我们期望性能提升将证明复杂性是合理的。
结论
在构建 AI 智能体时，最后一英里往往成为大部分旅程。在开发人员机器上工作的代码库需要大量的工程才能成为可靠的生产系统。智能体系统中错误的复合性质意味着传统软件的小问题可能完全使智能体脱轨。一步失败可能导致智能体探索完全不同的轨迹，导致不可预测的结果。由于本文描述的所有原因，原型和生产之间的差距往往比预期的更宽。
尽管有这些挑战，多智能体系统已被证明对开放性研究任务很有价值。用户说 Claude 帮助他们发现了他们未曾考虑的商业机会，导航复杂的医疗保健选项，解决棘手的技术错误，并通过揭露他们不会独自发现的研究联系节省了多达几天的工作。多智能体研究系统可以通过仔细的工程、全面的测试、细节导向的提示和工具设计、强大的运营实践以及在研究、产品和工程团队之间紧密协作（这些团队对当前智能体能力有深刻理解）可靠地大规模运行。我们已经在看到这些系统改变人们解决复杂问题的方式。
Clio 嵌入图显示人们今天使用 Research 功能的最常见方式。顶级用例类别是跨专业领域开发软件系统（10%）、开发和优化专业和技术内容（8%）、制定业务增长和收入生成策略（8%）、协助学术研究和教育材料开发（7%）、研究和验证有关人员、地点或组织的信息（5%）。
致谢
本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。这项工作反映了 Anthropic 几个团队的集体努力，他们使 Research 功能成为可能。特别感谢 Anthropic 应用程序工程团队，他们的奉献将这个复杂的多智能体系统投入生产。我们也感谢早期用户的出色反馈。
附录
以下是一些多智能体系统的额外杂项提示。
在多轮对话中变更状态的智能体的最终状态评估。 评估在多轮对话中修改持久状态的智能体提出了独特的挑战。与只读研究任务不同，每个操作都可以为后续步骤更改环境，创建传统评估方法难以处理的依赖关系。我们成功地专注于最终状态评估，而不是逐轮分析。而不是判断智能体是否遵循了特定过程，评估它是否达到了正确的最终状态。这种方法承认智能体可能找到相同目标的替代路径，同时仍然确保它们交付预期的结果。对于复杂的工作流程，将评估分解为离散的检查点，在这些检查点应该发生特定的状态变化，而不是尝试验证每个中间步骤。
长跨度对话管理。 生产智能体经常进行跨越数百轮的对话，需要仔细的上下文管理策略。随着对话的延长，标准上下文窗口变得不足，需要智能压缩和记忆机制。我们实现了智能体总结已完成的工作阶段并将重要信息存储在外部记忆中的模式，然后再继续新任务。当接近上下文限制时，智能体可以生成具有清晰上下文的新子智能体，同时通过仔细的交接保持连续性。此外，它们可以从记忆中检索存储的上下文（如研究计划），而不是在达到上下文限制时丢失以前的工作。这种分布式方法防止上下文溢出，同时在扩展交互中保持对话连贯性。
子智能体输出到文件系统以最小化"电话游戏"。 直接子智能体输出可以绕过某些类型结果的主协调器，提高保真度和性能。而不是要求子智能体通过主导智能体传达所有内容，实现工件系统，其中专用智能体可以创建独立持久化的输出。子智能体调用工具将其工作存储在外部系统中，然后将轻量级引用传递回协调器。这防止了多阶段处理期间的信息丢失，并减少了通过对话历史复制大输出的 token 开销。该模式特别适用于结构化输出，如代码、报告或数据可视化，其中子智能体的专用提示比通过通用协调器过滤产生更好的结果。