AI 工作流失败后怎样重试，才能避免重复处理？

超时不一定意味着没有执行

外部系统可能已经保存结果，只是响应没有及时返回。如果直接再次创建，可能产生重复记录。因此失败状态应区分明确失败、尚未执行和结果未知。

对于结果未知的动作，先根据业务标识查询目标系统。无法确认时交给维护人员处理，并向使用者说明正在核对，而不是把“请求已发出”显示为“业务已完成”。

将去重依据放在业务层

同一封来信、同一条申请或同一笔任务应有可追踪标识。接收事件时记录是否已处理，关键写入如果支持幂等机制，应按接口说明使用；不支持时需设计额外核对。

重试次数、间隔和停止条件应有界限。权限错误、字段无效和资料缺失通常不能靠反复调用解决，应转到修正输入或人工处理。

只恢复尚未完成的部分

保存关键步骤的状态，可以在恢复时跳过已经完成的动作。若某步需要撤回或补偿，先明确业务允许的处理方式，不假定所有外部操作都可以自动回滚。

用重复事件、网络超时和部分完成的样例验证流程。检查既没有遗漏待办，也没有重复发送或写入。可靠性来自对失败结果的处理，不只是正常路径运行成功。

业务标识和一次请求的标识不要混用

同一业务事项可能发起多次请求。请求标识用于追踪一次通信，业务标识用于判断是否属于同一封邮件、申请或订单处理。若每次重试都生成一个全新的业务标识，下游就难以识别重复。具体去重键应依据业务对象和接口约定设计。

保存去重结果时，还要记录处理状态与目标记录标识。仅记一个“见过此请求”，可能让中途失败的事项永远无法恢复；完全不记录则可能重复执行。并发进入的相同事项需要在持久存储层协调，不能只依赖某个进程里的临时变量。

不同失败应进入不同的处理分支

字段错误应返回修正输入，权限不足应交给账号或业务负责人，临时连接错误才可能适合有限重试。服务要求等待时按其规则处理，并为重试总时长设置上限。自动恢复结束后，仍应让维护者看见最终结果。

用“目标已保存但响应丢失”的场景测试最容易暴露重复问题。模拟后先按业务标识查找，再决定是否继续创建。无法确定时标记待核查，不要为了让流程显示绿色而直接重复发出有业务影响的动作。

先查目标结果，再决定是否重试

模拟发送超时，先按业务标识查询目标系统是否已生成结果。将已完成、未完成和结果未知分别处理，只恢复需要补做的部分；重复通知等不可撤销动作须有人工核对去向。