多 Agent 编排的失败模式：超时、环路、责任归属与补偿

失败的形态是结构性的

把一个任务拆给多个 Agent 之后，最常见的故障长这样：任务没有报错，也没有超时，就是一直没结束。或者：结束了，但中间某一步被人来回推了三次，最后一次谁都没做。

这类问题的共同点是——不是某个 Agent 变笨了，而是编排层的规则缺了东西。

单 Agent 的故障排查有一个天然锚点：所有决策都在一条 trace 上，责任主体是同一个。多 Agent 之后这个锚点没了：出错的边界落在"谁交给谁"这一步上，而这一步通常没有任何人负责。

下面四种失败模式，我认为是拆多 Agent 之后必然要面对的。

一、环路：谁都觉得该对方做

最典型的形态是来回踢：A 判断这属于 B 的职责，B 判断信息不足应该由 A 补充，A 又觉得 B 可以先做——两轮之后，任务卡在两个人中间。

根因有两个，都是设计缺省。

一是不存在"升级"这个概念。 编排规则里只有"交给谁"，没有"如果对方也不接，交给谁"。所以踢回来那一刻，系统只能再踢一次。

二是没有轮次账本。 没有地方记录"这件事已经被转手过几次"，也就无法在第二轮做出不同决策。

修法很直接：给任务加一个转手计数，超过阈值（比如 2 次）强制走"升级"分支——升级到人，或者升级到"由最初接收方负责收尾"。关键不是阈值定多少，而是这条分支必须存在。

二、超时叠加：总时长是乘积，不是加和

这是最容易被忽略的一种。

单 Agent 里，给一次模型调用设 30 秒超时、重试一次，最坏 60 秒。多 Agent 之后每一层各自设超时：A 等 B 60 秒，B 等 C 60 秒，C 等模型 30 秒还重试两次。

结果是：上层超时几乎永远不会触发，因为它总是大于下层的总和；而整条链的最坏耗时是各层超时的乘积量级，不是加和。用户那边表现为"偶尔有个请求要等十几分钟"。

正确做法是传 deadline，不传 timeout。

• timeout 是相对的：从现在起等 60 秒。它在每一层都会被重新计算，于是层数越多总时长越长。
• deadline 是绝对的：这个任务必须在 15:04:30 前返回。它不随层数变化，每层只做一件事——算出自己还剩多少时间，再决定还能不能重试。

这一条改动成本很低，却是多 Agent 里性价比最高的约束。它还顺带解决了另两个问题：重试预算和降级时机。

三、责任真空：出错时没人兜底

任务失败了，日志上能看出是哪个子任务挂的，但没有"谁来负责把它收尾"。

举个例子：三步流程，第二步的 Agent 判定"需要人工介入"就返回了。编排层收到这个信号之后做什么？规则里没写的话，常见结果是：编排层把它当成"已完成"，第三步照常执行——用着一个不完整的中间结果。

修法是在编排层引入任务所有者（owner）：每个子任务有一个唯一负责方，无论成功、失败还是"需要人工"，都由 owner 给出终态。owner 可以把活派出去，但不能把责任派出去。

这话听起来像管理术语，落到代码上很具体：子任务的返回类型必须包含明确的终态枚举，而不是"成功 / 抛异常"两种；编排层对未识别的终态必须报错，而不是当成成功。

四、补偿的牵连：撤销一个，动了三个

单 Agent 的补偿只涉及自己的步骤。多 Agent 之后，副作用之间会有关联。

典型场景：子任务 X 创建了一条记录，子任务 Y 基于这条记录发了通知。要回滚 X，就必须先撤回 Y 的通知——但 Y 并不知道 X 正在回滚。

所以副作用的登记要跨 Agent 做：谁创建了被依赖的对象、谁依赖了它，这两条关系要在编排层可见。补偿时按依赖逆序执行，而不是各自管各自的。

这里和状态持久化是同一件事的延伸：幂等键要跨 Agent 唯一。否则两个 Agent 各自生成的键互不识别，同一件事会被做两次，"去重"就失效了。

编排层的观测要求

上面四个问题能不能被及时发现，取决于 trace 里有没有记这几样东西：

• 转手计数：这次任务一共被转手几次、每次是谁给谁的
• deadline 与剩余时间：每个 span 带绝对截止时间和发起时的剩余量
• 终态枚举：子任务结束时的状态原样落库，不要归一化成"成功 / 失败"
• 副作用的依赖关系：哪个副作用依赖了哪个

少了任何一项，上面四种故障就只能靠人肉读日志猜。

一个反对意见

我不建议做"自由协商式"的多 Agent——让几个 Agent 自己讨论、自己决定谁来干。

它的问题不在效果，在可验证性：自由协商产生的执行路径无法预测，也就无法为它设计上面那四条约束（轮次账本、deadline 传播、owner、补偿顺序）。你会发现每次故障都是新形态，永远归纳不出规则。

更实用的结构是：固定流程 + 局部自主。整体流程写死在编排层（谁在什么条件下交给谁），只在单个节点内部保留 Agent 的自主性。这样路径可枚举，故障可归纳。

落地顺序

1. 先把 deadline 传播改了。改动最小，收益最大。
2. 加转手计数与升级分支。
3. 定义子任务的终态枚举，编排层拒绝处理未知终态。
4. 把 owner 落实到子任务的返回结构里。
5. 最后做跨 Agent 的副作用依赖登记与逆序补偿。

收尾

多 Agent 的价值在于分工，代价是故障会落在交界的缝里。上面四条约束做的是同一件事：把"缝"变成有规则的地方——谁负责、还剩多少时间、转了几手、撤销时牵连谁。

这些规则不写，多 Agent 就只是把单体的复杂度摊到更多进程上，而且更难查。

同系列：

• Agent 的状态与持久化：断点续跑、幂等与副作用补偿 https://cloud.tencent.com.cn/developer/article/2752149
• Agent 可观测性：Trace / Span 语义约定与任务回放 https://cloud.tencent.com.cn/developer/article/2757125
• 工具层治理：Schema 版本、权限边界与破坏性操作的闸门 https://cloud.tencent.com.cn/developer/article/2759896
• Agent 记忆架构：短期、长期、情景三层，以及向量加图的组合选型 https://cloud.tencent.com.cn/developer/article/2760648