S21-J02 · 多 Agent：协作、路由与子代理

适用读者：想上"多 Agent"但说不清收益的人。
前置：S21-J01。
实测环境：Python token/时间估算（2026-11-05）。
覆盖旧文：717(313) 459(289) 467(202) + 13 卡 = 2,147 点。
覆盖扩展：E-S21-009（多 Agent 的必要性）。
上一篇：S21-J01 · Harness 工程：运行时、Loop 与沙箱
下一篇：S21-J03 · 工作流与可视化编排。

1. 一句话结论

多 Agent 不是"更先进"，是"用更多 token 换来并行与隔离"。只有当任务真的可拆并行、或需要不同上下文/权限时，它才划算。

实测估算（12 步任务，每步 1200 token，handoff 摘要 300 token）：

方案	token	墙钟（步）
单 Agent（串行 12 步）	14,400	12
多 Agent（3×4 步 + 2 次汇总）	17,400（+21%）	6（-50%）

结论：+21% token 换 -50% 时间——只有"时间真的值钱"或"任务可并行"时才成立。

2. 多 Agent 的三种理由（E-S21-009）

理由	例子
并行	三个子任务互不依赖
上下文隔离	各自处理长文档，避免互相挤爆上下文
权限隔离	一个只读、一个可写

反例（不该多 Agent）：

场景	为什么
任务强顺序依赖	并行无收益，只增加 handoff
总步数少（<5）	协调开销盖过收益
单一上下文足够	隔离没价值

3. 协作的三种拓扑

拓扑	结构	适合
主管-下属（Supervisor）	主 Agent 分派、汇总	最常见
流水线（Pipeline）	A→B→C	阶段清晰
黑板（Blackboard）	共享状态竞争	需要全局一致性

判据："谁负责最终对用户负责？" 有人负责 → Supervisor；没有 → 别做多 Agent。

4. 消息路由与子代理

问题	做法
消息给谁	按意图分类（S20-J04 的路由）
子代理怎么回	结构化返回（结果 + 引用），不要返回整段思考
失败怎么办	主代理决定重试/换代理/交人工

"handoff 摘要要给什么"：目标 + 已完成 + 未完成 + 关键约束——不要传全部对话历史（否则上下文爆炸）。

5. 五个误区

误区	真相
"多 Agent 一定更强"	+21% token 换时间
"Agent 越多越快"	协调开销与 handoff 成本
"可以传完整历史"	上下文会爆
"子代理不需要权限约束"	每个都要（J01）
"强顺序任务也能并行"	无收益

6. 自检

实测里多 Agent 的 token 与时间变化？
三种成立理由与三个反例？
三种拓扑怎么选？
handoff 摘要该包含什么？
谁该对最终结果负责？

7. 下一篇

S21-J03 · 工作流与可视化编排

多 Agent 讲完，下一篇讲"固定流程怎么编排"。

本篇属于系列《S21 · Agent 工程与 MCP》。旧文来源：A-717/459/467 + 13 卡；扩展点 E-S21-009。token 为估算（每步 1200、handoff 300）。