6 月 16 日消息，近日，人工智能公司 Anthropic 披露其王牌产品 Claude 的一项重大升级：通过构建一个由多个 AI 智能体组成的“研究团队”，其在复杂研究任务上的表现较单智能体系统实现了 90.2% 的惊人提升。这标志着 AI 正从“单兵作战”迈向“协同智能”的新阶段。
这项名为“Research”（研究）的新功能，其核心是一个多智能体系统。在该架构下，一个“主导智能体”扮演项目经理的角色，负责规划和拆解任务，随后并行创建多个“子智能体”分头执行信息检索与分析。这种模式模仿了人类专家团队的高效协作，通过并行处理和关注点分离，有效攻克了传统 AI 难以胜任的开放性难题。
本文由 Anthropic 核心开发团队撰写，深入剖析了这一前沿系统的构建全貌。
以下是全文翻译：
【多智能体研究系统的构建历程】
我们的 Research 功能采用多个 Claude 智能体，协同探索复杂主题，以提升研究效果。本文将分享在该系统开发过程中遇到的工程挑战，以及我们总结的经验教训。
Claude 现已具备“Research”（研究）能力，能够跨互联网、Google Workspace 及各类集成工具检索信息，从而完成复杂任务。
这一多智能体系统（multi-agent system）从原型到正式上线的过程，让我们在系统架构、工具设计和提示词工程（prompt engineering）等方面积累了重要经验。多智能体系统由多个智能体（即 LLMs 在循环中自主调用工具）协作完成任务。我们的 Research 功能包含一个智能体，根据用户查询规划调研流程，并利用工具并行创建多个子智能体，协同检索信息。多智能体系统在智能体协同、评测与可靠性等方面带来了全新挑战。
本文将详细解析我们总结出的有效原则，希望能为你自行构建多智能体系统提供参考。
多智能体系统的优势
研究工作本身充满开放性，难以预先确定所需步骤。你无法为探索复杂主题预设一条固定路径，因为整个过程本质上充满变数且路径依赖明显。在实际调研中，人们会根据新的发现不断调整方法，跟随线索进一步深入。
这种不可预测性恰恰让 AI 智能体非常适合承担研究类任务。研究需要在调查过程中灵活转向，探索相关或边缘线索。模型必须能够在多轮自主管理下，根据中间结果动态决策进一步探索方向。线性、一次性流程无法胜任这一需求。
搜索的本质在于“压缩”—— 即从庞大语料中提炼洞见。子智能体通过各自独立的上下文窗口并行运行，同时探索问题的不同方面，随后将最重要的信息压缩汇总给主导智能体。这种机制还实现了关注点分离 —— 不同的工具、提示词和探索路径彼此独立，既降低了路径依赖，又保证了调研的全面性和独立性。
一旦智能体能力达到一定门槛，多智能体系统就成为扩展性能的关键方式。例如，尽管人类个体在过去十万年间变得更为聪明，但进入信息时代后，人类社会之所以指数级提升能力，正是因为集体智慧和高效协作。同样，即使是具备通用智能的单体智能体，其能力也有上限；而智能体群体协同作业则远远超越个体能力。
我们的内部评测显示，多智能体研究系统尤其擅长“广度优先型”查询，能够同时追踪多个独立方向。我们发现，以 Claude Opus 4 作为主导智能体、Claude Sonnet 4 作为子智能体的多智能体系统，在内部研究评测中较单智能体 Claude Opus 4 提升了 90.2%。例如，当系统被要求列举信息技术 S&P 500 指数成分企业全部董事会成员时，多智能体系统能够将任务拆解分配给各子智能体，从而找到正确答案，而单智能体系统因采用缓慢、串行的检索流程，未能给出答案。
多智能体系统之所以有效，主要在于它们能投入足够多的 tokens 来解决问题。我们的分析显示，在 BrowseComp 评测（用于测试智能体检索难以获取信息的能力）中，有三项因素解释了 95% 的性能差异。其中，token 使用量单独就能解释 80% 的差异，工具调用次数和模型选择则是另外两个主要影响因素。这一结果印证了我们的架构思路：通过不同上下文窗口分配任务，实现并行推理，提升系统容量。最新的 Claude 模型也极大提升了 token 使用效率，例如，升级至 Claude Sonnet 4 带来的性能提升，甚至超过在 Claude Sonnet 3.7 上将 token 配额翻倍。多智能体架构能有效扩展 token 使用，适配超出单一智能体处理能力的任务。
但这也带来了问题：在实际应用中，该架构 token 消耗极快。数据显示，单一智能体通常比聊天场景多用约 4 倍 tokens，多智能体系统则比聊天多用约 15 倍。要实现经济可行性，多智能体系统需专注于任务价值足以覆盖高性能消耗的应用场景。此外，部分领域要求所有智能体共享完全一致的上下文，或智能体间依赖关系极多，这类任务目前并不适合多智能体系统。例如，大多数编程任务真正可并行化的环节不如研究型任务多，且现阶段 LLM 智能体尚不擅长实时协调和分工。我们发现，多智能体系统在高并行度、信息量超出单一上下文窗口、需对接大量复杂工具的任务中表现最为突出。
Research 系统架构概览
我们的 Research（研究）系统采用多智能体架构，具体为“协调者-执行者”模式。主导智能体负责整体流程的协调，并将任务分派给并行运行的专业子智能体。
图/多智能体架构实操示意： 用户的查询首先进入主导智能体，由其创建多个专业子智能体，分别并行检索不同方面的信息。
当用户提交查询后，主导智能体会对查询进行分析，制定策略，并同时生成多个子智能体，分别探索不同方面。如上文所示，子智能体通过反复调用检索工具，充当智能过滤器。例如，在检索 2025 年 AI 智能体公司时，子智能体会收集相关信息，并将公司名单返回主导智能体，由其汇总形成最终答案。
传统的检索增强生成（Retrieval Augmented Generation，RAG）方法采用的是静态检索：即根据输入查询检索出最相似的信息片段，并用这些片段生成回复。相比之下，我们的架构采用多步搜索，能够动态发现相关信息，及时调整策略，并对结果进行分析，从而给出高质量答案。
图/流程图展示了我们多智能体 Research 系统的完整工作流程。当用户提交查询后，系统会创建一个 LeadResearcher（主研究者）智能体，进入迭代式研究流程。LeadResearcher 首先思考研究路径，并将研究计划保存至 Memory（记忆）以保证上下文持久存储。因为一旦上下文窗口超过 200,000 tokens，超出部分将被截断，因此计划的保存尤为关键。随后，LeadResearcher 会根据不同研究任务创建专业化的 Subagent（子智能体）（此处仅示例两个，实际可为任意数量）。每个子智能体独立进行网络检索，通过穿插思考（interleaved thinking）评估工具结果，并将发现返回至 LeadResearcher。LeadResearcher 对这些结果进行综合判断，如需进一步研究，可继续创建新的子智能体或优化研究策略。当信息收集充分后，系统将退出研究循环，并将所有研究结果交由 CitationAgent（引文智能体）处理。CitationAgent 会对文档和研究报告进行分析，标注具体引用位置，确保所有论断均有明确信息源支撑。最终，带有完整引文的研究结果返回给用户。
研究智能体的提示词工程与评估
多智能体系统与单智能体系统有本质区别，尤其在协调复杂度上增长迅速。早期的智能体经常犯错，比如为简单查询生成 50 个子智能体，无休止地全网搜索并不存在的信息源，或因频繁更新而彼此干扰。由于每个智能体都由提示词驱动，因此提示词工程成为我们优化行为的主要手段。以下是我们在智能体提示词设计中的一些经验原则：
站在智能体的角度思考。 要持续优化提示词，必须理解其实际效果。为此，我们在 Console 中用系统实际用到的提示词和工具构建了模拟，逐步观察智能体的行为。这很快揭示了常见失败模式：如明明已获得足够结果却继续执行，搜索指令冗长繁复，或工具选择错误。有效的提示词设计需要建立对智能体工作的准确心智模型，这样关键的改进点会变得一目了然。
指导协调者如何分工。 我们的系统中，主导智能体需要将查询拆分为具体子任务，并清晰地描述给子智能体。每个子智能体都需明确目标、输出格式、应使用的工具和信息源，以及清晰的任务边界。如果任务描述不够详尽，智能体之间容易重复劳动、出现遗漏，或找不到必要信息。我们最初允许主导智能体给出简短指令，例如“调研半导体短缺”，但发现这样的指令往往太过模糊，导致子智能体误解任务，甚至重复执行同一检索。例如，一个子智能体调查了 2021 年汽车芯片危机，另外两个则重复研究 2025 年供应链，却缺乏有效分工。
根据查询复杂度动态分配资源。 智能体难以自行判断不同任务应投入多少精力，因此我们在提示词中嵌入了分级规则。简单的事实检索只需 1 个智能体、3-10 次工具调用；直接比较可能需要 2-4 个子智能体，每个调用 10-15 次工具；复杂研究则可能用到 10 个以上子智能体，并有明确分工。这些明确的指导方针帮助主导智能体高效分配资源，避免在简单查询上投入过多，这是早期版本的常见问题。
工具的设计与选择至关重要。 智能体-工具接口和人机接口同样关键。选对工具不仅高效，很多时候更是完成任务的必要条件。例如，若智能体在网上搜索一条只存在于 Slack 的信息，必然无果。MCP 服务器为模型接入各种外部工具，但工具描述质量参差不齐，这一挑战更为突出。我们为智能体制定了明确的启发式规则：如先检查所有可用工具，将工具使用与用户意图相匹配，广泛探索时优先用网络搜索，专业任务优选专用工具而非通用工具。不恰当的工具描述可能导致智能体完全走错方向，因此每个工具都需有明确的功能和清晰的描述。
让智能体自我改进。 我们发现 Claude 4 模型本身就是出色的提示词工程师。当给定失败案例和原始提示词时，它能诊断智能体失败原因并提出改进建议。我们甚至开发了专门的工具测试智能体：当遇到描述不佳的 MCP 工具，它会试用该工具，并重写工具描述以避免失败。通过反复测试，这一智能体发现了诸多细节和漏洞。改进工具易用性的流程，使得未来智能体在使用新描述时，任务完成时间缩短了 40%，因为大多数错误被有效规避。
先广后深。 搜索策略应当类似人类专家：先全面了解，再聚焦细节。智能体往往倾向于一开始就用冗长且具体的查询，结果反而收效甚微。我们通过提示词引导智能体先用简短、宽泛的检索语句，评估可用信息后再逐步聚焦。
引导思考过程。 扩展思考模式（extended thinking mode）可让 Claude 在输出时展示可见的思考过程，作为可控的草稿板。主导智能体借助思考环节规划行动，评估任务所需工具、查询复杂度及子智能体数量，并明确各自职责。测试表明，这一模式能提升指令执行力、推理能力和效率。子智能体同样先制定计划，获取工具结果后再穿插思考，评估信息质量、发现遗漏并优化后续检索。这让子智能体能够更好地适应各种任务。
并行工具调用极大提升速度和表现。 复杂调研任务往往涉及多信息源的同步探索。早期智能体采用串行搜索，效率极低。为提升速度，我们引入了两种并行机制：(1) 主导智能体能并行生成 3-5 个子智能体，而非顺序创建；(2) 子智能体能并行调用 3 个以上工具。这些优化使复杂查询的研究时间最多缩短 90%，让 Research 系统能在几分钟内完成本需数小时的任务，且覆盖信息量远超其他系统。
我们的提示词策略注重培育良好的启发式，而不是僵化规则。 我们研究了熟练人类研究者的工作方式，并在提示词中融入这些策略 —— 如将难题拆解为小任务、细致评估信息源质量、根据新发现灵活调整检索方式、区分何时需深挖单一主题、何时需广泛并行探索。我们还通过设定明确的安全边界，主动规避智能体行为失控等副作用。最后，我们专注于构建可观测、可测试的快速迭代流程。
智能体的有效评估
良好的评估对于构建可靠的 AI 应用至关重要，智能体系统同样如此。然而，多智能体系统的评估面临独特挑战。传统评估通常假设 AI 每次都遵循相同步骤：输入 X，系统应按照路径 Y 产生输出 Z。但多智能体系统并非如此。即使初始条件完全相同，智能体也可能通过完全不同但同样有效的路径达成目标。有的智能体可能检索三种信息源，有的则检索十种，或采用不同工具得出相同答案。由于我们往往无法预知“正确”的具体步骤，因此也就无法简单核查智能体是否严格按预设流程执行。我们需要灵活的评估方法，既判断智能体是否达成预期结果，也关注其过程是否合理。
从小样本立刻开始评估。 在智能体开发早期，细微的改动往往带来显著影响，因为此时存在大量“低垂的果实”。一次提示词微调，成功率可能由 30% 提升至 80%。如此大的效果差异，只需少量测试用例即可观察到变化。我们最初用约 20 条代表真实使用场景的查询进行测试。这些测试经常能清楚反映改动的成效。我们常听说 AI 开发团队因认为只有包含数百个用例的大型评测才有意义而延迟开展评估。实际上，最佳做法是从少量样例的小规模测试立即着手，而不是等到有能力构建更全面评测时再开始。
以大语言模型（LLM）为判官的评估方法具有可扩展性。 研究型输出很难用程序化手段评估，因为其多为自由文本，且鲜有唯一正确答案。LLM 非常适合用于结果评分。我们使用 LLM 判官（LLM-as-judge），基于评分细则对每个输出进行评估，包括事实准确性（结论是否与信息源一致）、引用准确性（所引信息源是否与陈述相符）、全面性（是否覆盖所有要求的方面）、信息源质量（是否优先使用高质量的一手来源而非低质量的二手来源）、工具效率（是否合理选择并调用工具）。我们曾尝试用多个判官评估不同维度，但最终发现，单次 LLM 调用、以单一提示词输出 0.0-1.0 分数并给出通过 / 未通过判定，效果最为一致且与人工判断高度吻合。这种方法在测试用例答案明确时尤其有效，LLM 判官只需判断答案是否正确（例如是否准确列出研发投入最高的三家制药公司）。利用 LLM 判官，我们可以大规模评估数百个输出。
人工评估能发现自动化遗漏的问题。 人工测试智能体时，常能发现评测遗漏的边缘案例，如在特殊查询下出现幻觉答案、系统性故障，或信息源选择中的细微偏差。以我们的经验为例，测试人员发现早期智能体经常偏好 SEO 优化内容农场，而忽视了权威但排名较低的信息源，如学术 PDF 或个人博客。为此，我们在提示词中加入信息源质量的启发式规则，有效改善了这一问题。即便自动化评估日趋完善，人工测试依然不可或缺。
多智能体系统会出现“涌现行为”，即未经过明确编程而自然产生的新模式。 例如，对主导智能体的微小调整，可能以不可预测的方式改变子智能体行为。要取得成功，必须理解智能体之间的互动模式，而不仅仅是个体行为。因此，最佳提示词不仅仅是严格的指令，更应是协作框架，明确分工、解决问题的方法及资源投入的上限。要做到这一点，需要精心的提示词设计与工具配置、扎实的启发式规则、良好的可观测性以及高效反馈循环。具体可参考我们 Cookbook 中开源的系统提示词示例。
生产环境下的可靠性与工程挑战
在传统软件中，漏洞可能导致功能失效、性能下降或服务中断。而在智能体系统中，微小的改动可能引发大范围的行为变化，使得持续运行、需保持状态的复杂智能体代码极难维护。
智能体具备状态，且错误会累积。 智能体往往需要长时间运行，期间跨越多次工具调用并持续维护自身状态。这要求我们的系统必须具备持久化执行能力，并能妥善处理运行过程中的各类错误。若缺乏有效应对机制，哪怕极小的系统故障也可能对智能体造成灾难性影响。出错时，系统无法简单地从头重启 —— 重启代价高昂且令用户沮丧。因此，我们设计了可在出错点恢复的系统。同时，借助模型智能优雅处理异常问题，例如在工具失效时向智能体发出提示，让其主动调整，这一策略效果出奇地好。我们将基于 Claude 的 AI 智能体适应能力，与如重试逻辑、定期检查点等确定性防护措施相结合。
调试需采用新方法。 智能体的决策过程高度动态，即便提示词完全一致，不同运行结果也可能不同，给调试带来极大难度。例如，用户报告智能体“未能找到显而易见的信息”，但我们无法直接看出原因 —— 是检索指令设置不佳，还是信息源选择错误，亦或工具本身出错？我们通过引入全量生产追踪，系统性定位智能体失败原因并加以修复。除常规可观测性外，我们还监控智能体的决策模式与互动结构，但不监控具体对话内容，以保障用户隐私。这种高层级可观测性有助于发现根本原因、意外行为及常见故障。
部署需精心协调。 智能体系统由提示词、工具和执行逻辑组成，具备高度状态性，且几乎持续运行。因此，系统每次更新时，智能体可能正处于任意执行阶段。我们必须防止善意的代码更新破坏现有智能体的运行。无法让所有智能体同时切换至新版本，因此采用“彩虹部署”（rainbow deployments），即逐步将流量从旧版本切换到新版本，确保两者并行运行，避免对现有智能体造成干扰。
同步执行会造成瓶颈。 目前，主导智能体按同步方式执行子智能体，即需等待一批子智能-体全部完成后才能继续。这虽简化了协调，但也造成智能体之间信息流的瓶颈。例如，主导智能体无法动态引导子智能体，子智能体之间无法协作，整个系统可能因等待某个子智能体完成检索而被阻塞。异步执行则可实现更高并行度：智能体能并发工作，并在需要时动态生成新的子智能体。但异步同时带来结果协调、状态一致性和错误传播等新挑战。随着模型处理更长、更复杂研究任务的能力提升，我们预计性能提升将抵消由此带来的复杂性。
结论
在构建 AI 智能体的过程中，最后一公里往往成为最为艰难的阶段。开发者本地能够运行的代码，距离成为可靠的生产系统还需要大量工程化努力。在智能体系统中，错误具有复合特性，这意味着对于传统软件而言的轻微问题，可能会导致智能体完全崩溃。只要某一步失败，智能体就可能走向完全不同的路径，进而产生不可预测的结果。正如本文所述，从原型到生产环境之间的鸿沟，往往比人们预期的更为宽广。
尽管存在这些挑战，多智能体系统在开放性研究任务中依然展现出巨大价值。用户反馈称，Claude 帮助他们发现了未曾考虑过的商业机会，理清了复杂的医疗方案，解决了棘手的技术难题，还能通过揭示原本难以独立发现的研究关联，节省数天工作时间。只要注重工程细节、全面测试、精心设计提示词和工具、完善运维实践，并确保研究、产品与工程团队之间紧密协作，对当前智能体能力有深刻理解，多智能体研究系统完全可以在规模化应用中保持可靠运行。我们已经看到，这些系统正在改变人们解决复杂问题的方式。
图/Clio 嵌入图展示了当前用户对 Research 功能的主要使用方式。最常见的五大使用场景为：在专业领域开发软件系统（10%）、撰写与优化专业及技术内容（8%）、制定企业增长与营收策略（8%）、辅助学术研究与教学资料开发（7%）、以及查询与核实人物、地点或组织等相关信息（5%）。
作者：Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 与 Daniel Ford。本项目凝聚了 Anthropic 多个团队的共同努力，使 Research 功能成为可能。特别感谢 Anthropic 应用工程团队，正是他们的专注与奉献，将这一复杂的多智能体系统推向了生产环境。我们也感谢早期用户们提供的宝贵反馈。
附录
以下是关于多智能体系统的一些补充建议。
评估跨多轮对话持续变更状态的智能体终态。 对于在多轮对话中持续修改持久状态的智能体，其评估面临独特挑战。与只读型研究任务不同，每一步操作都会影响后续环境，形成步骤间的依赖关系，传统评估方法难以应对。我们的做法是关注终态评估（end-state evaluation），而非每一步的细致分析。与其考察智能体是否遵循了特定流程，不如评估其最终是否达到了正确的目标状态。这种方法认可了智能体实现目标的多样路径，同时确保结果符合预期。对于复杂流程，可将评估拆分为若干关键检查点，考察每个阶段是否发生了应有的状态变更，而无需验证每一步细节。
长周期对话管理。 生产环境下的智能体常需应对长达数百轮的对话，这对上下文管理提出了更高要求。随着对话延长，常规的上下文窗口已不够用，必须依靠智能压缩与记忆机制。我们的做法是让智能体在完成某一阶段任务后，总结关键信息并存储于外部记忆系统，然后再进入新任务。当接近上下文限制时，智能体可创建新的子智能体，以干净的上下文继续任务，并通过精心设计的交接流程保持连贯性。此外，智能体可随时从记忆中调取如研究计划等已存信息，而非因窗口溢出丢失工作进展。这种分布式方法可有效防止上下文溢出，同时保持长对话的一致性和连贯性。
子智能体直接输出至文件系统，减少“传话游戏”信息损失。 对于某些类型的结果，允许子智能体绕过主协调者（coordinator）直接输出，可提升结果的保真度和系统性能。与其让子智能体一切信息都经主智能体转述，不如引入工件系统（artifact systems），让专业化子智能体可独立生成、存储持久化输出。子智能体通过工具将工作成果存入外部系统，再将轻量级引用信息交还协调者。这一模式可防止多轮处理过程中的信息损失，也减少了因历史对话反复复制大块输出而造成的 token 消耗。对于结构化输出（如代码、报告或数据可视化）而言，采用专业子智能体的专属提示词，往往比通过通用协调者转述更能保证结果质量。
（本文由 AI 翻译，网易编辑负责校对）
广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。