Anthropic Claude Multi-Agent Research System Architecture

Research (or DeepResearch) 能力是 AI Agent 研究的一个重要方向，很多知名的 AI 公司都在积极探索这个方向。Anthropic 也不例外，Claude 现在也具备了强大的研究能力（https://www.anthropic.com/news/research），能够在互联网、Google Workspace 以及各种集成服务中搜索信息来完成复杂任务。

最近 Anthropic 分享了构建这套系统的工程经验（https://www.anthropic.com/engineering/built-multi-agent-research-system），从系统架构设计到提示工程优化，从评估方法到生产环境的可靠性保障，这些经验对于我们理解和构建类似的多智能体系统具有重要的参考价值。

接下来，让我们来一起学习 Anthropic 是如何构建 Claude 的研究功能的。

多智能体架构的必要性

研究（Research）工作的本质决定了它无法被简单的线性流程所处理。当我们探索复杂主题时，很难预先确定所需的具体步骤，因为研究过程本身就是动态的、路径依赖的。人类研究者会根据发现的内容持续调整方法，跟随调查过程中出现的新线索调整方向，处理这种灵活性的问题正是 AI 智能体的优势所在。

传统的 RAG 方法使用静态检索——获取与输入查询最相似的一些文档块，然后基于这些内容生成响应。但这种方法无法处理需要多步探索、动态调整策略的复杂研究任务。多智能体系统则能够根据中间发现来决定下一步的探索方向，实现真正的动态研究过程。

从信息处理的角度来看，搜索（Search）的本质是压缩——从庞大的语料库中提炼出有价值的信息。多智能体系统通过并行的让子智能体在各自的上下文窗口中操作，同时探索问题的不同方面，然后将最重要的信息汇总给主研究智能体（Lead Researcher）。这种分工不仅提高了效率，还实现了关注点分离，减少了路径依赖，确保了更全面、独立的调查。

Anthropic 的内部评估数据很好地证明了这一点。他们发现，使用 Claude Opus 4 作为主智能体、Claude Sonnet 4 作为子智能体的多智能体系统，在内部研究评估中比单智能体 Claude Opus 4 的表现提升了 90.2%。特别是在需要同时追求多个独立方向的广度优先查询方面，多智能体系统表现尤其出色。

更有趣的是，他们的分析揭示了多智能体系统有效性的根本原因：它们在解决问题时使用了足够多的 token。在 BrowseComp 评估中，token 使用量、工具使用次数和模型选择三个因素解释了 95% 的性能差异，其中仅 token 使用量就解释了 80% 的差异。这验证了多智能体架构的核心价值——通过分布式处理来扩展 token 使用容量。

当然，这种架构也有明显的成本考量。在实际应用中，智能体通常使用比普通聊天交互多约 4 倍的 token，而多智能体系统的 token 消耗更是达到了聊天交互的 15 倍。因此，多智能体系统更适合那些价值足够高、能够承担额外性能成本的任务。此外，一些要求所有智能体共享上下文或者智能体之间有大量依赖关系的领域，并不适合使用多智能体系统。

系统架构设计

Anthropic 的研究系统采用了编排者-工作者（orchestrator-worker）模式的多智能体架构。在这个架构中，主智能体（Lead agent）负责协调整个研究过程，同时将具体的搜索任务委托给并行运行的专门子智能体（Subagent）。

当用户提交查询时，主智能体会分析查询内容，制定研究策略，然后生成多个子智能体来同时探索不同的方向。子智能体充当智能过滤器的角色，通过迭代使用搜索工具收集信息，然后将筛选后的结果返回给主智能体进行最终的答案汇总。

这种架构的核心优势在于实现了真正的多步动态搜索。与传统 RAG 方法的静态检索不同，这个系统能够根据搜索过程中的新发现动态调整策略，适应性地寻找相关信息，并通过分析结果来制定高质量的答案。

整个系统的工作流程可以分为以下几个关键阶段：

查询分析与策略规划：用户提交查询后，系统创建主研究智能体（Lead Researcher），开始整个迭代研究过程。主智能体首先思考研究方法并将计划保存到记忆系统中，这样即使上下文窗口超过 token 数量限制时也能保持计划的持久性。

任务分解与并行执行：基于研究计划，主智能体创建专门的子智能体，每个都承担特定的研究任务。这些子智能体独立执行网络搜索，使用交错思考（interleaved thinking）模式评估工具结果，并将发现返回给主研究智能体。

结果综合与迭代优化：主研究智能体综合所有子智能体的结果，评估是否需要更多研究。如果需要，它可以创建额外的子智能体或完善现有策略，形成一个动态的研究循环。

引用处理与输出生成：收集到足够信息后，系统将所有发现传递给专门的引用智能体（CitationAgent），负责处理文档和研究报告，识别引用的具体位置，确保所有声明都有适当的来源支撑。

