OpenClaw 工作流一旦接入真实业务，回滚预案就不能等事故发生后再写。提示词改坏、工具返回异常、外部写入错字段、连接器权限配置错，都可能让自动化从“节省时间”变成“扩大问题”。
回滚预案不是一句“必要时恢复旧版本”。它要写清楚什么情况触发回滚，能回滚哪些部分，数据怎么恢复，谁先收到通知，回滚后怎么复盘。它应该和 灰度发布、回放验收、审计日志 放在一条链路里。
先写触发条件
回滚触发条件要具体。比如关键任务失败率超过阈值、外部写入错误、客户可见内容异常、费用突然上升、同类告警连续出现、人工复核判定为高风险。不要只写“出现严重问题”。
触发条件越清楚，值班人员越容易做决定。否则每次事故都要先争论算不算严重，真正的问题反而继续扩大。
确认哪些内容能回滚
不是所有动作都能简单回滚。提示词、工具版本、路由规则和知识库版本通常比较容易回退；已经发出的邮件、写入的客户承诺、导出的文件和被修改的数据，则可能需要补救而不是回滚。
预案里要把可回滚范围写清楚。对不可直接回滚的动作，要写补偿步骤，比如撤回通知、创建更正工单、冻结后续自动执行、通知客户成功跟进。
数据恢复要有证据
数据恢复不能只靠“找一份旧数据”。需要知道事故发生前的状态、被修改的对象、修改字段、修改时间、执行身份和原始输入。没有这些信息，恢复就可能造成二次错误。
这也是为什么 审计日志字段 不能只记成功或失败。输入摘要、动作、证据来源、工具版本和人工修改，都是未来恢复现场的依据。
通知顺序要提前排好
事故发生时，通知顺序很重要。先通知值班负责人和系统负责人，确认是否暂停自动化；再通知受影响业务负责人；如果客户可见，再准备对外说明。所有人同时收到模糊告警，反而容易混乱。
这一步可以接上 告警降噪。高风险事件需要即时通知，低风险事件可以进入日报，但回滚触发类事件必须有明确升级路径。
预案需要演练
没演练过的回滚预案，往往只是文档。建议用旧事故样本或测试工作流跑一遍：能不能找到版本，能不能暂停任务，能不能恢复数据，通知是否能到负责人手里。
演练结果要进入复盘，补充缺失字段和责任人。回滚预案不是写完就结束，而是随着工作流变化持续更新。
总结
OpenClaw 回滚预案的重点，是把触发条件、可回滚范围、数据恢复、暂停动作、通知顺序和演练复盘提前写清楚。事故现场越少临时决策，工作流恢复越稳。
