算
Agent 工具调用一超时，常见做法是无脑重试三次，结果下游被打爆、账单翻倍，还可能重复下单。超时处理要和重试、幂等一起设计。
一、先区分超时类型：连接超时多是网络或服务端没收到，读超时可能是服务端正在算。读超时盲目重试最危险，因为第一次请求可能已经在执行。
二、重试要有退避：固定间隔重试会在故障时形成脉冲，我一般用指数退避加抖动，首次 1 秒左右，上限 30 秒，总重试次数 2~3 次封顶。超过上限就走降级，别让一次调用拖垮整条链路。
三、幂等键是底线：凡是会产生副作用的调用（下单、写库、发消息），请求里必须带幂等键，服务端按 key 去重。没有幂等保障的接口，重试前先查状态：能查就查，不确定就别重试，宁可报给人工。
四、超时时间要分层：模型调用、向量检索、外部 API 的超时不能用同一个值。检索类可以短一点快速失败，生成类适当放宽，但都要设全局死线，防止链路无限等。
五、可观测性：把每次重试的耗时、退避、最终状态记下来，超时率一涨先看是某个工具集中超时还是普遍变慢，前者查工具，后者查网络和配额。
大家的 Agent 超时重试策略是怎样的？有没有因为盲目重试踩过重复执行的坑？
一、先区分超时类型：连接超时多是网络或服务端没收到，读超时可能是服务端正在算。读超时盲目重试最危险，因为第一次请求可能已经在执行。
二、重试要有退避：固定间隔重试会在故障时形成脉冲，我一般用指数退避加抖动，首次 1 秒左右，上限 30 秒，总重试次数 2~3 次封顶。超过上限就走降级，别让一次调用拖垮整条链路。
三、幂等键是底线：凡是会产生副作用的调用（下单、写库、发消息），请求里必须带幂等键，服务端按 key 去重。没有幂等保障的接口，重试前先查状态：能查就查，不确定就别重试，宁可报给人工。
四、超时时间要分层：模型调用、向量检索、外部 API 的超时不能用同一个值。检索类可以短一点快速失败，生成类适当放宽，但都要设全局死线，防止链路无限等。
五、可观测性：把每次重试的耗时、退避、最终状态记下来，超时率一涨先看是某个工具集中超时还是普遍变慢，前者查工具，后者查网络和配额。
大家的 Agent 超时重试策略是怎样的？有没有因为盲目重试踩过重复执行的坑？