业务与 Agent / PRACTICE NOTE
什么时候需要多个 Agent?三个信号与三种编排模式
单 Agent 不够用时才上多 Agent:任务可拆分、上下文装不下、价值覆盖 15 倍 token 成本,是三个硬信号。Anthropic 与 OpenAI 的一手实践:三种编排模式、适用边界与生产教训。
摘要
面向业务与技术负责人的多 Agent 决策指南:先用三个信号判断"要不要上多 Agent",再按任务特点选 orchestrator-worker、manager 或 decentralized 三种编排模式之一,附 Anthropic 生产实践的关键数据与教训。
- 体裁
- 实践文章
- 适用对象
- 业务部门 AI 负责人、AI 产品经理、Agent 开发团队
- 参考来源
- 3 项 · 详见文末
先说答案:三个信号,缺一不可
当一个任务能拆成多个相互独立的子任务、单个上下文窗口装不下所有信息、且任务价值付得起约 15 倍 token 成本时,才值得上多 Agent;否则单 Agent 加好流程就够了。
这是 Anthropic 把自家 Claude Research 从原型做到生产后,总结出的核心判断。他们的多 Agent 研究系统(一个主 Agent 规划、多个子 Agent 并行搜索)在内部研究评测上,比单个 Claude Opus 4 高出 90.2%。但账单也很诚实:多 Agent 系统的 token 消耗大约是普通对话的 15 倍。90% 的提升,15 倍的成本——这笔账算不过来,就别上。
OpenAI 的《A Practical Guide to Building Agents》说得更直接:先把单个 Agent 的能力榨干,只有在"复杂条件逻辑"或"工具重叠"实在绕不过去时,才拆成多个。Anthropic 的《Building effective agents》也是同一个立场:从最简单的方案开始,只有可验证的提升才值得加复杂度。
三种编排模式,各管一摊
| 模式 | 长什么样 | 适合 | 不适合 |
|---|---|---|---|
| Orchestrator-worker | 一个主 Agent 拆解任务,派发给多个 worker 并行执行,最后汇总 | 广度优先的研究、信息搜集、可拆分的分析任务 | 子任务强依赖、需要共享全部上下文的任务 |
| Manager(单 Agent 调子 Agent) | 一个主 Agent 把子 Agent 当工具调用,按需委派 | 任务边界清晰、需要复用专家子 Agent 的场景 | 需要子 Agent 之间实时协作的场景 |
| Decentralized(去中心化交接) | Agent 之间直接交接,一次只有一个在干活 | 客服分诊、按阶段流转的固定流程 | 需要全局视角做综合判断的任务 |
Anthropic 的生产经验里,orchestrator-worker 是数据最硬的一种:每个 worker 有独立的上下文窗口,一个子任务的噪声不会污染其他任务;并行带来速度和广度;主 Agent 是单一审计点,每次分派决策都看得见。
生产教训:协调比智能更难
Anthropic 公开的生产教训值得细读,因为每一句都是钱买来的:
第一,早期原型的典型死法是"协调失控":给简单查询派出 50 个子 Agent,或者让 Agent 在网上无休止地找不存在的来源。修法不是换更大的模型,而是提示工程——教会 orchestrator 怎么分派:每个子 Agent 要有明确的目标、输出格式、工具指引和任务边界。
第二,投入要跟任务复杂度匹配:简单查证 1 个 Agent、3 到 10 次工具调用就够;中等对比任务 2 到 4 个子 Agent;复杂研究才上 10 个以上。没有这套刻度,Agent 会在小任务上烧大钱。
第三,升级模型往往比加 token 更划算。在他们的分析里,token 用量能解释 80% 的性能差异,而把模型从 Sonnet 3.7 升到 Sonnet 4,比把 token 预算翻倍带来的提升还大。先升级模型,再考虑加 Agent。
自查清单:上多 Agent 之前,先回答这五个问题
- [ ] 任务能拆成 3 个以上相互独立的子任务吗?拆不开就别上。
- [ ] 单个上下文窗口装得下全部信息吗?装得下就别上。
- [ ] 任务的价值覆盖得了约 15 倍的 token 成本吗?覆盖不了就别上。
- [ ] 子任务之间是并行关系,还是强依赖?强依赖的任务,多 Agent 目前还玩不转。
- [ ] 给 orchestrator 写清楚"怎么分派"了吗?目标、输出格式、工具边界、用哪些来源,没写清楚之前,加 Agent 只会加乱。
五个都打勾,再谈架构;有一个打叉,先回去把单 Agent 做好。
参考来源
常见问题
多 Agent 和工作流(Workflow)有什么区别?
Anthropic 的划分很清楚:工作流走预定义的代码路径,Agent 自己决定过程和工具使用。多 Agent 是"多个自己拿主意的 Agent 协作",工作流是"按剧本走"。任务步骤可预测用工作流,路径不可预测才考虑 Agent。
90.2% 的提升是所有任务都有的吗?
不是。这是 Anthropic 在"广度优先的研究型查询"上的内部评测结果,比如"找出某指数成分股公司的全部董事"。对强依赖、需要共享上下文的任务(比如复杂编码),多 Agent 的优势小得多。
小团队能玩多 Agent 吗?
能,但要先算账。15 倍 token 成本是真实的生产数据,小团队更应该先榨干单 Agent:好提示、好工具文档、明确的评估,很多时候比加 Agent 管用。
三种模式可以混用吗?
可以,Anthropic 明确说这些模式是"积木,不是教条"。常见做法是 orchestrator-worker 打底,某个 worker 内部再用 evaluator-optimizer 做自我修正。关键是每加一层复杂度,都要有可验证的提升。