我们如何构建多 Agent 研究系统
发布日期： 2025年6月13日
作者： Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford
概述
Claude 的 Research 功能支持跨 Web、Google Workspace 和各类集成进行搜索，以处理复杂任务。本文详细介绍了构建这一多 Agent 系统过程中的工程挑战和经验教训。该系统使用多个 Claude Agent 协同工作——一个负责根据用户查询规划研究策略的编排器，然后生成多个并行 Agent 同时进行信息收集。
多 Agent 系统的优势
研究涉及开放式问题，所需步骤无法预先预测。这个过程本质上是动态的、路径依赖的，就像人类根据发现不断更新研究方法一样。
AI Agent 非常适合研究，因为这项工作需要在调查展开时灵活调整方向，并在多个回合中进行自主决策。线性流程无法胜任这种需求。
作者将搜索的本质定义为压缩——从海量语料库中提炼洞察。子 Agent 通过运行并行的 Context Window 来实现这一点，同时探索不同方面，然后将发现压缩给主 Agent。每个子 Agent 还通过使用不同的工具、提示词和探索路径来实现关注点分离。
他们类比了人类的集体智慧：虽然个体人类的智力在十万年间变化不大，但社会"因为集体智慧和协调能力，在信息时代变得指数级强大"。
内部评估显示，使用 Claude Opus 4 作为主 Agent、Claude Sonnet 4 作为子 Agent 的多 Agent 系统，在研究评估中"比单 Agent Claude Opus 4 的表现高出 90.2%"。在一个识别所有 IT 标普 500 公司董事会成员的任务中，多 Agent 系统通过任务分解成功完成，而单 Agent 则因缓慢的顺序搜索而失败。
三个因素解释了 BrowseComp 评估中 95% 的性能差异。仅 Token 使用量就占了 80% 的差异，工具调用次数和模型选择是另外两个因素。升级到 Claude Sonnet 4 带来的性能提升，比将 Claude Sonnet 3.7 的 Token 预算翻倍还要大。
权衡取舍： 多 Agent 架构会大量消耗 Token——大约是标准聊天的 15 倍。这些系统适合那些价值足以证明成本合理、可以大量并行化、信息量超出单个 Context Window、且涉及大量复杂工具的任务。例如，大多数编码任务涉及较少的可并行子任务，因此不太适合。
Research 架构概览
该系统采用编排器-工作者模式，由一个主 Agent 协调并委派给专门的并行子 Agent。
工作流程：
- 用户提交查询
- 主 Agent 分析查询，制定策略，生成子 Agent
- 子 Agent 充当智能过滤器，迭代使用搜索工具
- 子 Agent 将发现返回给主 Agent
- 主 Agent 综合结果，决定是否需要进一步研究
- 如果信息充足，发现会传递给 CitationAgent 进行来源归属
- 带引用的最终结果返回给用户
主 Agent 将计划保存到 Memory 中，因为超过 200,000 个 Token 的 Context Window 会被截断。子 Agent 独立执行网络搜索，使用交叉思维评估结果，并返回发现。这与使用静态检索的传统 RAG 方法不同——该系统能够动态适应新发现。
提示词工程与经验教训
早期的 Agent 表现出问题行为：为简单查询生成 50 个子 Agent、无休止地搜索不存在的来源、以及通过过多的更新互相干扰。提示词工程是改进的主要手段。
8 条提示词原则：
1. 像你的 Agent 一样思考。 团队使用 Console 构建了模拟环境，使用完全相同的系统提示词和工具，观察 Agent 逐步工作。这揭示了失败模式，例如 Agent 在结果已经足够时继续搜索，或使用过于冗长的查询。
2. 教会编排器如何委派。 每个子 Agent 需要一个目标、输出格式、工具/来源指导和清晰的任务边界。最初允许"研究半导体短缺"这样的简短指令，导致了误解和跨 Agent 的重复工作。
3. 根据查询复杂度调整工作量。 嵌入扩展规则：简单的事实查找需要约 1 个 Agent 进行 3-10 次工具调用；直接比较需要 2-4 个子 Agent，每个进行 10-15 次调用；复杂研究使用 10 个以上子 Agent，分工负责。这可以防止在简单查询上过度投入。
4. 工具设计和选择至关重要。 Agent 与工具的接口和人机接口一样重要。随着 MCP 服务器提供外部工具，Agent 会遇到质量参差不齐的工具描述。Agent 被赋予了明确的启发式规则：先检查所有工具，将工具使用与意图匹配，优先使用专用工具而非通用工具。
5. 让 Agent 自我改进。 Claude 4 模型可以作为出色的提示词工程师，诊断失败并提出改进建议。一个工具测试 Agent 在测试了数十次后重写了 MCP 工具描述，"使未来 Agent 的任务完成时间减少了 40%"。
6. 先广泛搜索，再逐步缩小范围。 搜索策略应模仿专家级人类研究——先探索全局，再深入细节。Agent 往往默认使用过长、过于具体的查询，返回的结果很少。
7. 引导思考过程。 扩展思维模式充当可控的草稿本。主 Agent 用它进行规划；子 Agent 在工具结果后使用交叉思维来评估质量和识别差距。
8. 并行工具调用改变速度和性能。 有两种并行化方式：主 Agent 并行启动 3-5 个子 Agent，子 Agent 并行使用 3 个以上工具。"这些变化将复杂查询的研究时间缩短了高达 90%。"
整体提示词策略侧重于灌输良好的启发式方法而非刚性规则，编码从熟练的人类研究人员身上观察到的策略——分解问题、评估来源质量、根据新信息调整方法，以及知道何时追求深度 vs. 广度。
Agent 的有效评估
多 Agent 系统每次执行的步骤不同，因此传统的评估方法不适用。团队需要灵活的方法来判断 Agent 是否通过合理的过程达到了正确结果。
立即用小样本开始评估。 早期变化往往会产生巨大影响。团队从大约 20 个代表真实使用模式的查询开始。即使少量测试用例也能清楚显示变化的影响。团队不应等待大型测试集才开始构建评估。
LLM-as-Judge 评估在做好时可以规模化。 研究输出是自由形式的文本，很少有单一正确答案。LLM 评审员根据评分标准评估：事实准确性、引用准确性、完整性、来源质量和工具效率。使用单次 LLM 调用，输出 0.0-1.0 分数和通过/未通过等级的提示词，被证明最一致且与人类判断一致。
人工评估能捕捉自动化遗漏的内容。 手动测试人员发现了评估遗漏的边缘情况——在不常见查询上产生幻觉答案、系统故障和来源选择偏差。例如，早期 Agent"持续选择 SEO 优化的内容农场，而非权威但排名较低的来源"。
多 Agent 系统具有涌现行为——对主 Agent 的微小改变可能不可预测地影响子 Agent 的行为。最好的提示词充当"协作框架，定义分工、问题解决方法和工作量预算"。
生产环境可靠性与工程挑战
Agent 是有状态的，错误会累积。 长时间运行的 Agent 在多次工具调用中保持状态。从头开始重启既昂贵又令人沮丧，因此团队构建了恢复系统。他们让 Agent 知道工具何时失败，以便 Agent 可以适应，同时结合确定性的保障措施，如重试逻辑和定期检查点。
调试需要新方法。 Agent 在不同运行之间是非确定性的。当用户报告 Agent"找不到明显的信息"时，需要完整的生产追踪来诊断根本原因——糟糕的查询、不良的来源选择或工具故障。他们监控 Agent 的决策模式和交互结构，同时通过不监控对话内容来保护用户隐私。
部署需要仔细协调。 Agent 系统是几乎持续运行的有状态网络。代码更改不能同时部署到所有 Agent。彩虹部署逐步将流量从旧版本转移到新版本，同时保持两个版本都在运行。
同步执行造成瓶颈。 目前主 Agent 同步执行子 Agent，等待完成后再继续。这简化了协调，但阻止了主 Agent 引导子 Agent 或子 Agent 之间进行协调。异步执行可以实现更多并行性，但在结果协调、状态一致性和错误传播方面增加了挑战。
结论
作者强调，对于 Agent 系统，"最后一英里往往成为旅程的大部分"。错误的复合性质意味着小问题可能完全破坏 Agent，"原型和生产之间的差距往往比预期的要大"。
尽管存在挑战，用户报告称发现了商业机会、导航医疗保健选项、解决技术 bug 并节省了数天的工作。成功需要精心的工程设计、全面的测试、注重细节的提示词和工具设计、稳健的运维实践以及紧密的跨团队协作。
一个 Clio 嵌入图显示了主要用例类别：跨专业领域开发软件系统（10%）、专业和技术内容（8%）、业务增长策略（8%）、学术研究（7%）以及验证关于人员/地点/组织的信息（5%）。
附录：额外建议
针对状态变更 Agent 的终态评估。 关注 Agent 是否达到了正确的最终状态，而不是评判每一步。将评估分解为离散的检查点，检查特定状态变更是否已发生。
长周期对话管理。 跨越数百个回合的对话需要智能压缩和记忆。Agent 在新任务之前总结已完成的工作阶段，并将必要信息存储在外部记忆中。当接近上下文限制时，可以生成具有干净上下文的新子 Agent，同时通过交接维护连续性。
子 Agent 输出到文件系统。 子 Agent 的直接输出可以通过工件系统绕过主协调器，Agent 将工作存储在外部系统中，并传回轻量级引用。这防止了多阶段处理中的信息丢失，减少了 Token 开销，特别适用于结构化输出，如代码、报告或数据可视化。
致谢
这项工作反映了 Anthropic 多个团队的集体努力。特别感谢 Anthropic 应用工程团队和早期用户的反馈。