Anthropic：How we built our multi-agent research system，2025 年 6 月 13 日。
一、适用场景与成本边界
开放式研究的路径很难预先确定。研究者需要根据中途发现不断调整问题、追踪新线索，固定的单次调用或线性流程难以完成这类任务。多 Agent 系统让一个主 Agent 负责规划与整合，由多个 Subagent 并行探索不同方向，再把各自发现压缩后交回主 Agent。
这种架构的收益有两个来源。第一，Subagent 拥有独立的上下文窗口，可以并行处理超出单个 Agent 容量的信息。第二，不同 Subagent 可以采用不同工具、Prompt 和探索路径，减少单一路径的依赖，使调查更全面。
Anthropic 的内部研究评测显示：以 Claude Opus 4 为主 Agent、Claude Sonnet 4 为 Subagent 的系统，相比单个 Claude Opus 4，表现高出 90.2%。例如，面对"找出 S&P 500 信息技术板块所有公司的董事会成员"这一任务，多 Agent 系统能拆分公司并行调查；单 Agent 的串行搜索则未能完成。
原文对 BrowseComp 结果的分析发现，token 用量、工具调用次数和模型选择共同解释了 95% 的表现差异；其中，token 用量单独解释了 80%。更强模型也会放大 token 的使用效率：从 Claude Sonnet 3.7 升级至 Sonnet 4 的收益，大于单纯把 Sonnet 3.7 的 token 预算翻倍。多 Agent 架构的核心价值，是为超出单 Agent 能力边界的任务增加并行推理容量。
代价同样明显：在 Anthropic 的数据中，一般 Agent 使用的 token 约为普通聊天交互的 4 倍 ，多 Agent 系统约为 15 倍。因此，该架构适用于价值足以覆盖成本、可以大量并行、涉及的信息超出单一上下文窗口，且需要使用多种复杂工具的任务。若所有 Agent 必须频繁共享同一上下文，或子任务之间存在大量依赖，多 Agent 未必合适。原文指出，多数编程任务的可并行部分少于研究任务，而当时的 LLM Agent 在实时协调与委派方面仍有限制。
二、Research 系统的架构
系统采用 Orchestrator--worker 模式：主 Agent（LeadResearcher）分析用户问题、制定策略、创建专门的 Subagent；Subagent 并行搜索、评估结果并返回发现；主 Agent 汇总后决定是否继续调查。
图：用户问题进入主 Agent，主 Agent 将不同研究方向交给专门的 Subagent 并行处理。
完整流程可分为六步：
- **规划并保存状态。**LeadResearcher 确定研究方案，将计划写入 Memory。这样，即使上下文超过 200,000 token 并发生截断，也能保留关键计划。
- **委派并行研究。**主 Agent 为不同 Subagent 指定独立任务；数量由问题决定，并不固定。每个 Subagent 通过搜索工具收集资料，并在工具返回后用 interleaved thinking 评估质量、识别缺口、调整下一步查询。
- **综合并决定是否继续。**主 Agent 汇总 Subagent 结果。证据不足时，可调整策略或创建新 Subagent；充分时，退出研究循环。
- **补充精确引用。**CitationAgent 根据研究报告和来源文档定位具体引文位置，为结论提供可核查出处。
- **返回报告。**用户收到带引用的最终结果。
这一流程与静态 RAG 有本质区别。传统 RAG 通常先检索与输入最相似的一组文本片段，再据此生成回答；这里的研究过程则由多步搜索构成，能够依据新发现持续调整检索方向，并分析结果后形成答案。
三、Prompt、委派与搜索策略
多 Agent 系统增加了协调复杂度。早期版本曾为简单问题创建 50 个 Subagent、不断寻找根本不存在的来源，或因过多进度更新互相干扰。Anthropic 主要通过 Prompt 和工具设计修正这些行为，形成以下实践。
1. 先观察真实执行轨迹，再调整 Prompt
团队用与生产系统相同的 Prompt 和工具构建模拟，在 Console 中逐步观察 Agent 行为。这样可以直接发现：已经获得足够结果却继续搜索、查询过长、选错工具等问题。Prompt 的改动应针对可观察的失败模式，而非仅凭对模型行为的想象。
2. 为委派任务写明目标、边界和交付格式
主 Agent 给 Subagent 的任务应包含目标、输出格式、建议使用的工具与来源，以及清晰的工作边界。仅用"研究半导体短缺"这样的笼统指令，会导致任务理解不一致、重复搜索或遗漏问题。原文举例：一个 Subagent 调查 2021 年汽车芯片危机，另两个却同时重复调查 2025 年供应链，分工未能有效覆盖研究范围。
3. 根据问题复杂度分配工作量
原文在 Prompt 中加入了明确的资源分配启发式：
| 任务类型 | 建议投入 |
|---|---|
| 简单事实查询 | 1 个 Agent，约 3～10 次工具调用 |
| 直接比较 | 2～4 个 Subagent，每个约 10～15 次工具调用 |
| 复杂研究 | 超过 10 个 Subagent，并明确分工 |
这些数字是该系统的经验规则，目的是防止简单问题被过度处理；它们不应被当作所有系统的固定配置。
4. 让搜索从宽到窄，并选择信息所在的工具
Agent 容易一开始就使用过长、过具体的查询，导致结果过少。更有效的策略是先用简短、宽泛的查询了解信息分布，再根据结果逐步缩小范围。工具选择同样决定成败：只存在于 Slack 的信息不可能通过网页搜索找到。接入 MCP 等外部工具后，Agent 面对的工具更多、描述质量参差不齐，因此每个工具都需要明确用途和边界。系统 Prompt 可提示 Agent 先检查可用工具，让工具与用户意图匹配：广泛的外部探索使用网页搜索，特定领域任务优先使用专用工具。
团队还构建了用于测试工具的 Agent：它尝试使用有缺陷的 MCP 工具，再根据失败修改工具描述。经过数十次测试，新描述让后续 Agent 的任务完成时间降低了 40%，主要因为它们避开了常见误用。
5. 引导规划，并在两个层面并行执行
主 Agent 用 extended thinking 规划工具选择、任务复杂度、Subagent 数量及分工。Subagent 也先规划，并在工具调用之后用 interleaved thinking 判断结果质量、发现缺口、修订查询。原文测试认为，这改善了遵循指令、推理和效率。
并行化发生在两个层面：主 Agent 同时启动约 3～5 个 Subagent；每个 Subagent 又可同时调用 3 个以上 工具。相较于最初的顺序搜索，复杂查询的研究时间最多缩短 90%，同时覆盖更多信息。
这些 Prompt 侧重传授研究启发式，而不是规定僵硬步骤：拆解复杂问题、判断来源质量、根据新证据调整搜索、在深入单一主题与并行探索多个主题之间切换。同时，需要设置防止无限扩张的边界，并通过可观察性与测试用例持续迭代。
四、如何评测多 Agent 研究
同一问题可能存在多条有效研究路径，因此评测不宜要求 Agent 严格遵循预设工具调用顺序。应重点判断结果是否正确、引用是否可靠，同时检查过程是否合理。
Anthropic 在早期使用约 20 个贴近真实使用的问题作为评测集。此阶段 Prompt 改动可能使成功率从 30% 升到 80%，少量测试即可观察明显差异；不必等到积累数百题才开始评测。
研究结果通常是自由文本，缺少唯一标准答案。团队使用 LLM judge，按 rubric 评估五个维度：
- 事实准确性：结论是否得到来源支持。
- 引用准确性：所引来源是否真的对应相应论断。
- 完整性：用户要求的方面是否全部覆盖。
- 来源质量：是否优先使用一手或权威资料，而不是低质量二手资料。
- 工具效率：是否选择合适工具，并控制调用次数。
团队试过让多个 judge 分别评分，但在其测试中，单次 LLM 调用、统一 Prompt、输出 0.0～1.0 分数与通过/失败判断，与人工评价的一致性最好，也更稳定。对于本身有明确答案的测试题，judge 可以直接核对结果是否正确。人工测试仍不可缺少：早期 Agent 曾倾向于选取搜索排名靠前的 SEO 内容农场，而忽略更权威的学术 PDF 或个人博客；人工观察发现这一偏差后，团队才在 Prompt 中加入来源质量规则。
多 Agent 系统还会出现交互带来的涌现行为：主 Agent 的微小改动可能意外改变 Subagent 的行为。因此，评测与调试都必须查看 Agent 之间的协作模式，而不能只检查单个 Agent 的输出。
对于会在多轮中修改持久状态的 Agent，更应以最终状态为主要评分依据，而不是逐轮核对固定动作。因为每一步都会改变后续环境，合法路径可能不止一条。复杂工作流可以设置少数离散检查点，验证关键状态变更是否已经发生。
五、生产可靠性与长期运行
状态、恢复与错误处理
Agent 可能跨越大量工具调用、持续运行很久；一次小故障也可能改变后续决策路径。简单地从头重启既昂贵，也损害用户体验。Anthropic 采用可从故障点恢复的执行机制，并结合重试、定期检查点等确定性保护。工具失败时，将情况反馈给 Agent，让模型调整策略，也能有效缓解部分问题。
长期会话可能跨数百轮，常规上下文窗口不足以保存全部历史。系统会在完成一个阶段后总结成果，将关键内容存入外部 Memory；接近上下文上限时，可创建拥有干净上下文的新 Subagent，通过明确交接继续工作，并从 Memory 取回原有研究计划。
可观察性与部署
相同 Prompt 也可能产生不同轨迹。用户反馈"没有找到明显信息"时，原因可能是查询不好、来源选择失当，或工具故障。完整的生产 trace 有助于系统性定位这些原因。原文称，团队还监控 Agent 决策模式和交互结构，同时避免监控个别对话内容，以维护用户隐私。
运行中的 Agent 可能处于流程的任意阶段，更新 Prompt、工具或执行逻辑时，不能假定所有实例会同时切换版本。团队采用 rainbow deployment：旧版与新版并行运行，逐步迁移流量，避免打断正在执行的 Agent。
同步协调的局限
当时的主 Agent 会同步等待一批 Subagent 全部完成，再继续执行。这简化了协调，却带来瓶颈：主 Agent 无法在过程中引导 Subagent；Subagent 无法互相协调；一个研究缓慢的 Subagent 就可能阻塞全局。异步执行能增加并行度、按需创建新 Subagent，但必须解决结果协调、状态一致性和错误传播问题。原文预期，随着任务变长、变复杂，异步化的收益将更值得其实现成本。
减少多级转述造成的信息损失
对代码、报告、数据可视化等复杂产物，Subagent 不必把全部内容经主 Agent 转述。更稳妥的方式是由 Subagent 直接写入持久化产物系统，再向主 Agent 返回轻量引用。这既降低大型结果在多阶段转述中的信息损失，也减少把完整内容复制进对话历史所消耗的 token。
六、结论与范围
多 Agent 研究系统适合开放、可并行、信息量大的高价值任务；其表现提升依赖清晰的任务分工、适当的资源预算、可靠的工具选择、结果导向的评测，以及状态管理、可观察性和渐进部署等工程能力。原型可用与生产可靠之间仍有显著距离，因为小故障可能改变整个 Agent 的后续轨迹。
原文所述的性能与成本数字来自 Anthropic 的内部系统和评测，应视为该架构的实证案例，而非对所有产品的通用保证。
原文还引用了 Clio 对 Research 使用方式的分析：最常见的类别包括特定领域软件系统开发（10%）、专业与技术内容的开发和优化（8%）、业务增长与营收策略（8%）、学术研究和教育材料（7%），以及人物、地点或机构的信息研究与核实（5%）。这些比例描述的是当时该产品的使用分布。