22｜多 Agent：什么时候用、用哪种模式

单个 agent 的工具系统完整了。但单个 agent 的上下文容量有限。复杂排查任务——跨多个系统、需要并行验证、涉及不同专业领域——单个 agent 容易被上下文塞满或能力不够。

这时候要多 agent 协作。但多 agent 不是银弹，用错了比单 agent 更糟。本篇讲两个判断：什么时候该上多 agent，上了用哪种模式。

先单后多

这是最重要的一条：大多数任务单 agent + 好工具就够，不要一上来就多 agent。

多 agent 的协调成本是真实的。每多一个 agent，就多一层通信、多一次结果合并、多一种失败可能。过早多 agent 是业界公认的反模式——多个来源都警告"premature complexity"，团队在单 agent 能搞定的时候就跳到多 agent 层级，结果协调开销超过收益。

什么时候才考虑多 agent？三个信号：

上下文塞不下。单个 agent 的上下文窗口装不下任务需要的全部材料。排查一个跨 5 个服务的故障，每个服务的日志、指标、Runbook 加起来超出窗口。这时把每个服务交给一个子 agent，各自在自己上下文里处理，父 agent 只收结论。

专业能力差异大。任务涉及差异很大的专业领域，一个 agent 的指令塞不下所有专业知识。数据库调优、网络抓包、容器诊断，每个领域一套知识体系，硬塞进一个 agent 的 system prompt 会互相干扰。

需要并行验证。同一个结论需要多个 agent 独立验证，降低单次推理偏差。根因分析时，让两个 agent 分别从日志和指标角度独立推断，结论一致才更可信。

没有这些信号，单 agent + 好工具永远更简单、更好调试、更便宜。

五种编排模式

确认要用多 agent 后，选哪种编排模式。业界主流的是五种，每种适合不同问题。

Orchestrator-Worker

一个编排者接收任务，拆成子任务，分派给专家 worker，汇总结果。worker 之间不通信，所有协调经过编排者。

         编排者
        /  |  \
    worker worker worker

适用：任务能干净拆分、需要单一责任点。客户服务路由到计费、技术、产品专家；运维排查路由到日志分析、指标分析、Runbook 检索。

失败点：goal drift——编排者经过多轮迭代后，计划偏离原始意图。回溯浪费算力，发现死路时整条分支的工作都白费。原始请求模糊时，编排者可能循环着试图建一个"完整"计划。编排者用强模型、worker 用便宜模型，能降成本。

Supervisor

中心协调者根据运行时状态动态路由任务给 worker。和 orchestrator-worker 接近，但更强调动态路由和监督。

适用：多领域复杂流程、需要可追溯性和质量保证。

失败点：过度中心化。supervisor 的 prompt 塞了 5 个以上职责时，一个 well-prompted 单 agent 往往更有效。supervisor 的同步路由强制串行执行，即使子任务逻辑上独立。协调开销超过拆分收益时，不如单 agent。

Swarm

去中心化接力。agent 之间通过 handoff 传递控制权，同一时刻只有一个 agent 活跃。

这里要纠正一个常见误解：swarm 不是并行执行。swarm 是"同时只有一个 agent 活跃"的接力控制转移，每个 agent 轮流行动。把它当并行执行用是错的。

适用：agent 独立、自包含上下文、路由逻辑嵌在任务本身里。

失败点：收敛难。没有编排者决定何时停，swarm 需要显式终止条件（最大迭代数、质量阈值、超时）。终止条件设太激进结果不完整，设太保守烧 token。

Mesh

点对点直连。agent 之间直接通信，不经过中心。

适用：agent 间需要直接协作、临时组队。

失败点：通信复杂度爆炸。N 个 agent 两两相连是 N² 条通信路径，调试极难。agent 多了之后 mesh 几乎不可维护，只适合少量 agent。

Pipeline

固定线性流程。每个步骤的输出是下一步的输入，顺序不变。

适用：流程可预测、每步依赖上一步。告警分诊 → 根因分析 → 报告生成这种固定链路。

失败点：不灵活。流程一旦要变（某步可跳过、某步要回退），pipeline 就不好使。

运维场景怎么选

ops-assistant 用哪种？看任务形状。

告警分诊到报告生成是固定链路，适合 pipeline：分诊 → 检索 → 分析 → 报告，每步依赖上一步，顺序不变。

跨服务根因分析需要并行查多个服务再汇总，适合 orchestrator-worker：编排者拆成"查 nginx 日志""查 redis 指标""查 mysql 慢查询"，worker 各自处理，编排者汇总根因。

开放式排查（用户说不清问题、需要多轮探索）适合 supervisor：动态决定下一步查什么，根据当前发现调整方向。

swarm 和 mesh 在运维场景用得少。swarm 的收敛难和 mesh 的通信爆炸，对需要确定性的运维排查是负担。

不是成员越多越快

不管选哪种模式，都有一个共同反模式：以为 agent 越多越快。

少量并行的 worker 比单个快，但继续加人不一定继续加速。任务拆解粒度、通信开销、结果合并复杂度都会随人数上升。Swarm 的最优规模取决于任务能否干净拆分，先用少量成员验证可拆分性，再决定是否扩规模，不要一上来就铺开。

这五种模式在现成框架里都有对应实现：CrewAI 的 role/process 是角色驱动的 pipeline 或 supervisor，AutoGen 的 group chat 是对话驱动的 swarm，LangGraph 的 supervisor 节点是动态路由。本系列讲清每种模式的适用边界和失败点，用框架时才知道选哪个、防什么（第 25 篇展开框架对应关系）。

选好模式之后

选定了编排模式，下一个问题是 agent 之间的控制权怎么传递、跨框架怎么协作。orchestrator-worker 里编排者调 worker，是"调一下拿结果"还是"把整个对话交出去"？不同机制影响很大。

下一篇讲协作机制：handoff、agents-as-tools，以及跨框架协作的 A2A 协议。