多 Agent 系统里，真正决定成败的，通常不是每个 Agent 内部有多聪明，而是三件事有没有被设计清楚：
- 状态怎么交接
- 边界怎么定义
- 最终控制权归谁
如果说第 22 章讨论的是协作模式，那么这一章讨论的就是协作模式落地之后最容易出故障的三个部位。因为在多 Agent 系统里，错误往往不是发生在“某个 agent 不够聪明”的地方，而是发生在“上一位已经做了什么、下一位到底接到了什么、最后又是谁真正拍板”的地方。
所以，本章第一条结论应该是：
多 Agent 系统的稳定性，首先取决于交接和裁决，而不是取决于单个角色的局部能力。一旦系统中存在多个主体，状态就不再只是“模型记没记住”，而变成“这份状态由谁持有、以什么格式持有、何时转交、转交后谁能继续修改”。如果这些问题含糊，系统看起来像在协作，实际上是在不断制造隐形断层。
先说状态交接。
很多团队在实现 handoff 时，最容易犯的错误是把交接理解成一句自然语言摘要，好像上一个 Agent 只要说一句“麻烦你继续处理”就够了。但真正稳定的交接，从来不是一段客气话，而是一份状态对象。它至少应该包含当前目标、已完成步骤、当前约束、关键证据、待解决问题、已知失败、剩余预算、以及权限边界。否则，下游 Agent 接到的只是“故事感”，不是“执行状态”。
这也是为什么成熟框架都会把 handoff、session、thread、checkpoint 这些对象显式化。因为真实系统已经意识到：交接的对象不应只是消息历史，而应是可恢复的运行状态。谁拿到了这个状态，谁就拿到了继续推进任务的权利；谁修改了这个状态，谁就改变了后续决策的基础。
所以，状态交接最关键的，不是“有没有传”，而是“传的是什么”。
是全量历史，还是裁剪后的历史？是摘要，还是结构化字段？是只传结论，还是把失败轨迹一起传过去？是把工具结果也交过去，还是只交高层状态？不同设计，对下游 Agent 的能力、成本和风险影响完全不同。
如果传得太少，下游 Agent 会失明。
它可能不知道哪些步骤已经做过，于是重复执行；不知道哪些方案已经被否决，于是绕回旧路；不知道哪些约束不能突破，于是做出越界判断。这样的问题表面上像“Agent 偶尔犯蠢”，本质上其实是状态交接不完整。
如果传得太多，下游 Agent 又会失焦。
它会拿到一大堆与当前职责无关的细节，承受更高 token 成本，更容易把不该继承的内容一并继承过去，例如无关的工具回执、过时的讨论、甚至不应跨角色传播的隐式指令和权限线索。这样的问题表面上像“上下文太长”，本质上其实是状态交接不加筛选。
因此，真正成熟的 handoff 设计，不是默认传全部，也不是默认只传一句摘要，而是显式定义：
- 哪些状态是必须继承的
- 哪些状态只能由当前角色消费
- 哪些内容必须在交接时被压缩
- 哪些内容绝不能跟着角色切换一起传播
只要这一步没有被显式化，Handoff 就会从协作机制退化成责任和上下文的随机漂流。
再说角色边界。
角色边界的本质，不是名字不同，而是职责不同。一个系统里可以有很多名字听起来很合理的 Agent，但如果它们的职责边界没有被写清楚，那么这些名字不会形成组织，只会形成重叠。
例如，路由 Agent 的职责是选路径，而不是给最终答案；规划 Agent 的职责是生成执行方案，而不是直接修改外部世界；审核 Agent 的职责是校验和阻断，而不是把前面的工作全部重做；worker 的职责是完成局部子任务，而不是越级做全局裁决。只要这些边界在实现里没有被强约束，系统就会不断出现角色漂移：本来只是负责路由的 agent 开始偷偷下判断，本来只是审核的 agent 开始重写主方案，本来只该执行的 worker 开始对外给最终承诺。
角色漂移一旦出现，多 Agent 的好处就会迅速消失。
因为分工最怕的不是能力不足，而是边界模糊。边界一模糊，系统就会产生两种常见退化。
第一种，是角色重叠。
多个 Agent 都在试图做相似的事，结果形成重复推理、重复检索、重复验证，系统成本上升而收益并未增加。
第二种，是角色缺位。
每个 Agent 都以为“最后会有别人负责”，结果真正需要负责的步骤没人做。例如没有人真正检查最终输出是否符合约束，没有人真正确认审批是否已经拿到，没有人真正对外部动作承担最终责任。
所以，角色边界如果只写在设计图上，而不写进运行时规则里，就等于没有边界。
这也是为什么成熟系统会把角色差异落实到更硬的结构上：不同 prompt、不同工具权限、不同可见上下文、不同输入输出 schema、不同审批要求、不同 tracing 标签。只有当角色差异被编码进系统对象里，边界才不是口号，而是约束。
最后说最终控制权。
这一步经常被忽略，但其实是多 Agent 系统最关键的锚点。因为不管前面有多少 manager、worker、handoff、debate、router，最终总要有一个地方回答四个问题：
- 最终答案由谁产出
- 最终动作由谁批准
- 最终责任由谁承担
- 多个 Agent 冲突时谁裁决
如果这个“最后一锤子”不存在，多 Agent 系统就很容易变成没有主心骨的松散对话。大家都参与了，但没有一个主体真正拥有最终裁决权；每个角色都提出了一点意见，但没有人真正对最终结果负责。
这也是为什么 Manager 模式和 Handoff 模式的差异在这一章会重新变得重要。Manager 模式下，中心 Agent 往往保留最终答案所有权；Worker 只是贡献局部结果。Handoff 模式下，最终答案所有权可能随着控制权一起转移给下游 Agent。两者没有谁天然更高级，但它们对应完全不同的责任链。系统如果在架构上没想清楚这一点，就会在出问题时发现，根本没人知道“到底该怪谁”。
对高风险动作来说，最终控制权还不能停留在 Agent 层。
很多官方系统卡和法规文件都在反复强调同一个事实：无论中间有多少轮 agent-to-agent 交接，影响现实世界的重要动作最终都应回到人类批准、人工监督或至少单一明确责任主体。用户确认、watch mode、人工接管、go/no-go 决策、stop 机制，这些设计看起来像“最后一步的麻烦”，实际上恰恰是在为整条多 Agent 链条补上最终责任出口。
也就是说，最终控制权不是礼貌性的“人类可以随时介入”，而是系统设计上必须预留的硬出口。
一旦没有这个出口，多 Agent 就很容易出现一种表面高效、实则危险的状态：每个局部步骤都看起来合理，每次 handoff 都显得顺滑，但整条链路最终在没有明确裁决者的情况下，把一个本不该自动完成的决定推到了外部世界。
因此，本章想建立的第二条结论是：
状态交接解决的是连续性问题，角色边界解决的是分工问题，最终控制权解决的是责任问题。这三者缺一不可。只有连续性而没有边界，系统会把错误流畅地传下去；只有边界而没有连续性，系统会在交接处不断失忆；只有前两者而没有最终控制权，系统会变成一条没有责任出口的自动化链。
从工程实现角度看，这也意味着多 Agent 系统不该只画角色图，还要明确三种对象。
第一种，是交接对象。
它定义传什么状态、如何传、是否可裁剪、是否保留历史、是否带权限元信息。
第二种，是职责对象。
它定义每个角色能做什么、不能做什么、能看到什么、何时必须回退或升级。
第三种，是裁决对象。
它定义谁拥有最终输出权、谁拥有最终执行权、谁拥有最终停止权，以及冲突时由谁拍板。
很多团队的问题，不是没有这些东西，而是把它们混在一起了。交接逻辑写在 prompt 里，角色边界藏在注释里，最终控制权只存在于人的想象里。这样一来，系统一旦扩展，必然出现边界滑动和责任扩散。
所以，第 23 章最终要建立的结论是：
多 Agent 系统真正的骨架，不是角色数量，而是交接对象、职责边界和最终控制权三者的明确组合。只有这三件事被显式设计出来，多 Agent 才会从“多个会说话的角色”变成“一个有连续性、有分工、也有责任出口的系统”。否则，Agent 越多，系统越像在互相传话，而不是在共同完成任务。