很多团队第一次接入 AI Agent 时，只保存最终回答。看起来省事，但一旦出现问题，就很难复盘：它为什么这么判断，查了哪些资料，用了哪个工具，谁确认过，失败后有没有重试。最后只能凭感觉说“这次模型不稳定”。
运行日志的价值，就是把 Agent 从一个黑箱变成可检查的流程。它和 工具输出校验、任务输入规范、决策日志 是一套东西：入口说清楚，过程留痕，结果能追。
第一层记录任务输入
日志里最先要保存的是任务输入，而不是模型回答。任务目标、范围边界、资料来源、输出格式、工具权限和验收条件都应该被记录下来。否则复盘时很容易把入口问题误判成执行问题。
比如用户只写“帮我整理客户反馈”，Agent 输出偏了，问题可能不在模型，而在任务没有写明客户范围、时间窗口和输出用途。运行日志要能把这种差异暴露出来。
第二层记录上下文来源
Agent 每次读取知识库、网页、表格或历史记忆，都应该留下来源、时间和片段摘要。对事实型任务来说，这比回答语气更重要。没有来源记录，就无法判断 Agent 是引用了旧资料，还是把临时上下文当成长期规则。
这部分可以接上 知识库过期审计。如果日志经常显示某个旧文档被引用，就说明知识库更新和检索权重都需要重新检查。
第三层记录工具调用
工具调用日志至少要有工具名称、输入参数、返回状态、关键字段和异常信息。不要只记“调用成功”，因为成功返回也可能是空数据、旧数据或格式不完整的数据。
如果工具会写入外部系统，还要记录写入对象、写入前状态、写入后状态和操作者身份。这里可以参考 最小权限 的思路，把只读、草稿、待确认写入和自动写入分开看。
第四层记录人工确认
很多 Agent 流程会在关键节点加入人工确认，但确认本身也要留下证据。谁确认、确认了什么、有没有修改、是否跳过某个警告，这些信息会直接影响责任边界。
尤其是合同、报价、CRM 写入、权限修改这类场景，人工确认不是一个按钮，而是业务控制点。它应该和 结果验收 一起进入日志。
总结
AI Agent 运行日志不是为了堆数据，而是为了让问题能被定位。输入、上下文、工具调用、人工确认、失败重试和业务结果都能串起来，团队才知道 Agent 是哪里跑偏，也知道下一次该改提示词、改工具还是改流程。
