你做了一个 AI Agent，调用搜索、数据库、支付或发消息的 Tool。偶尔却突然报错：429、timeout、服务繁忙。最直觉的处理方式，是"失败了就再试一次"。
一次 Retry 看起来无害，但如果几十个请求同时失败、同时重试，原本只是短暂拥堵，可能被放大成更严重的拥堵。更麻烦的是，有些 Tool 一旦重复执行，后果不是多一次请求，而是多扣一次钱、多发一封邮件，甚至多创建一笔订单。
所以，Tool Retry 真正要解决的，不是"失败后怎么再试"，而是"什么失败值得重试，什么失败绝不能自动重试"。
先分清：限流不是一种错误，而是一种信号
Tool 被限流，常见表现是 HTTP 429、rate limit、quota exceeded，或者平台明确告诉你"稍后再试"。
它通常意味着：请求太快，或者额度已经用完。
如果只是短时限流，Retry 有意义；如果当天额度耗尽，再重试十次也不会成功。类似地，参数错误、权限错误、资源不存在，也通常不是重试能解决的问题。
设计 Retry 前，可以先把错误分成三类：可恢复错误，如 429、临时 5xx、网络超时；条件可恢复错误，如 token 过期、依赖服务尚未完成；不可恢复错误，如参数非法、权限不足、业务规则拒绝。
只有第一类，才适合默认进入自动 Retry。
Retry 不是越多越稳，通常 2～3 次就够了
很多系统把 Retry 设成 5 次、10 次，觉得"多试几次成功率更高"。这个逻辑只看到了单个请求，没有看到整个系统。
假设 100 个请求同时被限流，每个请求再重试 5 次，你最多会制造 500 次额外请求。服务本来已经拥堵，你却继续加压，这就是典型的 retry storm。
对多数普通 Tool 调用，比较稳妥的默认值是：首次失败后再尝试 2～3 次。再往上加，收益通常迅速下降。
当然，次数不是固定答案。还要看任务有多重要、用户能等多久、失败成本有多高。读取天气、搜索网页，可以稍微积极一点；支付、下单、发送消息，则应非常保守。
Interval 的关键，是让重试错开
最差的 Retry Interval，是固定等待 1 秒。
因为如果 100 个请求同一时刻失败，它们会在 1 秒后再次同时发起，第二轮拥堵准时到来。
更常用的方案是指数退避：第一次等 1 秒，第二次约 2 秒，第三次约 4 秒，再加一点随机抖动，也就是 jitter，让不同请求不要在同一时间醒来。
如果服务端返回 Retry-After，优先尊重它，因为那是服务端明确告诉你的恢复窗口。
关键原则只有一个：Retry 要减少冲突，而不是把失败请求重新同步。
最危险的情况，是 Retry 成功了两次
有一类 Tool，绝不能只因为"超时"就自动重试：具有不可逆副作用、且无法确认第一次是否已经执行成功的操作。
典型例子包括支付扣款、创建订单、转账、发送邮件或短信、发布内容、删除资源、提交审批。
想象一个场景：你调用"支付 100 元"，服务器已经成功扣款，但返回结果途中网络超时。客户端看到 timeout，以为失败，又自动 Retry。第二次也成功，于是用户被扣了两次。
这里的问题在于，你不知道第一次到底有没有成功。
如果 Tool 支持幂等键，风险会小很多。所谓幂等，就是同一个业务操作即使提交多次，系统也只执行一次。例如支付时带一个唯一 request_id，服务端发现这个 id 已处理，就直接返回第一次的结果，而不是再次扣款。
如果 Tool 不支持幂等，又有真实副作用，默认策略应该是：不要自动重试，先查询状态，或者交给用户确认。
一个实用判断：重复执行会发生什么？
设计 Tool Retry 时，可以用一个简单判断框架。
如果重复执行没有副作用，例如搜索、读取文件、查询数据库，通常可以自动 Retry。
如果有副作用，但接口具备可靠幂等机制，可以在严格限制次数的前提下 Retry。
如果可能造成重复扣款、重复发送、重复删除，而你又无法确认第一次结果，就不要自动 Retry。
这比死记"哪些错误码能重试"更有用。因为真正决定风险的，不只是错误码，还有 Tool 的业务语义。
把 Retry 当成可靠性策略，而不是异常处理
成熟的 Tool 调用链通常不只有 Retry。它还应该有 timeout、并发限制、circuit breaker、fallback，以及足够的日志和指标。
如果每次出错都只想到"再试一次"，系统迟早会遇到一个被 Retry 放大的问题。
可以给自己设一个默认规则：读取型 Tool 遇到明确的临时错误，指数退避加 jitter，最多重试 2～3 次；写入型 Tool 先确认是否幂等，再决定是否自动 Retry；任何无法判断第一次是否成功的高风险操作，都不要盲目重试。
Tool 的可靠性，不取决于你能把失败请求再发多少次，而取决于你是否知道什么时候该重试，什么时候该停。