法务智能体接入审批流后，我最担心的不是它少提了一条建议，而是事后问起“这份合同为什么被放行”，系统里只剩一句“审核通过”。留痕不能只是证明机器运行过，还得让复核者看清：它看了什么、依据什么、做了什么，最后是谁拍板。
把建议与动作分开记
我会把留痕拆成两条线。建议线记录合同及其版本、对应条款、采用的规则与依据、风险提示，以及人工采纳或驳回的情况；动作线记录谁发起任务、何时调用审批平台、修改了什么、通知了谁，以及操作是否成功。
这两条线要能关联起来。否则，“建议修改付款条款”和“合同已进入下一审批节点”各有记录，却无法解释两者之间发生了什么。尤其要区分提出建议、尝试执行和执行成功，不能把一次调用当成动作已经完成。
留住当时的判断现场
合同在改，规则也在改。如果复核时只能看到最新文件和最新规则，就容易拿今天的标准解释昨天的决定。我的判断是：每次审核应关联当时的合同版本、规则版本和审核结果；后续复检另留记录，不覆盖原来的判断。
人工复核也不能只留一个“同意”。对风险建议的采纳、修改或驳回，应记录处理人和必要理由；涉及例外放行，更要留下依据。智能体的建议不是审批人的决定，责任边界需要体现在记录里，而不只是界面上的提示。
验收时倒查一次
我更愿意拿一份合同做倒查：从最终审批结果出发，能否找到签字的人、人工处理意见、机器建议、对应条款和当时规则？再核对修改、通知等动作是否真的完成，失败后有没有后续处理。
留痕也不是把敏感合同复制得到处都是。记录的查看权限应随合同类型和项目边界设置，并明确留存、导出与退出安排。真正有用的可追溯，是该查的人能还原决策过程，而不是所有人都能翻到一堆日志。