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