我们如何构建多 Agent Research 系统

Agent 现在已经具备能力，可以搜索网页、Google Workspace 以及各种集成，以完成复杂任务。

这个多 Agent 系统从原型走向生产的过程，让我们学到了很多关于系统架构、工具设计和提示词工程的重要经验。多 Agent 系统由多个 Agent 共同工作组成，而每个 Agent 本质上都是一个能够在循环中自主使用工具的 LLM。我们的 Research 功能会先由一个 Agent 根据用户查询规划研究流程，然后通过工具创建多个并行 Agent，让它们同时搜索信息。与单 Agent 系统相比，多 Agent 系统也带来了 Agent 协调、评测和可靠性方面的新挑战。

本文将拆解对我们有效的一些原则，希望这些经验也能帮助你构建自己的多 Agent 系统。

### 多 Agent 系统的优势

研究类任务通常是开放式问题，很难提前预测需要执行哪些步骤。对于复杂主题，你无法把探索路径硬编码成一条固定流程，因为研究过程本身就是动态的，并且具有路径依赖性。人类在进行研究时，也会不断根据新的发现调整方法，并追踪调查过程中出现的新线索。

这种不可预测性，恰恰让 AI Agent 非常适合研究任务。研究要求系统能够随着调查推进随时改变方向，或者探索旁支联系。模型必须在很多轮中自主运行，并根据中间发现决定下一步应该沿着哪些方向继续探索。线性的、一次性的流水线无法很好地处理这类任务。

搜索的本质其实是一种压缩：从庞大的信息语料中提炼洞见。Subagent 可以使用各自独立的上下文窗口并行工作，同时探索问题的不同方面，然后再把最重要的信息压缩后交给 Lead Research Agent。每个 Subagent 还天然形成了关注点分离：它们拥有不同的工具、提示词和探索路径。这种设计可以减少路径依赖，让不同方向得到更充分、彼此独立的调查。

当智能达到一定门槛之后，多 Agent 系统就会成为扩展系统能力的重要方式。举例来说，虽然过去十万年中单个人类的智力没有发生指数级变化，但在信息时代，人类社会的整体能力却呈指数级增长，这很大程度上依赖于我们的集体智能与协作能力。即使是具备通用能力的 Agent，作为单个个体运行时也会受到限制；多个 Agent 协作可以完成远远更多的事情。

我们的内部评测显示，多 Agent Research 系统在“广度优先”型查询上尤其有优势，也就是那些需要同时沿着多个彼此独立方向进行探索的任务。我们发现，以 Claude Opus 4 作为 Lead Agent、Claude Sonnet 4 作为 Subagent 的多 Agent 系统，在内部 Research Eval 上比单 Agent 的 Claude Opus 4 高出 90.2%。

例如，当任务是找出标普 500 信息技术板块所有公司的董事会成员时，多 Agent 系统可以把问题拆分给多个 Subagent 分别处理，从而找到正确答案；而单 Agent 系统只能缓慢地顺序搜索，最终未能完成任务。

多 Agent 系统之所以有效，一个重要原因在于它可以为问题投入足够多的 Token。

