AI agent 的失败不是单点问题，而是系统缺少失败语义。只要失败都写成 failed，平台就不知道该重试、追问、暂停还是转人工，最终会变成重试风暴和人工疲劳。
为什么 Failure Taxonomy 是运营指标，不只是开发细节
失败分类直接决定三个结果：
- 自动恢复率是否可提升
- 用户是否能得到可操作反馈
- 值班团队是否能快速定位责任边界
没有 taxonomy，所有 runbook 都会变成“先看看日志”。
一套够用的失败分层
| failureType | 典型信号 | owner | 默认动作 |
|---|---|---|---|
| input_gap | 缺字段、目标不完整 | 用户/业务 | ask_user |
| policy_block | 命中策略限制 | 平台治理 | stop |
| tool_runtime | 超时、429、连接断开 | 平台/基础设施 | retry_with_backoff |
| plan_quality | 计划偏题、遗漏关键步骤 | agent orchestration | replan |
| handoff_required | 高风险动作、证据不足 | 人工审核 | human_review |
| unknown | 无法归类 | 工程值班 | quarantine |
关键不是分得多细，而是每一类都绑定下一步动作和责任方。
失败动作映射比重试策略更重要
推荐先建立动作映射表，再做 retry 策略：
ask_user：必须输出缺失字段和问题模板retry_with_backoff：限制次数与预算，不允许无限重试replan：只允许在计划层重算，不直接重复工具调用human_review：提交证据包，而不是一句“请人工处理”quarantine：隔离异常 run，防止污染主队列
失败案例：把 policy_block 当作 tool_error
某团队把策略拦截误判为工具超时，导致 agent 连续 3 次重试同一高风险动作，触发更多告警。修复后，他们将策略拦截单独分类并直接 stop，告警量下降，人工值守压力显著降低。
上线 Checklist
- 每个失败类型有唯一代码和可读说明
- 每个失败类型都绑定 owner 与默认动作
- retry 只作用于可恢复类失败
-
unknown会自动入隔离队列并触发复盘 - 周报里有失败类型分布与趋势
结语
Failure taxonomy 的价值不在“分类很学术”，而在“把失败变成可执行动作”。只有失败可治理，agent 才能稳定放量。
延伸阅读：
