我们的研究功能利用多个 Claude 智能体，更有效地探索复杂主题。本文将分享构建该系统时遇到的工程挑战以及我们从中汲取的经验教训。

Claude 现已具备研究能力，能够跨网络、Google Workspace 以及各类集成应用进行搜索，以完成复杂任务。

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

本文将剖析对我们行之有效的原则——希望你在构建自己的多智能体系统时，会觉得这些原则有用。

多智能体系统的优势

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

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

搜索的本质是压缩：从海量语料中提炼洞见。子智能体通过并行运行各自独立的上下文窗口，同时探索问题的不同维度，再将最重要的模型 token 压缩提炼后提交给主研究智能体，从而加速这一压缩过程。每个子智能体还实现了关注点分离——使用不同的工具、提示词和探索路径——这降低了路径依赖性，使得深入、独立的调查成为可能。

一旦智能达到某个阈值，多智能体系统就成为扩展性能的关键方式。例如，尽管在过去十万年间个体人类的智力有所提升，但在信息时代，人类社会的能力呈指数级增长，这得益于我们的集体智慧与协调能力。即便是通用智能体，在独立运作时也会面临局限；而多个智能体组成的群体能够完成远超个体的成就。

我们的内部评估显示，多智能体研究系统尤其擅长广度优先的查询——即需要同时推进多个独立方向的任务。我们发现，以 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。在我们的数据中，智能体通常使用的模型 token 量大约是聊天交互的 4 倍，而多智能体系统使用的模型 token 量大约是聊天的 15 倍。为了经济上的可行性，多智能体系统需要应用于任务价值足够高、能够为性能提升买单的场景。此外，某些领域要求所有智能体共享相同的上下文，或者涉及智能体之间大量的依赖关系，这些领域目前并不适合采用多智能体系统。例如，大多数编码任务中真正可并行化的任务比研究任务要少，而且大语言模型智能体在实时协调和委托任务给其他智能体方面还不太擅长。我们发现，多智能体系统在以下方面表现出色：涉及大量并行化的高价值任务、信息量超出单个上下文窗口的任务，以及需要与众多复杂工具交互的任务。

研究系统的架构概览

我们的研究系统采用了一种具有编排器-工作者模式的多智能体架构，其中主智能体负责协调整个流程，同时将任务委托给并行运行的专门子智能体。

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

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

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

多智能体系统与单智能体系统存在关键差异，其中协调复杂性的快速增长尤为突出。早期智能体常出现以下错误：为简单查询生成50个子智能体、无休止地在网络上搜索不存在的来源、以及通过过多更新相互干扰。由于每个智能体都由提示词驱动，提示词工程便成为我们改进这些行为的主要手段。以下是我们总结的智能体提示词设计原则：

1. 像你的智能体一样思考。要迭代优化提示词，就必须理解其效果。为此，我们利用控制台构建了模拟环境，使用系统中完全相同的提示词和工具，然后逐步观察智能体的工作过程。这能立即暴露出故障模式：智能体在已获得足够结果时仍继续运行、使用过于冗长的搜索查询、或选择错误的工具。有效的提示词设计依赖于建立准确的智能体心智模型，这能让最具影响力的改进变得显而易见。
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。但多智能体系统并非如此运作。即使起点完全相同，智能体也可能采取完全不同的有效路径来达成目标。一个智能体可能搜索三个来源，而另一个可能搜索十个，或者它们可能使用不同的工具来找到相同的答案。由于我们并不总是知道正确的步骤是什么，通常无法仅仅检查智能体是否遵循了我们预先规定的“正确”步骤。相反，我们需要灵活的评估方法，既能判断智能体是否达成了正确的结果，同时也能评估其是否遵循了合理的过程。

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

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

人工评估能捕捉到自动化手段遗漏的问题。人类测试人员在测试智能体时，会发现评估未能覆盖的边缘情况。这些情况包括：针对不常见查询产生的模型幻觉回答、系统故障，或是微妙的来源选择偏差。在我们的案例中，人工测试人员注意到，早期的智能体始终倾向于选择经过搜索引擎优化的内容农场，而非权威性更高但排名靠后的来源，例如学术PDF或个人博客。在提示词中加入来源质量启发式规则，帮助解决了这一问题。即便在自动化评估盛行的时代，人工测试依然不可或缺。

多智能体系统会涌现出未经特定编程的行为。例如，对主智能体进行微小改动，可能会以不可预测的方式改变子智能体的行为。要取得成功，需要理解交互模式，而不仅仅是单个智能体的行为。因此，针对这些智能体的最佳提示词，并非仅仅是严格的指令，而是定义分工、问题解决方法和算力预算的协作框架。要正确实现这一点，依赖于精心的提示词设计和工具设计、可靠的启发式规则、可观测性以及紧密的反馈循环。请参阅我们 Cookbook 中的开源提示词，以了解我们系统中的示例提示词。

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

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

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

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

部署需要谨慎协调。智能体系统是由提示词、工具和执行逻辑组成的高度有状态网络，几乎持续不断地运行。这意味着，每当我们部署更新时，智能体可能正处于其流程中的任何位置。因此，我们需要防止我们善意的代码变更破坏现有的智能体。我们无法同时将所有智能体更新到新版本。相反，我们采用彩虹部署来避免中断正在运行的智能体，方法是逐步将流量从旧版本迁移到新版本，同时让两者并行运行。

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

结论

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

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

致谢

本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。这项工作凝聚了 Anthropic 多个团队为实现研究功能所付出的集体努力。特别感谢 Anthropic 应用工程团队，他们的奉献精神使这个复杂的多智能体系统得以投入生产。我们同样感谢早期用户提供的宝贵反馈。

附录

以下是一些针对多智能体系统的额外实用建议。

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

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

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

想了解更多？

探索课程