什么是幂等重试？重复请求不出错

大模型服务里，同一个请求发两遍，结果和发一遍完全一样，这个特性叫幂等。超时控制掐断的请求、客户端抖动的重发、重试机制的自动补刀，都可能让同一个请求被送出多次，幂等设计保证这些重复不会变成重复的扣费、重复的写入、重复的推送，它是重试敢放手用的前提。

重复发也不双倍算

幂等的关键是为每个请求发一张“身份证”。客户端生成唯一标识，服务端凭标识去重：头一回见到，正常处理；标识已见过，直接返回之前的结果，不再执行第二遍。对查询类请求天然幂等，问一百遍答案还是那个答案；对有副作用的动作，这张身份证是刚需。

落到计费和配额上，幂等的价值最直观。生成任务失败后客户端自动重试，没有幂等保护，同一次生成可能被记成两笔，用户平白多付；有幂等保护，重复请求被识别、被合并，账才算得清。这也是长任务场景下用户投诉“莫名多扣”的常见根因之一。

像电梯按钮按多次

理解幂等，可以类比电梯按钮按多次。赶时间的人对着关门键连按三下，电梯不会因此关三次门、多走一层——按一次和按十次，系统响应完全一致。幂等设计就是给系统装这样的“去躁”逻辑：动作到过一次，重复的手势不再产生新后果。

电梯类比还解释了为什么查询天然安全。你反复问电梯“到几楼了”，答案不会因为你问了三遍就变成三个；查询类请求不改变任何状态，重复多少次，世界还是那个世界。真正需要设计保护的是“会改变世界”的那类请求。

按钮类比的两处偏差

这个类比有两处对不上。其一，电梯按钮的防抖是本地逻辑，AI 服务的幂等要跨设备、跨网络生效，客户端重发时标识必须带得上，丢了标识，服务端也无从去重。其二，电梯的响应是即时的，AI 的请求可能跨节点、跨较长时间，首次请求还没处理完，重复请求就到了，服务端要能区分“进行中”和“已完成”两种已见状态。

还有一处工程细节：标识不能由服务端生成。服务端为每个收到的请求现发一个编号，重复请求拿到的是不同编号，去重就失效了。身份证必须客户端带进来，这是幂等设计里最容易踩的坑。

不幂等的重试有多险

缺少幂等保护时，重试机制等于把故障放大。网络超时引发重试，服务端其实已经处理完旧请求，两边一对账，用户看到的是重复的生成记录、翻倍的资源消耗。极端情况下，一次大范围超时足以让重试流量把服务再次压垮，服务降级都来不及生效。对个人开发者来说，接入任何带副作用的接口前，先问清楚幂等参数怎么传，能避开大部分重复扣费的坑，这一条值得写进接入清单。

智谱清言和纳米AI在开放接口文档里都强调过幂等参数的作用，这是开发者接入时的必修课。带走一个判断：幂等是重试的安全带，没有它，越是自动化的系统，越容易在故障时刻自伤；看到“重复请求”四个字，先问标识怎么带。

速查表：幂等=重复请求结果一致；靠客户端生成的唯一标识去重；类比电梯按钮按多次；标识丢了去重即失效；查询天然幂等、写入类必须设计。

聊聊幂等重试的常见疑问

• 幂等和防重提交是一回事吗？目标一致，做法同源，都是靠唯一标识拦下重复动作。
• 为什么有时重复请求还是被执行了？标识没带上、过了去重有效期，或服务端只缓存了短时间记录。
• 普通用户能感知到幂等吗？能，故障恢复后账单和记录是否干净，就是幂等是否到位的直观体现。