OpenClaw 工作流跑完以后，如果只留下“成功”或“失败”的状态，后面很难做复盘。真正有用的是运行证据：它当时接到了什么任务，调用了哪些工具，谁审批了敏感动作，人工改了什么，最后是否进入失败样本库。
运行证据导出不是为了堆文件，而是为了让事故复盘、上线验收和合规检查有同一份材料。它可以接上 审计日志字段、失败样本库 和 回滚预案。
先导出任务基础信息
每份证据包都应该有任务编号、触发时间、触发来源、执行身份、工作流版本、模型版本、连接器版本和最终状态。这些字段决定了后面能不能找到同一类问题。
如果只保存自然语言描述，复盘时很难筛选。结构化字段越清楚，后面做统计、评测和告警归因就越省力。
工具轨迹要保留关键参数
OpenClaw 里很多风险来自工具调用。证据导出时，要保存工具名称、调用顺序、参数摘要、返回状态、耗时和关键结果。涉及敏感信息的参数可以脱敏，但不能完全丢失。
这一步和 连接器清单 有关系。证据包里看到某个连接器反复失败，就应该回到清单里检查负责人、权限范围和停用条件。
审批记录要和动作绑定
敏感动作审批不能只存在聊天记录里。付款、删除、外发、批量修改、客户承诺这类动作，要在证据包里显示审批人、审批时间、审批结论和最终执行结果。
这样复盘时才能看清楚：系统有没有正确拦截，审批人看到的信息是否足够，执行结果是否和审批内容一致。
把失败样本和回滚材料放进去
如果任务失败或触发人工接管，证据包里要标记是否进入失败样本库。进入样本库的，还要补充人工修正、根因判断和后续评测题状态。
如果发生回滚，也要保存回滚触发条件、回滚版本、数据恢复范围和通知记录。这些材料以后能反向检查回滚预案是否真的可用。
总结
OpenClaw 运行证据导出的重点，是把日志、工具轨迹、失败样本、审批记录、人工修正和回滚材料放在一起。证据包越完整，团队越容易把一次异常变成长期改进。
