Anthropic多智能体研究系统构建方法详解
Anthropic 近期披露了其多智能体研究系统的内部技术细节。概括而言，该系统旨在让多个 Claude 智能体协同工作，处理单个模型难以独立完成的高复杂度任务。本文将对这套系统的架构设计、工程落地的具体挑战，以及实际运行中积累的性能数据展开详细拆解。
研究功能目前已具备跨网络、Google Workspace 及其他集成应用进行搜索与执行复杂任务的能力。从原型验证到正式产品的演进过程中，系统架构的搭建、工具链的设计以及提示词的调优，每个环节都值得深入复盘。
多智能体系统的核心，是让多个能够自主调用工具的大语言模型协同作业。Anthropic 的实现方式为：一个“主智能体”负责根据用户问题规划研究路径，随后创建并行的“子智能体”，分别独立搜索信息。下面我们直接进入正题。
多智能体系统的优势
研究任务大多面向开放性问题，其执行路径在开始前难以完全预判。对一个复杂课题硬编码固定工作流并不可行，因为研究本质上是动态的，依赖探索过程中的发现。人类的研究工作正是如此——根据新线索不断调整方向。
这种不可预测性，恰恰让 AI 智能体成为研究任务的理想载体。它必须具备灵活转向、探索相关分支的能力，能够自主进行多轮迭代，并根据中间结果决定下一步的探索方向。线性的一次性流程，完全无法胜任这类任务。
搜索的本质在于信息压缩——从海量数据中提取出有深度的洞见。子智能体通过并行运作强化了这一压缩过程：每个子智能体拥有独立的上下文窗口，可以同时探索问题的不同侧面，并将最关键的信息（tokens）提炼后回传至主智能体。此外，每个子智能体都实现了“关注点分离”——它们各自拥有独特的工具、提示词和探索路径——从而减少了路径依赖，确保了调查的彻底性与独立性。
一旦智能体的能力达到一定阈值，多智能体系统便成为扩展性能的关键手段。打个比方：过去十万年间，个体人类的智力并未发生质的飞跃，但人类社会在信息时代的能力却呈指数级增长，其核心驱动力在于集体智慧与协调能力。同样，即便通用智能体单兵作战存在能力边界，当它们形成群体协作时，却能完成远超个体总和的任务。
内部评估数据能直观反映这一点：在处理需要同时探索多个独立方向的“广度优先”查询时，多智能体系统的优势最为突出。我们测试了“Claude Opus 4 做主智能体 + Claude Sonnet 4 做子智能体”的组合，并将其与单个 Claude Opus 4 进行对比。结果显示，多智能体系统的性能高出 90.2%。举个例子，当要求找出标普500信息技术板块所有公司的董事会成员时，多智能体系统通过拆解任务并分发给子智能体，能够顺利找到答案；而单智能体系统由于需要逐一顺序搜索，最终因超时而失败。
多智能体系统高效的根本原因，在于它能够调动足够的计算资源（tokens）来解决问题。我们在分析中找出了影响 BrowseComp 评估（该评估用于测试浏览智能体定位稀有信息的能力）性能的三个因素，它们共同解释了 95% 的性能差异。其中，仅 token 使用量就解释了 80% 的差异，另外两个因素分别是工具调用次数和模型选择。这一发现验证了我们的架构设计方向：通过将工作分配给拥有独立上下文窗口的多个智能体，从而增加系统的并行推理能力。同时，最新的 Claude 模型在 token 使用效率上取得了巨大提升。例如，将模型升级到 Claude Sonnet 4 所带来的性能增益，甚至超过了在 Claude Sonnet 3.7 上翻倍 token 预算的效果。对于那些单个智能体难以完成的任务，多智能体架构能够有效扩展 token 的使用规模。
当然，任何方案都有代价。多智能体系统的显著劣势在于 token 消耗速度极快。数据表明，智能体通常比普通聊天多消耗约 4 倍的 token，而多智能体系统则可能攀升至 15 倍左右。要使其在经济上可行，这些系统所处理的任务必须具有足够高的价值，以覆盖性能提升带来的成本。此外，在某些场景下，多智能体系统并非合适选择——例如，当所有智能体必须共享同一上下文，或者智能体之间存在大量依赖关系时。大多数编码任务就是典型例子：其真正可并行执行的任务比研究任务少得多，且大模型智能体目前在与其他智能体的实时协调与任务委派方面表现欠佳。总结来看，多智能体系统最适合处理那些价值高、涉及大量并行处理、信息量超出单个上下文窗口，并且需要与众多复杂工具打交道的任务。
研究功能的架构概览
这套研究系统采用的是“协调者-工作者”多智能体架构。简而言之，由一个主智能体负责全局协调，同时将任务派发给并行的专业子智能体。
用户提交查询后，主智能体首先分析问题并制定策略，随后生成子智能体，让它们同时探索问题的不同侧面。如上图所示：子智能体充当智能过滤器，反复使用搜索工具收集信息（本例中涉及2025年AI智能体公司的情况），最后将公司列表返回给主智能体，由后者汇编成最终答案。
传统方法依赖“检索增强生成”（RAG），其核心是静态检索——即先获取一批与输入查询最相似的文本块，再利用这些文本块生成回答。而我们的架构则完全不同，它是一位多步搜索的专家，能够动态发现相关信息、适应新发现、分析结果，并最终形成高质量答案。
流程图展示了整个工作流的全貌。用户提交查询后，系统创建一个 LeadResearcher（主研究员）智能体，并进入迭代的研究过程。LeadResearcher 首先思考研究方法，将计划保存至 Memory（记忆）中——因为一旦上下文窗口超过20万个 token 会被截断，保留计划至关重要。随后，它会创建专门的 SubAgents（子智能体）（图中显示两个，实际数量可任意），为每个子智能体分配具体的研究任务。每个 Subagent 独立进行网络搜索，并采用“交错思考”的方式评估工具返回的结果，再将发现结果返回给 LeadResearcher。LeadResearcher 综合这些结果，判断是否需要进一步研究——如需继续，可以创建更多子智能体或调整策略。一旦信息收集完成，系统退出研究循环，将所有发现结果传递给一个 CitationAgent（引文智能体），该智能体负责处理文档和研究报告，确定引文的具体位置，确保所有声明都有来源可查。最后，附带引文的最终研究结果将呈现给用户。
研究智能体的提示工程与评估
多智能体系统与单智能体系统的关键区别在于，协调复杂度会急剧增长。早期版本曾出现不少问题——例如，为简单查询生成了50个子智能体，为寻找不存在的来源而没完没了地搜索网络，还会因为大量更新而相互干扰。由于每个智能体都由提示词驱动，提示工程便成为改进这些行为的核心手段。以下是我们总结出的一些原则：
- 建立智能体的心智模型。 要迭代优化提示词，必须先理解它们的效果。我们通过 Console 构建了模拟环境，直接使用系统里实际的提示词和工具，然后一步步观察智能体的运作。这种方法能快速暴露失败模式：智能体在手头结果已足够时仍继续搜索，搜索查询又长又啰嗦，或者选错了工具。有效的提示词依赖你对智能体建立准确的“心智模型”，一旦模型正确，最需要改动的地方便一目了然。
- 教会协调者如何委派任务。 主智能体负责将查询分解为子任务，然后向子智能体描述这些任务。每个子智能体需要明确：目标是什么、输出什么格式、该用哪些工具和来源、任务边界在哪里。缺少详细的任务说明书，智能体就会重复劳动、留下空白、或者找不到关键信息。早期我们让主智能体只扔一句简单的“研究半导体短缺”，结果指令过于模糊，子智能体要么误解任务，要么与同事做一模一样的搜索。比如，一个子智能体在研究2021年的汽车芯片危机，另外两个却在重复调查当前的2025年供应链——根本没有形成有效分工。
- 根据查询的复杂性动态调整投入。 智能体很难判断不同任务需要多少投入，因此我们在提示词中嵌入了伸缩性规则。简单事实查找：1个智能体，3-10次工具调用；直接比较：2-4个子智能体，每个10-15次调用；复杂研究：可能需要超过10个子智能体，且有明确划分的职责。这些指导方针能帮助主智能体高效分配资源，防止在简单查询上过度投入——这是早期版本常见的问题。
- 工具设计与选择至关重要。 智能体与工具的接口，其重要性不亚于人机界面。选对工具能极大提升效率，但很多时候根本绕不开。例如，一个在Slack里找信息，但信息实则只存在于网站上的智能体，从一开始就注定失败。MCP 服务器让模型能访问外部工具后，问题变得更加复杂——智能体可能碰到描述质量参差不齐的未知工具。我们为它们设定了一些明确的启发式规则：先检查所有可用工具，让工具使用匹配用户意图，网络搜索用于广泛的外部探索，优先使用专业工具而非通用工具。糟糕的工具描述会把智能体引上完全错误的道路，因此每个工具都要有明确的用途和清晰的描述。
- 让智能体实现自我改进。 我们发现 Claude 4 模型可以成为出色的提示工程师。给它一个提示词和一个失败模式，它能诊断出问题并给出改进建议。我们甚至创建了一个工具测试智能体——给它一个有缺陷的 MCP 工具，它会尝试使用这个工具，然后重写工具描述来避免失败。经过数十次测试，它找出了关键的细微差别和错误。经过这一轮“工具人机工程学”改进，未来使用新描述的智能体完成任务的时间减少了40%，因为它们能绕开大多数错误。
- 先宽泛后聚焦。 搜索策略应模仿人类专家的研究方法：在深入具体细节之前，先对整个领域有大致的了解。智能体常犯一个错误：默认使用又长又具体的查询，结果返回寥寥无几。我们通过提示词让它们从简短宽泛的查询开始，评估现有信息，然后逐步缩小焦点。这个调整效果非常显著。
- 引导思考过程。 “扩展思考”模式能让 Claude 在一个可见的思考过程中输出额外的 token，这相当于给了一张可以自由涂写的草稿纸。主智能体利用思考来规划方法、评估哪些工具适合任务、确定查询复杂度和子智能体数量、定义每个子智能体的角色。测试显示，扩展思考明显改善了指令跟随能力、推理能力和效率。子智能体也会先做规划，然后等工具返回结果后，用“交错思考”来评估质量、找出差距、优化下一次查询。这让它们能更灵活地适应任务。
- 并行工具调用改变了速度与性能。 复杂的研究任务自然涉及探索大量来源。早期的智能体是顺序执行搜索的，慢得令人难以忍受。为了提速，我们引入了两种并行化方式：一是主智能体并行启动3-5个子智能体，而非逐个启动；二是子智能体并行使用3个以上的工具。这一改动将复杂查询的研究时间缩短了最高90%，让研究功能能在几分钟内完成更多工作（而非几小时），同时覆盖的信息也更加全面。
提示策略的重点并非制定死板的规则，而是灌输良好的启发式方法。我们研究了顶尖人类研究者处理任务的方式，并将这些策略写进提示词中——比如将难题分解为更小的任务、仔细评估来源质量、根据新信息调整搜索方法、识别何时该深入（深挖一个主题）何时该拓宽（并行探索多个主题）。我们还设置了明确的边界来预防意外的副作用，防止智能体失控。最终，整个工作围绕一个快速迭代循环展开：可观察性 + 测试用例。
对智能体的有效评估
好的评估是构建可靠AI应用的基础，智能体也不例外。但评估多智能体系统有其独特的挑战。传统的评估通常假设AI每次都走同样的步骤：给定输入X，系统应该沿着路径Y产生输出Z。但多智能体系统并非如此运作——即便起点完全相同，智能体也可能采取完全不同但同样有效的路径。一个智能体可能搜索三个来源，另一个可能搜索十个；它们可能用了不同工具但找到了相同答案。因为我们并不总是知道什么才是“正确”的步骤，所以不能只检查智能体是否照搬预设的路径。相反，我们需要灵活的方法，既能判断结果是否正确，也能判断过程是否合理。
立即用小样本开始评估。 在智能体开发的早期阶段，改动往往能带来巨大效果——因为到处都是唾手可得的优化空间。一个提示词的小调整就可能把成功率从30%拉高到80%。在这个阶段，只用几个测试用例就能看出变化。我们是从大约20个能代表真实使用模式的查询开始的，测试这些查询通常就足以判断改动的效果。常听说有AI开发团队推迟建立评估，因为觉得只有包含几百个测试用例的“大评估”才有意义。但与其等着凑够大规模再行动，不如立刻用几个例子开始小规模测试。
“大语言模型充当评委”的评估方法，如果运用得当，可以规模化。 研究输出很难通过程序自动评估——它们是自由格式的文本，很少只有一个标准答案。大语言模型天然适合为输出打分。我们采用的方法是：让一个大模型评委根据一套评分标准来打分——事实准确性（声明与来源匹配吗？）、引文准确性（引用的来源与声明匹配吗？）、完整性（所有要求的内容都覆盖了吗？）、来源质量（使用了主要来源还是低质量的次要来源？）、工具效率（是否以合理的次数使用了正确的工具？）。我们曾尝试用多个评委分别评估每个部分，但最终发现，采用单次调用、单个提示词输出0.0-1.0分数并附带“通过/不通过”等级的方式，最一致且最符合人类判断。尤其是对于那些评估本身有明确答案的测试用例（例如“它有没有准确列出研发预算最高的三家制药公司？”），这种方法格外好用。通过用大模型当评委，我们能够规模化地评估几百个输出结果。
人工评估能捕捉到自动化遗漏的东西。 让人来测试智能体，会发现评估里漏掉的各种边缘情况——比如在不常见的查询下出现幻觉答案、系统故障，或者微妙的来源选择偏见。我们就遇到过这种情况：早期智能体总是优先抓取SEO优化过的内容农场，而不去选那些更权威但排名不高的来源（比如学术PDF或个人博客）。后来我们在提示词里加上了来源质量的启发式规则，这才解决问题。即便自动化评估越来越成熟，手动测试依然是不可替代的一环。
多智能体系统有一种“涌现行为”——这些行为并非通过明确编程产生。例如，对主智能体做一个小改动，可能会不可预测地改变所有子智能体的行为。要成功运作，你需要理解的是交互模式，而不只是单个智能体的行为。因此，这类智能体最好的提示词并非冰冷的指令，而是一套协作框架——它定义了分工、解决问题的方法和投入预算。要做到这一点，依靠的是精心设计的提示词和工具、靠谱的启发式方法、完善的可观察性，以及紧密的反馈循环。
生产环境的可靠性与工程挑战
在传统软件中，一个bug可能破坏功能、降低性能或导致服务中断。但在智能体系统中，微小的改动会像雪崩一样造成巨大的行为变化，这为编写那些必须在长期运行中维持状态的复杂智能体代码带来了极大的困难。
智能体是有状态的，错误会累积。 智能体可以长时间运行，在多次工具调用中维持状态。这意味着我们需要永久性地执行代码、处理过程中的错误。没有有效的缓解措施，一个微小的系统故障对智能体来说就是灾难性的。而且一旦出错，我们不能简单地从头开始——重启对用户来说既昂贵又令人烦恼。因此，我们构建的系统能在错误发生时，从智能体当前所在的位置恢复。我们还利用智能体的智能来优雅地处理问题：例如，让智能体知道某个工具坏了，让它自己学会适应，效果出乎意料地好。我们将基于Claude构建的AI智能体的适应性，与重试逻辑、定期检查点等确定性保障措施结合了起来。
调试需要新方法。 智能体做出的是动态决策，而且即便使用一模一样的提示词，每次运行的结果也是不确定的——这让调试变得更棘手。举个例子，用户报告说“智能体找不到一个很明显的信息”，但看不出原因。是搜索关键词太糟？来源选得差？还是工具遇到了故障？我们增加了完整的生产环境追踪，这才能够诊断失败原因并系统性地修复问题。除了标准的可观察性，我们也监控智能体的决策模式和交互结构——所有这些监控都不触及单个对话内容，以保护用户隐私。这种高层次的可观察性帮助我们找到问题根源、发现意外行为、修复常见故障。
部署需要精心协调。 智能体系统是由提示词、工具和执行逻辑构成的高度有状态的网络，几乎是持续24小时运行的。这意味着每次更新部署时，智能体可能正处于流程中的任何一个位置。我们不能让好心的代码变更把正在运行的智能体给破坏了，也不能一口气把所有智能体都更新到新版本。解决方案是“彩虹部署”——新旧版本同时运行，然后逐步将流量从旧版本切换过来，避免干扰正在运行的任务。
同步执行会造成瓶颈。 目前，我们的主智能体是同步执行子智能体的——先等每一批子智能体都完成后才继续进行。这简化了协调，但也在智能体之间的信息流中制造了瓶颈。主智能体无法实时引导子智能体，子智能体之间无法协调，整个系统可能因为等待一个子智能体完成搜索而被卡住。异步执行能实现额外的并行性：智能体可以并发工作，根据需要创建新的子智能体。但这也会在结果协调、状态一致性和跨子智能体的错误传播方面增加新的挑战。随着模型能力越来越强，能够处理更大、更复杂的研究任务，我们预计性能提升终将证明这种复杂性是值得的。
结论
构建AI智能体时，“最后一公里”往往占据了整个旅程的大部分工作量。在开发者机器上运行良好的代码库，需要投入大量的工程精力才能变成一个可靠的生产系统。智能体系统中错误会“复合增长”的特性，意味着那些在传统软件里无伤大雅的小问题，可能会让智能体彻底脱轨——一步失败就可能导致智能体探索出一条完全不同的路线，产生不可预测的后果。基于前面讨论的所有原因，原型与生产之间的差距往往比很多人预想的要大得多。
尽管挑战不少，多智能体系统在处理开放式研究任务上的价值已经得到证明。用户反馈显示，Claude 帮助他们找到了此前从未考虑过的商业机会，理清了复杂的医疗保健选项，解决了棘手的技术错误，还通过揭示他们自己无法找到的研究关联，节省了长达几天的工作量。通过精心的工程设计、全面的测试、打磨细节的提示词和工具设计、稳健的运营实践，以及拥有对当前智能体能力深刻理解的研究、产品和工程团队之间的紧密协作，多智能体研究系统完全可以稳定运行在规模化的场景中。我们已经看到这些系统正在实实在在地改变人们解决复杂问题的方式。
这是一张 Clio 嵌入图，展示了当前人们使用“研究”功能最常见的方式。排名靠前的用例包括：跨专业领域开发软件系统（10%）、开发和优化专业及技术内容（8%）、制定业务增长和创收策略（8%）、协助学术研究和教育材料开发（7%），以及研究和核实关于人物、地点或组织的信息（5%）。
附录
下面是一些关于多智能体系统的额外杂项技巧。
对多轮修改状态的智能体进行终态评估。 评估那些在多轮对话中修改持久状态的智能体，挑战独特。与只读的研究任务不同，这里的每个动作都可能改变后续步骤的环境，形成传统评估方法难以处理的依赖关系。我们发现，成功的关键是专注于“终态评估”，而不是一轮接一轮地分析。与其判断智能体是否走了特定流程，不如评估它有没有达到正确的最终状态。这个方法承认智能体可能通过不同路径到达同一个目标，同时仍然能确保它们交付预期的结果。对于复杂的工作流，评估应分解成离散的检查点——在这些点上应已发生特定的状态变化——而不是试图去验证每个中间步骤。
长跨度对话管理。 生产环境中的智能体经常会进行跨越几百轮的对话，这需要精细的上下文管理策略。随着对话变长，标准的上下文窗口变得不够用，需要聪明的压缩和记忆机制。我们实现了一些模式，让智能体在进入新任务之前，先总结完成的工作阶段，并把基本信息存储到外部记忆中。当接近上下文限制时，智能体可以生成一个带有干净上下文的新子智能体，通过精心的交接保持连续性。同时，它可以从记忆中检索之前存储的上下文（比如研究计划），而不是在达到上下文限制时丢失之前的工作。这种分布式方法既保持了扩展对话的连贯性，又防止了上下文溢出。
将子智能体的输出保存到文件系统，以最大限度地减少“传话游戏”。 对于某些类型的结果，子智能体可以直接“绕开”主协调者输出，从而提高保真度和性能。与其要求子智能体把所有信息都通过主智能体来传递，不如实现一个“工件”系统，让专业智能体能创建独立且持久的输出。子智能体调用工具把工作成果存到外部系统中，然后只把轻量级的引用传回给协调者。这既能防止在多阶段处理过程中产生信息丢失，也能减少因为把大量输出复制到对话历史里消耗的token开支。这种模式特别适用于结构化输出，比如代码、报告或数据可视化——子智能体的专业化提示词往往比通过通用协调者过滤能产出更好的结果。