AI API 超时后能直接重试吗？先分清“没收到”和“没执行”

客户端报超时，最容易做的事是再点一次。问题在于，第一次请求可能根本没到服务器，也可能已经执行，只是结果没回到客户端。这两种情况，对重试和费用的含义不同。

先留下排查线索

记录请求时间、模型标识、所用分组、HTTP 状态（如果有）和请求 ID。记清是“连接失败”“一直没有首段输出”，还是“已经输出一半后断开”。这比只保存一张“请求失败”截图更有帮助。

反馈问题时，不要把 Authorization 头、完整 API Key 或客户材料一起发出去。可从接入指南核对基础地址和协议路径。来源 2

超时不负责告诉你业务状态

客户端等待时间用完，只能说明它停止等结果。HTTP 标准对非幂等请求的自动重试有明确限制：需要知道重试语义安全，或有办法确认原请求没有生效，才适合自动重试。来源 1

模型生成通常通过 POST 提交。不能仅因为网络错误，就假定同样的请求再发一次一定不会重复执行。某个 SDK、某个网关支持的去重字段，也不能直接推广到所有渠道。

已经有输出时，先查用量

如果流式回答已经返回一部分，再断开时，应先保存这部分内容和错误信息，并去用量记录核对。账单记录可能需要等待处理完成；暂时没有记录，也不是免费或未执行的证明。来源 3

停止生成同样不能一概理解成撤销调用。是否已产生费用，要看实际用量和渠道规则。

重试策略要有停止条件

可以把重试安排成有限次数，并给重复任务一个应用内部标识；发生不明状态时暂停自动循环，转为核对记录。内部标识便于日志关联，但只有服务端明确支持并执行去重，它才可能提供去重保证。

如果调用会继续触发发信、写库或下单等工具动作，应先检查那些动作是否已经完成。重新生成一段文字与重复写入业务系统，是不同的恢复问题。

在小范围里验证

先对一项不涉及真实外部写入的任务检查正常返回、输入错误和人工取消。需要模拟断网时，可在测试环境用不计费的模拟服务验证客户端逻辑。本文没有发起付费故障测试，也不承诺所有提供商都会采用相同计费或重试规则。

第一次调用的格式检查可以参考已知答案验收例子。把“接口能通”和“失败后能正确恢复”分别验收，会更容易定位上线后的问题。