智能体工具调用失败时的重试与兜底：让 Agent 跌倒了能自己爬起来

给 Agent 接入工具之后，最常见的问题不是模型不够聪明，而是工具调用失败：网络超时、接口限流、参数格式不对、返回结果为空。一次失败如果直接抛给用户，体验就断了；如果无脑重试，又可能把一次小故障放大成重复扣费或重复写库。本文分享一套实用的重试与兜底做法。

一、先给失败分个类，再决定怎么处理。不是所有失败都值得重试。第一类是临时性失败，比如网络超时、服务 503、限流 429。这类失败重试大概率能成功，值得重试，但要加退避：第一次等 1 秒，第二次等 2 秒，第三次等 4 秒，最多 3 次。第二类是参数性失败，比如缺少必填字段、枚举值不在范围内、JSON 格式错误。这类失败重试多少次结果都一样，正确做法是停下来，让模型根据错误信息修正一次参数再调用；修正一次仍失败，就把错误原样告诉用户。第三类是业务性失败，比如查无此人、余额不足、权限不够。这类失败不是技术问题，重试没有意义，应该直接把业务含义翻译成用户能懂的话。

二、重试要有护栏：次数、超时与幂等。一是总次数上限，单次工具调用最多重试 3 次。二是总超时上限，给整个工具调用链路设一个总预算，比如 30 秒。三是幂等键，对写操作必须带幂等键，重试时用同一个键，避免重复执行。

三、兜底：重试都失败后怎么办。降级一：换一条路，查不到实时数据就用缓存数据并注明时效。降级二：拆小步，一次大调用失败拆成多次小调用定位问题。降级三：诚实交代，把已尝试步骤、失败原因、下一步建议写清楚交给用户。

四、一个小清单：失败分三类了吗；重试次数和退避设了吗；写操作有幂等键吗；总超时设了吗；重试耗尽后的降级路径写了吗；最后的失败信息用户能看懂吗。工具调用的稳定性很大程度上不在模型，而在这些工程细节上。