OpenClaw 工作流出现问题以后，如果日志里只有“成功”或“失败”，基本帮不上忙。团队真正需要知道的是：当时输入是什么，Agent 为什么选择这个动作，读了哪些证据，调用了哪个工具版本，谁在中间改过，最后是否回滚。
审计日志字段设计得越清楚，事故复盘越少靠猜。它应该和 回放验收、工具版本锁定、告警降噪 放在一条运维链路里。
动作字段要写清楚
动作不能只写 run 或 call tool。更有用的是记录动作类型：读取、检索、判断、生成、写入、外发、暂停、接管、回滚。动作越细，后面越容易筛选风险。
如果一个流程涉及外部系统写入，还要记录目标系统、对象 ID、字段变化和写入结果。否则出了问题，只能去多个系统里反查。
原因字段比结果更重要
日志不能只记录 Agent 做了什么，还要记录为什么做。比如触发了哪条规则，引用了哪段证据，置信度是多少，是否因为工具异常转人工。
这部分可以回到 可解释运行。没有原因字段，审计日志就只是流水账，无法解释决策路径。
证据和版本要绑定
同一条知识库内容，不同版本可能结论不同。同一个工具，不同接口版本可能返回字段不同。审计日志要记录证据来源、知识库版本、工具版本、提示词版本和模型配置。
这样做不是为了日志好看，而是为了复盘时能还原现场。否则今天看到的知识库已经被修改，根本不能代表事故发生时 Agent 看到的内容。
人工动作也要进入日志
很多流程出问题，不一定是 Agent 单独造成的。人工接管、补证据、改派、批准、拒绝、继续执行和终止任务，都应该写入审计日志。
这和 OpenClaw 人工接管入口 是配套的。人不是流程外的临时干预，而是生产链路中的一个可追踪节点。
总结
OpenClaw 审计日志字段不要停留在成功或失败。动作、原因、输入摘要、证据来源、工具版本、人工修改和回滚记录都要能查到，团队才能在事故复盘和合规检查时还原真实过程。
