导读：How we built our multi-agent research system 未开始

题记与说明

收藏理由：Anthropic 官方复盘（2025-06）：Claude Research 背后 orchestrator-worker 多代理架构的设计、prompt 工程、评估与生产可靠性教训，该领域被引用最多的实战文章。

这篇讲什么

Anthropic 工程团队复盘 Claude Research 功能从原型到生产的全过程：为什么研究类任务天然适合多代理、orchestrator-worker 架构怎么搭、prompt 怎么写、评估怎么做、上生产后踩了哪些坑。核心流程是：LeadResearcher 先把研究计划写入 Memory（防止 200K 上下文被截断丢失计划）→ 按任务并行 spawn 子代理各自搜索 → 引用代理收尾保证每个论断可溯源。

核心观点

• 研究任务路径不可预知，线性 pipeline 搞不定；多代理的本质是压缩与并行：子代理各开各的上下文窗口探索，只把最重要的 token 带回主代理。
• 多代理不是免费的：token 消耗约为普通聊天的 15×（单代理也有 4×），只适合高价值、可重度并行、信息量超出单一上下文的任务；文中明确说编码任务并行度低，反而不适合。
• 好的 agent prompt 不是死规则，而是「协作框架」：定义分工、解题思路和努力预算。

最值得记住的金句/数据

1. 「Multi-agent systems work mainly because they help spend enough tokens to solve the problem」——token 用量单项就解释了 BrowseComp 评估中 80% 的性能差异（另两项是工具调用次数和模型选择）。
2. Opus 4 主控 + Sonnet 4 子代理的多代理系统，在内部研究评估上比单代理 Opus 4 高 90.2%；两类并行化（主控并行开 3-5 个子代理 + 子代理并行调 3+ 工具）把复杂查询的研究时间砍掉最多 90%。
3. 「The last mile often becomes most of the journey」——agent 系统里错误会复利式放大，一步走偏整条轨迹变形，所以要 checkpoint 恢复、rainbow 部署、全链路追踪（但不看对话内容以保隐私）。

对我的启发

• Agent 系统：八条 prompt 原则里最可迁移的两条——①把努力缩放规则直接写进 prompt（简单事实查证 1 代理 3-10 次工具调用；对比类 2-4 个子代理各 10-15 次；复杂研究 >10 个子代理），②让 Claude 自己当 prompt 工程师（工具测试代理重写糟糕的工具描述后，后续任务完成时间降 40%）。
• 个人知识管理：Appendix 那条「子代理把产出写到文件系统、只回传轻量引用，避免传声筒式失真」，正是知识库的正确姿势——存原件、传指针。
• AI 编程工具：本文解释了为什么 Claude Code / Codex 类编程工具走单代理+上下文工程路线而非多代理；其「先宽后窄」的搜索策略同样适用于代码库探索。
• 写作：「start wide, then narrow down」就是专家级资料收集法，选题和调研阶段同样适用。

适合谁读

在搭 agent / 自动化工作流的人（架构图和 prompt 原则可直接借鉴）、想搞懂 Deep Research 类产品内部机制的产品与研究者、需要为非确定性系统设计评估的工程师，以及关心上下文工程与知识管理的重度 AI 工具用户。原文为英文，附录三条实战技巧（终态评估、长程对话记忆管理、文件系统传递产出）信息密度最高，别跳过。