Peijie Dong

Claude 现在拥有研究功能，可以跨网络、Google Workspace 及各类集成进行搜索，以完成复杂任务。

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

本文梳理了对我们有效的核心原则——希望这些原则能对你构建自己的多智能体系统有所启发。

多智能体系统的优势

研究工作涉及开放性问题，很难预先预测所需步骤。探索复杂主题没有固定路径可循，整个过程本质上是动态且路径依赖的。人们在开展研究时，往往会根据发现不断调整方法，追寻调查过程中浮现的线索。

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

搜索的本质是压缩：从海量语料中提炼洞见。子智能体通过并行运行各自的上下文窗口来促进压缩，同时探索问题的不同方面，再将最重要的内容汇聚给主研究智能体。每个子智能体还实现了关注点分离——独立的工具、提示词和探索轨迹——从而降低路径依赖，支持深入、独立的调查。

一旦智能程度达到阈值，多智能体系统就成为提升性能的重要途径。例如，尽管过去十万年来个体人类的智力有所提升，但人类社会在信息时代变得_指数级_更强大，这得益于我们的_集体_智慧与协调能力。即使是通用智能体，作为个体运作时也面临局限；智能体群体则能完成远超个体的任务。

我们的内部评估表明，多智能体研究系统尤其擅长广度优先查询——即同时追寻多个独立方向的任务。我们发现，以 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。出于经济可行性考虑，多智能体系统要求任务的价值足以覆盖性能提升所带来的成本。此外，某些需要所有智能体共享同一上下文或智能体之间存在大量依赖关系的领域，目前并不适合多智能体系统。例如，大多数编程任务真正可并行化的部分较少，且大语言模型智能体目前在实时协调和委派方面还不够出色。我们发现，多智能体系统在涉及高度并行化、信息量超出单一上下文窗口、以及需要与众多复杂工具交互的高价值任务上表现卓越。

研究功能的架构概述

我们的研究系统采用多智能体架构，使用编排者-工作者模式：主智能体负责协调整个流程，同时将任务委派给并行运行的专用子智能体。

多智能体架构的实际运作：用户查询流经主智能体，主智能体创建专用子智能体，并行搜索问题的不同方面。

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

使用检索增强生成（RAG）的传统方法采用静态检索，即获取与输入查询最相似的若干片段，并使用这些片段生成响应。相比之下，我们的架构采用多步骤搜索，能够动态发现相关信息、适应新发现，并分析结果以生成高质量答案。

流程图展示了我们多智能体研究系统的完整工作流程。当用户提交查询时，系统创建一个 LeadResearcher 智能体，进入迭代研究流程。LeadResearcher 首先思考研究方法，并将计划保存至 Memory 以持久化上下文——因为如果上下文窗口超过 200,000 个 token 将被截断，保留计划至关重要。随后，它创建带有具体研究任务的专用 Subagent（此处展示两个，实际数量不限）。每个 Subagent 独立执行网络搜索，使用交错思考评估工具结果，并将发现返回给 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 评判者直接检查答案是否正确（例如：是否准确列出了研发预算最高的三家制药公司？）。使用 LLM 作为评判者让我们能够对数百个输出进行可扩展的评估。

人工评估能捕捉到自动化遗漏的问题。 人工测试智能体能发现自动化评估所遗漏的边界案例，包括不寻常查询上的幻觉答案、系统故障，或细微的来源选择偏差。在我们的案例中，人工测试人员注意到早期智能体始终倾向于选择针对 SEO 优化的内容农场，而非权威但排名较低的来源，如学术 PDF 或个人博客。在提示中加入来源质量启发式规则后，这一问题得到了改善。即便在自动化评估盛行的今天，手动测试依然不可或缺。

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

生产可靠性与工程挑战

在传统软件中，一个缺陷可能会导致某个功能损坏、性能下降或服务中断。而在智能体系统中，细微的变化会引发大范围的行为连锁反应，这使得为必须在长时间运行过程中维护状态的复杂智能体编写代码变得异常困难。

