我们如何构建多智能体研究系统 \ Anthropic

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 3.7 升级到 Claude Sonnet 4 的性能增益，大于把 token 预算翻倍。多智能体架构能够有效扩展超出单智能体能力边界的任务所需 token 使用量。

但也有代价：实践中这类架构消耗 token 很快。我们的数据中，智能体通常使用约为聊天交互 4 倍的 token，多智能体系统则约为聊天的 15 倍。要具备经济可行性，任务价值必须足以支付性能提升的成本。此外，一些要求所有智能体共享同一上下文、或智能体间依赖很多的领域，目前并不适合多智能体系统。例如，大多数编码任务中真正可并行的任务较少，LLM 智能体也还不擅长实时协调和委派。我们发现，多智能体系统最擅长高价值、重度并行化、信息超出单一上下文窗口且需要连接大量复杂工具的任务。

Research 的架构概览

我们的 Research 系统采用编排者—工作者多智能体架构：主智能体协调流程，同时把工作委派给并行运行的专门子智能体。

多智能体架构实际运行时，用户查询流向主智能体；主智能体创建专门子智能体，并行搜索不同方面。

用户提交查询后，主智能体分析查询、制定策略，并生成子智能体以同时探索不同方面。如图所示，子智能体充当智能过滤器，迭代使用搜索工具收集信息——此例为 2025 年的 AI 智能体公司——再把公司清单返回主智能体，由其汇编最终答案。

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

流程图展示了多智能体 Research 的完整工作流。用户提交查询后，系统会创建进入迭代研究流程的 LeadResearcher 智能体。LeadResearcher 先思考方法并把计划保存到 Memory 以持久化上下文，因为上下文窗口超过 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 工具后，它尝试使用该工具，再重写工具描述以避免失败。这个智能体多次测试工具后发现关键细节与 bug。改进工具易用性的这一过程，让未来使用新描述的智能体任务完成时间降低了 40%，因为它们能避开大部分错误。
6. 先宽后窄。 搜索策略应模仿专家人类研究：先探索全景，再深入具体。智能体常默认使用过长、过于具体的查询，得到的结果很少。我们通过提示让智能体先用简短、宽泛的查询，评估可用内容，再逐步收窄重点，以抵消这种倾向。
7. 引导思考过程。 扩展思考模式会让 Claude 在可见思考过程中输出额外 token，可作为可控草稿板。主智能体使用思考来规划方法：评估哪些工具适合任务、确定查询复杂度和子智能体数量、定义每个子智能体角色。测试显示扩展思考改善了指令遵循、推理和效率。子智能体也会在工具结果之后规划并使用交错思考评估质量、找出空白并细化下一次查询，因此更能适应任何任务。
8. 并行工具调用改变速度和性能。 复杂研究天然要探索许多来源。早期智能体顺序执行搜索，速度极慢。为提高速度，我们引入两类并行化：(1) 主智能体并行而非串行启动 3–5 个子智能体；(2) 子智能体并行使用 3 个以上工具。这些改动把复杂研究时间最多缩短 90%，使 Research 能在数分钟而不是数小时中完成更多工作，并覆盖比其他系统更多的信息。

我们的提示策略着重灌输良好启发式，而非僵硬规则。我们研究熟练人类如何进行研究，并将这些策略编码到提示词中——如将难题分解为更小任务、仔细评估来源质量、依据新信息调整搜索方式，以及识别何时聚焦深度（详细调查一个主题）或广度（并行探索许多主题）。我们还用明确护栏主动缓解意外副作用，防止智能体失控。最后，我们专注于具备可观测性和测试用例的快速迭代循环。

对智能体进行有效评估

良好的评估是构建可靠 AI 应用的必要条件，智能体也不例外。不过，评估多智能体系统有独特挑战。传统评估常假定 AI 每次会遵循同样步骤：给定输入 X，系统应沿路径 Y 产生输出 Z。但多智能体系统并非如此。即使起点相同，智能体也可能采用完全不同但都有效的路径达成目标；一个智能体可能搜索三个来源，另一个搜索十个，或者它们使用不同工具找到同一答案。由于我们并不总知道正确步骤是什么，通常不能只检查智能体是否遵循预先规定的“正确”步骤；我们需要灵活的评估方法，判断智能体是否达成正确结果，同时遵循合理过程。

立即用小样本开始评估。 在智能体开发早期，改动通常影响巨大，因为存在大量低垂果实。一次提示词调整可能把成功率从 30% 提升到 80%。有这么大的效应量，只需少数测试用例就能观察到变化。我们从约 20 个代表真实使用模式的查询开始；测试这些查询常能清楚看出改动影响。我们经常听到 AI 开发团队延迟创建评估，因为他们认为只有包含数百个测试用例的大型评估才有价值。但与其等到能够构建更彻底评估，不如立即用少数案例开始小规模测试。

做好 LLM-as-judge 评估就能扩展。 研究输出难以用程序评估，因为它们是自由文本，且很少存在唯一正确答案。LLM 很适合评分。我们使用 LLM 评审依据 rubric 评价每个输出：事实准确性（主张是否符合来源？）、引文准确性（引文是否匹配主张？）、完整性（是否涵盖所有请求方面？）、来源质量（是否优先使用一手来源而非低质量二手来源？）和工具效率（是否用合理次数调用正确工具？）。我们尝试让多个评审评价每一部分，但发现单次 LLM 调用、单个提示词输出 0.0–1.0 分数及通过/失败结论，最一致且最符合人类判断。当评估测试用例确实有明确答案时，这种方法尤其有效；我们可让 LLM 评审简单检查答案是否正确（例如是否准确列出研发预算最高的前三家制药公司）。LLM 评审使我们能扩展到数百份输出。

