🏠 总目录 📚 资料库智能体构建模式

How We Built Our Multi-Agent Research System(我们如何构建多 Agent 研究系统)

📄 来自 Claude 官方博客
原文标题
How We Built Our Multi-Agent Research System(我们如何构建多 Agent 研究系统)
原文链接
https://www.anthropic.com/engineering/multi-agent-research-system
作者
Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox、Daniel Ford
发布日期
2025-06-13
⚠️ 本页是原文的中文结构化整理笔记(保留架构、数据、案例、结论),并非逐字翻译。具体参数与功能名更新很快,落地前请点击上方链接核对原文。

14 分钟 | 🔬 一个真实的主从编排案例

🎯 一句话

研究型任务用主从编排:主 Agent 拆解问题并派发,子 Agent 各自检索,主 Agent 汇总。⭐ 关键设计是子 Agent 只回传结论而不是原始资料——这才是它省上下文的地方。

📑 本页目录

Anthropic 为 Claude 的 Research 功能构建了生产级多 Agent 系统,性能显著超越单 Agent。经验表明:架构设计、提示词工程、系统性评估和稳健的运维实践缺一不可。

架构:编排器-工作者模式

  1. 主导 Agent(Opus 4)分析用户查询、制定研究策略、把研究计划存入记忆
  2. 多个专门化子 Agent(Sonnet 4)并行探索不同侧面,各自迭代搜索、用交错思考评估结果、识别缺口
  3. 子 Agent 把发现返回主导 Agent,由其综合并决定是否需要补充研究
  4. 引用 Agent 把论断映射到具体来源位置
  5. 带引用的最终结果返回用户

与静态检索的传统 RAG 不同,该系统做的是随中间发现动态演化的迭代搜索。

关键数据

适用与不适用场景

适合: 广度优先的并行探索、信息量超出单个上下文窗口、重度并行化领域、复杂工具接口、信息压缩类任务 不适合: 大多数编码任务(可并行成分少)、需要所有 Agent 共享上下文的领域、Agent 间强依赖的场景

八条提示词工程经验

  1. 像你的 Agent 一样思考: 在 Console 里用完全相同的提示词和工具做模拟,逐步观察失败模式
  2. 教主导 Agent 委派: 每个子任务要有明确目标、输出格式、工具指引、任务边界——含糊的指令导致子 Agent 重复劳动
  3. 按复杂度分配投入: 显式规则——简单事实查找 1 个 Agent、3-10 次工具调用;直接对比 2-4 个子 Agent、各 10-15 次调用;复杂研究 10+ 个子 Agent 各有分工
  4. 工具设计至关重要: 「工具-Agent 接口和人机接口一样关键」;先查看所有可用工具、匹配用户意图、宽泛探索用 web search、优先专用工具
  5. 让 Agent 自我改进: Claude 4 能诊断失败模式并改写工具描述——「工具测试 Agent」让后续任务完成时间下降 40%
  6. 先宽后窄的搜索策略: 模仿专家:先宽泛查询评估信息面,再逐步收窄
  7. 用扩展思考引导: 扩展思考让规划可见可控;交错思考让子 Agent 在搜索后评估质量、识别缺口
  8. 并行工具调用: 主导 Agent 同时启动 3-5 个子 Agent、子 Agent 同时用 3+ 工具——复杂查询的研究时间减少最多 90%

评估方法

生产环境的挑战与对策

附录实用洞察

结论

「最后一公里往往是大部分旅程」——原型到生产之间隔着大量工程。Agent 错误会复利,传统软件里的小问题足以让 Agent 走向完全不同的轨迹。成功需要细致的工程、全面测试、精雕细琢的提示词与工具、稳健的运维,以及研究/产品/工程团队的紧密协作。


✅ 检查点

  1. 研究任务为什么适合多 Agent?
  2. 子 Agent 该回传什么?为什么?
  3. 这类系统的主要成本和风险是什么?
👀 答案
  1. 因为研究任务天然可以按「子问题」并行拆分,而且检索过程会产生大量中间资料——如果都进主上下文会迅速撑爆。⭐ 拆开之后,每个子 Agent 在自己的上下文里翻资料,主上下文保持干净。
  2. 只回传结论和关键引用,不回传原始资料。因为省上下文正是多 Agent 在这里的核心价值——如果子 Agent 把搜到的网页全文都传回来,那还不如单 Agent 直接搜。回传内容应该是:结论 + 支撑证据的简短摘录 + 来源链接。
  3. ⚠️ 成本是 token 消耗成倍增长(每个子 Agent 都有自己的系统提示和工具定义);风险是子 Agent 之间看不到彼此的发现,可能重复劳动或得出互相矛盾的结论,而主 Agent 未必能察觉矛盾。⭐ 缓解:让主 Agent 在汇总时显式检查冲突,并对关键结论要求交叉验证。

🛑 可以停在这里

走神救援
研究任务用主从编排:主 Agent 拆解派发、子 Agent 各自检索、主 Agent 汇总。适合的原因:研究天然可按子问题并行,且检索会产生大量中间资料,都进主上下文会迅速撑爆。⭐⭐关键设计:子 Agent 只回传结论和关键引用,不回传原始资料——省上下文正是多 Agent 在这里的核心价值,如果把搜到的网页全文都传回来,那还不如单 Agent 直接搜;回传内容应是:结论 + 支撑证据的简短摘录 + 来源链接。⚠️成本是 token 成倍增长(每个子 Agent 都有自己的系统提示和工具定义);风险是子 Agent 看不到彼此的发现,可能重复劳动或得出矛盾结论,缓解是让主 Agent 汇总时显式检查冲突、关键结论要求交叉验证