译者按: 本文是 Anthropic (工程博客, 署名含 Jeremy Hadfield 等研究与工程团队成员) 于 2025-06-13 发表的《How we built our multi-agent research system》的中文校对翻译。原文出处: https://www.anthropic.com/engineering/multi-agent-research-system。读原文时深受启发, 特将全文译出与中文读者分享, 感谢原作者的点醒与提携。译文仅供学习交流, 版权归原作者所有, 如有出入以原文为准。
[!note] 版本说明 原文是 Anthropic 官方工程博客长文, 受版权保护。本文为编译精要版: 按原文结构完整转述全部要点与数据, 不是逐句全文翻译。
一、为什么用多智能体
Claude 的 Research 功能要处理开放式研究问题, 这类任务无法预先写死流程, 需要边搜边判断下一步。单个智能体的上下文窗口和串行搜索速度都是硬约束。
多智能体的解法: 让多个子智能体各自带着独立的上下文窗口并行探索, 再把压缩后的发现汇总。文中给出的核心数据: 以 Claude Opus 4 当主管、Claude Sonnet 4 当子智能体的多智能体系统, 在内部研究评估上比单智能体 Claude Opus 4 高出 90.2%。
对性能来源的分析更有信息量: 在 BrowseComp 评估中, 三个因素解释了 95% 的性能方差, 其中 token 用量单独解释 80%, 其余是工具调用次数和模型选择。换句话说, 多智能体的本质是一种花更多 token 换更好结果的架构。代价也直白: 普通聊天的约 15 倍 token 消耗 (单智能体任务约 4 倍)。
因此有明确的适用边界: 适合可高度并行、信息量超出单个上下文窗口、工具面复杂的重活; 不适合子任务强耦合、需要共享同一上下文的场景, 文中点名"大多数编码任务"目前不适合。
二、架构: 主管加工人 (orchestrator-worker)
流程: 用户提问 → LeadResearcher (主研究员) 用扩展思考制定策略并把计划存入外部记忆 → 派生多个子智能体并行搜索 (每个子智能体拿到明确的目标、输出格式、工具指引) → 子智能体用交错思考评估搜索结果、迭代收窄 → 主管汇总并决定是否追加轮次 → 最后由专职的 CitationAgent 核对每条论断的出处。
与传统 RAG 的静态检索不同, 这是动态多步搜索: 根据中间发现调整方向。上下文超过 20 万 token 时截断, 靠外部记忆保持计划连贯。
三、提示工程八条经验
- 像你的智能体那样思考: 在控制台里逐步回放智能体的行为, 观察失败模式, 再改提示。
- 教主管怎么分活: 任务描述必须含目标、输出格式、工具指引、边界。反例: 只说"研究半导体短缺", 结果三个子智能体做了重复调查。
- 投入与难度匹配: 简单事实查询 1 个智能体 3 到 10 次工具调用, 直接比较 2 到 4 个智能体, 复杂研究 10 个以上, 防止杀鸡用牛刀。
- 工具设计是生死攸关的事: 工具描述质量决定智能体表现; 他们让一个测试智能体反复试用工具并自动重写工具描述, 使后续任务完成时间下降 40%。
- 让智能体自我改进: Claude 4 能诊断自己失败的原因并给出提示修改建议。
- 先宽后窄: 先发短而宽的查询摸底, 再逐步聚焦, 模仿人类专家的检索习惯。
- 引导思考过程: 主管用扩展思考做规划, 子智能体在工具调用间用交错思考评估质量、找缺口。
- 并行工具调用: 主管并行派 3 到 5 个子智能体, 子智能体并行调 3 个以上工具, 复杂查询的研究时间最多缩短 90%。
总原则: 给策略性的启发式而不是死规则, 同时设护栏防失控。
四、怎么评估这种系统
- 多智能体系统是非确定性的: 同样的输入可以走完全不同但同样有效的路径, 所以评结果不评步骤。
- 别等攒够几百条用例才开始: 开发早期约 20 条代表性查询就能看出提示改动的效果 (他们经历过成功率从 30% 到 80% 的跳变)。
- LLM 当裁判: 用单次调用按事实准确性、引用准确性、完整性、来源质量、工具效率五个维度打分 (0 到 1 加通过/不通过), 可规模化。
- 人工测试不可省: 人类测试员发现了自动评估漏掉的问题, 例如系统偏爱 SEO 内容农场而不是权威来源, 靠往提示里加来源质量启发式修复。
五、生产工程的硬骨头
- 有状态与错误复利: 智能体长时间运行、步步依赖, 小错会滚雪球。解法是持久化执行、从出错点恢复而不是从头重跑、重试逻辑加定期检查点, 并让模型参与善后 (告知它工具挂了, 它会绕路)。
- 调试非确定系统: 加全链路生产级追踪, 看智能体的决策模式而非只看结果, 同时保持对用户对话内容的隐私边界。
- 部署: 智能体几乎随时都在跑, 不能停机升级, 用彩虹部署 (rainbow deployment) 让新旧版本并行、流量渐移。
- 当前瓶颈: 主管同步等待每批子智能体完成, 无法中途调整; 异步化能解锁更多性能, 但会引入状态一致性和错误传播的复杂度, 团队判断随着模型变强这笔账会越来越划算。
六、结语
文中的总结句 (转述): 最后一公里往往占了旅程的大半。原型到生产的距离在智能体系统上格外长, 复合错误、非确定性、有状态运行都是传统软件没有的坑。上线后的回报也真实: 用户用它发现了没想到的商业机会、理清复杂医疗选项、解决技术难题, 把几天的工作压缩到很短时间。
附录里还给出使用分布: 专业软件开发占 10%, 内容优化 8%, 商业增长策略 8%, 学术研究 7%, 人物与组织核查 5%。
一句话总结
这篇博客第一次把"多智能体系统在生产环境怎么活下来"的完整账本摊开: 性能提升 90.2% 的另一面是 15 倍 token 成本, 提示工程的另一面是评估与部署的脏活。它把多智能体从演示题材变成了工程学科。
原文出处: How we built our multi-agent research system 原作者: Anthropic (工程博客, 署名含 Jeremy Hadfield 等研究与工程团队成员) 原文发表: 2025-06-13
本文收录于「X深度阅读」栏目: 精选全球 X/Twitter 与博客上最值得精读的 AI 长文, 逐篇校对翻译成中文。