跨系统工作流失败以后，如何恢复业务一致性

失败不一定意味着什么都没有发生

设想工作流先创建内部记录，再发送外部通知。第二步失败时，内部记录已经存在；若从头重跑，可能造成重复记录。系统需要保留每一步的结果标识，并能查询真实状态。

网络超时尤其需要谨慎区分：没有收到响应，与对方没有执行，是两件不同的事。恢复逻辑应先查证，避免把通信不确定性转化为业务重复。

重试、撤销和补偿承担不同职责

重试是再次尝试未完成动作，适合明确可重复且满足幂等条件的步骤；撤销要求原动作确实支持回退；补偿则是在已经发生的事实基础上，执行一个经过定义的后续处理。

例如，已经发出的通知不能当作从未被阅读。即使可以删除本地记录，也可能需要发送更正说明。恢复方案应尊重业务事实，而不是只让数据库看起来恢复原状。

在上线前定义失败后的责任

为影响较大的步骤记录成功证据、可能失败位置和恢复负责人。对难以自动处理的情况，预先设计人工入口，比发生异常后临时猜测更可靠。

测试可以故意让中间步骤失败，检查系统是否能够准确呈现部分完成状态，以及恢复后有没有重复或遗漏。测试结果应覆盖业务后果，而不只是异常被捕获。

自动化不应抹去已经发生的事情

企业系统之间很难保证所有动作同时成功。承认这种现实，才能设计可持续的流程。清楚记录并修复差异，比把复杂性藏在一个“重新执行”按钮后面更有价值。

未来 AI 可以帮助分析异常和提出恢复建议，但重要恢复动作仍应经过业务规则与权限检查。让机器协助理解局面，不等于让它自行决定所有后果。

先确认部分完成，再授权补偿

模拟内部记录已建但通知未确认的情况，分别列出可重试、可撤销和需新补偿的动作。已发送内容不能假装从未发生；重要恢复操作按企业授权执行，并保留结果与人工接手记录。