我们如何构建多智能体研究系统¶

原文发布于 2025 年 6 月 13 日，作者 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox 和 Daniel Ford

引言¶

Claude 的 Research 功能通过多个 Agent 协同工作来完成复杂的信息检索任务。 Claude 现已具备 Research 能力，可以跨 Web、Google Workspace 以及各种集成服务进行搜索来完成复杂任务。

本文回顾了这个多智能体系统从原型到生产的完整历程，分享了系统架构、工具设计和 Prompt 工程方面的经验。所谓多智能体系统，是指多个 Agent（在循环中自主使用工具的 LLM）协同工作的系统。Research 功能的运行方式是：一个 Agent 根据用户查询规划研究路径，然后创建多个并行 Agent 同时进行搜索。

为什么选择多智能体系统¶

研究是一类开放性问题——无法预先预测所需的步骤，特别适合 Agent 灵活探索。 研究任务涉及开放性问题，很难提前预测需要哪些步骤，也无法为探索复杂主题硬编码一条固定路径。AI Agent 非常适合这类场景，因为研究需要根据中间发现灵活调整方向。

搜索的本质是压缩——从海量语料中提炼洞察。子 Agent 通过并行工作促进了这种压缩：它们各自拥有独立的上下文窗口，同时探索不同方面，然后将最重要的信息浓缩给主 Agent。每个子 Agent 都实现了关注点分离——拥有各自的工具、Prompt 和探索路径。

性能对比¶

举例说明：当被要求识别 S&P 500 中 IT 公司的所有董事会成员时，多智能体系统通过分解任务成功完成，而单 Agent 则因为顺序搜索而失败。

影响性能的关键因素¶

在 BrowseComp 评估中，三个因素解释了 95% 的性能差异：

成本考量¶

Agent 通常消耗约 4 倍于普通对话的 Token，而多智能体系统消耗约 15 倍于对话的 Token。

多智能体系统需要任务价值足以证明其成本合理。最适合的场景包括：

• 需要大量并行处理的任务
• 信息量超出单个上下文窗口的任务
• 需要对接大量复杂工具的任务

Research 的系统架构¶

采用编排者-工作者模式：一个主 Agent 协调全局，多个子 Agent 并行执行具体搜索任务。

当用户提交查询时，主 Agent 分析请求、制定策略，然后派出子 Agent 同时探索不同方面。子 Agent 充当智能过滤器——反复使用搜索工具收集信息，然后将结果返回给主 Agent 进行汇总。

详细工作流程¶

1. 用户提交查询 → 系统创建 LeadResearcher Agent
2. LeadResearcher 思考研究方案，将计划保存到 Memory（因为超过 200K Token 的上下文会被截断）
3. 创建专门的子 Agent，分配具体研究任务
4. 每个子 Agent 独立进行搜索，使用交错思考（interleaved thinking）评估结果
5. 将发现返回给 LeadResearcher
6. LeadResearcher 综合结果，判断是否需要更多研究
7. 可以创建新的子 Agent 或调整策略
8. 收集足够信息后，将发现传给 CitationAgent
9. CitationAgent 处理文档和研究报告，识别引用位置
10. 带引用的最终结果返回给用户

Prompt 工程与评估¶

从早期 Agent 的各种失败中提炼出 8 条核心原则，逐步驯服了多智能体系统的混乱行为。 早期的 Agent 会犯各种错误：对简单查询派出 50 个子 Agent、无止境地搜索不存在的来源、子 Agent 之间发送过多状态更新互相干扰等。

原则 1：像你的 Agent 一样思考¶

通过模拟 Agent 的运行过程来发现故障模式。 在 Console 中用完全一致的 Prompt 和工具构建模拟，逐步观察 Agent 的行为。由此发现了多种失败模式：Agent 在已有足够结果时还在继续搜索、使用过于冗长的查询、或选择了错误的工具。

原则 2：教会编排者如何委派任务¶

每个子 Agent 需要明确的目标、输出格式、工具指引和任务边界。 缺少详细描述时，Agent 会重复工作或遗漏内容。早期版本使用简单指令如"研究半导体短缺"会导致误解和重复搜索。

有效的子 Agent 任务描述应包含：

原则 3：根据查询复杂度调整投入¶

在 Prompt 中嵌入分级规则，让系统自动匹配合适的资源投入。

原则 4：工具设计和选择至关重要¶

Agent 与工具的接口设计和人机接口一样关键。

