一句话定义：同一个操作执行一次和执行多次，对系统状态造成的影响完全相同——这个操作就是幂等的。
先看一个生活例子
按电梯按钮。按一次电梯来，你着急连按十下，来的还是同一趟电梯。按钮是幂等的。
转账不是。转一次扣 100 元，手抖点两次就扣 200 元。所以银行 App 里点完转账会转圈，你也不敢再点。
这两件事的差别，就是幂等和不幂等。查询、读取天然幂等；创建订单、扣款、发消息天然不幂等。
怎么把不幂等的操作变幂等
常见三招：
幂等键（Idempotency Key）。 客户端为这次操作生成一个唯一 ID，重复请求带同一个 ID。服务端记住"这个 ID 我处理过了"，第二次直接返回上次的结果，不再真正执行。这是支付、下单最常用的做法。
状态机 + 条件更新。 只有订单处于"待支付"才扣款；重复请求进来时状态已经是"已支付"，直接跳过。
用赋值代替累加。 "把余额设为 500"重复多少次都一样；"余额加 100"重复两次就错了。写代码时能写成前者就别写后者。
和相邻概念的区别
| 概念 | 说的到底是什么 |
|---|---|
| 幂等性 | 重复执行不产生额外副作用，是性质 |
| 重试（Retry） | 失败后再试一次，是行为；安全的前提是有幂等性 |
| 去重（Dedup） | 识别并丢弃重复请求，是手段 |
| 原子性（Atomicity） | 要么全做要么全不做，和"做多次等于做一次"不是一回事 |
| 恰好一次（Exactly-once） | 分布式系统里很难真做到，通常用"至少一次 + 幂等"逼近 |
为什么 Agent 从业者必须在意它
Agent 调用工具时几乎一定会遇到失败：网络超时、模型推理中断、进程重启。最麻烦的是——你分不清那次调用是"根本没执行"，还是"执行成功了但响应在路上丢了"。
此时唯一可行的动作就是重试。而重试会不会把事搞砸，完全取决于工具是否幂等。
- 读类工具（查天气、搜文档、读数据库）：放心重试。
- 写类工具（发邮件、下单、调外部 API 扣费）：必须带幂等键，或者把副作用设计成可确认、可撤销的。
- 断点续跑（resume）能不能做，本质也在这里：重放已完成步骤时，如果每一步都幂等，重放就是安全的；如果不幂等，重放一次就等于多干一次坏事。
一条给团队的建议
给每个工具明确定义"重复调用会发生什么"，并写进工具描述里，让模型知道哪些能放心重试、哪些必须谨慎。实现细节各平台差异不小，具体以官方文档为准。