AI Agent 一旦进入真实业务，故障形态会比传统后端更复杂。
因为问题不一定出在某个单独服务上，而可能是下面几层同时出问题：
- 模型输出不稳定
- 工具接口超时或返回脏数据
- 状态机迁移异常
- 权限配置失效
- 重试策略把小故障放大成风暴
所以 Agent 的事故响应不能只靠“看日志”，而要有一套明确的止血顺序。
建议先看 AI Agent 可观测性与 Tracing 实战、AI Agent 状态机设计指南、AI Agent 安全与权限控制 和 AI Agent Session Replay 调试指南。
一、先分清事故类型，再决定怎么止血
| 事故类型 | 典型表现 | 第一优先动作 |
|---|---|---|
| 超时类 | p95 延迟飙升、任务卡住 | 降级并限制重试 |
| 幻觉类 | 输出看似完整但事实错误 | 收紧证据校验 |
| 越权类 | 调用了不该用的工具或数据 | 立即熔断高风险工具 |
| 风暴类 | 重试、并发、回放引发雪崩 | 先限流，再排查根因 |
很多团队在事故里最容易犯的错误，是一开始就追根因。真正正确的顺序通常是：
$$ 止血 > 限流 > 降级 > 回放 > 根因修复 $$
二、典型失败案例：一次工具超时演变成重试风暴
某个订单 Agent 在调用库存工具时出现间歇性超时。为了提升成功率，系统设置了三层重试：
- 工具 SDK 自动重试
- Agent 编排层重试
- 前端请求超时后又重新触发整个 run
结果本来只是 5% 的库存查询失败，最后演变成：
- 下游 API QPS 翻倍
- 平均延迟升高 4 倍
- 多个 run 进入 stuck 状态
事故真正的根因不是“库存接口慢”，而是重试预算没有统一管理。
三、事故发生时先做哪 5 件事
- 识别影响面：哪类任务、哪些用户、哪些工具受影响
- 关闭高风险写工具：先保护数据和资金安全
- 降低并发和重试：防止事故继续放大
- 切换降级路径：返回只读结果、草稿结果或人工接管
- 标记样本 run：为后续 replay 和根因分析保留证据
这 5 步做完，才适合开始追查提示词、schema、状态迁移或外部接口。
四、事故回放时重点看什么
建议优先按这条链路回放：
| 检查点 | 关键问题 |
|---|---|
| 用户输入 | 是否触发了异常边界条件 |
| Prompt/Policy | 是否把不该执行的动作放开了 |
| Tool selection | 模型为什么选这个工具 |
| Tool response | 返回是否不完整或冲突 |
| State transition | 系统是在哪一步进入错误状态 |
如果没有结构化 replay，事故复盘很快就会退化成“看聊天记录猜原因”。
五、值班团队至少要有这几个开关
disable_high_risk_toolslimit_parallel_branchesdisable_auto_retryforce_human_reviewfallback_to_read_only_mode
这些开关的意义，不在于优雅，而在于事故来的时候能立刻操作。
六、AI Agent 事故响应清单
- 有明确的事故分级和对应动作
- 高风险工具支持快速熔断
- 重试和并发可以在运行时限流
- 关键 run 支持 replay 和 trace 回放
- 值班文档写清楚降级和人工接管流程