Agent 需要明确的启发式规则：先检查所有可用工具，根据用户意图匹配工具使用方式，优先使用专用工具而非通用工具。

原则 5：让 Agent 自我改进¶

Claude 4 系列模型能够诊断 Prompt 缺陷并建议改进。 一个用于测试有缺陷 MCP 工具的 Agent 在反复尝试数十次后，"使未来 Agent 的任务完成时间减少了 40%"。

原则 6：先广后窄¶

引导 Agent 从短而宽泛的查询开始，评估信息可用性后再逐步缩小范围。 Agent 默认会使用过长、过具体的查询。需要在 Prompt 中明确引导它们先用简短宽泛的查询试探，评估可获取的信息后再聚焦。

原则 7：引导思维过程¶

扩展思考模式（Extended Thinking）是一个可控的"草稿纸"。 主 Agent 用思考来规划方案，子 Agent 在获取工具结果后用交错思考来评估质量和调整查询策略。

原则 8：并行工具调用是速度和性能的革命¶

两种并行化方式结合使用，将复杂查询的研究时间缩短了最多 90%。

如何有效评估 Agent¶

评估多智能体系统的核心挑战在于：Agent 可能通过完全不同但同样有效的路径达成目标。

立即开始评估，用小样本起步¶

从约 20 个代表真实使用模式的查询开始。早期开发中效果差异足够大，少量样本就能检测出来。

LLM-as-Judge 评估在做好时能很好地扩展¶

使用 LLM 裁判根据以下维度评分：

单次 LLM 调用输出 0.0-1.0 的分数和通过/失败判定，这种方式最稳定且与人类判断最一致。

人工评估能捕捉自动化遗漏的问题¶

人工测试者发现了一个有趣的现象：早期 Agent 会"一致地选择 SEO 优化的内容农场而非权威但排名较低的来源"，比如学术 PDF 或个人博客。

关于 Prompt 的认知转变¶

多智能体系统存在涌现行为——对主 Agent 的微小修改可能不可预测地影响子 Agent 的行为。最好的 Prompt 不是精确的指令集，而是"定义了分工、问题解决方法和资源预算的协作框架"。

生产环境的可靠性与工程挑战¶

从原型到生产的"最后一公里"往往变成了旅程的大部分。

Agent 是有状态的，错误会累积¶

Agent 在多次工具调用中长时间运行并维护状态。团队构建了能够从错误发生处恢复而非从头重启的系统。当被告知工具失败的具体信息时，模型的智能能够优雅地处理问题。

调试需要新方法¶

Agent 在不同运行之间是非确定性的。团队添加了完整的生产追踪能力，监控 Agent 的决策模式和交互结构，但出于隐私考虑不监控具体对话内容。

部署需要谨慎协调¶

使用彩虹部署（Rainbow Deployments）来避免中断正在运行的 Agent——新旧版本同时运行，流量逐步从旧版本切换到新版本。

同步执行产生瓶颈¶

当前主 Agent 同步执行子 Agent。这简化了协调但造成了瓶颈：

异步执行能实现更多并行性，但会增加协调和状态一致性方面的挑战。

用户价值与使用场景¶

用户反馈表明 Research 帮助他们发现商业机会、导航医疗选项、解决技术 Bug，并通过发现研究关联节省了数天工作。

主要使用场景分布：

附录：实践建议¶

面向最终状态的评估¶

对于多轮修改状态的 Agent，关注最终状态而非逐轮分析。 将评估分解为若干检查点，在每个检查点验证预期的状态变化是否已发生。

长对话上下文管理¶

生产 Agent 的对话可能跨越数百轮。解决方案：

• Agent 总结已完成阶段，将关键信息存入外部 Memory
• 当上下文接近限制时，生成带有干净上下文的新子 Agent
• 通过任务交接保持连续性，子 Agent 可从 Memory 中检索已存储的上下文

子 Agent 输出到文件系统，减少"传话游戏"¶

让子 Agent 直接将工作产出写入持久化存储，而非一切都通过主 Agent 传递。 子 Agent 将工作成果存入外部系统，只将轻量级引用返回给协调者。这样做可以：

• 防止信息在传递中丢失
• 减少 Token 开销
• 让专门的 Agent 独立创建持久化产出

总结¶

"最后一公里往往变成了旅程的大部分。"

在开发机器上运行的代码要成为可靠的生产系统，需要大量工程投入。原型与生产之间的鸿沟往往比预期更宽。多智能体系统的真正挑战不在于让它"能工作"，而在于让它"可靠地工作"。