同一请求来了两遍，如何避免生成两份文档？
避免同一请求生成两份文档，需要为一次业务意图建立稳定身份，并由执行层识别重复请求。只在提示词里要求 Agent“不要重复”，无法解决网络重试、进程重启或用户双击带来的重复创建。
幂等键代表一次意图，不代表一次网络发送
例如用户要求生成“十月经营简报”，第一次请求在返回途中断开。再次发送应沿用同一操作键，才能查询或复用原结果。如果每次重试都生成新键，服务端看到的就是两次独立创建。另一方面，用户明确要求另做一份不同版本，也不能机械沿用旧键。
Stripe 的幂等请求文档给出了一个可参考的实现：以键关联请求结果，并比较重试参数。其具体保存时长和 API 版本行为属于 Stripe 自身契约，不应直接当成文档产品的默认规则。企业文档适配层需要定义自己的作用域、有效期和参数一致性检查。
把请求指纹和结果一起保存
| 记录 | 用途 |
|---|---|
| 操作键 | 识别同一次业务意图 |
| 请求指纹 | 发现同键但内容不同的请求 |
| 执行状态 | 区分未开始、执行中和已确认 |
| 文档 ID | 定位首次创建的实际产物 |
请求指纹应覆盖影响结果的字段，例如模板版本、输入资料集合、目标目录和生成选项。不要把密钥或完整私人内容直接塞进操作键。若同一键带着不同输入到达，应该报告冲突，由调用方核对意图，而不是静默返回旧文档或创建新文档。
并发重复比串行重试更容易漏测
两个请求几乎同时到达时，都可能先查到“没有记录”，再各自创建一个文件。因此“先查有没有，再创建”不等于已经实现幂等。需要服务端已有的原子机制，或经过验证的唯一约束与状态转换，将首次执行权和结果关联起来。不能用普通读写表格冒充原子锁。
若目标系统本身没有幂等创建接口，适配层应说明能力边界。可以通过外部操作台账和产物标记降低重复概率，并在不确定时先对账；但不能承诺任何故障下都只执行一次。请求接受、文件创建、台账更新之间的失败窗口需要专门测试。
用故障演练验收
至少检查重复发送、并发发送、响应丢失、客户端重启和同键参数变化。每次查看实际文档数量、稳定文档 ID 和台账，而不是只看调用返回码。成功标准应是重复请求收敛到同一结果，或在无法确认时明确停在待对账状态。
在企业文档自动化中，幂等是执行系统的责任。Agent 可以正确携带操作键、读回结果并避免盲重试，但最终保证来自真实接口和存储约束，不能由模型的自我承诺代替。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。