人工评估能捕捉自动化遗漏。 测试智能体的人会发现评估遗漏的边缘案例，包括罕见查询上的幻觉、系统失败或细微来源选择偏见。我们的例子中，人类测试者发现早期智能体总是选择 SEO 优化的内容农场，而不是学术 PDF 或个人博客等权威却排名较低的来源。向提示词加入来源质量启发式有助于解决这一问题。即使在自动化评估的世界，人工测试仍然必不可少。

多智能体系统有无需特定编程便会出现的涌现行为。例如，对主智能体的小改动会不可预测地改变子智能体行为。成功需要理解交互模式，而不仅是个体智能体行为。因此，最好的这类提示词不是严格指令，而是定义分工、问题解决方式与投入预算的协作框架。做好这一点依赖细致的提示和工具设计、可靠启发式、可观测性及紧密反馈循环。我们系统中的提示词示例可参见 Cookbook 中的开源提示词。

生产可靠性与工程挑战

在传统软件中，一个 bug 可能破坏某项功能、降低性能或造成宕机。在智能体系统中，微小改动会级联为巨大的行为变化，使得为必须在长时运行流程中维持状态的复杂智能体编写代码极其困难。

智能体有状态，错误会累积。 智能体可以运行很长时间，在大量工具调用中保持状态。这意味着我们需要持久地执行代码，并沿途处理错误。没有有效缓解，小系统失败对智能体可能是灾难性的。发生错误时不能简单从头重启：重启对用户代价高且令人沮丧。相反，我们构建能从错误发生处恢复的系统。我们也利用模型智能优雅处理问题：例如，让智能体知道工具正在失败并允许它适应，效果出人意料地好。我们将基于 Claude 的 AI 智能体适应性，与重试逻辑和定期检查点等确定性护栏结合。

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

部署需要细致协调。 智能体系统是提示词、工具和几乎连续运行的执行逻辑组成的高度有状态网络。这意味着每次部署更新时，智能体可能正处于流程的任何位置。因此，需要防止善意的代码改动破坏现有智能体；不能同时把每个智能体更新到新版本。我们使用彩虹部署，在保留新旧版本同时运行的情况下，逐步把流量从旧版本切到新版本，避免中断正在运行的智能体。

同步执行会形成瓶颈。 当前主智能体会同步执行子智能体：等待每组子智能体完成后才继续。这简化了协调，但会在信息流中形成瓶颈。例如，主智能体无法引导子智能体，子智能体无法相互协调，整个系统可能因等待一个子智能体搜索完成而阻塞。异步执行可提供额外并行性：智能体并发工作并创建新子智能体。但异步性又会带来结果协调、状态一致性和跨子智能体错误传播的挑战。随着模型能处理更长、更复杂的研究任务，我们预计性能增益将值得付出复杂度。

结论

构建 AI 智能体时，最后一公里往往构成了大部分旅程。能在开发者机器上运行的代码库，要成为可靠的生产系统仍需要大量工程。智能体系统中错误的复合性质意味着，传统软件中的小问题可能完全让智能体偏航；一个步骤失败就可能使其探索截然不同的轨迹，产生不可预测结果。基于本文描述的所有原因，原型与生产之间的差距往往比预想更大。

尽管有这些挑战，多智能体系统已证明对开放式研究任务很有价值。用户表示，Claude 帮助他们发现此前未考虑的商业机会、应对复杂医疗选择、解决棘手技术 bug，并通过发现原本找不到的研究关联节省了长达数天的工作。通过细致工程、全面测试、注重细节的提示和工具设计、稳健运维实践，以及对当前智能体能力有深刻理解的研究、产品和工程团队之间紧密合作，多智能体研究系统可以在规模上可靠运行。我们已经看到这些系统正在改变人们解决复杂问题的方式。

一张 Clio 嵌入图，展示人们当前使用 Research 功能最常见的方式。排名最高的用例类别包括：跨专业领域开发软件系统（10%）、开发和优化专业与技术内容（8%）、制定业务增长和收入策略（8%）、辅助学术研究与教育材料开发（7%），以及研究和核实与人物、地点或组织相关的信息（5%）。

致谢

本文由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford 撰写。本工作反映了 Anthropic 多个团队的共同努力；他们让 Research 功能得以实现。特别感谢 Anthropic 应用工程团队，他们的投入让这个复杂的多智能体系统走向生产。也感谢早期用户提供的优秀反馈。

附录

以下是一些关于多智能体系统的补充提示。

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

长程对话管理。 生产智能体往往进行跨数百轮的对话，需要谨慎的上下文管理策略。随着对话延长，标准上下文窗口不足，必须采用智能压缩和记忆机制。我们实现了这样的模式：智能体总结已完成工作阶段，并在进入新任务前把关键信息存入外部记忆。当接近上下文限制时，智能体可以生成拥有干净上下文的新子智能体，同时通过细致交接保持连续性。它们还能从记忆中取回研究计划等存储上下文，而非达到上限时丢失先前工作。这种分布式方法在扩展交互中保持对话连贯，同时防止上下文溢出。

将子智能体输出写入文件系统，减少“传话游戏”。 对某些结果，直接的子智能体输出可以绕过主协调者，同时提升保真度和性能。与其要求子智能体把一切都经由主智能体传达，不如实现工件系统，使专门子智能体能创建独立持久的输出。子智能体调用工具把工作存入外部系统，再向协调者传回轻量引用。这能防止多阶段处理中信息损失，并减少把大输出复制穿过对话历史的 token 开销。该模式尤其适合代码、报告或数据可视化等结构化输出，此时专门子智能体的提示词能产生比经通用协调者过滤更好的结果。