Agent 操作失败后，撤销和补偿为什么不能混用
文档 Agent 的失败恢复，应先区分撤销与补偿。撤销通常依赖某个编辑器或事务提供的回退能力；补偿则是在已经发生的结果上，再执行一组业务动作，使流程回到可接受的状态。两者不能用同一个“全部恢复”按钮含糊表示。
先画出已经发生的动作
假设一次任务创建了项目报告、生成附件、更新业务台账，最后一步失败。此时报告和附件可能已经被其他人打开，台账却仍指向旧版本。直接删除前面所有产物，可能让已有引用失效；恢复整份旧台账，又可能覆盖别人在此期间新增的数据。
微软的补偿事务模式强调，补偿与业务有关，不一定按原步骤的相反顺序执行，也不一定恢复到操作之前完全相同的状态。对文档工作流而言，更实际的目标可能是标记这批材料暂不可用、保留原始成果并修正台账关联，而不是抹掉全部历史。
给每个动作定义恢复边界
| 已发生的动作 | 可考虑的恢复方式 |
|---|---|
| 创建了未交付草稿 | 标记废弃或移入隔离位置 |
| 更新了业务记录 | 按记录版本撤回本次字段变化 |
| 已导出并被下载 | 保留版本说明并提供修订文件 |
| 已经触发外部流程 | 查询对方状态，再执行其支持的补偿 |
表中的动作只是设计选项，需要真实接口与业务规则支持。文件移入隔离位置是否保留链接、字段更新能否条件回退、外部流程是否可取消，都必须单独验证。不能因为某个步骤叫“撤销”，就认为它自动解决所有后续影响。
补偿本身也会失败
补偿流程需要持久记录每一步是否完成、对应对象和实际回执。比如移动两份附件时只成功一份，恢复进程应接着处理另一份，而不是反复移动第一份。具有副作用的补偿动作同样需要幂等设计，并保留无法确认的状态。
不要把恢复代码写成一段只会打印异常的清理函数。它应能够被再次启动，能够说明哪些业务状态已修复，哪些仍需人工处理。对不能自动补偿的动作，应在任务规划时就标出边界，并在执行回执中保留足够证据。
从最危险的中间状态验收
可以用三个场景演练：主流程中途失败，补偿中途失败，以及补偿期间有人继续编辑目标。每次检查文档、附件和台账是否仍能互相解释。单纯确认程序没有报错，不足以说明业务已经恢复一致。
企业文档平台的原生撤销历史、版本恢复和跨系统补偿属于不同能力。接入石墨等工具时，应按实际支持范围组合流程。最后的报告写清“哪些动作已补偿、哪些仍保留、下一步由谁处理”，比一句“已回滚”更能帮助团队继续工作。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。