https://www.anthropic.com/engineering/multi-agent-research-system read and summarize

回复 群友 607： 这是 Anthropic 2025 年 6 月 13 日的工程博客，讲他们 Research 功能背后的 multi-agent 系统怎么从原型做到上生产。核心是 orchestrator-worker 模式，也就是主 Agent 派活、子 Agent 并行干活。 一、为什么用多 Agent 研究类问题没法预先写死路径，必须边查边改方向，所以适合让 Agent 自主跑多轮。子 Agent 的价值在于各自独立上下文窗口并行探索，再把最关键的 token 压缩后交回主 Agent，同时天然做了关注点分离（不同工具、prompt、探索轨迹），减少路径依赖。他们内部评测里，Opus 4 当主 + Sonnet 4 当子，比单 Agent Opus 4 高 90.2%。性能差异里 token 用量单独解释了 80% 的方差，也就是多 Agent 本质是"把 token 花出去"的一种扩容方式。代价是：Agent 一般比普通对话多花 4 倍 token，多 Agent 系统约 15 倍；而且所有 Agent 必须共享同一上下文、或者彼此依赖很重的任务不适合，比如大多数编码任务。适合的是可高度并行、信息量超过单窗口、要对接大量复杂工具的场景。 二、架构 用户提问后主 Agent（LeadResearcher）先想策略，把计划写进 Memory——因为超过 20 万 token 上下文会被截断，计划必须持久化。然后派生若干子 Agent，各自搜索、用 interleaved thinking 边看结果边调整，把发现回传。主 Agent 汇总后判断够不够，不够就再派或改策略。信息够了交给 CitationAgent，定位每条结论的出处，最后带引用返回用户。它跟传统 RAG 的区别是：RAG 是静态召回一次性生成，这里是多步动态搜索。 三、提示词八条 一是像 Agent 一样思考，用 Console 复现线上 prompt 和工具，逐步看它干活，失败模式一眼就出来（已经有结果还接着查、query 太啰嗦、工具选错）。二是教会主 Agent 怎么派活：每个子任务要有目标、输出格式、可用工具和来源、清晰边界，早期就是只给一句"研究半导体短缺"，结果三个子 Agent 里一个查 2021 汽车芯片、两个重复查 2025 供应链。三是按查询复杂度给资源，简单事实 1 个 Agent 3 到 10 次调用，对比类 2 到 4 个子 Agent 各 10 到 15 次，复杂研究 10 个以上子 Agent，早期常见毛病是对简单问题过度投入。四是工具设计是关键，工具描述写得烂会让 Agent 跑偏，他们还做了个 tool-testing agent 反复试错重写工具描述，后续任务完成时间降了 40%。五是让 Agent 自己改进 prompt，Claude 4 干这个很行。六是先宽后窄，先短查询探路再逐步收窄。七是用 extended thinking 当可控草稿纸，主 Agent 用它做规划，子 Agent 在拿到工具结果后用它评估质量、找缺口。八是并行工具调用，主 Agent 并行起 3 到 5 个子 Agent、子 Agent 并行用 3 个以上工具，复杂查询研究时间最多降 90%。 四、评估 他们的观点是别等大 eval，先拿 20 条贴近真实使用的 query 就开始测，早期改动效果大，几条用例就看得出来。输出是自由文本、没有唯一答案，所以用 LLM-as-judge，一条 prompt 打 0 到 1 分加 pass/fail，维度是事实准确性、引用准确性、完整性、来源质量、工具效率。多 judge 反而没单 judge 稳。但人工测试不可省：人发现了 Agent 偏好 SEO 内容农场而不是学术 PDF 和个人博客这种隐性偏见。 五、生产上的坑 Agent 是有状态的、错误会累积，所以不能一出错就从头跑，要能断点续跑加确定性重试和 checkpoint。调试要靠全链路 tracing，加上监控决策模式和交互结构（不看对话内容）。发版要 rainbow deployment 灰度切流，因为 Agent 可能正卡在流程中间。最后一个已知瓶颈：目前主 Agent 是同步等所有子 Agent 跑完，主 Agent 不能中途纠偏、子 Agent 之间也不能协同，一个慢的全卡住；异步能提性能但结果汇总、状态一致性和错误传播会难很多。 他们的结论那句挺有名：Agent 开发的"最后一公里"往往就是整段旅程。 顺带说一句，这篇跟群里前阵子聊的 harness 是一条线：多 Agent 那边讨论的"派活描述、工具描述、effort 预算、状态持久化、可观测性"，本质都是 harness 要解决的问题，也是为什么现在通用补丁会被模型吸收、而 harness 得往组织上下文那层走。