怎么防止 Agent 重复付款？从一次超时说起

Agent 请求一份 1 美元数据，付款接口一直没有响应。Agent 看到“超时”之后立即再付一次，可能发生什么？第一次请求可能已经成功，只是结果在网络途中丢失；第二次可能再产生一笔付款。

阅读边界：下面讨论通用设计，并不声称所有支付接口都支持相同的重试、幂等或退款语义。请以具体服务文档和测试结果为准。

flowchart TD A[付款请求超时] --> B[标记状态未知] B --> C[查询订单与支付记录] C --> D{状态是否明确?} D -->|已付款| E[检查数据是否交付] D -->|未付款| F[按服务规则决定重试] D -->|仍未知| G[暂停并人工处理]

先把状态拆开

状态	它说明什么	不能说明什么
客户端超时	客户端未及时收到结果	服务端一定没有执行
付款成功	支付系统确认达到其成功条件	商品或数据已经交付
数据交付成功	收到了服务商的响应	账务已经完成最终结算
请求重复	收到相同或类似请求	每个服务都会自动去重

什么是幂等键？

可以把幂等键理解为给一次业务操作贴上的稳定标识：当接口支持该机制时，同一次操作因网络故障重试，应按照该接口的规则复用同一键。Stripe 的 API 对幂等请求记录首次结果，并规定键的保留与参数比较规则；这只是 Stripe 具体 API 的语义，不可直接套到别家。Stripe 幂等请求文档

幂等键不是万能保险：要确认它的作用范围、有效期、相同键与不同参数如何处理，以及第一次请求返回错误时能否重试。新键通常会被当成新操作；超过服务保留期，也不能假设仍能去重。

实用检查清单

一次任务、订单、付款请求和服务交付分别有什么标识？
可以查询哪些状态？支付方和服务商各保存什么？
回调重复或迟到时如何去重？
状态未知时，系统是否暂停后续支付并保留预算占用？
何时需要人工联系服务商，是否有退款与对账路径？

有些链上或 x402 实现的凭证、交易及重试机制不同，不能把一种银行卡 API 的幂等规则当成全行业标准。付款与交付的区别可参考失败处理文章。