智能体重试 API，先防重复写入

智能体调用 API 超时后，直接重试可能把同一件事做两遍：工单重复创建，退款也可能重复执行。dev.to 的这篇文章讨论了一个容易被忽略的问题：在让 Agent 修改业务数据前，应用需要识别哪些请求属于同一次业务操作，不能把超时直接当成失败。

目前能确认什么

原文用一个假设场景说明风险：服务端已经创建工单，但连接在响应返回前断开。Agent 没收到结果，于是重试，服务端又建了一张工单。这是分布式系统中常见的结果不确定问题，并非语言模型独有。

幂等键（Idempotency Key）的作用，是给一次业务操作分配唯一标识。服务端保存标识及处理结果，收到相同键的重试时，可以返回已有结果，避免再次执行。

幂等键标识的是一次业务操作，重试时必须复用。

作者强调，应在工作流步骤被安排执行时生成并持久化这个标识，让它跨重试、进程重启保持稳定。每次请求前重新生成 UUID，会让去重失效；仅根据模型生成的请求正文计算标识也不可靠，因为措辞可能变化。

节选中的 FastAPI、SQLite 示例还把工单和幂等记录放进同一数据库事务，确保两者一起成功或失败，避免出现工单已创建、去重记录却没保存的缺口。

我的判断

给 Agent 开放写接口时，开发者需要检查的，不只是工具参数是否合法，还包括超时后如何恢复。创建客户、开票、发邮件这样的连续步骤，不能靠从头重跑保证正确；每一步都需要保留操作身份。

请求里带上幂等键，只完成了保障的一部分。

当前节选尚未完整展示接口实现，同一键对应不同参数时如何处理、并发重试如何协调、记录保留多久，都还不能确认。数据库事务也不能直接覆盖邮件发送或外部退款。涉及这些副作用时，还需要核对下游接口的幂等约定，才能判断重复执行的风险是否真正被控制住。