AI 操作业务系统时，应给每次已经确认的业务动作分配稳定编号，并约定重复请求、内容变更和撤销的处理规则。员工连点按钮、发送“再试一次”或网络中断，都不应成为重复建单的理由。
这项设计适用于采购申请、库存预留、任务派发等会改变业务记录的工作。单纯查询无需套用整套撤销流程；涉及多个系统时，则需要逐步列出已发生的动作和可恢复条件。
一次业务动作的识别规则
建议用组织、任务编号、动作步骤和参数版本共同标识一次业务动作。系统保留该编号对应的关键内容，例如物料、数量、仓库与目标单据，重复请求到来时先比较内容。
同一编号与相同内容返回原处理记录；同一编号却带来不同数量，应提示内容冲突，不能直接覆盖。用户明确提出追加一批时，再生成新动作，防止把两笔合法业务误合为一笔。
| 请求情况 | 预期处理 | 留下的业务记录 |
|---|---|---|
| 同一动作被连续提交 | 返回同一处理进度或结果 | 原动作编号与重复请求时间 |
| 原动作仍在执行 | 等待原动作结果 | 当前步骤与受理记录 |
| 同一编号但数量变化 | 暂停并确认新版本 | 新旧数量、变更原因 |
| 明确要求再订一批 | 创建新的业务动作 | 新动作与原单关系 |
| 提交中断、结果未知 | 查询原动作，暂不另建 | 外部单号或待核对状态 |
动作登记与并发控制也要由后台统一负责。同一编号的登记必须一次完成并具有唯一约束，让同时到达的请求中只有一个能取得执行资格；仅仅先查有没有、再创建，仍可能重复。不能只依赖页面按钮变灰，因为同一任务还可能从聊天、其他页面或恢复流程再次发起。若目标系统无法按动作编号识别重复提交，需要明确降低哪些动作的自动执行范围。
防重记录的保留范围
防重记录应至少覆盖任务可能重放的业务期间，并与正式单据建立持久关联。清理运行日志时，不要连带删掉仍有用的动作与单据关系，否则历史请求再次到来时就无法判断。
对于由任务分出的多步动作，要分别登记。例如一项备货任务含预留物料、创建领料单、通知班组，三步使用各自的动作编号，并关联同一个任务。重发通知不应顺带重建领料单。
需要特别处理人员同时操作的情况：员工已经手工完成建单后，Agent 恢复执行，应先检查是否存在对应业务记录。仅靠 Agent 自己的动作日志无法识别这类手工结果。可在单据中保留来源任务编号，或约定能唯一定位的业务组合；无法判断时，向员工展示候选单据供确认，不能用名称相似直接认定重复。
提交结果的查询方式可参考Agent 写后回读设计。这里还要补上并发样本：两个入口同时提交同一动作，检查最终是否只有一条有效业务记录。
撤销与纠正的区别
页面上的“撤销”应对应具体业务动作。尚未提交的任务可以取消执行；已经生成的草稿是否可作废，由原系统状态决定；已经领走的物料，则需要通过退料等正式流程处理。
不要把恢复理解成直接把数据库字段改回原值。后续人员可能已经处理过这张单，直接恢复旧值会覆盖新的事实。撤销前应重新检查当前状态，并说明拟释放的数量、拟作废的单据和无法收回的影响。
建议在动作清单中增加三列：可撤销条件、纠正动作、处理责任人。无法提供纠正方式的动作，应在开放前由业务负责人明确其执行边界。
示例：预留成功但领料单创建失败
以下为设计示例：Agent 根据生产任务预留一批物料，随后创建领料单时发现领料部门缺失。此时预留已存在，领料单尚未生成，整个任务应显示“待补部门”，同时列出预留编号与数量。
补齐部门后，只继续建领料单，不再追加一次预留。若生产负责人决定取消任务，先查看预留是否仍未被领用，再发起释放预留的动作。释放也保留自己的编号，并关联原预留记录。
如果部分物料已经领走，任务应列明已领与未领数量。未领部分按规则释放，已领部分转交退料处理；不能把原任务简单改成“已撤销”并从列表消失。
异常恢复的验收表
测试应覆盖连续点击、两个入口并发、响应丢失、相同编号换参数、单据已被人工修改以及部分完成后取消。每个样本记录预期单据数、允许的状态变化和最终需要保留的关联。
人工接管时提供具体可选动作，例如补部门继续、取消并释放预留、转退料处理。员工完成处理后保留纠正记录，原动作历史仍可查。异常的责任与流转可结合Agent 异常队列设计一起安排。
需要接入真实 ERP 或项目系统时，可在企业 AI 落地方案中逐项列出防重依据和恢复条件，再确定哪些操作开放给 Agent。
