在真实生产环境里，Agent 工具调用失败是常态而不是意外。接口超时、网络抖动、触发限流、模型把参数填错（缺必填字段、格式不对、生成坏掉的 JSON）、返回格式混乱，都会导致调用失败。因此，只会“重试”并不足以应对：网络波动类问题重试确实能恢复，但参数填错这类确定性错误，原样重试一百次仍然会失败。

正确做法是把每次工具调用包在一层保护逻辑里，遵循“调用失败 → 错误分类 → 路由到对应恢复动作”的思路，按错误类型差异化兜底，而不是不分类地盲目重试。

第一类是临时性错误，例如接口超时、网络抖动、被限流。应对方式是带退避的重试：重试间隔按 1 秒、2 秒、4 秒指数递增，避免高频重打压垮服务端，同时设置最大重试次数，防止无限循环。如果某个工具连续失败超过阈值，说明它可能已经不可用，应触发熔断，暂时停用并切换到备用方案，避免单个坏工具拖垮整条流程或烧穿预算。

第二类是确定性错误，例如参数错误、格式错误、缺字段、坏 JSON。这类错误重试原样请求没用，应让模型自我纠正：把具体报错信息作为反馈重新喂回模型，让它带着错误原因重新生成。多数格式错误在给一次带反馈的重试机会后就能改对。进一步可以把报错结构化，明确指出修改方向，形成“失败 → 反思 → 带教训重试”的自我修复循环。

第三类是严重错误，例如预算即将超支、涉及不可逆危险操作、反复恢复仍然失败。这类情况的原则是绝不让 Agent 自作主张。一个失控的 Agent 比一个停下来的 Agent 危险得多。发生严重异常时，Agent 应立即停止、冻结并保存当前状态与进度，把最终决策权交回给人。

整套错误恢复还必须配合完整的日志与可观测性：把每一步调用、失败和恢复动作都记录下来，保证出问题时全链路可追溯，也便于事后复盘。