Prompt Engineering

多智能体系统的复杂性主要体现在协调层面（coordination complexity）。早期版本的智能体经常出现一些典型问题：为简单查询生成过多的子智能体、无休止地搜索不存在的信息源、智能体之间过度通信导致效率低下等。由于每个智能体都由 prompt 引导，提示工程自然成为解决这些问题的主要手段。

Anthropic 团队在实践中总结出了一套行之有效的提示工程原则，这些原则不仅适用于他们的研究系统，对其他多智能体系统的构建也具有重要的指导意义。

像智能体一样思考

要有效地迭代优化 prompt，首先必须深入理解它们的实际效果。Anthropic 团队使用他们自己的 Console 系统构建了完整的模拟环境，使用与生产系统完全相同的 prompt 和工具，然后逐步观察智能体的工作过程。这种方法能够及时的发现各种的失败模式：智能体在已经获得足够结果时仍然继续工作、使用过于冗长的搜索查询、选择错误的工具等。有了这样的工具，便可以使开发者能够像智能体一样思考，从它们的角度审视问题并找到有效的解决方案。

教会编排者如何有效调度

在多智能体系统中，主智能体需要将复杂查询分解为子任务，并向子智能体清晰地描述这些任务。每个子智能体都需要明确的目标、输出格式、工具使用指导以及清晰的任务边界。缺乏详细任务描述的后果往往是灾难性的：智能体会重复工作、留下关键信息空白，或者完全无法找到必要的信息。

根据查询复杂性动态调整工作量

智能体往往难以准确判断不同任务所需的合适工作量是多少，因此需要在 prompt 中嵌入明确的工作量等级规则。简单的事实查找可能只需要 1 个智能体进行 3-10 次工具调用，直接比较类任务可能需要 2-4 个子智能体各自进行 10-15 次调用，而复杂的研究任务可能需要超过 10 个子智能体，每个都有明确分工的责任。

工具设计和选择的关键性

智能体与工具的接口设计与人机交互界面同样重要。使用正确的工具不仅是效率问题，往往是任务成功的必要条件。比如，让智能体在网络上搜索只存在于 Slack 中的信息，这样的任务从一开始就注定失败。因此，需要为智能体提供明确的启发式的工具选择方法：优先检查所有可用工具、将工具使用与用户意图匹配、针对广泛探索使用网络搜索、优先选择专门工具而非通用工具等。

智能体自我改进

Anthropic 团队发现了一个有趣的现象，Claude 4 模型本身就是出色的 prompt 工程师。当提供 prompt 和失败模式时，模型能够诊断智能体失败的原因并提出改进建议。Anthropic 甚至创建了专门的工具测试智能体——当给定一个有缺陷的MCP工具时，它会尝试使用该工具，然后重写工具描述以避免失败。通过对该工具进行数十次测试，这个智能体发现了关键的细微差别和漏洞。通过自动改进工具描述，使得后来使用这些工具的智能体完成任务的时间减少了40%。

先宽后窄的搜索策略

搜索策略应该模仿专家级人类研究者的方法：在深入具体细节之前先探索整体情况。智能体往往默认使用过长、过于具体的查询，导致返回结果很少。为了克服这个问题，需要通过 prompt 引导智能体从简短、广泛的查询开始，评估可用内容，然后逐步缩小焦点。

充分利用扩展思考模式

扩展思考（Extended Thinking）模式为智能体提供了可控的"草稿本"。主智能体可以利用思考过程来规划方法、评估工具适用性、确定查询复杂性和子智能体数量、定义各个子智能体的角色。测试表明，扩展思考显著改善了指令遵循、推理能力和整体效率。扩展思考为什么有效？因为显示的思考过程会明显提升大语言模型在处理复杂问题时的性能表现，具体可以参考如何让 AI 学会思考这篇文章。

并行化带来的性能提升

复杂研究任务天然需要探索多个信息源。早期的智能体采用顺序搜索方式，速度极其缓慢。通过引入两种并行化策略——主智能体并行启动 3-5 个子智能体，以及子智能体并行使用多个工具——系统的研究时间减少了高达 90%。这种并行化不仅提升了速度，还显著改善了整体性能。

评估方法的挑战与实践

评估多智能体系统比评估传统 AI 应用更加复杂。传统评估通常基于确定性假设：给定输入 X，系统应该遵循路径 Y 产生输出 Z。但多智能体系统的工作方式完全不同——即使面对相同的起始条件，不同的智能体可能采取完全不同但同样有效的路径来达成目标。

这种非确定性特点迫使我们需要重新思考评估策略。我们不能简单地检查智能体是否遵循了预设的"正确"步骤，而需要更灵活的评估方法来判断智能体是否达成了正确的结果的同时遵循了合理的过程。

