AI Agent 上线以后，很多团队很快会遇到一个尴尬问题：告警太多。工具超时也告警，知识库没命中也告警，用户问法奇怪也告警，最后值班的人开始麻木。真正危险的情况来了，反而没人第一时间处理。
所以异常分级不是运维术语，而是 Agent 能不能长期跑下去的基础。它应该和 运行证据包、可观测性、值班表 放在一起设计。
先区分失败和事故
一次任务失败，不一定就是事故。知识库没找到答案、外部工具临时超时、用户取消任务、模型要求补充信息，都可能只是普通失败。真正需要升级的，是失败已经影响用户、产生错误写入、暴露敏感数据、造成成本异常，或者反复发生但没有自动恢复。
分级时可以先问三个问题：有没有用户影响，有没有外部动作，有没有持续扩大。三个问题都是否定，通常不需要半夜叫人。
工具异常要看动作类型
读工具失败和写工具失败不是一个等级。读取知识库失败，可能只是回答不完整；写入 CRM、发送邮件、删除文件、提交工单失败，就可能影响业务承诺。更危险的是写入成功但 Agent 误判为失败，随后又重试一次。
这一步可以接上 连接器清单。每个工具都应该标明读写属性、风险等级和失败后的处理方式。
成本异常也要进入分级
很多 Agent 事故不是一次性报错，而是悄悄烧钱。长上下文反复重跑、搜索工具不断补查、定时任务循环失败，都会让成本在短时间内抬高。昨天写过 成本预算，异常分级里要把成本斜率放进去。
比如单次任务成本超过阈值，可以先降级模型或暂停重试；某类任务一天内成本突然翻倍，就应该进入人工复核。
升级规则要写清楚谁接
异常分级最后一定要落到人。P3 可以进入日报，P2 进入值班群，P1 需要负责人确认，P0 立即暂停相关流程并执行回滚。只写“通知相关人员”没有意义，真正出事时没人知道自己是不是相关人员。
这里可以复用 回滚预案 的写法：触发条件、第一响应人、决策人、通知对象和恢复标准都提前写好。
总结
AI Agent 异常分级的目标，不是把告警做得更多，而是让不同风险进入不同处理通道。任务失败、工具超时、权限拒绝、成本异常、外部写入和用户影响分清楚，团队才能少被无效告警打扰，也不漏掉真正的事故。
