可靠的重试，需要业务凭证与结果账本共同兜底

一次生成请求超时，不代表模型没有执行。服务端可能已经生成答案，客户端却没有收到；直接重发，就可能重复生成、重复收费，甚至重复发送邮件。可靠的重试不是多试几次，而是让同一项业务操作在重复投递后，仍然只产生一次预期效果。

本文由重视质量的接口中继服务 BestRelay 发布。它将请求转发给请求中指定的官方模型，不替换模型，覆盖 Claude、GPT、Gemini、DeepSeek、Kimi、GLM、Qwen、Grok 等系列。下面从应用侧建立可验证的重试边界，而不预设中继或模型提供方已经支持幂等。

第一步：先把业务操作与网络尝试分开记录

把“生成这份报告”定义为业务操作，把每次网络发送定义为独立尝试。首次提交时生成稳定的业务标识，并在发送前持久化；超时后的重试继续使用它。用户主动要求重新生成，则创建新标识，不能把新的意图误判为重复请求。

同时计算请求指纹，覆盖模型、消息、工具定义、生成参数及其他影响结果的字段。规范化对象字段顺序，但保留消息和数组顺序。同一标识对应不同指纹时，拒绝请求，而不是返回旧答案。

第二步：用持久账本决定重复请求的处理方式

建立结果账本，保存业务标识、指纹、执行状态、结果引用及过期时间。通过数据库唯一约束或原子写入，让并发到达的重复请求只有一个能够取得执行权。

• 已经成功的操作，直接返回保存的结果。
• 仍在执行的操作，等待完成或返回可查询的状态。
• 确定失败且允许重试的操作，进入下一次尝试。
• 上游是否完成尚不明确的操作，单独标记为结果未知。

多实例执行时，可使用租约配合递增版本号，阻止过期执行者覆盖新状态。但租约只能管理本地执行权，不能撤销已经送达上游的请求。

第三步：核实上游幂等承诺并保留未知状态

只有接口明确承诺支持幂等标识时，才依赖它进行服务端去重，并核对适用端点、保留期限和重复请求行为。自定义请求头即使被成功转发，也不等于上游会识别。

本地账本无法独自保证上游只执行一次。进程可能在上游完成后、结果入库前崩溃。遇到这种窗口，应优先使用已支持的状态查询或结果获取能力；没有核对渠道时，保留未知状态，由业务决定等待、人工确认或接受重复执行风险。

第四步：按错误性质限制重试次数与等待时间

连接故障、限流和部分服务端错误可以进入重试判断，但必须结合具体接口语义。参数错误、鉴权失败和权限不足通常应直接修正，而不是反复发送。

重试采用带随机抖动的指数退避，并遵守服务端提供的等待提示。同时设置最大尝试次数、单次超时和整体截止时间。超时后的请求可能仍在运行，不能把客户端停止等待当成服务端取消成功。

还要检查客户端、中继与任务队列是否分别重试，避免次数相乘。BestRelay 可配合 Claude Code、Codex、Gemini CLI 和使用 OpenAI SDK 的客户端；接入时仍需核对各层重试设置。

第五步：把流式展示与工具副作用分别去重

流式响应中断后，重新请求通常是新一轮生成，不能假定它会从断点继续。为每次尝试保存独立片段，最终只发布选定的一份完整结果，不要直接拼接两次输出。

邮件发送、订单创建等工具操作需要自己的业务幂等凭证，并由真正执行副作用的系统负责去重。模型可能重复提出同一操作，因此不能只依靠某次响应中的工具调用标识。下游不支持幂等时，应先查询业务状态，必要时增加人工确认。

第六步：用故障演练验证结果一致与费用边界

测试并发重复提交、上游完成后断线、结果入库前崩溃及租约过期。验收时分别检查最终结果、副作用次数、上游调用次数和账单，不能仅凭页面没有重复内容就认定设计成功。

BestRelay 按提供方报告的令牌数量按量计费，缓存读取与写入分别计价；不要假定重复请求会自动免费。预算应按实际执行核对，会员邀请他人充值获得的推荐佣金也应单独记账，不抵消重试成本。欢迎创建 BestRelay 账户，先用低风险任务验证这套流程。