从小样本开始，快速迭代

在智能体开发的早期阶段，由于有大量容易实现的目标，所以很多改动往往会产生巨大影响。一个简单的 prompt 调整可能就能将成功率从 30% 提升到 80%，即使只用几个测试用例也能清楚地看到变化。

Anthropic 团队从大约 20 个代表真实使用场景的查询开始构建评估集。这种做法的优势在于能够快速获得反馈，避免了过早构建大规模评估集的陷阱。许多 AI 开发团队会因为认为只有包含数百个测试用例的大规模评估才有用而推迟进行评估的时间，但实际上，从小规模测试开始并快速迭代是更好的策略。

LLM-as-Judge

研究的输出通常是自由形式的文本，很少有单一的正确答案，这使得程序化评估变得难以实施。LLM 很自然的成为了这种任务的最佳选择。Anthropic 使用 LLM 根据多个维度评估每个输出：

• 事实准确性（声明是否与来源匹配）
• 引用准确性（引用的来源是否支持相关声明）
• 完整性（是否涵盖了所有要求的方面）
• 来源质量（是否使用了高质量的主要来源）
• 及工具效率（是否合理地使用了正确的工具）

他们尝试过用多个 LLM 来评估每个部分，但发现，通过单个提示词调用一次大语言模型，让其输出 0.0 到 1.0 的分数以及通过或不通过的评级，这种方式与人类评判最为一致。仅通过一次向 LLM 提交包含所有评估标准的提示词，即可完成对成果的综合评分，无需多次调用模型或分拆评估维度。当评估测试用例确实有明确答案时，这种方法尤其有效。比如，我们可以用大语言模型直接检查答案是否正确，像是「是否准确列出了研发预算排名前三的制药公司」这种问题。使用大语言模型作为评判者，使我们能够大规模地评估数百个研究成果。

人工评估

尽管自动化评估很重要，但人工测试仍然能够发现自动化评估遗漏的边缘情况。这些包括对不寻常查询的幻觉回答、系统故障，或者细微的来源选择偏见。

一个典型的例子是，人工测试者注意到早期的智能体系统始终倾向于选择 SEO 优化的内容，而忽略了权威性更高但搜索排名较低的来源，如学术 PDF 或个人博客。这种细微的偏见很难通过自动化评估发现，但对研究质量有重要影响。通过在 prompt 中添加强调来源质量的启发式方法，这个问题得到了有效解决。

生产环境的工程挑战

将多智能体系统从原型推向生产环境面临着很多工程挑战。与传统软件不同，智能体系统中的一些微小的变化可能会引起连锁反应，造成巨大的行为差异，这使得构建稳定可靠的生产系统变得异常困难。

状态管理与错误累积

智能体是有状态的，且错误会不断累积。智能体能够长时间运行，并在许多工具调用过程中维持状态一致。这就表明，我们需要持续稳定地运行代码，并在这一过程中处理错误。要是没有有效的应对措施，一些小的系统故障对于智能体而言都可能是灾难性的。

当出现错误时，我们不能仅仅从头开始重启：因为重启成本高，用户感知也很强烈。为了解决这个问题， Anthropic 构建了能够从错误发生时智能体所处状态恢复运行的系统。他们还利用 LLM 的自我提升能力来处理问题：例如，在工具出现故障时告知智能体，让其进行自适应调整，效果出奇地好。

最后，Anthropic 采用了一个综合的方法，将 AI 智能体的自我适应和优化能力，与重试逻辑和定期检查点（checkpoint）等确定性保障措施相结合。

完整的跟踪（Tracing）系统

智能体的动态决策特性和非确定性行为使得传统的调试方法变得不够用。即使使用相同的 prompt，智能体在不同运行之间也可能表现出不同的行为，这让问题诊断变得更加困难。

为了解决这个问题，Anthropic 添加了完整的生产跟踪系统，让他们能够诊断智能体失败的原因并系统性地修复问题。除了标准的可观测性工具，他们还监控智能体的决策模式和交互结构——当然，这些都不涉及监控个人对话内容，以保护用户隐私。这种高层次的可观测性帮助他们诊断根本原因、发现意外行为并修复常见故障。

部署需要精心协调

智能体系统是由 prompt、工具和执行逻辑组成的高度有状态的网络，几乎持续运行。这意味着在部署更新时，智能体可能处于其执行过程中的任何位置，需要防止代码变更破坏正在运行的智能体。

他们采用了彩虹部署（rainbow deployment）策略来避免中断运行中的智能体。这种方法通过在保持新旧版本同时运行的情况下，逐渐将流量从旧版本转移到新版本，确保了平滑的过渡。

