调用大模型 API，超时是常态：高峰期排队、长文本生成、网络抖动，都可能在几十秒后才等来一个 504。几乎每个团队的第一反应都是加一层重试——但重试做得不对，比不重试更危险：重复扣费、重复写入、重复通知用户。重试机制的第一道防线，不是退避算法，而是幂等性。

第一，先分清哪些调用可以盲目重试

查询类调用（问答、摘要、分类）天然幂等，失败了重发一次没有副作用。但"生成并落库"“提交工单”"发送通知"这类调用不是：第一次请求可能已经在服务端执行成功，只是响应没回来。盲目重试，等于把同一个动作做两遍。

可执行做法：把业务动作拆成"生成"和"提交"两步。模型生成内容是幂等的，随便重试；真正写状态的提交动作，单独包一层，重试前先查询上次请求的最终状态，确认失败再重发。

第二，指数退避加抖动，别把重试变成雪崩

服务端限流（429）或短暂故障时，所有客户端如果都在"1 秒后重试"，等于把故障放大成冲击波。指数退避（1s、2s、4s、8s）是标配，但必须叠加随机抖动（jitter），把重试时间打散。同时设置重试上限和总超时预算：一个请求最多重试 3 次、总耗时不超过 30 秒，超过就失败落人工，不要无限吞吞吐吐。

还有一个常见坑：重试逻辑写在调用方和网关两层，两层叠加后实际重试次数是乘积。重试策略全系统只放一层，其余层透传失败。

第三，请求 ID 是排查和防重的关键

每次调用生成唯一的 request_id，随请求发送，并和本地业务记录绑定。超时后先拿 request_id 去查询接口确认结果，查不到再重试，重试时带上同一个 request_id——服务端见到重复 ID 直接返回上次结果。这样即便重试十次，业务上也只执行一次。

没有服务端幂等键的供应商接口，就要在客户端做兜底：把"已提交未确认"的请求记在本地表里，恢复后逐条对账。对账逻辑听起来繁琐，但它把"不确定"变成了"可核实"，而可核实恰恰是自动化系统敢放量运行的前提。

写在最后

超时重试的本质不是"多试几次"，而是在不可靠网络上维持业务语义的确定性：该执行一次的，执行且只执行一次。先写好幂等键和状态查询，再调退避参数——顺序反了，重试越勤奋，事故越频繁。

——文/吴佳文，广东省人工智能与机器人学会副秘书长，长期关注AI产业落地与人工智能人才培养。