OpenClaw 工作流进入生产以后，日志不能只记录“执行成功”。一旦出现错误通知、错误写入、错误引用或客户投诉，团队需要追问的是：输入是什么，Agent 调了哪些工具，权限是否允许，输出依据是什么，最终有没有人工确认。
审计日志要和 运行监控、运行看板、事故复盘 配合。监控看趋势，看板看处理，审计日志负责还原证据链。
输入字段要保留摘要和来源
日志不一定要保存完整原文，尤其涉及客户隐私和内部资料时更要克制。但至少要保留输入摘要、来源系统、任务编号、触发人、触发时间和敏感等级。
如果后续要复盘，就能知道 Agent 是基于什么材料做判断，而不是只看到一段孤立输出。
工具调用要记录结果和重试
每次工具调用都应该记录工具名称、参数摘要、返回状态、耗时、重试次数和是否写入数据。只记录最终答案，会让很多问题无法追踪。
比如工具第一次超时、第二次成功，和工具一直成功但返回空结果，是两种完全不同的问题。前者要查稳定性，后者要查输入和数据源。
权限判断要能解释为什么放行
生产 Agent 最怕“谁都能让它做高风险动作”。审计日志里要记录权限判断：当前用户、角色、动作类型、目标系统、是否需要人工确认、是否被拒绝。
这能接上 权限复核 和 责任矩阵。如果某类高风险动作反复被人工放行，说明流程边界也需要重新定义。
输出证据和版本信息不能漏
输出日志要记录引用来源、生成版本、提示词版本、知识库版本、是否被人工修改、最终发送或写入的位置。否则同一个问题过两周再查，很难知道当时到底用了哪一版规则。
如果工作流已经接入 变更审批，版本信息还能帮助定位是哪次改动带来了结果变化。
总结
OpenClaw 审计日志字段的目标，不是堆满技术细节，而是在出问题时能还原证据链。输入摘要、工具调用、权限判断、输出证据、人工接管和版本信息都有留痕，生产 Agent 才能被真正管理。
