什么是执行日志？Agent 干了什么可查

AI 干完一轮活，你问它刚才都做了什么，它若答不上来，你就只能干瞪眼。执行日志就是那份底账：智能体每一步调了什么工具、传了什么参数、拿回了什么、耗时多少，全部按时间记下来，随时可查。出问题时，这份底账是唯一的目击者。

日志里通常记了哪些内容

一份够用的日志至少包含四样：时间戳，精确到每次调用；动作记录，调用了哪个工具、传入了什么参数；返回摘要，工具吐回了什么、状态如何；以及分支走向，走了哪条路、为什么。秘塔AI搜索的检索过程、DeepSeek 的多步推理，在支持日志的平台里都能逐步回放。

日志和聊天记录是两回事。聊天记录只留人机对话，日志则连内部的工具调用、参数细节都留。排查「为什么它做了这件事」时，聊天记录帮不上忙，日志才行。

日志的保存策略也值得了解：一般按时间滚动保留，比如三十天或九十天，超期归档或清理。对排障来说，近期日志价值最高；对回溯来说，关键事件的日志值得单独留档。还有个实用技巧是给日志加关联标识——同一个任务的多步日志用同一个任务号串起来，跨任务的排查从大海捞针变成按号取件。日志本身不产生价值，能被快速查到才有价值，组织方式比记录数量更重要。有条件的平台还支持把日志导出成文件，离线分析更方便。记录的详略在设计阶段就定下来，比事后补录现实得多。

生活类比：行车记录仪

行车记录仪不参与驾驶，只负责忠实记下全过程。平时没人看它，出事故时它是唯一说得清的东西。执行日志同理：绝大多数时间无人问津，关键时刻价值连城。

记录仪比方盖不住的地方：记录仪只录镜头内的画面，日志却可以选择记录的详略——全记会撑爆存储，少记会漏关键线索。所以工程上常做分级：关键动作全记，普通调用只记摘要。分级的依据是动作的风险等级：动钱、动数据、对外发送的记全，查询类的记摘要，标准提前定好写进配置，不要出了事再补。

出问题时怎么翻日志

按这个顺序找，通常不会绕路：

• 先定位出问题那一步的时间点，看返回内容里的错误信息。
• 再往前看一步：传进去的参数对不对，是不是源头就错了。
• 最后看分支：当时为什么走了这条路，判断依据是什么。
• 都正常却结果不对？看看是不是上游数据源本身就变了。

排查三连：

• 这一步的返回状态是什么？
• 这一步的输入参数和预期一致吗？
• 再上一步的输出正常吗？

三连问下来，问题大多能锁定到具体某一步。

日志是给事后看的，事中把关靠什么，见人工在环；强制关卡怎么设，见审批节点；失败后的处理路径，见容错处理；隔离运行怎么留痕，见沙箱执行；网页任务的过程记录，见浏览器 Agent。

从今天起立个规矩：Agent 一反常，先翻日志再重跑——重跑只是再掷一次骰子，日志才是答案所在。养成这个习惯，排障效率至少翻倍，也不必再靠猜。

关于执行日志的三个常问问题

• 日志会占很多存储吗？：会，尤其是长流程加全量记录。常见做法是分级加过期清理：关键节点留全量，普通步骤留摘要，超期自动归档。
• 日志可以给模型看吗？：可以，而且有用。排查对话里把关键日志贴给模型，它能帮你定位问题，比自己逐条读快得多。
• 日志和审计有什么关系？：日志是审计的原料。谁在什么时候让 Agent 做了什么、结果如何，都靠日志还原，记录不全就无从回溯。