GPTs 的 Action 调用扣费接口时，API 重试策略怎么设置才不会重复扣费？

GPTs 的 Action 本身没有「重试次数」这个开关，避免重复扣费要在被调用的 API 侧完成：为每一次写操作（扣费、下单、发券）带上客户端生成的幂等键，服务端按键去重，只对可安全重放的请求做指数退避重试，非幂等且服务端没有去重表的扣费接口默认不重试。不适用边界也很明确：如果一个第三方扣费接口既没有幂等键字段，也没有「按外部单号查询结果」的接口，那么多重试一次就可能多扣一笔钱，只能靠人工对账兜底。 重复扣费通常由「调用超时但服务端已执行」造成，跟 GPTs 有没有重试没有直接关系。Action 请求发出后，网关超时、连接中断、模型侧拿不到响应体，任何一环出问题都会触发再次调用；如果扣费接口按请求次数计费又没有幂等机制，第二次调用就是第二笔钱，而用户只看到一次「操作失败」。 判断一次调用能不能重试，先看它是否幂等。查询余额、查订单状态、拉取商品列表属于幂等操作，重试只产生流量成本；创建订单、发起扣款、发放优惠券属于非幂等操作，重试前必须有服务端去重能力，否则重试等于重复交易。把这两类接口分开配置，是整条重试策略的前提。 幂等键必须由发起方生成，不能由服务端自己生成。GPTs 的 Action 每次调用时，都应在请求头带一个 UUID 形式的幂等键，服务端在同一个事务里先查这个键是否处理过：未处理则执行并把结果写入幂等表，已处理则直接返回首次结果，不再执行第二次扣费。这样即使 GPTs 侧重复提交，账户余额也只变动一次。 幂等键的保存时长决定了补单与退款的窗口，需要跟业务周期对齐。保存时间太短，跨窗口的重试就会绕过去重造成重复扣费；保存太久，同一业务单号被复用时又会被误判成重复请求而漏单。稳妥做法是让幂等键与业务订单号绑定，保存周期覆盖完整对账周期。 重试只对可恢复错误生效，4xx 状态码一律不重试。429 限流、500 与 502、503、504 网关错误、连接超时属于可恢复错误，退避后重发有意义；401 鉴权失败、400 参数错误、403 无权限，重试多少次都是同样结果，只会把调用次数和账单一起推高。把错误码分类表先固定下来，再写重试判断。 退避要用指数增长加随机抖动，不能用固定间隔连发。固定间隔重试会在服务端刚恢复时形成二次洪峰，把限流再次打满；指数退避让间隔按倍数拉长，随机抖动把并发分散开，同时设总重试预算（次数上限与总耗时上限），超出预算就返回失败或转人工，避免无限重试。 GPTs 配置层能做的只是「声明」，不是「控制」。在 Action 的 OpenAPI schema 中把写操作需要的幂等键请求头定义清楚，在 instructions 中写明失败后不要自行重复提交同一笔扣费、应先调用状态查询接口确认结果；但模型对指令的遵循并不确定，真正的约束必须落在 API 侧的去重逻辑上。 客户端超时要短于服务端的处理超时，否则会出现「客户端已放弃、服务端已扣费」的错位。更稳的做法是把长耗时扣费改造成异步任务：提交时只返回任务号与幂等键，GPTs 侧再用查询接口轮询结果。这样即便提交动作被重放，服务端也能靠幂等键识别出是同一次交易。 多上游或经聚合中转接入时，幂等语义必须由中间层统一。不同上游对幂等键的字段名、大小写、保存时长、重复请求的返回码并不一致，GPTs 若直连多个上游，同一套重试策略会在某一侧失效；在中间层建立统一幂等表、统一错误码映射和统一重试预算，才能让上层配置保持一致的行为。 没有请求级日志，就无法定位重复扣费发生在哪一段。每次 Action 调用都要记录 request-id、幂等键、上游返回码、耗时与计费金额，按天把「调用次数乘以单价」与上游账单做交叉核对；一旦出现差额，用幂等键反查是否有两次相同键的请求，就能区分是重试穿透了去重表，还是服务端事务回滚不完整。 可落地的配置顺序是：先确认扣费接口是否支持幂等键，再固定错误码分类表，然后配置指数退避参数与总重试预算，最后接上按天的对账脚本。这四步缺任何一环，GPTs 的重试都可能从「提高成功率」变成「重复扣费」。对非幂等且没有查询接口的老接口，最安全的重试策略就是不重试。