Agent 失败了怎么办：重试、回滚、还是叫人
Demo 里的 Agent 永远成功：给它一个任务，它调几个工具，输出漂亮的结果。真实环境里，它有一半时间在做各种意料之外的事。
失败要先分类
我们把失败分成四类，处理方式完全不同：
一、工具调用失败（网络/超时/5xx）
这是最无害的。重试一次，带指数退避。重试还失败，换备用工具或降级。
二、参数错误（400 类）
工具报参数不合法。不要盲目重试——同样的参数重试还是错。应该把错误信息回给模型，让它修正后重新调用。我们限制最多修正两次，第三次就中断。
三、目标无法达成（数据不存在、权限不足）
这类失败不该重试，应该明确告诉用户"做不到，原因是 X"。含糊其辞最让人抓狂。
四、行为越界（调了不该调的工具、做了不该做的操作）
最危险的一类。必须立即中断，记录完整上下文，并且这次操作要能被回滚。
回滚怎么做
不是所有操作都能回滚。发出去的邮件收不回来，提交的订单也撤不掉。
所以我们的原则是：不可逆操作前置确认。Agent 可以准备内容，但真正执行"发送/提交/支付"之前，必须有人点一下。
如果非要自动化，加一个"冷静期"：操作先进入待执行队列，5 分钟内可以撤销，5 分钟后才真正执行。很多误操作是在冲动的那几秒发生的。
什么时候该叫人
判断标准是：这个错误如果发生 100 次，人工能处理得过来吗？
能，就转人工队列，把完整上下文一起带过去（模型想了什么、调了什么、拿到什么）。人工不需要重头问一遍用户。
不能，说明流程本身有问题，需要改设计，而不是加人工。
一个具体例子
我们有个 Agent 负责处理退款申请。最初的逻辑是全自动：判断符合规则就退。
上线一周出了两次问题：一次是同一笔订单重复退了两次（幂等没做），一次是把"咨询退款政策"的用户当成申请退款处理了。
改成三段式之后稳定了：
- 意图识别（只判断是不是真的要退款）
- 规则校验（代码判断，不靠模型）
- 金额超过阈值的人工确认，低于阈值的自动执行，但幂等键必须带订单号
模型负责理解，代码负责决策。 这条界线划清楚，大部分事故都能避免。