核心要点
能说清为何特别需要：Agent 天然会重试失败步骤、从断点重放、多轮反复决策，同一写操作极易被执行多次，非幂等工具会造成副作用累积（重复扣款、重复下单、群发轰炸）
能给设计手段：为写操作引入幂等键/唯一请求 id 做服务端去重，让"执行两次等于执行一次"
能做前置防护：操作前先查状态（订单是否已存在、邮件是否已发），区分只读工具与写工具并对写操作加确认/人工兜底
能做事后补救：记录已执行动作避免重放，副作用已发生时用补偿事务（退款、撤单、发更正邮件）回滚而非假装无事
标准回答
为什么 Agent 对幂等性格外敏感
幂等性指"同一操作执行一次和多次效果相同"。普通服务也讲幂等，但 Agent 把风险放大了：它会在工具失败后自动重试，会在崩溃/中断后从断点重放，还会在多轮循环里反复决策同一类动作，加上模型本身有不确定性，可能误判"上一步没成功"而再做一遍。于是对非幂等的写操作——发邮件、下单、转账、调外部 API——一次"看似无害"的重试就可能变成重复扣款、重复下单、对客户群发轰炸。在自动化、少人盯的 Agent 场景里，这类副作用累积往往无声无息却代价高昂。
设计层：让重复执行天然安全
核心武器是幂等键 / 唯一请求 id：客户端为每个写操作生成稳定 id（基于业务语义而非随机，确保重试时复用同一个），服务端按此 id 去重——首次执行并记录结果，再次到来直接返回首次结果而不重复落地副作用。这要求接口和工具从设计上就支持幂等键（如 Stripe 的 Idempotency-Key），把"执行两次 = 执行一次"做进协议。
防护层：操作前查状态 + 读写分离 + 人工兜底
在调用前先查状态：下单前查是否已有同语义订单、发邮件前查是否已发送过，已完成就跳过。架构上区分只读工具与写工具——只读工具可放心自动重试，写工具走更严格的路径：高风险、不可逆的写操作（转账、删数据、对外发送）加确认环节或人在回路审批，由人或强校验把关后才真正落地。
补救层：记录动作防重放 + 补偿事务回滚
维护一份已执行动作记录（动作 id + 状态），重放/恢复时先查记录，已执行的跳过，从根上防止重复触发。万一副作用已经发生且确属错误，不能假装无事，要走补偿事务做语义回滚——转错了就发起退款、下错单就撤单、发错邮件就补发更正——以"反向操作"抵消已造成的影响。幂等键防的是重复，补偿事务兜的是已发生的错误，两者配合才让有副作用的 Agent 系统真正可靠。
常见误区
⚠️ 常见踩坑
最危险的误区是默认工具调用一定成功且只执行一次，从而对发邮件、下单、转账这类写操作不做任何去重——一旦 Agent 重试或重放就重复扣款、重复发送。另一个误区是用随机值当幂等键：重试时若生成新随机 id，服务端无法识别为同一请求，去重形同虚设，幂等键必须由业务语义决定、重试时复用同一个。还有人以为加了幂等键就万无一失，却忽略副作用已发生时需要补偿事务回滚，以及把高风险写操作和只读操作一视同仁地自动重试——正确做法是读写分离、写操作配确认与补偿。
追问
追问 1：幂等键应该怎么生成才可靠？
关键是"同一逻辑操作在重试时必须得到同一个键"。应基于业务语义派生，而不是每次随机生成——比如用 (用户 id + 业务动作 + 关键参数 + 时间窗) 做哈希，或在任务开始时就分配并随状态持久化，重试/重放时复用同一个键。服务端按键存储首次执行结果并设置合理过期，重复请求命中即返回原结果。切忌在重试路径里现生成 UUID，那会让每次重试都成为"新请求"，去重彻底失效。
追问 2：有些第三方工具本身不支持幂等，怎么补救？
在 Agent 与该工具之间加一层幂等代理/包装：自己维护 (幂等键 → 执行状态/结果) 的去重表，调用前先查表，已成功就直接返回缓存结果，不再真正调下游。对"先查后写"有竞态的场景用分布式锁或数据库唯一约束兜底（如对订单号建唯一索引，重复插入直接被拒）。若下游连查询是否已执行都不支持，就只能尽量把该动作设计成需人工确认的一次性操作，并辅以详尽日志便于事后核对与补偿。
追问 3：补偿事务和数据库事务回滚有什么区别？什么时候只能用补偿？
数据库事务回滚是在提交前撤销，依赖 ACID，作用范围限于单库且尚未对外可见。但 Agent 的副作用大多跨越外部系统、已经对外生效——邮件发出去了、款转出去了、第三方订单已创建，这些无法靠 ROLLBACK 撤销。此时只能用补偿事务：执行一个语义上相反的操作来抵消影响（退款冲销付款、撤单抵消下单、发更正函澄清错误邮件）。它是最终一致而非强一致，且补偿本身也可能失败，需要重试、幂等和人工兜底，常配合 Saga 模式管理这一串带补偿的长流程。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习