工具调用失败怎么办？重试和兜底怎么设计？

先这样答

设计容错的第一步是把失败分类，因为不同失败的正确反应完全不同。

第一类：模型侧的参数错误，比如 Schema 校验不过、参数不合理。这类不该重试，正确反应是把校验错误信息结构化地回传给模型，让它基于错误修正参数再调。这个「校验-回传-修正」回路通常一轮就能修正，两三轮还不过说明工具定义有问题，要回头改 Schema。

第二类：瞬时故障，比如网络超时、服务临时 5xx、限流。这类适合自动重试，但要带退避（指数退避加随机抖动，别集体同时重试）和上限（两三次）。重试前判断一下幂等性：查询类随便重试，写操作类必须确认接口幂等或者拿幂等键，否则一次超时重试就是两笔扣款。

第三类：确定性失败，比如权限不够、资源不存在、参数在语义上就不对（查一个不存在的订单号）。重试毫无意义，要立刻停止重试，把明确的失败原因交给模型决策：换一种查询方式、告知用户、或者走别的路线。

第四类：上游持续不可用。重试和换路线都救不了，进兜底：降级输出（明确告知用户该功能暂时不可用，而不是编一个答案）、切换备用数据源、或者把任务挂起转人工。

整体原则一句话：重试是给瞬时故障的，纠正是给模型错误的，兜底是给系统性故障的，三类手段不能混用。所有失败都要落日志、打指标，失败率突增是线上事故的第一信号。

面试官会怎么追问

• 错误信息怎么给模型才有效？ 结构化、具体、带下一步建议：不说「调用失败」，说「参数 date 格式应为 YYYY-MM-DD，你传的是 2026/9/1」。模型的修正质量取决于错误信息的质量。
• 怎么防止重试叠加成本？ 全链路预算制：单任务的重试次数、token 花费、总时长都有上限，任何一项到线就跳出循环走兜底。
• 降级输出怎么设计不显得像幻觉？ 降级话术模板化：明确说「这个信息暂时查不到」，把已确认的部分和未确认的部分分开表述，禁止模型在失败后自由补全。

回答的坑

• 只会「失败就重试三次」。不分类的统一重试，遇到确定性失败就是浪费钱还拖延迟。
• 忘了幂等性。写操作的重试不加幂等保护是生产事故题库里的经典。