执行日志和审计日志有什么区别？

智能体每跑一步都会留痕，在大模型应用的日志体系里，执行日志和审计日志常被当成一回事，其实是一对分工不同的双胞胎：一个陪你排障，回答刚才哪一步出了岔子；一个替你留凭据，回答这件事当时是谁批准、依据什么做的。分不清两者，要么排障时缺细节，要么追溯时拿不出证据。

分工一句话：一个管过程一个管凭据

执行日志面向开发与运维，记的是每一步的输入、输出、耗时、报错，用途是把问题定位出来，看几十天就可以归档。审计日志面向管理与追溯，记的是谁在什么时间发起、用了哪个版本、改了什么配置，用途是事后还原现场，往往要按年保留。读者不同、寿命不同，内容设计自然不同。两者还有个容易混的点：同一次调用往往两边都要留痕迹，只是摘取的字段不同，好比同一件事对内对外各写一份纪要。

记录粒度和保留期各不相同

执行日志求全，模型每次调用的提示词、返回、重试次数都值得记，粒度细到能重放单步。审计日志求准，宁可少记也不能记错，条条要有据可查，写入后不可随意改动。保留期上，执行日志通常几十天滚动清理，审计日志按制度要求长期留存，两者混在一起存，成本和查阅效率都会吃亏。

写入方式也不同。执行日志可以异步批量写，丢一两条不影响排障大局；审计日志必须同步落盘、不可改写，丢一条就是凭据缺口。存储选型因此分道扬镳：前者追求写入吞吐，后者追求完整和不可抵赖，把两种要求塞进同一个通道，往往两头都做不好。

两类日志的分工，落在下面五个维度上：

定位问题靠执行日志一步步回放，重试了几次、卡在哪一环一目了然。追溯决策靠审计日志，比如三个月前那次自动发送是谁开启的开关。两者用途不可互换：拿执行日志当凭据，它太碎；拿审计日志排障，它太粗。把两类日志的用途写进团队手册，新人上手时先读一遍，比事后纠正成本低得多。

失败处理和日志的关系很直接，没有好日志，回滚和补偿有什么区别？分界点在哪 里讲的恢复动作根本无从判断；接入外部服务时的请求留痕，参考 内部工具和外部 API 差在哪？一文看懂。

日志设计先于工具落地

先定三类问题：出错时最想三分钟内知道什么、半年后可能被追问什么、哪些操作必须留痕。再据此定字段和保留期，最后才挑存储工具。顺序反过来，常见结果是日志堆成山却找不到关键信息。文心一言、腾讯元宝这类平台自带的调用记录，多数只够排障级，要当凭据用还得自己补一层。字段设计有个实用技巧：给每条记录带上请求编号和环节编号，靠这两个编号能把一次任务的全部记录串成一条线，排障时按号索引，比按时间翻快得多。

日志自查清单

• 每条日志分得清是排障用还是凭据用吗
• 保留期分别定了吗
• 出事后能不能按一次请求串起全部记录

日志的价值不在多，在关键时刻找得到。

任务形态也影响日志怎么记，流水任务要按链路串联，独立任务和流水任务有什么区别？ 讲了形态差异；提示词版本变了日志对不上号也是常踩的坑，见 固定提示词和动态拼装有什么区别？；一口气跑完的和一问一答的，记录节奏也不同，可对照 批处理任务和交互任务有什么区别？。

关于执行日志与审计日志再多问三句

• 小项目需要两套日志吗？：至少要分两个通道，哪怕先写进同一个文件，也要打上不同标记，日后好拆。
• 日志里能存用户敏感信息吗？：排障日志尽量脱敏，凭据日志按制度定最小字段，能少存就少存。
• 多久清理一次合适？：排障类滚动三十到九十天，凭据类按追溯要求来，清理动作本身也要留记录。