Agent 重试不能重复下单：业务写入的幂等设计怎么做

用户想购买两件相同商品，可以形成两笔内容相同但意图不同的订单。网络丢包后重试同一笔订单，则是同一意图的不同尝试。把参数哈希直接当去重标识，可能把第二次真实购买误删。

AWS 的幂等 API 文章说明由调用方提供唯一请求标识，并讨论相同标识、不同意图和迟到请求。本文沿用这一原则，具体订单流程为本站演练。

稳定标识在意图被确认后生成，后续查询和重试沿用。任务重新计划、改变商品或用户另下新单，是否构成新意图必须由业务规则明确，不能让模型随意更新标识。

稳定 intent_id 应在首次写请求之前持久化，并与已确认任务及内容绑定。进程重启、检查点恢复或回调重放时读取原标识，不重新生成。否则服务端即使正确处理相同标识，客户端恢复后换了标识仍会重复下单。记录持久化失败时停止发送，先修复任务状态。

字段名和状态为示例。标识不是密码，知道它不代表有权查询订单。每次请求仍检查身份与对象范围；记录和查询入口不能泄露其他用户的结果。

如果先创建订单再登记标识，中间崩溃就可能在重试时再创建一次；如果先登记完成却没写入订单，调用方会被错误地告知成功。对于可放入同一数据库的变更，可用事务与唯一约束处理一致性。

调用外部支付、邮件或第三方服务时，单个本地事务不能覆盖整个网络链路。利用对方提供的幂等能力和结果查询，记录中间状态，再通过对账或明确补偿处理不一致。不要暗示本地加一张表就能保证所有外部动作只发生一次。

并发重复请求也要测试。两个请求同时查到“未处理”，再各自执行，会绕过普通的先查后写。服务端需要可靠的原子占用或唯一性机制，并定义处理中请求的返回方式。

幂等性保护重复副作用，不保证服务永远成功。超时、权限变化和下游故障仍需要预算与恢复流程。

第一次提交商品 A，重试却提交商品 B，如果服务直接返回原订单，用户会误以为买到 B；如果按新内容执行，就破坏了去重合同。应返回内容冲突，并说明需要重新确认当前意图。

内容指纹可以用于检测这种变化，但它不是生成意图标识的唯一依据。计算时明确哪些字段参与，例如对象、金额、币种与目标；忽略真正影响动作的字段会留下漏洞。

草稿修改、审批过期或权限撤销时，继续执行前重新校验。旧标识不能证明当前授权仍有效，已完成请求的结果查询与尚未执行的新动作应按各自规则处理。

服务的幂等记录通常有保留范围。若记录已经过期，一个很晚的重试可能被当作新请求。项目应说明允许的重试窗口、记录保留和窗口外的结果查询或人工确认方式。

不要把所有请求无限保留，也不要为了省存储任意删除。期限由业务任务周期、对账和平台能力决定。任务端保存足够标识，超过窗口后停止自动重试，不猜测原动作没有发生。

测试覆盖响应丢失、并发重复、不同内容、暂停恢复和迟到请求。最后检查真实对象数量与状态，而不是只检查工具返回码。

优先检查创建订单、退款、发送消息或工单等重复代价明确的动作，确认服务是否有幂等标识和查询能力。没有这两项时，缩小自动执行范围，先生成草稿或安排受控接管。

这套方法适合带副作用的 Agent 与工作流。它描述的是约定边界内重复请求的处理，不承诺分布式系统全局“恰好一次”。外部平台的具体幂等合同必须单独核实。