改变答案的重试：针对非确定性 LLM 调用的幂等键

评估流水线评分了错误的副本。 如果存在两个输出，而你的追踪摄取抓取了最后到达的那一个，你的评估（eval）就是在对一个从未交付的人造产物进行分级。仪表盘在变动，原因却无从寻找，你花了一个 Sprint 的时间去追踪一个从未有人读过的响应所产生的退化。

缓存污染。 以提示词为键的响应缓存可能会存储重试产生的答案 —— 即用户从未见过的那个。下一个拥有相同提示词的用户收到的生成结果，仅仅是因为三个请求前的网络波动而存在的。

针对非确定性后端优化的幂等键 (Idempotency keys)​

解决方案与支付系统使用了十年的原始方案相同 —— 幂等键 (idempotency key) —— 但其语义必须进行调整，因为被去重的内容不再是确定性的。

形式如下：客户端 为每个逻辑请求生成一个唯一的键并附带上。位于应用程序和模型提供商之间的网关根据存储检查该键。第一次看到该键时，它运行生成逻辑，将结果与该键对应存储，并将其返回。之后每一个带有相同键的请求都返回 存储的 结果 —— 它不会重新采样。现在，逻辑请求精确地映射到一个答案，无论传输层在下面重试了多少次。

对于 LLM 调用，有两个细节比支付场景更重要。

键属于逻辑请求，而不是传输尝试。 如果你的重试中间件在每次尝试时都生成一个新的键，那么你什么也没构建 —— 每次重试仍然是一个新的生成过程。键必须在所有重试逻辑的上游生成一次，并向下传递到每一个可能重新发送的层级。这是最常见的实现错误：键虽然存在，但在错误的地方被重新生成。

参数不匹配必须报错，而不是默默重新运行。 如果一个带有已知键的请求到达，但 Prompt 或参数不同，网关应该拒绝它，而不是提供陈旧的答案或默默生成一个新的答案。已经提供幂等性 Header 的供应商已经这么做了 —— 当键被重复使用但参数不匹配时，OpenAI 的 API 会返回带有 HTTP 409 的 idempotency_conflict。在自己的网关中复制这一契约：键是一个承诺，即该请求是 同一个 请求，而不匹配则意味着这是一个值得大声指出的 Bug。

一个实际的难点：生成可能需要 30 秒以上，因此在第一次尝试仍在进行中时，重试可能会到达。存储需要三种状态，而不是两种 —— 进行中 (in progress)、已完成 (completed)、已失败 (failed) —— 这样并发重试就会阻塞在进行中的结果上，而不是启动并行的生成。只有“已见/未见”状态的幂等存储在生成缓慢的情况下仍然会导致双倍计费。

教会重试层识别“从未送达”与“可能已完成”的区别​

幂等键让重试变得 安全。它们并不能让重试变得 聪明。重试层仍然需要做出决定，并且应该根据请求到达的程度来决定。

如果连接在发送任何字节之前就失败了 —— DNS 失败、连接被拒绝、TLS 握手错误 —— 则可以证明请求从未到达模型。重新采样是正确的，而且几乎不需要键。如果失败发生在请求完全传输 之后 —— 读取超时、响应中途连接断开、已经转发调用的网关返回 5xx —— 请求 可能 已经完成，重试必须走幂等路径。将此作为重试中间件中的分类体系进行编码：传输前失败可以自由重试，传输后失败只能通过键进行重试。

然后为副作用划定界限。幂等键对 生成 进行去重；它不会自动对 生成产生的工具调用 (tool call) 进行去重。将工具执行视为其自身的幂等单元：将工作流 ID、工具名称和参数哈希成第二个键，保留执行调用的分类账，运行每个处理器一次，并在任何重试中重放存储的结果。生成层和动作层各需要自己的“精确一次 (exactly-once)”边界 —— 一个保护你的账单，另一个保护你的用户。

最后，修复计费对账。将成本归于逻辑请求（由幂等键标识），而不是传输尝试。如果你的成本仪表板计算供应商调用次数，那么网关吸收的去重重试仍会显示为支出，除非你根据键进行对账。否则，你解决了正确性问题，却留下了会计问题。

值得铭记的启示​

“超时重试”是从一个重新发送请求要么无害要么收敛的世界中继承下来的原始做法。将其原封不动地放入具有非确定性后端的系统中，会将每一次超时变成一次抛硬币 —— 既费钱、又可能触发副作用、还会悄悄分叉你对话历史的第二次掷骰子。

这种规程并不陌生。它是幂等键，是让支付 API 变得安全的同一套工具，外加非确定性所迫使的两个调整：为 逻辑 请求生成键，使其在每次重试中幸存下来；并将“精确一次”边界拆分为两个 —— 一个围绕生成，一个围绕它触发的副作用。审计你的技术栈，查看键是在哪里生成的。如果它产生于重试循环内部而不是外部，你就不具备幂等性。你只是在进行一个会改变答案的重试，而你还没发现罢了。