让 Agent 出错后，也能继续把事办完

开篇：Agent 不能只写成功路径

普通程序会失败，Agent 更会失败。

它要调用模型、工具、数据库、搜索服务、第三方 API。任何一环出错，整条链路都会受影响。

所以，真正能上线的 Agent，不是永远不出错，而是出错后能稳住。

能发现错误。能判断错误。能重试。能降级。能回滚。能告警。

这就是异常处理与恢复。

一、异常处理与恢复是什么

异常处理，解决的是“出错时怎么接住”。

恢复机制，解决的是“接住之后怎么回到稳定状态”。

两者合在一起，才是生产级 Agent 的底线。

模型输出不符合 JSON 格式，要能修复或重新生成。

工具调用超时，要能重试或切备用接口。

权限过期，要能提示重新授权，而不是继续失败。

写操作失败，要能回滚状态，避免数据污染。

连续失败，要能告警或转人工。

二、为什么 Agent 更需要异常处理

传统系统的流程通常比较固定。输入、处理、输出，边界清楚。

Agent 不一样。

它会自己决定下一步。它会调用不同工具。它会根据上下文调整路径。它的运行过程更像一条动态链路。

动态链路越长，失败点越多。

LLM 可能选错工具。

LLM 可能生成错误参数。

工具可能超时。

外部系统可能限流。

RAG 可能查不到资料。

状态可能在多轮任务里丢失。

如果只靠一句 Prompt 让模型“请稳一点”，没有用。可靠性必须靠工程设计。

三、核心流程：发现、分类、处理、恢复

异常处理不是简单 try-catch。

try-catch 只是接住错误。真正的关键，是接住之后做什么。

这条链路里，最重要的是“分类”。

不同错误，处理方式完全不同。

临时网络错误可以重试。业务规则错误不能重试。权限错误需要重新授权。严重写入错误必须回滚。

四、案例：退款查询 Agent

用户问：“我的退款到哪了？”

Agent 判断这是退款状态查询，于是调用 refund_api。

但退款接口超时了。

没有异常处理时，系统可能直接报错。用户只看到一句“服务异常”。

有异常处理时，流程应该这样走：

第一次调用超时，记录错误。

按短间隔重试，最多 2 次。

仍然失败，切换到订单快照或工单系统。

如果只能拿到部分信息，就明确告诉用户。

同时记录 trace_id，方便后续排查。

五、错误不能直接穿透

工程上，不要把所有异常都交给大模型自由发挥。

工具层、编排层、状态层都要有自己的边界。

一个比较稳的运行逻辑如下：

这里有几个关键点。

工具调用前要做参数校验，避免把明显错误打到下游。

工具调用时要设置 timeout，不能无限等待。

重试只用于临时错误，不用于业务错误。

涉及写操作，要先保存检查点。

最终失败时，要给用户一个安全、明确、可继续的结果。

六、什么时候该重试，什么时候不能重试

重试不是万能药。

错误用错策略，会把小问题放大成大事故。

可以重试

网络抖动。

临时超时。

服务返回 429 或 503。

工具偶发失败。

不该盲目重试

余额不足。

订单不存在。

权限不足。

参数明显错误。

写操作已经部分成功。

特别是写操作，必须考虑幂等。

比如发券、扣款、下单、发消息。重复调用一次，可能就是一次事故。

七、上线前检查清单

异常处理不应该等出事后再补。

只要 Agent 要连接真实系统，就应该在第一版设计里加进去。

八、总结

Agent 的可靠性，不来自一句万能 Prompt。

它来自明确的错误分类、清晰的恢复策略、可回滚的状态、可追踪的日志，以及必要时的人类接管。

能演示的 Agent，只要成功路径就够了。

能上线的 Agent，必须认真设计失败路径。

一句话总结：

真正成熟的 Agent，不是不犯错，而是犯错后不会把系统拖垮。