同步执行带来性能瓶颈

目前的系统中，主智能体采用同步方式执行子智能体，需要等待每组子智能体完成后才能继续。这种设计简化了协调逻辑，但在智能体之间的信息流中创建了瓶颈。

异步执行能够实现更高的并行性——智能体可以并发工作，并在需要时创建新的子智能体。但这种异步性也带来了新的挑战：协调结果、状态一致性以及跨子智能体的错误传播等问题都变得更加复杂。随着模型能够处理更长且更复杂的研究任务，团队期望异步执行带来的性能提升将足以弥补其复杂性。

一些建议

子任务分配

前文已经说过，Token 的使用量是多智能体成功的关键。但同时， Anthropic 团队也发现，升级到 Claude Sonnet 4 带来的性能提升，甚至超过了在 Claude Sonnet 3.7 上将 token 预算翻倍的效果。这说明单个智能体的能力依然是任务能否完成的关键，当主智能体分配任务时，应该采用启发式的方法，考察每个模型的能力，将合适的任务分配给最适合的模型。

长期对话的上下文管理

投入实际应用的智能体常常参与跨度达数百轮的对话，这就需要谨慎的上下文管理策略。随着对话的推进，标准的上下文窗口会变得不够用，因此需要智能的压缩和记忆机制。

Anthropic 采用的策略是，智能体在进入新任务前，先总结已完成的工作阶段，并将关键信息存储到外部记忆中。同时，针对可能出现的上下文溢出情况，采用两种策略来处理：

1. 主动预防：当接近上下文限制时，智能体可以生成具有全新上下文的新子智能体，同时通过精心设计的交接方法，将任务交接给新的子智能体，来保持连贯性；
2. 被动恢复：万一未及时处理，上下文达到了限制，智能体可以从其记忆系统中检索诸如研究计划之类已存储的上下文信息，而不会丢失之前的工作成果。

子智能体直接输出到文件系统

让子智能体输出到文件系统，尽量减少 “传话” 带来的信息损失。对于某些类型的结果，子智能体的输出可以不通过主智能体直接输出到文件系统，这样能同时提高准确性和性能。

在这个系统中，子智能体通过工具调用将其工作存储在外部系统中，然后只向主智能体传递轻量级的引用。这种设计不仅防止了多阶段处理过程中的信息丢失，还显著减少了从对话历史中复制大量输出所需的 token 开销。这种模式特别适用于结构化输出，如代码、报告或数据可视化等场景，其中子智能体中专门设计的 prompt 能够产生比通过通用的主智能体过滤更好的结果。

端到端的评估方法

多智能体的研究系统是一个典型的多轮对话系统，并且每一轮的对话中，都会涉及到状态的修改。评估这类系统，有着特殊的挑战，它的每一个动作都会改变后续步骤的环境，产生传统评估方法难以处理的依赖关系。

Anthropic 发现，将重点放在最终状态评估上会更有成效。不是判断智能体是否遵循了特定的过程，而是评估它是否达到了正确的最终状态。这种方法认可智能体可能会通过不同路径实现相同目标，同时仍能确保它们达成预期结果。

对于复杂的工作流程，端到端的评估可能忽视一些重要的细节，因此可以采用相对折中的方案，将系统分为几个固定的检查点，在这些检查点处特定的状态变化应该已经发生，只评估这些检查点即可，即不用验证每一个中间步骤，也避免了只关注最后结果。

总结

构建 AI 智能体系统时，"最后一公里"往往会成为整个旅程中最具挑战性的部分。在开发环境上运行良好的代码，要真正上线到生产环境需要大量的工程投入。智能体系统中错误具有累积性，这意味着对于传统软件而言的小问题，却可能使智能体彻底瘫痪。一个步骤的失败就可能导致智能体探索完全不同的路径，从而产生不可预测的结果。基于本文所述的所有这些原因，原型与实际生产之间的差距通常比预期的更大。

尽管面临这些挑战，多智能体系统已经在开放式研究任务中证明了其价值。用户反馈显示，Claude 的研究功能帮助他们发现了之前未曾考虑的商业机会、导航复杂的医疗选择、解决棘手的技术问题，并通过发现他们单独无法找到的研究联系节省了大量时间。

从上图可以看出，用户使用研究功能的主要场景包括：跨专业领域的软件系统开发（10%）、专业技术内容的开发和优化（8%）、业务增长和收入策略制定（8%）、学术研究和教育材料开发（7%），以及人员、地点或组织信息的研究验证（5%）。

通读整篇博客我们会发现，现在在构建 AI agent 方面，很多公司虽然采用不同的模型、不同的技术框架，但是核心的思想都是类似，比如：长短期结合的记忆系统、专业而精确的 prompt，单元测试与端到端结合的测试方式等等。