OpenClaw 工作流上线后，团队一定会遇到执行错误。真正决定损失大小的，不是有没有错误，而是出错后能不能快速停住、退回、接管和复盘。回滚方案如果上线前没写好，事故发生时就只能临时救火。
回滚方案可以和 责任边界、责任矩阵、事故复盘 连起来。准入时检查有没有回滚，责任矩阵指定谁处理，事故复盘再更新下一版规则。
先给动作分级
不是所有动作都需要同样的回滚。读取资料和生成草稿通常影响较小；写入系统、发送外部通知、修改客户状态、变更权限就要更严格。动作级别不同，回滚策略也不同。
建议把动作分成三类：可重试动作、可撤销动作、不可直接撤销动作。可重试动作关注幂等，可撤销动作关注恢复记录，不可直接撤销动作必须有人工确认和外部补救路径。
写入动作要保留前后状态
只要 Agent 会写入系统，就要记录写入前状态、写入后状态、写入时间、触发任务和执行人或执行 Agent。没有前后状态，回滚时就不知道该恢复到哪里。
这部分可以复用 运行日志 的思路。日志不是为了好看，而是为了在出错时能支撑恢复和追责。
外部通知不能假装可撤回
邮件、短信、客户通知、群消息这类外部通知，很多时候不能真正回滚。即使系统支持撤回，对方也可能已经看见。因此通知类动作的重点不是事后撤销，而是事前确认和事后补救。
高风险通知应该进入人工确认；发错以后要有补充说明、客户解释和内部记录。把通知当作普通写入动作处理，会低估它的外部影响。
权限变更要有快速冻结路径
权限动作出错时，最先要做的往往不是恢复原状态，而是冻结风险。比如错误开放了资料访问，先暂停对应权限或停用工作流，再核对影响范围。
这里可以接上 OpenClaw 权限复核清单。权限变更越敏感，越应该有审批、日志和定期复核。
总结
OpenClaw 回滚方案的核心，是按动作类型分级。写入动作看前后状态，外部通知看确认和补救，权限变更看冻结和复核。回滚方案提前写清楚，Agent 工作流才敢进入真实业务。
