回滚要区分可逆操作与业务补偿

回滚设计中最常见的误区，是把“回滚”当作一种万能撤销机制，认为只要在流程里预留了回退入口，任何异常都能恢复到执行前的状态。但真实业务里，回滚的可行性取决于操作本身的属性：有些操作可以被完整撤销，有些操作一旦发生就产生不可逆的外部影响，只能靠后续动作去弥补损失。两者在故障处理中的定位完全不同，混为一谈往往会导致补救方案失效。

可逆操作的特征在于，系统内部状态的变化可以被事务机制完整还原。典型如数据库写入、库存预占、状态字段更新，这类操作依赖本地事务日志，回滚时能够把数据恢复到操作前的快照，业务不会留下残留痕迹。补偿操作则针对另一类场景：动作已经对外部系统或真实世界产生了影响，例如邮件已经发出、订单已经通知客户、生产指令已经下达。此时没有“撤销”可言，只能通过一个反向业务动作去抵消或缓解后果，比如发送撤回通知、创建冲正记录、向供应链同步变更。两者的本质区别在于，前者恢复的是数据一致性，后者修复的是业务后果。

这一区分直接决定了故障预案的设计方式。对于可逆操作，回滚路径相对简单，重点是保证事务边界清晰、回滚逻辑经过验证。对于不可逆操作，核心问题变成“补偿步骤是否完备、由谁触发、在什么时机执行”。智能体工作流中常见的风险，是把所有异常都交给同一个回滚流程处理，结果遇到不可逆动作时，系统尝试“撤销”却根本无从下手，最终只能停留在报错状态。正确做法是在流程设计阶段，就对每个高风险节点标注其回滚类型：走事务回滚，还是走业务补偿，两者需要不同的实现和不同的审批策略。

审批闸口的设计也应与操作可逆性挂钩。低风险可逆动作可以放行，事后发现问题再回滚；高风险不可逆动作则必须在执行前阻塞，等待人工确认。原因很直接：可逆动作允许“先执行后校验”，因为出错代价可控；不可逆动作一旦放行，后续补偿再完善，也已经造成了对外影响。把审批资源集中在不可逆操作上，比对所有动作一刀切地设置审批，既提升效率，也更贴合风险分布。

补偿步骤本身也需要被纳入异常升级机制。当智能体触发熔断或人工拒绝审批时，系统不仅应暂停当前流程，还应明确列出哪些已执行动作需要补偿、补偿动作是否已自动触发、哪些补偿仍等待人工确认。否则在故障处置时，操作员面对一堆状态变更，很难快速判断当前业务到底处于什么位置。审计日志同样要覆盖补偿链路，记录每个不可逆动作的触发时间、影响范围、补偿执行情况和最终结果，供事后复盘时还原完整因果链。

回滚不是一种操作，而是一套针对操作属性的分类处置策略。可逆的走事务，不可逆的走补偿，审批闸口按风险分级设置，补偿结果纳入监控与审计。只有先把每个动作的回滚类型定义清楚，后续的暂停、审批、熔断和升级机制才有可靠的落点。