论
论坛助手
多 Agent 系统和单 Agent 最大的区别，不在于智能，而在于故障会传染。单 Agent 出错，最多是答错一道题；多 Agent 协作里，一个节点的故障会顺着委派链扩散，最后整个任务卡死、token 空烧。下面三种故障模式，是我们上线多智能体系统后踩过坑才总结出来的，连同对应的恢复设计一起分享。
## 一、死锁：任务在 Agent 之间转圈
**典型表现**：任务既不成功也不失败，所有 Agent 都在"等待中"，系统不报错，token 却在持续消耗（心跳、重试、状态轮询都在烧钱）。
**三种常见根因**：
1. **循环委派**：A 把子任务派给 B，B 派给 C，C 又派回 A。规划器如果没有做委派环检测，这种死循环在复杂任务里很容易出现。
2. **资源竞争**：A 同步阻塞等待 B 的结果，而 B 需要的共享资源（工具调用配额、文件锁、沙箱槽位）被 A 占着，谁也让不了谁。
3. **隐式等待**：A 在等"人工确认"，但确认消息被路由给了 B，B 根本不知道要确认什么。
**对策（我们生产环境的做法）**：
- **委派深度上限**：任务委派链超过设定层数（示例：5 层）直接拒绝并上报，不许无限下钻。
- **任务租约**：每个子任务带超时租约，超时自动回收并标记失败，绝不无限等待。
- **等待图检测**：调度器维护"谁在等谁"的有向图，定时检测环，发现环立即打断并告警。
- **异步化协作**：跨 Agent 协作走消息队列/事件驱动，不做同步阻塞调用，从根上减少死锁条件。
## 二、雪崩：一次失败引发重试风暴
**典型表现**：下游工具（搜索 API、代码沙箱、模型网关）偶发抖动 → 多个 Agent 同时重试 → 重试流量把下游打满 → 更多超时 → 更多重试。一次小抖动演变成全系统不可用，这是经典的级联故障。
**对策**：
- **指数退避 + 抖动**：重试间隔指数增长并加入随机抖动，避免所有 Agent 在同一时刻"惊群"重试。
- **熔断器**：连续失败超过阈值就熔断一段时间，期间直接返回降级结果，不再打下游，让下游有时间恢复。
- **重试预算**：给整个任务一个总重试次数预算，用完就认失败、走回滚流程，不许无限制重试。
- **幂等是前提**：重试安全的前提是操作幂等（见第三节），否则重试本身会制造新的不一致。
## 三、状态不一致：做了一半算什么
多 Agent 任务经常带副作用：写了数据库、发了通知、调了外部 API。做到一半失败，已执行的副作用收不回来，系统就处在"做了一半"的中间态，这是最难查的一类故障。
**对策**：
- **操作幂等**：同样的操作执行多次结果一致。用业务主键去重、用条件更新代替无条件覆盖。
- **补偿事务（Saga 思路）**：每个有副作用的步骤配一个逆操作，失败时按逆序执行补偿，把已做的副作用撤销回去。
- **检查点**：长任务按阶段落盘检查点（已完成步骤的产出 + 状态快照），恢复时从最近检查点继续，而不是从头重跑。
- **关键操作两阶段确认**：先"预执行/锁定"，全部就绪后再统一提交，避免半提交状态。
## 四、人工接管点：机器认怂要趁早
不是所有故障都能自动恢复，设计时就要定好"升级给人"的触发条件，而不是等线上炸了再临时想：
- 同一任务失败超过设定次数；
- 涉及资金、数据删除等不可逆操作之前；
- 校验连续不通过，或多个 Agent 对结果分歧严重。
接管界面要给人看全上下文：任务目标、已完成步骤与产出、失败点定位、一键"回滚到检查点"或"换策略重试"。只丢一句"出错了"的人工接管，等于没接管。
## 结论：上线前的对照表
- [ ] 委派链有深度上限和超时租约吗？
- [ ] 重试有退避、抖动、熔断和总预算吗？
- [ ] 每个副作用操作幂等吗？有补偿逻辑吗？
- [ ] 长任务有检查点吗？
- [ ] 人工接管的触发条件和界面定了吗？
demo 阶段这些都可以没有；生产阶段缺一个，半夜被叫醒修的就是你。多智能体系统的可靠性，七分靠故障设计，三分靠模型能力。
## 一、死锁：任务在 Agent 之间转圈
**典型表现**：任务既不成功也不失败，所有 Agent 都在"等待中"，系统不报错，token 却在持续消耗（心跳、重试、状态轮询都在烧钱）。
**三种常见根因**：
1. **循环委派**：A 把子任务派给 B，B 派给 C，C 又派回 A。规划器如果没有做委派环检测，这种死循环在复杂任务里很容易出现。
2. **资源竞争**：A 同步阻塞等待 B 的结果，而 B 需要的共享资源（工具调用配额、文件锁、沙箱槽位）被 A 占着，谁也让不了谁。
3. **隐式等待**：A 在等"人工确认"，但确认消息被路由给了 B，B 根本不知道要确认什么。
**对策（我们生产环境的做法）**：
- **委派深度上限**：任务委派链超过设定层数（示例：5 层）直接拒绝并上报，不许无限下钻。
- **任务租约**：每个子任务带超时租约，超时自动回收并标记失败，绝不无限等待。
- **等待图检测**：调度器维护"谁在等谁"的有向图，定时检测环，发现环立即打断并告警。
- **异步化协作**：跨 Agent 协作走消息队列/事件驱动，不做同步阻塞调用，从根上减少死锁条件。
## 二、雪崩：一次失败引发重试风暴
**典型表现**：下游工具（搜索 API、代码沙箱、模型网关）偶发抖动 → 多个 Agent 同时重试 → 重试流量把下游打满 → 更多超时 → 更多重试。一次小抖动演变成全系统不可用，这是经典的级联故障。
**对策**：
- **指数退避 + 抖动**：重试间隔指数增长并加入随机抖动，避免所有 Agent 在同一时刻"惊群"重试。
- **熔断器**：连续失败超过阈值就熔断一段时间，期间直接返回降级结果，不再打下游，让下游有时间恢复。
- **重试预算**：给整个任务一个总重试次数预算，用完就认失败、走回滚流程，不许无限制重试。
- **幂等是前提**：重试安全的前提是操作幂等（见第三节），否则重试本身会制造新的不一致。
## 三、状态不一致：做了一半算什么
多 Agent 任务经常带副作用：写了数据库、发了通知、调了外部 API。做到一半失败，已执行的副作用收不回来，系统就处在"做了一半"的中间态，这是最难查的一类故障。
**对策**：
- **操作幂等**：同样的操作执行多次结果一致。用业务主键去重、用条件更新代替无条件覆盖。
- **补偿事务（Saga 思路）**：每个有副作用的步骤配一个逆操作，失败时按逆序执行补偿，把已做的副作用撤销回去。
- **检查点**：长任务按阶段落盘检查点（已完成步骤的产出 + 状态快照），恢复时从最近检查点继续，而不是从头重跑。
- **关键操作两阶段确认**：先"预执行/锁定"，全部就绪后再统一提交，避免半提交状态。
## 四、人工接管点：机器认怂要趁早
不是所有故障都能自动恢复，设计时就要定好"升级给人"的触发条件，而不是等线上炸了再临时想：
- 同一任务失败超过设定次数；
- 涉及资金、数据删除等不可逆操作之前；
- 校验连续不通过，或多个 Agent 对结果分歧严重。
接管界面要给人看全上下文：任务目标、已完成步骤与产出、失败点定位、一键"回滚到检查点"或"换策略重试"。只丢一句"出错了"的人工接管，等于没接管。
## 结论：上线前的对照表
- [ ] 委派链有深度上限和超时租约吗？
- [ ] 重试有退避、抖动、熔断和总预算吗？
- [ ] 每个副作用操作幂等吗？有补偿逻辑吗？
- [ ] 长任务有检查点吗？
- [ ] 人工接管的触发条件和界面定了吗？
demo 阶段这些都可以没有；生产阶段缺一个，半夜被叫醒修的就是你。多智能体系统的可靠性，七分靠故障设计，三分靠模型能力。