流程显示失败，客户却已经收到通知
一个售后 Agent 需要先读取订单、创建工单、发送确认邮件，再给客服群推送提醒。某天工单接口超时，系统把整个任务标成失败并自动重试。第一次执行其实已经发出邮件，第二次又发一封；工单仍未创建，客户却收到两次“我们已受理”的承诺。
跨系统自动化很难像数据库操作那样整体回滚。邮件发出去无法真正收回，外部平台的记录也可能已经被其他人使用。真正需要设计的不是一个笼统的成功或失败，而是每一步做到了哪里、哪些动作还能重试、哪些必须补偿。
先画出不可逆动作，再决定执行顺序
流程设计时，把读取、内部写入、外部通知、付款、发货等步骤分别标记。能安全撤销或重复的动作可以靠前，难以撤销的动作尽量放在必要条件全部满足之后。例如先创建工单并取得编号，再发送包含编号的客户通知。
有些业务无法等到所有步骤完成才通知，就要在文案中使用准确状态，比如“已收到申请，正在创建工单”，而不是提前承诺“工单已经建立”。流程语言也属于技术控制的一部分，能减少半成功时的业务误解。
- 标记每一步是否可重试、可撤销和有外部副作用。
- 不可逆动作尽量放在关键写入成功之后。
- 通知文案与流程真实状态保持一致。
补偿不等于假装从未发生，而是把业务恢复到可接受状态
邮件无法收回时，补偿动作可能是发送更正通知；库存已经预占但订单失败，可以释放库存；客户标签改错，可以根据原值恢复。每个高影响动作都要预先定义对应补偿、执行条件和负责人。
补偿本身也可能失败，所以要有状态记录和人工队列。系统不能无限自动尝试，更不能在不知道当前状态时重复执行。超过次数或时间阈值后，把完整上下文交给值班人员处理。
流程状态要比“成功、失败”更细
实用状态可以包括待执行、执行中、部分完成、等待重试、等待补偿、人工处理中和已关闭。每一步保存外部系统返回的业务编号、时间和结果，重试前先确认动作是否其实已经成功，只是响应丢失。
这也要求接口支持幂等标识。同一个业务任务无论重试多少次，都能识别为同一请求，不重复创建工单或扣减库存。状态机、幂等和补偿是一起工作的，缺少其中任何一项，异常处理都会变成猜测。
上线前专门测试中间失败，不要只测顺利走通
测试时人为让第二步、第三步和最后一步分别超时或返回错误，观察系统是否重复动作、状态是否清楚、补偿是否生效、人工能否接手。还要测试外部系统实际成功但响应超时这种最容易误判的情况。
企业 AI 自动化的可靠性，不是看正常流程跑得多漂亮，而是事情做到一半时能不能有序收场。把部分失败当成必然会发生的运行状态，团队才不会在真实客户面前第一次学习怎么补救。
要点总结
- 不是。补偿通常是新的业务动作，用来抵消或修正已经发生的影响，不一定能恢复到完全未发生。
- 不够。还要确认动作是否幂等、外部是否已成功，并为不可逆步骤准备补偿和人工处理。
- 外发通知、付款、库存、订单、客户资料修改等会产生外部影响或难以撤销的动作。
参考来源说明
本文围绕“邮件发出去了，工单却没建成功：企业 AI 流程要为“半成功”准备补偿动作”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。