AI API 重试与代理IP：如何确认没有重复请求和额外费用

重试会增加客户端发送尝试，但发送次数、服务端实际执行次数、计费用量和账单事件并不总是一一对应。失败请求是否计费取决于服务商、端点和实际处理状态，不能直接按请求次数乘单价推算。本文先用受控靶子验证客户端行为，再依据具体服务商文档和用量明细核对费用。

哪些现象可以说明请求被重复发送

• 信号一：靶子接收次数高于逻辑请求数，提示可能有重试、重定向或并发尝试，需按尝试 ID 继续核对。
• 信号二：相同幂等键出现多条访问记录，不能单凭访问次数判断执行次数；还要看处理事件和去重结果。
• 信号三：服务商用量明细与本地预期不符，作为待查信号，不能直接认定重复计费。

这些信号都只用于触发进一步核查。分别记录逻辑请求 ID、尝试 ID、服务商请求 ID、服务端处理事件、输入/输出/缓存用量及价格版本；只有证据链能对齐时，才判断是否重复执行或产生额外费用。

为什么要用计数靶子替代真实付费接口

不要拿真实付费接口做故障注入。搭建只在测试环境可达的受控服务，记录逻辑 ID、尝试 ID、到达时间、测试请求标识、响应和服务端处理次数；只在自有测试数据上按需延迟响应或返回 429/5xx。请求体哈希仅在自有系统、获得授权且确有必要时保存，并做好脱敏。靶子结果只能说明客户端行为，不能代表第三方服务的计费规则。

在自建靶子中，可按测试计划构造以下响应：

• 可以按需返回 429 并带 Retry-After，观察客户端是否遵守。
• 可以在收到请求后延迟响应，触发客户端超时重试。
• 可以返回 307/308，观察是否重放请求体。

靶子只服务测试流量，不接入业务链路；实验结束后关闭，避免误用。

何时可以依赖幂等键

自建靶子可以实现并验证幂等键；调用第三方 AI API 时，只有服务商文档明确说明该端点支持对应幂等键、去重窗口和请求体规则，才能依赖此能力。

对自建靶子，可在逻辑请求开始时生成键并供所有重试复用；明确去重窗口及同键、不同请求体和并发请求的处理规则。第三方端点若不支持幂等，不要通过随意添加请求头假设服务端会去重；超时后先查任务状态，无法确认执行且操作非幂等时不要盲目重试。

对第三方接口，记录具体端点、文档版本、支持的键名、有效窗口及不同请求体的行为；没有明确文档时，将幂等能力标为未确认。

如何逐项验证重试什么时候会触发

• 场景：读超时后重试 ｜ 发送尝试数：按记录填写 ｜ 服务端处理数：按受控靶子事件填写 ｜ 去重命中：按靶子契约填写 ｜ 费用核验：第三方账单待核
• 场景：连接重置后重试 ｜ 发送尝试数：按记录填写 ｜ 服务端处理数：连接建立前后分别记 ｜ 去重命中：按接口能力填写 ｜ 费用核验：不从连接数推算费用
• 场景：429 与 Retry-After ｜ 发送尝试数：分别记录等待前后尝试 ｜ 服务端处理数：按服务端实际处理记录 ｜ 去重命中：按契约核对 ｜ 费用核验：等待用量明细结算
• 场景：307 / 308 跟随 ｜ 发送尝试数：记录各跳请求 ｜ 服务端处理数：核对各跳是否执行业务 ｜ 去重命中：按端点契约填写 ｜ 费用核验：以服务商用量明细为准

发送尝试、服务端处理、去重结果和费用是四种不同计数。对 429 按 Retry-After 前后的请求及观察窗口记录预期；同键两次访问但仅执行一次可能符合契约。账单尚未结算或缺少服务端处理记录时，标注“证据不足/账单未结算”，不要判定通过或重复计费。

客户端重试前应依据具体 API 契约确认可重试状态、幂等支持和 Retry-After 处理。

307 和 308 重定向为什么可能重放请求

客户端若自动跟随 307/308，通常会尝试保留方法和请求体；是否产生第二次业务处理取决于客户端策略、请求体可重放性以及原请求是否已执行。重定向由客户端按响应处理，换代理出口不决定业务请求应计一次还是两次。用自有靶子记录每一跳请求和处理事件，并注明客户端版本。

• 客户端关闭自动跟随，或按端点契约逐跳处理并记录。
• 只有服务端明确支持幂等时才依赖其去重；否则先查询原任务状态。
• 记录重定向链路，确认中间有几跳。

浏览器跨源请求在符合 CORS 条件时可能出现 OPTIONS 预检；这不适用于所有客户端，不能把它一概视为 API 重复调用。

重定向语义可查 RFC 9110 HTTP Semantics；具体客户端跟随行为以所用 SDK 文档和版本为准。

如何对账请求次数、用量和实际费用

对账涉及客户端日志、靶子或网关计数、服务商用量面板。按逻辑请求、每次尝试、服务端处理事件、输入/输出/缓存用量和账单事件分别汇总。保存服务商请求 ID、价格版本、账单时间窗及结算状态；差额只作待查信号，按服务商用量明细和账单项核实，考虑结算延迟，不假定失败请求收费或按请求数乘单价计费。

如何判定结果并加固重试策略

加固方向包括限制重试条件与次数、使用退避和随机抖动、按接口契约复用幂等键、分别记录逻辑请求与尝试 ID。结论可分为“符合约定”“发现重复执行/费用”“证据不足/账单未结算”；按事先约定的执行次数和费用标准验收，不能把所有重复发送一律判失败。

FAQ

Q：幂等键由客户端生成，重试时复用就可以了吗？

A：只在目标端点文档明确支持该键和去重规则时可以依赖；第三方不支持或规则不明时，不能仅靠客户端加头实现幂等。

Q：重试次数越多，成功率越高吗？

A：不一定。次数增加会放大成本和排队压力，对非幂等请求还可能造成重复写入，应设上限并配合退避。

Q：怎么快速判断账单异常是不是重试造成的？

A：先关联逻辑请求 ID、尝试 ID、服务商请求 ID和用量明细，再检查账单事件与结算状态。多条连接或访问记录不能单独证明重复执行或重复计费；普通 HTTPS 隧道通常也看不到请求体哈希。