原文：10-multi-agent-research-system.md 来源：https://www.anthropic.com/engineering/multi-agent-research-system
我们如何构建多 Agent 研究系统
发布于 2025 年 6 月 13 日
我们的 Research 功能用多个 Claude Agent 更高效地探索复杂主题。本文分享构建该系统的工程挑战和经验教训。
Claude 现在具备 Research 能力——可以跨 Web、Google Workspace 和任意集成完成复杂任务。
这个多 Agent 系统从原型到生产的旅程教会了我们关于系统架构、工具设计、提示词工程的关键经验。多 Agent 系统由多个协同工作的 Agent（在循环中自主使用工具的 LLM）构成。我们的 Research 功能涉及一个 Agent 基于用户查询规划研究流程，然后用工具创建并行 Agent 同时搜索信息。多 Agent 系统在 Agent 协调、评估和可靠性上引入新挑战。
多 Agent 系统的好处
研究工作涉及难以预先预测所需步骤的开放性问题。你无法为探索复杂主题硬编码固定路径——过程本质上是动态、路径依赖的。人在做研究时倾向基于发现持续更新方法，跟随调查中浮现的线索。
这种不可预测性使 AI Agent 特别适合研究任务。研究要求灵活性——随调查展开转向或探索切线连接。模型必须自治运行多轮，基于中间发现做关于追求哪些方向的决策。线性、单次管线无法处理这些任务。
搜索的本质是压缩：从大量语料中提炼洞察。Sub-agent 通过用各自上下文窗口并行运行促进压缩——同时探索问题的不同方面，再向主研究 Agent 凝练最重要的 token。每个 sub-agent 还提供关注点分离——独特的工具、提示、探索轨迹——降低路径依赖，启用彻底、独立的调查。
一旦智能达到阈值，多 Agent 系统就成为扩展性能的关键方式。例如尽管个体人类在过去 100,000 年变得更聪明，但人类社会在信息时代变得呈指数级更强大——因为我们的集体智能和协调能力。即使通用智能 Agent 作为个体也面临极限；Agent 群组可以完成更多。
我们的内部评估显示多 Agent 研究系统在广度优先查询上特别出色——涉及同时追求多个独立方向。我们发现以 Claude Opus 4 为主 Agent、Claude Sonnet 4 为 sub-agent 的多 Agent 系统在内部研究评估上比单 Agent Claude Opus 4 高出 90.2%。例如要求识别信息技术 S&P 500 公司所有董事会成员时，多 Agent 系统通过分解为 sub-agent 任务找到正确答案，而单 Agent 系统由于慢、顺序的搜索而失败。
多 Agent 系统主要因为它们帮助花足够 token 解决问题而 work。在 BrowseComp 评估的分析中，三个因素解释了 95% 的性能方差：token 使用本身解释 80% 方差，工具调用次数和模型选择是另两个解释因素。这验证了我们把工作分布到带独立上下文窗口的 Agent，为并行推理增加容量的架构。
不利的一面：这些架构快速燃烧 token。我们的数据中，Agent 通常使用聊天交互约 4 倍的 token，多 Agent 系统约 15 倍。经济可行性要求任务价值足够高以支付增加的性能。
不适合的领域：所有 Agent 需要共享同一上下文或 Agent 间有许多依赖的领域。例如大多数编码任务比研究真正可并行的更少，且 LLM Agent 还不擅长实时协调和委派。多 Agent 系统在涉及大量并行化、超出单上下文窗口的信息、与众多复杂工具交互的有价值任务上出色。
Research 架构概览
我们的 Research 系统使用编排者-工作者模式的多 Agent 架构——主 Agent 协调流程同时委派给并行运行的专门 sub-agent。
用户提交查询时，主 Agent 分析它、发展策略、生成 sub-agent 同时探索不同方面。sub-agent 作为智能过滤器——迭代用搜索工具收集信息（例如关于 2025 年 AI Agent 公司），然后把公司列表返给主 Agent 编译最终答案。
传统 RAG 用静态检索——抓取与输入查询最相似的某些块，用它们生成响应。我们的架构使用多步搜索——动态发现相关信息、适应新发现、分析结果 以制定高质量答案。
完整工作流：用户提交查询 → 系统创建 LeadResearcher → LeadResearcher 思考方法并把计划保存到 Memory（持久化以防上下文窗口超过 200,000 token 被截断）→ 创建带特定研究任务的 Sub-agent → 每个 Sub-agent 独立执行 Web 搜索、用 interleaved thinking 评估工具结果、把发现返给 LeadResearcher → LeadResearcher 综合结果决定是否需要更多研究 → 最后传给 CitationAgent 处理文档和研究报告以识别引用位置 → 带引用的最终结果返回用户。
研究 Agent 的提示词工程与评估
多 Agent 系统与单 Agent 的关键区别：协调复杂性快速增长。早期 Agent 犯错——为简单查询生成 50 个 sub-agent、无尽搜索不存在的源、用过多更新分散彼此注意力。因为每个 Agent 由提示控制，提示词工程是改善这些行为的主要杠杆。
8 条 Agent 提示原则
1. 像你的 Agent 一样思考：要在提示上迭代必须理解它们的效果。我们用 Console 中的精确提示和工具构建模拟，观察 Agent 一步步工作。这立即揭示失败模式：Agent 已有充足结果时继续工作、用过于冗长的搜索查询、选错工具。有效提示依赖发展 Agent 的准确心智模型。
2. 教编排者如何委派：主 Agent 把查询分解为子任务并描述给 sub-agent。每个 sub-agent 需要：目标、输出格式、工具和源的指引、清晰任务边界。没有详细任务描述，Agent 重复工作、留缝隙、找不到必要信息。我们最初让主 Agent 给简短指令如"研究半导体短缺"，但这些指令太模糊，sub-agent 误解任务或执行与其他 Agent 完全相同的搜索。
3. 让努力规模匹配查询复杂度：Agent 难以判断不同任务的合适努力，所以我们在提示中嵌入扩展规则——简单事实查找只需 1 个 Agent 加 3-10 次工具调用，直接对比可能需要 2-4 个 sub-agent 各 10-15 次调用，复杂研究可能用 10+ 个 sub-agent 加清晰职责划分。这些显式指南帮助主 Agent 高效分配资源，防止对简单查询的过度投资。
4. 工具设计和选择至关重要：Agent-工具接口与人机接口同等关键。用对工具高效——常常严格必要。例如在 Web 搜索仅在 Slack 中存在的上下文的 Agent 从一开始就注定失败。我们给 Agent 显式启发法：先检查所有可用工具、把工具使用匹配到用户意图、Web 搜索做广泛外部探索、相对通用工具优先选择专门工具。
5. 让 Agent 改善自己：Claude 4 模型可以是出色的提示词工程师。给一个提示和失败模式，它们能诊断为什么 Agent 失败并建议改进。我们甚至创建工具测试 Agent——给一个有缺陷的 MCP 工具，它尝试用工具然后重写工具描述以避免失败。通过测试工具数十次，这个 Agent 找到关键细微差别和 bug。这个改善工具人体工学的过程为未来用新描述的 Agent 带来 40% 的任务完成时间下降。
6. 先广后窄：搜索 策略应反映专家人类研究——先探索景观再钻入具体。Agent 常默认过长、具体的查询返回少量结果。我们提示 Agent 从短、广查询开始、评估可用内容、再逐步缩小焦点。
7. 引导思考过程：扩展思考模式作为可控草稿本。主 Agent 用思考规划方法、评估哪些工具适合任务、确定查询复杂度和 sub-agent 数量、定义每个 sub-agent 角色。测试显示扩展思考改善指令遵循、推理和效率。Sub-agent 也规划，工具结果后用 interleaved thinking 评估质量、识别缺口、精炼下一查询。
8. 并行工具调用变革速度和性能：复杂研究任务自然涉及探索许多源。我们早期 Agent 顺序搜索——痛苦地慢。两种并行化：(1) 主 Agent 并行而非串行启动 3-5 个 sub-agent；(2) sub-agent 并行用 3+ 个工具。这把复杂查询的研究时间削减最多 90%，让 Research 在分钟而非小时内完成更多工作。
我们的提示策略聚焦灌输好的启发法而非僵化规则。我们研究熟练人类如何处理研究任务，把这些策略编码进提示——分解难问题为更小任务、仔细评估源质量、基于新信息调整搜索方法、识别何时聚焦深度（详细调查一个主题）vs. 广度（并行探索多主题）。
Agent 的有效评估
多 Agent 系统的评估呈现独特挑战。传统评估常假设 AI 每次遵循相同步骤——给输入 X，系统应遵循路径 Y 产生输出 Z。但多 Agent 系统不这样。即使相同起点，Agent 可能采取完全不同的有效路径 达到目标。一个 Agent 可能搜 3 个源而另一个搜 10 个，或它们可能用不同工具找到相同答案。我们需要灵活的评估方法判断 Agent 是否在遵循合理过程的同时达到正确结果。
立即用小样本开始评估
早期 Agent 开发中，改动倾向有戏剧性影响——提示调整可能把成功率从 30% 提升到 80%。这种效应大小让你只需几个测试用例就能看到改动。我们从约 20 个代表真实使用模式的查询开始。许多 AI 开发者团队推迟创建评估，认为只有数百测试用例的大评估才有用——应该立即用几个示例小规模测试，而非延迟到能构建更彻底的评估。
LLM-as-judge 评估在做得好时可扩展
研究输出难以程序化评估——它们是自由形式文本，很少有单一正确答案。LLM 是评分输出的天然选择。我们用 LLM 评判员根据规则评估每个输出：事实准确性（声明匹配源吗？）、引用准确性（引用源匹配声明吗？）、完整性（覆盖所有要求方面吗？）、源质量（用初级源 vs. 低质量二级源？）、工具效率（用对工具合理次数吗？）。
实验多个评判员评估每个组件，但发现单个 LLM 调用、单个提示、输出 0.0-1.0 分数加 pass-fail 等级最一致、最契合人类判断。
人类评估捕捉自动化错过的
人测试 Agent 发现评估错过的边缘情况——异常查询的幻觉答案、系统失败、微妙的源选择偏差。我们案例中，人类测试者注意到我们早期 Agent 一致选择 SEO 优化的内容农场而非权威但排名较低的源（如学术 PDF 或个人博客）。在提示中加入源质量启发法帮助解决该问题。即使在自动化评估世界，手工测试仍必不可少。
生产可靠性与工程挑战
Agent 是有状态的，错误复合。Agent 可以长时间运行，跨许多工具调用维持状态。我们需要持久执行代码并处理路上的错误。没有有效缓解，小系统失败对 Agent 是灾难性的。错误时不能从头重启——重启昂贵且让用户沮丧。我们构建能从错误发生处恢复的系统。我们也用模型智能优雅处理问题：让 Agent 知道工具失败并适应工作得出奇地好。结合 AI Agent 的适应性与确定性保护（重试逻辑、定期检查点）。
调试受益于新方法。Agent 做动态决定，运行间非确定（即使提示相同）。这让调试更难。用户报告 Agent"找不到明显信息"，但我们看不到为什么。加完整生产追踪让我们诊断 Agent 失败原因并系统性修复。除了标准可观察性，我们监控 Agent 决策模式和交互结构（不监控对话内容以维护用户隐私）。
部署需要仔细协调。Agent 系统是高度有状态的提示、工具、执行逻辑网络，几乎持续运行。我们部署更新时 Agent 可能在流程的任何位置。不能同时把每个 Agent 更新到新版本。用彩虹部署避免打扰运行中的 Agent——通过逐步从旧版本转移流量到新版本，同时保持两者运行。
同步执行造成瓶颈。当前主 Agent 同步执行 sub-agent，等每组 sub-agent 完成才推进。这简化协调但创造 Agent 间信息流的瓶颈——主 Agent 不能引导 sub-agent，sub-agent 不能协调，整个系统可能等单个 sub-agent 完成搜索时阻塞。异步执行将启用额外并行性——但增加结果协调、状态一致性、跨 sub-agent 错误传播的挑战。
结论
构建 AI Agent 时，最后一英里常成为旅程的大部分。开发者机器上 work 的代码库需要大量工程才能成为可靠生产系统。Agent 系统中错误的复合性质意味着传统软件的小问题可能完全脱轨 Agent。一步失败可能导致 Agent 探索完全不同的轨迹，导致不可预测的结果。
尽管这些挑战，多 Agent 系统对开放研究任务证明有价值。用户说 Claude 帮他们发现没考虑的商业机会、导航复杂医疗选项、解决棘手技术 bug、通过揭示他们独自找不到的研究连接节 省最多数天的工作。
附录
多轮变更状态的 Agent 的最终状态评估：评估跨多轮对话修改持久状态的 Agent 呈现独特挑战。聚焦最终状态评估而非逐轮分析。不是判断 Agent 是否遵循特定过程，评估它是否达到正确最终状态。复杂工作流中，把评估分为离散检查点（特定状态变化应已发生），而非验证每个中间步骤。
长程对话管理：生产 Agent 常进行跨数百轮的对话。让 Agent 总结已完成工作阶段，把基本信息存到外部内存再继续新任务。接近上下文极限时，Agent 可以用干净上下文生成新 sub-agent，通过仔细交接维持连续性。
Sub-agent 输出到文件系统最小化"传话游戏"：直接 sub-agent 输出可绕过主协调员，提升保真度和性能。实施产物系统让专门 Agent 创建独立持久的输出。Sub-agent 调用工具把工作存到外部系统，传轻量引用回协调员。这防止多阶段处理中的信息损失，减少通过对话历史复制大输出的 token 开销。