查询可以再来一次，写入系统却不能想当然地重试
员工让 AI 根据客户邮件创建售后工单。接口返回超时，系统没有拿到成功结果，于是自动重试。事实上第一张工单已经建立，第二次请求又建了一张。两个客服同时跟进，客户收到两条通知，后来才发现根源不是员工操作，而是一次看似正常的重试。
AI Agent 连接业务系统后，风险与普通问答不同。读取库存失败可以再查一次，创建订单、发送优惠券、修改客户状态和发外部消息一旦执行两遍，就会产生真实后果。自动化设计必须区分“可以重复查询”和“只能成功一次”的动作。
先给每个业务动作一个唯一身份
每次执行应生成唯一任务号，并与原始请求、客户、业务对象和动作类型绑定。再次收到相同任务时，系统先查询是否已经执行，而不是直接再做一遍。业务系统如果支持幂等键，应把唯一任务号传入接口；不支持时，也要在中间层保存执行状态。
唯一编号不能只用当前时间临时拼接，否则员工重复点击仍会生成新任务。要根据业务含义识别同一件事，例如同一客户、同一邮件、同一服务请求在限定时间内只允许创建一个主工单。确有必要重开时，由员工明确发起新动作。
- 请求进入时生成可追踪的唯一任务号。
- 写入前核对业务对象是否已有成功记录。
- 重复请求返回原结果，不重新执行动作。
状态不要只分成功和失败，中间态最需要说明
接口超时不等于业务失败。任务至少应区分待执行、执行中、已成功、明确失败和结果未知。遇到结果未知时，先查询下游系统或进入人工核对，不能立刻把同一动作再发送一次。
员工页面也要显示状态。按钮点击后给出任务编号和处理进度，避免因为页面没有反馈而连续点击。若系统阻止重复提交，应告诉员工原任务在哪里，而不是只弹出“操作失败”，否则人会换一个入口继续尝试。
自动补偿也要谨慎，撤销并不总能恢复原状
有些团队认为做错了再自动撤回即可，但外部消息已经被客户看到、库存已经被其他订单占用、审批状态已经触发后续动作，撤销并不能抹去影响。高风险动作应该在执行前确认，而不是依赖事后补偿。
可以把低风险、可逆动作交给系统自动处理，把金额、合同、客户承诺和大批量修改设为人工确认。失败后自动生成待办，附上原请求、已完成步骤和建议处理方式，让人接手时不用重新猜测发生了什么。
真正可靠的 Agent，不是跑得快，而是每一步都能收住
上线前用断网、超时、重复点击、接口慢响应和系统重启做演练，观察会不会重复建单、漏写状态或误报失败。上线后统计重复拦截次数和结果未知任务，它们能暴露接口与流程的薄弱位置。
企业 AI 自动化的价值在于减少重复劳动，但不能制造新的重复业务。把唯一任务、状态校验、人工确认和异常队列做好，Agent 才能从会调用工具，走到可以承担实际流程。
要点总结
- 简单说，同一个业务请求重复提交多次，最终只产生一次有效结果。
- 查询类影响较小，建单、付款、发券、改状态和外部通知等写入动作必须重点处理。
- 应先判断是否可重复，并查询原动作状态；结果未知的写入动作不宜直接重试。
参考来源说明
本文围绕“AI Agent 重试一次，为什么生成了两张工单？自动执行先解决重复操作”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。