智能体是有状态的，错误会累积叠加。 智能体可以长时间运行，并在多次工具调用中维护状态。这意味着我们需要持久化地执行代码并在此过程中处理错误。如果没有有效的缓解措施，轻微的系统故障对智能体而言可能是灾难性的。当错误发生时，我们不能从头重新开始：重启代价高昂，也会让用户感到沮丧。因此，我们构建了能够从错误发生时的断点处恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，当工具出现故障时告知智能体并让其自行适应，效果出人意料地好。我们将基于 Claude 构建的 AI 智能体的适应性与重试逻辑和定期检查点等确定性保障机制结合起来。

调试需要新的方法。 智能体会动态地做出决策，即使使用完全相同的提示词，不同运行之间也具有不确定性。这使得调试更加困难。例如，用户会反映智能体”找不到显而易见的信息”，但我们无法看清原因——是智能体使用了糟糕的搜索查询？选择了质量差的来源？还是遭遇了工具故障？引入完整的生产追踪使我们能够诊断智能体失败的原因，并系统性地修复问题。除标准可观测性之外，我们还监控智能体的决策模式和交互结构——同时不监控单次对话的具体内容，以保护用户隐私。这种高层级的可观测性帮助我们诊断根本原因、发现意外行为，并修复常见故障。

部署需要精细的协调。 智能体系统是由提示词、工具和执行逻辑构成的高度有状态的网络，几乎持续不间断地运行。这意味着每当我们部署更新时，智能体可能正处于流程中的任意位置。因此，我们需要防止善意的代码变更破坏正在运行的智能体。我们无法同时将所有智能体升级到新版本。为此，我们采用彩虹部署来避免中断正在运行的智能体，通过同时保持新旧版本运行并逐步将流量从旧版本切换到新版本来实现平稳过渡。

同步执行会产生瓶颈。 目前，我们的主智能体以同步方式执行子智能体，在继续下一步之前等待每组子智能体完成任务。这简化了协调工作，但也在智能体间的信息流中造成了瓶颈。例如，主智能体无法引导子智能体，子智能体之间也无法相互协调，整个系统可能会因等待某个子智能体完成搜索而陷入阻塞。异步执行将实现更高程度的并行化：智能体并发工作，并在需要时创建新的子智能体。但这种异步性在子智能体之间的结果协调、状态一致性和错误传播方面带来了新的挑战。随着模型能够处理更长、更复杂的研究任务，我们预期性能提升将证明这种复杂性是值得的。

结语

在构建 AI 智能体时，最后一公里往往会成为整个旅程的大部分。在开发者机器上运行良好的代码库，需要大量工程工作才能成为可靠的生产系统。智能体系统中错误的累积性意味着，传统软件中的小问题可能会让智能体完全脱轨。一个步骤的失败可能导致智能体探索完全不同的路径，从而产生不可预测的结果。由于本文所述的种种原因，从原型到生产之间的差距往往比预期的要大得多。

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

一张 Clio 嵌入图，展示了人们目前使用研究功能的最常见方式。排名靠前的使用场景类别为：在专业领域开发软件系统（10%）、开发和优化专业及技术内容（8%）、制定业务增长和收入创造策略（8%）、协助学术研究和教育材料开发（7%），以及研究和核实关于人物、地点或组织的信息（5%）。

致谢

由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。本文凝聚了 Anthropic 多个团队的集体努力，正是他们使研究功能得以实现。特别感谢 Anthropic 应用工程团队，正是他们的付出将这一复杂的多智能体系统推向了生产环境。我们也对早期用户提供的宝贵反馈深表感谢。

附录

以下是关于多智能体系统的一些额外补充建议。

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

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

将子智能体输出写入文件系统，以减少”传话游戏”效应。 对于特定类型的结果，子智能体可以绕过主协调者直接输出，从而同时提升保真度和性能。与其要求子智能体通过主智能体传递所有内容，不如构建制品系统，让专业智能体能够创建独立持久存储的输出。子智能体调用工具将其工作存储在外部系统中，然后将轻量级引用传回给协调者。这可以防止多阶段处理中的信息丢失，并减少通过对话历史复制大量输出所带来的 token 开销。这种模式对于代码、报告或数据可视化等结构化输出尤为有效——在这些场景中，子智能体的专业化提示词能产出比经过通用协调者过滤更好的结果。