做 AI 应用时，我为什么开始重新重视日志系统

以前做普通后端接口时，我当然也知道日志重要，但说实话，很多时候只是把它当成一个基础配置。

能查报错、能看到请求链路、线上出问题能定位，大概也就这些。

但开始做 AI 应用之后，我对日志系统的重视程度明显上去了。因为这类系统很多问题，不是直接报一个 500 就结束，而是它“看起来像正常工作”，只是结果越来越不对。

这种问题如果没有足够细的日志，基本很难查。

AI 应用的麻烦，在于错误经常不是硬错误

比如工具确实调成功了，但调错了工具。

检索确实召回了内容，但召回的是过期信息。

模型确实给了答案，但关键判断被前面一段无关上下文带偏了。

这些情况如果只看最终响应，很多时候你只能知道“结果不太对”，但完全不知道链路里哪一步开始偏。

所以我后来更关注过程日志

我现在会更想记录这些东西：

• 用户输入被系统归成了哪类任务。
• 当前上下文里塞了哪些关键信息。
• 模型为什么走了某个工具调用。
• 工具返回了哪些有效结果。
• 哪一步触发了降级、追问或者失败兜底。

这些信息不是为了把一切都暴露出来，而是为了让系统出了问题以后还有机会复盘。

否则很多 AI 应用的排查方式就会变成一句很虚的话：它这次好像脑抽了。

日志不是越多越好

这个我也慢慢在调整。

因为这类系统链路本来就长，如果什么都打，很快就会把自己淹掉。而且一旦涉及用户内容、业务数据和模型上下文，日志本身还会碰到隐私和成本问题。

所以我现在更倾向于记“关键决策点”，而不是记一切。

比如：

• 为什么选择这个分支。
• 为什么判定当前信息不足。
• 为什么决定调用某个工具。
• 为什么最后没有继续往下做。

这些点一旦清楚，很多问题其实就能复盘出来。

我为什么觉得这件事会越来越重要

因为 AI 应用一旦走向真实业务，稳定性和可解释性一定会被追问。

用户不会满足于“反正模型大概就是这么想的”。开发者自己也不能每次都靠猜来修问题。

所以日志系统在这里不只是运维配套，它已经慢慢变成了理解 AI 链路本身的一部分。

至少对我现在做的东西来说，日志不再只是“有没有打”，而是“有没有把关键决策过程留下来”。这两者差得其实挺远。