幂等（Idempotency）
先用一句话说清楚
幂等（Idempotency）是指同一个业务动作重复执行多次，最终结果仍然和执行一次一致，不会造成重复副作用。
实战知识卡
| 维度 | 要点 |
|---|---|
| 项目里看什么 | 看重复提交、重试和刷新页面是否会造成重复业务后果。 |
| 新手最该记住 | 幂等（Idempotency）是防止同一动作被执行多次。 |
| 作品集证据 | 展示同一个请求重复提交时不会重复建工单、扣费或发通知。 |
| 面试回答公式 | 先说哪些动作需要幂等，再说请求编号、状态检查和重复结果复用。 |
| 常见扣分点 | 工具失败就盲目重试，导致重复写入。 |
新手通俗解释
如果用户点了两次“创建工单”，系统不应该创建两个一模一样的工单。模型调用工具失败后重试，也不应该重复退款、重复发消息、重复提交审批。
幂等（Idempotency）就是用业务编号、状态检查、请求标识和重复提交控制，防止“同一件事被做两遍”。
为什么岗位会问它
Tool Calling（工具调用）会把 AI Agent（人工智能体）连接到真实业务动作。面试官问幂等（Idempotency），是在看你是否理解写入工具的副作用。
| 场景 | 幂等风险 |
|---|---|
| 创建工单 | 重复创建 |
| 发送通知 | 重复发送 |
| 提交审批 | 重复提交 |
| 扣减库存 | 重复扣减 |
| 退款申请 | 重复退款或重复申请 |
它在项目里怎么用
写入工具要设计幂等（Idempotency）字段或业务规则：
| 方法 | 作用 |
|---|---|
| 幂等键 | 同一请求重复提交时识别为同一动作 |
| 业务状态检查 | 已创建、已提交、已审批就不重复执行 |
| 去重规则 | 同一用户、同一订单、同一问题不重复建单 |
| 审计记录 | 记录重复请求和处理结果 |
| 用户确认 | 关键动作重复时提示用户确认 |
和重试的关系
没有幂等（Idempotency），重试会变危险。只读工具通常可以安全重试，写入工具必须先设计幂等或补偿机制，再考虑自动重试。
常见误解
| 误解 | 为什么不对 | 正确理解 |
|---|---|---|
| 幂等（Idempotency）只是后端细节 | Agent（智能体）工具调用最容易重复触发 | 面试要能主动讲 |
| 只读和写入一样处理 | 写入有副作用 | 写入工具必须重点控制 |
| 前端按钮禁用就够了 | 网络重试和模型重试仍可能发生 | 后端要保证幂等 |
| 重试次数少就没事 | 一次重复也可能造成损失 | 关键动作要严格控制 |
面试官可能怎么追问
1. 为什么工具调用需要幂等？
考察点： 是否理解副作用。
参考回答： 因为工具调用可能因为网络超时、模型重试、用户重复点击或任务恢复而重复执行。只读工具影响小，写入工具可能重复创建工单、发送通知或提交审批，所以要用幂等键、状态检查和审计记录控制。
容易扣分： 说“失败就重试”。
2. 如何设计创建工单的幂等？
考察点： 是否能落到业务。
参考回答： 可以用用户 ID（编号）、业务对象、问题类型和时间窗口生成幂等键。提交前先查是否已有未关闭工单，已有则返回原工单；没有才创建。每次重复请求都记录审计（Audit）。
容易扣分： 完全依赖前端防重复点击。
作品集里怎么展示它
- 在写入工具说明里写幂等策略。
- 展示重复提交样例。
- 展示重复提交不会产生两条业务记录。
- 展示审计（Audit）里如何记录重复请求。