多 Agent 不是单一形态，而是几种完全不同的协作逻辑。
如果第 21 章讨论的是“什么时候值得上多 Agent”，那么这一章要讨论的就是：一旦真的进入多 Agent，究竟是在搭建哪一种组织。因为 Manager、Worker、Handoff、Debate 这些词看起来像“几个常见角色”，但它们真正的差异，不在角色名称，而在控制权、上下文所有权、决策收敛方式和责任结构完全不同。
所以，本章的第一条结论应该是：
多 Agent 模式的差别，不是用了几个角色，而是谁掌控流程、谁持有上下文、谁做最终裁决。只要从这个角度去看，这几种逻辑就会变得很清楚。
第一种，是 Manager-Worker。
这是一种典型的中心化协作结构。一个总控 Agent 持有全局目标、全局上下文和最终结果整合权；多个 Worker 接收明确、局部、有边界的子任务，把结果返回给 Manager。Worker 一般不直接面对用户，也不拥有最终控制权。它们更像专门化执行单元，而不是对外独立主体。
这种结构的优势很明显。
它保留了一个统一的控制中心，因此更容易维持全局一致性，也更容易施加统一的 guardrails、统一的工具权限和统一的最终审查。很多 subagent、agents-as-tools、supervisor-subagents 框架，本质上都属于这一类。它们的目标不是创造一群平等讨论的 Agent，而是让中心 Agent 以更低上下文负担调用多个专门执行者。
但它的代价也同样清楚。
Manager 很容易成为瓶颈。所有路由、记忆、合流和裁决，最后都要经过它；一旦 Worker 返回内容过长、数量过多，Manager 就会重新背上巨大的上下文和整合负担。于是，Manager-Worker 最大的风险不是“Worker 不够聪明”，而是中心过载。
所以，Manager-Worker 适合的，不是“所有复杂任务”，而是“任务可以清晰分解，且最终仍需一个中心统一判断”的场景。
第二种，是 Handoff。
Handoff 和 Manager-Worker 看起来都像“把任务给别人做”，但它们的逻辑完全不同。Manager-Worker 里，中心 Agent 从不真正失去控制权；Handoff 里，控制权会在某个节点被转移给下一个 Agent。也就是说，下游 Agent 不只是“帮忙做个子任务”，而是“从这一刻开始接管后续工作”。
这意味着 Handoff 更像接力，而不是外包。
它特别适合按照领域或阶段切分任务。例如从总入口 Agent 路由到医疗专家、法务专家、客服专家；或者从咨询阶段交给执行阶段，再交给审批阶段。这里的关键不是“让更多人参与”，而是“让最合适的那个主体真正接手后续局面”。
但 Handoff 的难点也恰恰在这里。
只要控制权发生转移，系统就必须回答：交过去的到底是什么？是全量历史、裁剪历史、结构化状态、局部摘要，还是某种组合？下游 Agent 到底继承哪些约束，能看到多少先前推理，拥有哪些工具权限，是否能继续转交，用户又如何知道自己现在在和谁交互？如果这些问题不清楚，Handoff 很快就会从“专家接管”变成“责任丢失”。
所以，Handoff 适合的不是“只要有不同角色就用”，而是“确实存在控制权该被转移的阶段性边界”。
第三种，是 Debate。
Debate 的逻辑又不同。它不强调单中心控制，也不强调会话接力，而是强调多个 Agent 在相同或相近问题上提出不同观点，再通过比较、反驳、投票、共识或裁决机制，收敛到某个结果。这里每个 Agent 的价值不在“分工完成子任务”，而在“提供独立视角、彼此纠错或暴露盲点”。
因此，Debate 的核心不是分工，而是分歧。
如果没有真实分歧空间，Debate 就没有意义。多个 Agent 只是把同一种思路说几遍，既不能增加鲁棒性，也不会增加信息量。很多团队最容易犯的错误，就是把 Debate 误当成“多找几个 Agent 来附和一下”。真正有效的 Debate，必须在信息、立场、路径或评判标准上具有某种独立性。
这也是为什么 Debate 常常比人们想象中更脆弱。
一旦多个 Agent 使用高度相似的 prompt、相似的知识、相似的偏见，它们很容易进入从众、迎合、伪共识和问题漂移。讨论轮次一多，还可能越来越偏离原问题。所以 Debate 最关键的不是“让他们多说几轮”，而是“如何设计裁决协议”。到底是多数投票、中心裁判、形成一致、还是让专门 judge 来决定，这些收敛机制会直接决定 Debate 是帮助系统纠错，还是把系统拖入更长的无效争论。
因此，Debate 适合的不是“所有想提高质量的场景”，而是“确实存在多视角信息增益，且有清晰收敛机制”的场景。
第四种，是流水线协作。
这类模式往往不那么显眼，但在生产里非常常见。它并不依赖多个 Agent 互相辩论或动态接管，而是让每个 Agent 负责一个固定加工环节，例如理解、规划、执行、审核、发布。每一站处理完后，把结构化产物传给下一站。它最像工业流水线，也最接近工作流系统。
流水线的优点，是结构清晰、可控、可测。
因为每个环节做什么、输入输出是什么、失败如何回退，通常都比较明确。它特别适合那些步骤相对稳定、合规要求高、需要固定审查链的场景。它的缺点则是灵活性较差，一旦中途需要改路、跳步或跨阶段回流，系统就会显得僵硬。
如果把这四种模式放在一起，就会发现它们分别对应四种完全不同的问题。
如果你要的是集中控制和统一汇总，就更像 Manager-Worker。
如果你要的是阶段性接管和领域切换，就更像 Handoff。
如果你要的是多视角纠错和论证性收敛，就更像 Debate。
如果你要的是稳定、固定、可审查的长链流程，就更像流水线。
也就是说，多 Agent 设计不是“角色越多越丰富”，而是“协作机制和任务依赖结构是否匹配”。
从经典组织理论看，这也完全说得通。层级组织擅长处理可委派、可汇总的问题；合同式委派擅长任务匹配与交接；blackboard 和共享工作面适合异步接力；argumentation 结构适合在没有单一真理入口时，通过论证机制逼近可接受结论。今天的 LLM 多 Agent 看起来新，但它们在组织逻辑上并不神秘。
所以，设计这几种模式时，真正要问的问题各不相同。
设计 Manager-Worker 时，要问：Manager 是否真的有必要保留全局控制？Worker 的结果返回格式是否足够短、足够结构化？Supervisor 会不会成为性能和上下文瓶颈？
设计 Handoff 时，要问：控制权转移的边界是否足够明确？哪些状态必须交接、哪些状态绝不能交接？用户是否知道自己当前处于哪个 agent 的责任范围内？
设计 Debate 时，要问：这些 Agent 之间是否真的有视角独立性？收敛协议是什么？什么时候停止？如何避免从众、漂移和空转？
设计流水线时，要问：环节之间的输入输出是否稳定？步骤顺序是否真的固定？一旦中途发现前面有错，是否允许回流修正？
这也解释了为什么很多框架会同时提供 manager、handoff、group chat、router、pipeline 等模式，而不是宣布“某一种才是最先进的多 Agent”。因为真正成熟的系统，不会把这些逻辑混成一个模糊的“协作”，而会根据任务结构选择最小足够的机制。
从工程角度看，最常见的误用有两种。
第一种，是本该用 Manager-Worker，却用了 Handoff。
结果就是：任务明明还需要中心统一综合，却把控制权早早交给了下游 Agent，导致用户体验断裂、责任不清、状态丢失。
第二种，是本该用流水线或 router，却用了 Debate。
结果就是：本来只是需要确定性分类、固定步骤加工或专家路由，却被做成多轮讨论，既增加了成本，也不带来真正的信息增益。
所以，这一章最终想建立的，不是“这四种模式分别是什么”这么浅的记忆点，而是一个更有用的判断框架：
Manager、Worker、Handoff、Debate 的区别，本质上是控制权如何分配、上下文如何流动、结果如何收敛。只要这三个问题想清楚，多 Agent 设计就不会停留在角色命名层，而会真正进入组织机制层。到那时，你看的就不再是“系统里有几个 Agent”，而是“这个系统到底是层级控制、接力切换、并行论证，还是固定流水线”。这才是理解多 Agent 协作逻辑的关键。