降级预案：Agent 失灵时，业务怎么不停摆

核心观点

给 Agent 上线时，大家都按“它一直正常工作”来设计流程；可一旦它失灵、接口中断、返回结果明显离谱，整个业务就跟着停摆。降级预案就是提前写好退路：Agent 靠不住时，业务靠什么继续转、转到什么程度、由谁来拍板降级。

四步降级清单

• 先定触发条件：连续失败几次、耗时超过多久、结果明显越界，就触发降级；不要等到用户投诉才动手。
• 再定降级形态：能自动降级就自动降级——切到旧规则、切到人工队列、只读不写；降级后用户看到什么，必须事先写清。
• 留好人工接管口：降级不是关机，要有人能接管未完成的任务，并且知道任务停在了哪一步。
• 恢复也要有标准：指标回到什么水平才算恢复、谁有权宣布恢复、恢复后要不要补跑降级期间积压的任务。

一个反面案例

举个例子：某客服 Agent 依赖的外部接口半夜中断，系统没有降级预案，排队的用户问题既不转人工也不给提示，一直显示“正在处理”。第二天早上，积压的问题和投诉一起涌进来——而一句“系统繁忙，已转人工处理”本可以把损失挡在门外。

今日思考题

你的 Agent 今天如果突然失灵，你的业务第一步会做什么？如果答不上来，降级预案就是今天最该补的一页。