为有副作用的AI请求建立幂等账本

AI 接口超时后再试一次，重复的可能不只是模型生成，还可能是发消息、写数据库，甚至扣款。作者给出的结论是：有副作用的 AI 操作，要在应用边界建立持久化的幂等账本，让同一业务请求重放时拿到已记录的结果。

这篇的价值在于把「支持重试」拆成了可以检查的约束：谁定义请求、如何抢占执行权、结果保存在哪里、处理中断后怎么恢复。不过，它提供的是实施契约和验证步骤，没有给出生产实测数据，也没有交付完整实现。

同一次业务操作，不能靠模型调用 ID 来认领

幂等要解决的问题是：用户提交的同一个操作，因为超时、断连或重试到达多次，业务副作用仍然只发生一次。它不要求模型每次重新生成的文字完全相同。

作者列出了四个控制点：logical_request_id、idempotency_key、request_digest、durable_result。它们分别用于串联逻辑请求、识别重复操作、确认请求内容一致，以及保存可供重放的最终结果。

关键约束是把调用方提供的 idempotency_key，绑定到一个已认证主体、一种操作和规范化请求摘要。账本的键范围是 principal_id + operation + key，摘要负责检查内容有没有变化。同一作用域里，同键同摘要返回原结果；同键不同摘要必须拒绝，不能把旧结果交给新请求。

这里的「规范化」不能省略。比如 JSON 字段顺序不同，是否算同一请求，需要提前约定；原文要求保留 request_digest + schema_version，但没有给出具体算法。

模型调用 ID 只能辅助关联日志，不能替代这套身份规则。它可能随重试变化，也未必对应用户眼中的业务动作。HTTP POST 同样不能直接决定业务能否幂等，真正决定重放行为的是应用账本。

先抢到执行权，再允许副作用发生

幂等的关键是原子地取得执行权，并把最终结果持久化。

作者用下面的 SQL 展示预占操作记录的入口，防止多个工作进程同时执行同一操作：

BEGIN;
INSERT INTO operation_ledger
  (principal_id, operation, idempotency_key, request_digest, status)
VALUES
  (:principal, :operation, :key, :digest, 'pending')
ON CONFLICT DO NOTHING;
-- only the transaction that owns the new row may perform the side effect
-- persist terminal result before returning it to the caller
COMMIT;

要盯住 ON CONFLICT DO NOTHING 后面的第一条注释：只有成功创建新记录的事务才能执行副作用。遇到冲突后继续往下执行，仍然会重复操作。这依赖正确的唯一约束，也需要检查插入结果。

原文把四种做法列为发布阻断项：只在内存去重、只有键没有摘要、先查询再执行的竞态，以及拿模型调用 ID 当业务键。内存记录扛不住重启和跨节点并发；查询与执行之间的空隙，则可能让两个进程同时通过检查。

这段 SQL 仍然只是骨架。它没有展示冲突后的摘要比较、结果写入，以及并发请求遇到 pending 时如何响应。尤其是外部消息或支付已经成功、账本却没写完的情况，数据库事务无法自动消除两者之间的故障窗口。

因此，作者要求对过期 pending 使用有明确归属的恢复租约，再查询外部副作用凭据，最后补写终态，不能直接重做。原文没有给出过期时间和租约参数，需要按操作实现恢复流程。

验收要覆盖断连、重放和最终结算

作者建议先划清责任：客户端负责本地配置，网关负责认证、路由、限额、计量和尝试记录，提供方负责原生协议及其能力约定。一次文本请求成功，只能证明那条路径当时可用。

验证前要固定客户端、网关策略、模型别名、路由集合和观测基线，保留配置快照。然后发送确定性的正向探针，记录客户端响应、请求 ID、选中路由、终态及用量。

接下来才是更有价值的故障验证：制造拒绝、限额或断连，确认失败发生在预期层；通过实际协议入口重放，确认同键同摘要返回持久化结果；再用同键不同摘要验证冲突拒绝。恢复检查还要保留 lease + side_effect_receipt + terminal_write，让每次尝试都能归到同一个逻辑请求。

网关兼容 OpenAI 接口，不足以证明相邻的原生协议入口也支持相同能力。作者还要求保留显式零值，并以最终持久化结算作为计费依据。

灰度发布需要负责人、到期时间、停止阈值和回滚准备；监控则要同时看成功与损害，并事先确定统计分母。原文没有给出具体指标公式或通用阈值，只要求根据工作负载的服务等级目标（SLO）制定。调用方截止时间也应保留，拒绝、取消、重试、回退和结算要分别可观测。

我的判断

我赞同把幂等放在理解业务操作的应用边界。网关能集中处理路由和调用记录，却未必知道一次工具调用是在重发同一条消息，还是发送另一条内容相同的消息。仅靠网关请求 ID，很难做对这个判断。

持久化账本比内存去重、简单查询防重更能覆盖并发和故障，但实现成本也更高。对已有唯一业务编号的数据库写入，可以先评估现有唯一约束是否足够；涉及外部系统副作用时，执行凭据和恢复机制通常更关键。

这篇给出的是设计原则与验收清单，不能当作已经验证的完整方案。

作者任职于 Modelflare，文中对产品能力的介绍带有明确利益关系。文章没有并发压测、故障注入结果或替代方案对照数据。它注明资料核验日期为 2026-08-07，也明确说来源不能证明未经测试的路由。至于最终失败是否永久重放、何时允许重新发起操作，原文没有说清，需要业务另定规则。

能拿来做什么

• 在 Node 服务接收发消息、写数据库或工具执行请求时，先定义业务操作的键范围、摘要规则和终态结果，再接入自动重试。
• 让前端重试同一次提交时沿用原来的键；用户修改内容后重新提交，则按新操作处理，并由服务端核验主体和摘要。
• 为 AI 工具执行补上并发重复、同键异参、执行后断连和过期 pending 恢复检查，验证账本与外部副作用能否对上。
• 区分只读生成与有副作用操作的重试策略：前者按预算控制，后者先查账本和执行凭据，再决定下一步。