Claude 现在具备研究（Research）能力，可以跨网络、Google Workspace 以及各类集成进行搜索，完成复杂任务。
这套多智能体系统从原型走向生产的历程，让我们在系统架构、工具设计和提示工程方面获得了关键经验。多智能体系统由多个协同工作的智能体（在循环中自主使用工具的 LLM）组成。我们的 Research 功能包含一个智能体：它根据用户查询规划研究流程，再借助工具创建并行的智能体，同时检索信息。多智能体系统在智能体协调、评估和可靠性方面带来了新的挑战。
本文梳理了对我们行之有效的原则，希望对你构建自己的多智能体系统有所帮助。
多智能体系统的优势
研究工作面对的是开放式问题，很难事先预测所需的步骤。探索复杂主题时，你无法写死一条固定路径，因为这一过程本质上是动态的，并且依赖于路径。人在做研究时，往往会根据新的发现不断调整方法，顺着调查中浮现的线索继续深入。
这种不可预测性使 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 很快。根据我们的数据，智能体通常比普通聊天交互多用约 4 倍的 token，而多智能体系统比聊天多用约 15 倍的 token。要在经济上可行，多智能体系统需要用于价值足够高的任务，以抵偿性能提升所付出的成本。此外，有些领域目前并不适合多智能体系统，比如要求所有智能体共享同一上下文，或智能体之间存在大量依赖的领域。例如，大多数编码任务中真正可并行的部分比研究要少，而且 LLM 智能体还不太擅长实时地协调和委派任务给其他智能体。我们发现，多智能体系统擅长这样一类有价值的任务：需要大量并行、信息量超出单个上下文窗口，以及需要对接众多复杂工具。
Research 的架构概览
我们的 Research 系统采用多智能体架构，使用编排者-工作者（orchestrator-worker）模式：由一个主智能体负责协调整个流程，并把任务委派给并行运行的专用子智能体。
用户提交查询后，主智能体会分析查询、制定策略，并派生子智能体同时探索不同方面。如上图所示，子智能体扮演智能过滤器的角色：它们反复使用搜索工具收集信息（本例是关于 2025 年的 AI 智能体公司），然后把公司列表返回给主智能体，由其汇总出最终答案。
采用检索增强生成（Retrieval Augmented Generation，RAG）的传统方法使用的是静态检索，即取回与输入查询最相似的一组文本块，并用这些文本块生成回答。相比之下，我们的架构使用多步搜索，能动态地找到相关信息、根据新发现调整，并分析结果以形成高质量的答案。
研究智能体的提示工程与评估
多智能体系统与单智能体系统有关键区别，其中之一是协调复杂度急剧增长。早期的智能体会犯一些错误，比如为简单查询派生 50 个子智能体、在网上无休止地搜寻并不存在的来源，以及用过多的更新相互干扰。由于每个智能体都由提示来引导，提示工程就成了我们改善这些行为的主要手段。以下是我们总结出的几条智能体提示原则：
- 像你的智能体一样思考。要迭代提示，你必须理解提示的效果。为此，我们使用控制台（Console）搭建了模拟环境，采用与系统中完全相同的提示和工具，然后逐步观察智能体的工作。这立刻暴露出了一些失败模式：已经有足够结果时智能体仍继续搜索、搜索查询过于冗长，或选错工具。有效的提示依赖于对智能体建立准确的心智模型，这能让最有影响力的改动一目了然。
- 教会编排者如何委派任务。在我们的系统中，主智能体把查询拆解为子任务，并向子智能体描述这些任务。每个子智能体都需要明确的目标、输出格式、关于使用哪些工具和来源的指引，以及清晰的任务边界。如果没有详细的任务描述，智能体就会重复劳动、留下空白，或者找不到所需信息。起初，我们允许主智能体给出简短的指令，比如“研究半导体短缺”，但发现这类指令往往含糊不清，导致子智能体误解任务，或执行与其他智能体完全相同的搜索。例如，一个子智能体探究 2021 年的汽车芯片危机，另外 2 个却重复调查 2025 年当前的供应链，分工并不有效。
- 让投入的精力与查询复杂度相匹配。智能体很难判断不同任务该投入多少精力，因此我们在提示中嵌入了扩展规则。简单的事实查找只需 1 个智能体，进行 3 到 10 次工具调用；直接的对比可能需要 2 到 4 个子智能体，每个调用 10 到 15 次；复杂的研究则可能使用 10 个以上的子智能体，并明确划分职责。这些明确的准则帮助主智能体高效分配资源，避免在简单查询上投入过度，而这正是我们早期版本中常见的失败模式。
- 工具的设计与选择至关重要。智能体与工具之间的接口，其重要性不亚于人机界面。使用正确的工具效率很高，往往还是绝对必要的。例如，一个智能体在网上搜索只存在于 Slack 中的上下文，从一开始就注定失败。借助让模型访问外部工具的 MCP 服务器，这个问题会更加严重，因为智能体会遇到从未见过的工具，而这些工具的描述质量参差不齐。我们给智能体提供了明确的启发式规则，例如：先检查所有可用工具，让工具的使用与用户意图相匹配，用网络搜索进行广泛的外部探索，或者优先使用专用工具而非通用工具。糟糕的工具描述可能把智能体引向完全错误的方向，因此每个工具都需要有明确的用途和清晰的描述。
- 让智能体自我改进。我们发现 Claude 4 系列模型可以是出色的提示工程师。给定一个提示和一种失败模式，它们能够诊断智能体失败的原因并提出改进建议。我们甚至创建了一个工具测试智能体：给它一个有缺陷的 MCP 工具，它会尝试使用该工具，然后重写工具描述以避免失败。通过对工具进行数十次测试，这个智能体发现了关键的细微之处和 bug。这一改善工具易用性的过程，使后续使用新描述的智能体完成任务的时间缩短了 40%，因为它们能避开大多数错误。
- 先宽后窄。搜索策略应当模仿人类专家的研究方式：先摸清整体情况，再深入具体细节。智能体往往默认使用过长、过于具体的查询，结果返回寥寥。我们通过提示让智能体从简短、宽泛的查询开始，评估有哪些可用信息，再逐步收窄焦点，以此抵消这种倾向。
- 引导思考过程。扩展思考模式（extended thinking mode）会让 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 评审者检查答案是否正确（比如，它是否准确列出了R&D 预算最大的前三家制药公司？）。使用 LLM 作为评审者，使我们能够规模化地评估数百个输出。
人工评估能发现自动化遗漏的问题。测试智能体的人会发现评测遗漏的边缘情况，包括对非常规查询给出的幻觉式答案、系统故障，或细微的来源选择偏差。就我们的情况而言，人工测试者注意到，我们早期的智能体总是倾向于选择经过 SEO 优化的内容农场，而不是权威但排名较低的来源，比如学术 PDF 或个人博客。在提示中加入来源质量的启发式规则，帮助解决了这一问题。即使在自动化评估盛行的时代，手动测试仍然必不可少。
多智能体系统具有涌现行为，这些行为并非出自特定的编程。例如，对主智能体的细微改动，可能不可预测地改变子智能体的行为。要取得成功，需要理解交互模式，而不仅仅是单个智能体的行为。因此，这类智能体的最佳提示不只是严格的指令，而是定义分工、解决问题的方法和精力预算的协作框架。要做好这一点，依赖于细致的提示与工具设计、可靠的启发式规则、可观测性，以及紧密的反馈循环。我们系统的示例提示见 Cookbook 中的开源提示。
生产环境的可靠性与工程挑战
在传统软件中，一个 bug 可能导致某个功能失效、性能下降或服务中断。而在智能体系统中，细微的改动会层层放大为巨大的行为变化，这使得为必须在长时间运行的过程中维持状态的复杂智能体编写代码异常困难。
智能体是有状态的，错误会不断累积。智能体可以长时间运行，并在大量工具调用之间保持状态。这意味着我们需要持久地执行代码，并在过程中处理错误。若没有有效的缓解措施，轻微的系统故障对智能体来说也可能是灾难性的。出错时，我们不能简单地从头重新开始：重启代价高昂，也会让用户沮丧。因此，我们构建了能够从智能体出错时所处位置恢复的系统。我们还利用模型的智能来优雅地处理问题：例如，告知智能体某个工具出现故障并让它自行调整，效果出奇地好。我们把基于 Claude 构建的 AI 智能体的适应能力，与重试逻辑和定期检查点等确定性的保障措施结合起来。
调试需要新的方法。智能体会做出动态决策，即使提示完全相同，每次运行的结果也是非确定性的。这使调试更加困难。例如，用户会反馈智能体“找不到显而易见的信息”，但我们看不出原因。是智能体使用了糟糕的搜索查询？选择了不佳的来源？还是遇到了工具故障？加入完整的生产环境追踪后，我们得以诊断智能体失败的原因，并系统性地修复问题。除了标准的可观测性之外，我们还监控智能体的决策模式和交互结构，同时不监控单个对话的内容，以保护用户隐私。这种高层次的可观测性帮助我们诊断根本原因、发现意外行为，并修复常见故障。
部署需要细致的协调。智能体系统是由提示、工具和执行逻辑构成的高度有状态的网络，几乎持续不断地运行。这意味着每当我们部署更新时，智能体可能处于其流程中的任何位置。因此，我们需要防止出于好意的代码改动破坏现有的智能体。我们无法同时把所有智能体更新到新版本。相反，我们采用彩虹部署（rainbow deployments），通过让新旧版本同时运行、逐步把流量从旧版本转移到新版本，来避免干扰正在运行的智能体。
同步执行会造成瓶颈。目前，我们的主智能体以同步方式执行子智能体，需要等待每一批子智能体完成后才继续。这简化了协调，但在智能体之间的信息流动中造成了瓶颈。例如，主智能体无法引导子智能体，子智能体之间无法相互协调，整个系统还可能因为等待某一个子智能体完成搜索而被阻塞。异步执行可以带来更多并行性：智能体并发工作，并在需要时创建新的子智能体。但这种异步性也在结果协调、状态一致性以及跨子智能体的错误传播方面增加了难度。随着模型能够处理更长、更复杂的研究任务，我们预计性能收益将证明这种复杂性是值得的。
结论
构建 AI 智能体时，最后一公里往往占据了大部分旅程。在开发者机器上能运行的代码库，需要大量工程工作才能成为可靠的生产系统。智能体系统中错误的累积特性意味着，对传统软件而言的小问题，可能让智能体彻底偏离轨道。一个步骤失败，就可能让智能体探索完全不同的轨迹，导致不可预测的结果。出于本文所述的种种原因，原型与生产之间的差距往往比预想的更大。
尽管存在这些挑战，多智能体系统已被证明对开放式研究任务很有价值。用户反馈说，Claude 帮助他们发现了此前未曾考虑过的商业机会、理清了复杂的医疗方案、解决了棘手的技术 bug，并通过挖掘出他们靠自己找不到的研究关联，节省了多达数天的工作。只要有细致的工程、全面的测试、注重细节的提示与工具设计、稳健的运维实践，以及对当前智能体能力有深刻理解的研究、产品和工程团队之间的紧密协作，多智能体研究系统就能在规模化场景下可靠运行。我们已经看到，这些系统正在改变人们解决复杂问题的方式。
致谢
本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。这项工作凝聚了 Anthropic 多个团队的共同努力，是他们让 Research 功能成为可能。特别感谢 Anthropic 应用工程团队，他们的投入使这一复杂的多智能体系统得以投入生产。我们也感谢早期用户提供的宝贵反馈。
附录
以下是关于多智能体系统的一些其他杂项提示。
对多轮中不断改变状态的智能体进行终态评估。评估在多轮对话中修改持久状态的智能体，有其独特的挑战。与只读的研究任务不同，每个动作都可能改变后续步骤所处的环境，产生传统评估方法难以应对的依赖关系。我们发现，侧重终态评估而非逐轮分析效果不错。与其判断智能体是否遵循了特定流程，不如评估它是否达到了正确的最终状态。这种做法承认智能体可能找到通往同一目标的其他路径，同时仍确保它们交付了预期的结果。对于复杂的工作流，应把评估拆分为若干离散的检查点，在这些节点上应当发生特定的状态变化，而不是试图验证每一个中间步骤。
长周期对话管理。生产环境中的智能体常常进行长达数百轮的对话，这需要细致的上下文管理策略。随着对话延长，标准的上下文窗口会变得不够用，因此需要智能的压缩和记忆机制。我们实现了这样的模式：智能体先总结已完成的工作阶段，并把关键信息存入外部记忆，再继续新的任务。当接近上下文上限时，智能体可以派生拥有干净上下文的新子智能体，并通过细致的交接保持连续性。此外，它们还可以从记忆中取回研究计划等已存储的上下文，而不是在达到上下文上限时丢失之前的工作。这种分布式做法既能防止上下文溢出，又能在长时间交互中保持对话的连贯性。
让子智能体把输出写入文件系统，以尽量减少“传话游戏”效应。对于某些类型的结果，子智能体的输出可以绕过主协调者直接交付，从而同时提升保真度和性能。与其要求子智能体把所有内容都通过主智能体转达，不如实现制品（artifact）系统，让专用智能体创建可独立持久保存的输出。子智能体调用工具把成果存入外部系统，再把轻量级的引用传回给协调者。这样可以避免多阶段处理中的信息丢失，并减少因在对话历史中复制大型输出而产生的 token 开销。这一模式尤其适用于代码、报告或数据可视化等结构化输出，因为子智能体的专用提示产生的结果，比经过通用协调者过滤要好。
