探讨工具链调用失败的最佳回退策略

工具链调用失败时，我最怕的不是“这次没做成”，而是模型明明已经拿到错误结果，却还继续往下编。一次网络超时，最后可能变成一份看似完整、实际没有依据的报告；一个非 JSON 返回，也可能让后续步骤把错误内容当成正常数据继续处理。对我来说，好的回退策略不是“多试几次”，而是让系统知道什么时候重试、什么时候降级、什么时候停下来求助。

先判断失败，再决定动作

我会先把失败分成三类：暂时性失败、输入或格式失败、任务本身无法继续。网络超时、服务短暂不可用，更适合有限重试；返回内容格式错误，则应先校验并要求工具重新返回，不能直接把异常文本传给下一步；如果权限不足、关键文件不存在，继续重试通常只是浪费时间，这时应该立即转入人工处理或明确报错。

重试也不能无脑循环。每次重试前，模型需要记录上一次失败原因，并判断是否改变了条件。比如缩小请求范围、拆分任务、改用纯文本输入，才算真正的回退；只是重复发送同一个请求，往往只会增加耗时和成本。涉及写文件、执行操作这类可能产生副作用的工具，还要避免重试造成重复执行。

回退要有清晰的层级

我更倾向于设计一条逐级收缩的路径：先重试原操作，再简化任务；如果图像解析失败，就退回 OCR 结果或纯文本描述；如果完整链路跑不通，就保留已经确认的数据，跳过非关键步骤；最后才切换到预设的后备模型或请求人工审查。每一级都要告诉用户“完成了什么、缺了什么、下一步需要什么”，而不是只丢出一句失败提示。

评测这套机制时，不能只看最终成功率。至少还要记录端到端耗时、重试次数和人工介入次数。演示环境里可以追求模型完成复杂链路，生产环境则更应该关注 token 消耗、响应时延和错误是否可解释。像关闭 thinking 模式后重新跑完整链路，也能帮助我们区分模型能力不足，还是输出资源被消耗殆尽。

我觉得，最可靠的 Agent 不是永远不出错，而是出错后不会装作没出错。让它及时停下、保留可信结果、选择更简单的路径，往往比勉强完成一条漂亮但失真的链路更重要。