# 跨系统工作流失败以后，如何恢复业务一致性 区分重试、撤销和补偿，处理 AI 自动化跨系统执行中的部分成功与异常恢复。 要点：跨系统工作流可能只完成一部分动作。恢复前应查清已经发生的业务事实，再决定重试、撤销或补偿。补偿是一项新的业务动作，需要明确条件和记录，不能假设所有操作都能回到执行前。 ![在班次交接时核对资料与未完成事项（AI概念配图）](/images/unique-scenes/efficiency-handover.png) ## 失败不一定意味着什么都没有发生 设想工作流先创建内部记录，再发送外部通知。第二步失败时，内部记录已经存在；若从头重跑，可能造成重复记录。系统需要保留每一步的结果标识，并能查询真实状态。 网络超时尤其需要谨慎区分：没有收到响应，与对方没有执行，是两件不同的事。恢复逻辑应先查证，避免把通信不确定性转化为业务重复。 ## 重试、撤销和补偿承担不同职责 重试是再次尝试未完成动作，适合明确可重复且满足幂等条件的步骤；撤销要求原动作确实支持回退；补偿则是在已经发生的事实基础上，执行一个经过定义的后续处理。 例如，已经发出的通知不能当作从未被阅读。即使可以删除本地记录，也可能需要发送更正说明。恢复方案应尊重业务事实，而不是只让数据库看起来恢复原状。 | 恢复方式 | 需要先确认 | | --- | --- | | 重试 | 原动作是否已生效、是否可重复 | | 撤销 | 系统与业务是否允许回退 | | 补偿 | 新的处理动作由谁授权 | | 人工接手 | 哪些事实与材料需要交接 | ## 在上线前定义失败后的责任 为影响较大的步骤记录成功证据、可能失败位置和恢复负责人。对难以自动处理的情况，预先设计人工入口，比发生异常后临时猜测更可靠。 测试可以故意让中间步骤失败，检查系统是否能够准确呈现部分完成状态，以及恢复后有没有重复或遗漏。测试结果应覆盖业务后果，而不只是异常被捕获。 ## 自动化不应抹去已经发生的事情 企业系统之间很难保证所有动作同时成功。承认这种现实，才能设计可持续的流程。清楚记录并修复差异，比把复杂性藏在一个“重新执行”按钮后面更有价值。 未来 AI 可以帮助分析异常和提出恢复建议，但重要恢复动作仍应经过业务规则与权限检查。让机器协助理解局面，不等于让它自行决定所有后果。 ## 先确认部分完成，再授权补偿 模拟内部记录已建但通知未确认的情况，分别列出可重试、可撤销和需新补偿的动作。已发送内容不能假装从未发生；重要恢复操作按企业授权执行，并保留结果与人工接手记录。 ## 参考来源 - [n8n Docs｜调试执行记录](https://docs.n8n.io/build/understand-workflows/understand-executions/debug-executions)：利用已有执行数据定位问题 - [n8n Docs｜Webhook](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook)：事件接收与测试、生产入口区别 ## 先查证，再恢复 - 确认事实：哪些动作已经生效 - 选择方式：重试、撤销或补偿 - 验证一致：没有重复、遗漏或失联 ![先查证，再恢复](/images/guides/diagrams/workflow-compensation.svg) ## 继续阅读 - [AI 工作流失败后怎样重试，才能避免重复处理？](/guides/workflow-retries) - [AI 工作流的状态管理：不要让“正在处理”成为终点](/guides/ai-workflow-state) - [AI 如何连接已有 CRM、ERP 和业务系统？先确认数据归属](/guides/system-integration) 明确授权、处理位置与双方责任；部署、接口、定制及代运维另列技术实施。 下一步：[核对数据与合作边界](/data-boundary) 原文：/guides/workflow-compensation 内容版本：guide:workflow-compensation:v1 [结合企业情况咨询](/intake?source=%2Fguides%2Fworkflow-compensation&articleId=guide%3Aworkflow-compensation&versionId=guide%3Aworkflow-compensation%3Av1)