3.5 ToolRetryMiddleware中间件

基于指数退避算法，设置工具调用失败时的重试策略。

指数退避（Exponential Backoff） 的核心思想就是：当某个操作失败（通常是网络请求、API 调
用或数据库连接）时，系统不会立刻重试，也不会每次都等待相同的固定时间，而是让每一次重试
的延迟时间按指数级增长。
为什么不直接重试？
想象一下，某个热门网站的服务器因为瞬间流量太大（比如抢票或秒杀）崩溃了。如果所有失败的
客户端都立刻或每隔1秒就重试一次，这无异于对已经瘫痪的服务器进行了一场持续的 DDoS（分
布式拒绝服务）攻击，服务器可能永远也缓不过来。

jitter是为了避免大量工具的重试请求集中在固定的时间点，引入抖动。
假设：按照策略，两次工具调用请求的时间间隔应为10秒，加入抖动后，可能为8.9秒，也可能为10.2秒。

举例1：带抖动

call_times_with_jitter.txt 文件内容
为了精确查看工具调用的时间间隔，以理解各项参数的含义，我们将工具调用时间写入本地文件

举例2：无抖动

call_times_without_jitter.txt文件内容

自动重试失败的工具调用。
第 1 次重试（retry_number=1）: 等待 ~ 1.0 * (2.0 ** 1) = 2.0 秒
第 2 次重试（retry_number=2）: 等待 ~ 1.0 * (2.0 ** 2) = 4.0 秒
第 3 次重试（retry_number=3）: 等待 ~ 1.0 * (2.0 ** 3) = 8.0 秒
也就是说，等待时间以指数方式增长 —— 每失败一次，下次再试之前等待更长时间。
如果你把 backoff_factor = 0，就意味着不使用指数增长，重试之间始终用固定的 initial_delay。

2. 为什么要引入 Jitter（抖动）？关闭它会有什么问题？
   在单用户、单并发的测试环境下，关闭 jitter没有任何副作用，甚至能让等待时间非常规律、可预测。但在高并发的生产环境中，关闭 jitter会引发灾难性的“惊群效应（Thundering Herd Problem）” ：