在我们对 [BrowseComp](https://openai.com/index/browsecomp/) 评测的分析中，有三个因素能够解释 95% 的性能差异。BrowseComp 用于测试浏览型 Agent 查找难以发现的信息的能力。我们发现，仅 Token 使用量一个因素就可以解释 80% 的性能方差，另外两个主要因素是工具调用次数和模型选择。

这一结果验证了我们的架构设计：把任务分散给拥有独立上下文窗口的多个 Agent，可以为并行推理增加更多容量。

最新的 Claude 模型本身也能够大幅提升 Token 的使用效率。举例来说，从 Claude Sonnet 3.7 升级到 Claude Sonnet 4 所带来的性能提升，比单纯把 Claude Sonnet 3.7 的 Token 预算翻倍还要明显。

对于那些超出单 Agent 能力或上下文限制的任务，多 Agent 架构实际上提供了一种有效扩展 Token 使用量的方法。

当然，它也有明显的代价：这类架构在实践中消耗 Token 的速度非常快。

根据我们的数据，一般 Agent 使用的 Token 大约是普通聊天交互的 4 倍，而多 Agent 系统大约会消耗普通聊天的 15 倍 Token。

因此，要在经济上可行，多 Agent 系统必须应用在那些任务价值足够高、能够抵消额外推理成本的场景中。

此外，有些领域要求所有 Agent 共享同一份上下文，或者 Agent 之间存在大量依赖关系，这些任务目前并不适合多 Agent 架构。

例如，大多数编程任务相比研究任务，真正可以并行化的工作要少得多，而且当前的 LLM Agent 还不擅长实时协调和委派给其他 Agent。

我们的经验是，多 Agent 系统最适合那些具有以下特征的高价值任务：

- 可以进行大量并行化；
- 所需信息量超过单一上下文窗口；
- 需要与大量复杂工具交互。

### Research 系统的架构概览

我们的 Research 系统采用一种基于“编排者—工作者（orchestrator-worker）”模式的多 Agent 架构：Lead Agent 负责协调整个流程，同时把任务委派给并行工作的专业 Subagent。

> 多 Agent 架构的实际运行方式：用户查询先进入 Lead Agent，再由 Lead Agent 创建多个专门的 Subagent，并行搜索问题的不同方面。

当用户提交查询后，Lead Agent 会先分析问题、制定策略，然后创建多个 Subagent，同时探索不同方向。

如上图所示，这些 Subagent 会充当智能过滤器。它们反复使用搜索工具来收集信息。在图中的例子里，它们负责搜索 2025 年的 AI Agent 公司，最后把公司列表返回给 Lead Agent，再由 Lead Agent 汇总成最终回答。

传统的检索增强生成（RAG）通常使用静态检索。也就是说，它会找出一批与输入查询最相似的文本块，再用这些文本块生成回答。

相比之下，我们的架构采用多步骤搜索：系统会动态寻找相关信息，根据新发现不断调整方向，并分析搜索结果，从而生成高质量答案。

> 多 Agent Research 系统完整工作流：用户提交查询后，系统会创建一个 `LeadResearcher` Agent，并进入迭代研究流程。`LeadResearcher` 首先思考研究方法，然后把计划保存到 Memory，以持久化上下文。由于上下文窗口一旦超过 200,000 Tokens 就可能发生截断，因此保留研究计划非常重要。之后，它会创建拥有明确研究任务的专业 Subagent。图中只画出了两个 Subagent，但实际数量可以任意变化。每个 Subagent 独立执行网页搜索，并使用交错思考（interleaved thinking）评估工具结果，然后把发现返回给 `LeadResearcher`。`LeadResearcher` 会综合这些结果，并判断是否还需要进一步研究。如果需要，它可以创建更多 Subagent，或者调整研究策略。当收集到足够信息后，系统退出研究循环，并把所有发现交给 `CitationAgent`。`CitationAgent` 会处理相关文档和研究报告，定位具体的引用位置，确保所有观点都能正确归因到来源。最后，带有引用的完整研究结果会返回给用户。

### Research Agent 的提示词工程与评测

多 Agent 系统与单 Agent 系统之间存在一些关键差异，其中一个就是协调复杂度会快速增长。

早期版本的 Agent 曾出现过很多问题，比如：

- 面对一个非常简单的问题却创建 50 个 Subagent；
- 为了寻找根本不存在的来源而无休止地搜索网页；
- Agent 之间发送过多状态更新，反而互相干扰。

由于每一个 Agent 都是通过提示词进行引导，因此提示词工程成为我们改善这些行为的主要手段。

以下是我们在给 Agent 编写提示词时总结出的一些原则。

- **像你的 Agent 一样思考。**  
  想迭代提示词，首先必须真正理解提示词会产生什么效果。为了做到这一点，我们在 [Console](https://console.anthropic.com/) 中用生产系统完全相同的提示词和工具构建模拟环境，然后逐步观察 Agent 的工作过程。

  这种做法很快暴露了失败模式，比如 Agent 明明已经拿到足够结果却仍然继续搜索、使用过度冗长的搜索查询、或者选择错误的工具。

  有效的提示词工程，依赖于你是否能够建立一个准确的“Agent 心智模型”。一旦真正理解 Agent 是如何行动的，最有影响力的修改往往会变得非常明显。

- **教会编排者如何委派任务。**  
  在我们的系统中，Lead Agent 会把用户查询拆成多个子任务，然后把这些任务描述给 Subagent。

  每一个 Subagent 都应该得到：
  - 明确的目标；
  - 指定的输出格式；
  - 应该使用哪些工具和来源的指导；
  - 清晰的任务边界。

  如果任务描述不够详细，不同 Agent 就会重复工作、遗漏关键部分，或者无法找到必要信息。

  我们一开始允许 Lead Agent 只给出类似“研究半导体短缺”这样的简短指令，但很快发现这种指令太模糊，Subagent 很容易误解任务，甚至与其他 Agent 做完全相同的搜索。

  例如，有一个 Subagent 在调查 2021 年汽车芯片危机，而另外两个 Agent 则重复调查 2025 年当前供应链，整个系统没有形成有效的分工。

- **让投入规模匹配查询复杂度。**  
  Agent 不太擅长判断不同任务究竟应该投入多少工作量，因此我们直接把资源扩展规则写进了提示词。

  例如：
  - 简单事实查询：1 个 Agent，调用工具 3–10 次；
  - 直接对比任务：2–4 个 Subagent，每个调用工具 10–15 次；
  - 复杂研究任务：可能使用 10 个以上 Subagent，并且需要明确划分职责。

  这些显式规则可以帮助 Lead Agent 更有效地分配资源，也避免在简单查询上过度投入。这是我们早期版本中非常常见的失败模式。

- **工具设计与工具选择至关重要。**  
  Agent 与工具之间的界面，就像人与计算机之间的界面一样重要。

  使用正确的工具不仅更加高效，在很多情况下甚至是完成任务的必要条件。

  例如，如果某段上下文只存在于 Slack，而 Agent 却一直用网页搜索寻找，那么从一开始就注定无法完成任务。

  当 [MCP Server](https://modelcontextprotocol.io/) 为模型提供越来越多外部工具之后，这个问题会更加严重，因为 Agent 可能遇到从未见过的工具，而这些工具的描述质量参差不齐。

  因此，我们给 Agent 提供了明确的启发式规则，例如：
  - 先检查所有可用工具；
  - 根据用户意图匹配工具；
  - 做大范围外部探索时使用网页搜索；
  - 专用工具优先于通用工具。

  糟糕的工具描述可能把 Agent 引向完全错误的方向，因此每个工具都应该有清晰且独立的用途，并配有明确描述。

- **让 Agent 改进自己。**  
  我们发现 Claude 4 系列模型本身就是非常优秀的提示词工程师。

  当把提示词和一个失败案例交给它时，它能够诊断 Agent 为什么失败，并提出改进方法。

  我们甚至创建了一个“工具测试 Agent”。给它一个存在问题的 MCP 工具之后，它会尝试使用这个工具，然后重写工具描述，以避免相同失败。

  通过对工具进行数十次测试，这个 Agent 找到了许多关键细节和 Bug。

  这种改善工具易用性的流程，使后续 Agent 使用新工具描述完成任务的时间降低了 40%，因为它们能够避免大多数常见错误。

- **先宽后窄。**  
  搜索策略应该模仿专家型人类研究者：先了解整体信息版图，再深入具体细节。

  Agent 往往会默认使用非常长、非常具体的查询，这种查询反而只能返回少量结果。

  我们通过提示词抵消这种倾向：要求 Agent 从简短、宽泛的查询开始，先判断有哪些信息可用，然后再逐渐缩小范围。

- **引导思考过程。**  
  [Extended Thinking](https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking) 模式会让 Claude 输出额外的思考 Token，因此可以被当作一种可控的草稿纸。

  Lead Agent 会使用思考过程来规划研究方法，例如：
  - 判断哪些工具适合当前任务；
  - 判断查询复杂度；
  - 决定应该创建多少 Subagent；
  - 定义每个 Subagent 的职责。

  我们的测试显示，Extended Thinking 可以改善指令遵循、推理效果和整体效率。

  Subagent 也会先做规划，然后在获得工具结果之后使用交错思考（interleaved thinking）评估结果质量、发现信息缺口，并改进下一轮查询。这使得 Subagent 能够更灵活地适应不同任务。

- **并行工具调用能够彻底改变速度和性能。**  
  复杂研究任务往往天然需要探索大量来源。

  我们早期的 Agent 会顺序执行搜索，速度非常慢。

  为了提高速度，我们加入了两层并行化：

  1. Lead Agent 会同时创建 3–5 个 Subagent，而不是逐个创建；
  2. 每个 Subagent 也会同时调用 3 个以上工具。

  对于复杂查询，这些变化最多可以把研究时间缩短 90%。

  因此，Research 可以在几分钟内完成原本需要数小时的工作，同时覆盖比其他系统更多的信息。

我们的提示词策略主要关注培养良好的启发式规则，而不是设置死板的规则。

我们研究了熟练的人类研究人员如何处理研究任务，并把这些策略写入提示词，例如：

- 把困难问题拆成更小的任务；
- 仔细评估来源质量；
- 根据新信息调整搜索方法；
- 判断什么时候应该追求深度，也就是深入调查一个主题；
- 判断什么时候应该追求广度，也就是并行探索多个主题。

与此同时，我们也通过明确的防护规则主动减少非预期副作用，防止 Agent 行为失控。

最后，我们非常重视快速迭代循环，并配合可观测性和测试用例持续改进系统。