AI 应用 Debug 需要的不是“更多 log”，而是 Runtime Trace

最近在做 AI 生图项目，处理用户反馈时发现 debug 体验很差。用户说“生成结果不符合预期”“风格不对”“参考图没生效”“同样的 prompt 结果差很多”，但真要定位问题时，翻 log 经常翻到怀疑人生。

我就跟朋友吐槽：传统 log 方式不适合 AI 应用，AI 应用 debug 更应该关注 runtime 下的全流程 trace。

朋友一句话怼回来：“暴论，你以为改个名字就不叫 log 了是吧。”

这个质疑其实挺有价值。很多工程概念确实容易变成换皮术语：log、trace、event、telemetry、observability，好像名字一换就高级了。但我这里说的不是“不要 log”，也不是“trace 和 log 完全无关”，而是：传统 log 的核心模型，和 AI 应用的故障形态不匹配。

先说清楚，我说的“传统 log”是什么。

传统 log 通常是开发者在代码里主动打点，输出一段面向人的文本或结构化事件：

[INFO] user_id=123 create order success

[ERROR] request failed: timeout

它的默认前提是：程序逻辑大体确定，关键状态由代码路径决定，异常通常来自分支、参数、IO、依赖服务。debug 时，我们关心的是“代码有没有执行”“变量是什么”“哪里报错”“哪个依赖慢了”。

这套方式在传统后端里很好用。请求进来，经过 controller、service、dao，最后返回。只要 log 打得够好，基本能把问题定位到某个代码分支、某个外部依赖、某个异常堆栈。

但 AI 应用不一样。

AI 应用的核心行为不是完全写死在代码里的，而是在 runtime 中由多种动态因素共同生成的：用户输入、prompt 模板、上下文、模型版本、采样参数、seed、工具调用、检索结果、历史消息、系统状态、外部 API 返回、agent 中间决策。真正决定结果的东西，很多不是代码，而是运行时内容。

以 AI 生图为例，用户反馈“图不对”，传统 log 可能只告诉你：

{"event":"generation_start","request_id":"req_123","user_id":"u_001","model":"xxx","prompt_length":120}

{"event":"generation_end","request_id":"req_123","latency_ms":8230,"status":"success"}

这些信息当然有用，但对定位“为什么图不对”帮助非常有限。

你真正想知道的是：用户原始 prompt 是什么？系统有没有做 prompt rewrite？套了哪个风格模板？negative prompt 是什么？参考图有没有上传成功？参考图 hash 是多少？有没有走 ControlNet、IP-Adapter、LoRA？权重是多少？seed、sampler、steps、CFG scale、分辨率分别是什么？模型具体 revision 是哪个？有没有触发安全过滤？有没有被队列重试？后处理有没有裁剪、压缩、水印？最终返回给用户的是哪张图？

这些东西用传统 log 也能记，但问题是：如果只是把它们都塞进字符串 log，debug 体验会非常差。因为你需要的不是几行文本，而是一条请求在 runtime 中完整的因果链。

有人可能会反驳：这些东西为什么不能都塞进 log？prompt 打一行，参数打一行，模型响应打一行，不也能查吗？

能，但“能记录”不等于“适合作为 debug 模型”。

如果只是把 prompt、参考图、模型参数、工具返回全部打印成 log，本质上还是把一次 AI 执行拆成很多离散文本。debug 的时候你要靠 request_id 去 grep，再靠时间顺序脑补调用关系，再从一堆字符串里还原 input/output。系统越复杂，这个过程越像人工反序列化。

更关键的是，AI 应用里的关键数据不是普通日志事件，而是有结构、有层级、有体积、有版本的 runtime artifact。完整 messages 可能几十 KB，检索上下文可能几百 KB，工具返回可能是 JSON、HTML、表格甚至文件，生图里的参考图、mask、control image、输出图更不可能直接塞进 log。

硬塞会带来几个问题：日志系统被大对象污染，索引膨胀，查询变慢，成本上升，脱敏困难；调用之间的因果关系仍然不清楚；更重要的是，很难稳定 replay。

AI debug 很多时候不是“看一眼当时发生了什么”，而是要把某个线上失败 case 拿回来重放：换一个 prompt 模板会不会好？换一个模型版本会不会好？固定 seed 后能不能复现？去掉某个 LoRA 后结果是否正常？如果当时的上下文只是散落在 log 文本里，就很难恢复成可执行输入。

所以这里的关键区别不是“记录还是不记录”，而是记录模型不同。

传统 log 是 message-centric：以一条条文本消息为中心。

AI runtime trace 应该是 execution-centric：以一次执行过程为中心。

也就是说，不应该只问“打印了什么日志”，而应该问“这次 AI 调用到底经历了哪些阶段，每个阶段的输入、输出、决策依据和副作用是什么”。

这里还要补一句：传统 Web 当然也有 trace 系统。Zipkin、Jaeger、OpenTelemetry、APM 这一套早就存在了。所以我的意思不是“Web 只有 log，AI 才需要 trace”。更准确地说，AI 应用需要的是一种更偏 runtime semantic trace 的东西。

传统 Web trace 主要回答的是：一次请求经过了哪些服务，哪个 RPC 慢了，哪个 DB query 报错了，哪个下游依赖超时了。它关注的是调用链、延迟、错误、吞吐、服务拓扑，本质上还是围绕确定性代码路径和分布式系统性能问题展开。

AI trace 可以借用 span/trace 这个模型，但要记录的语义不同。它不只是：

service A -> service B -> database

而是：

user input -> prompt rewrite -> context build -> model call -> tool call -> postprocess -> final output

每个节点里的关键对象，也不只是普通低基数字段，而是 prompt、messages、reference image、model config、seed、tool arguments、agent state 这些会直接改变模型输出的 runtime artifact。

传统 Web trace 很擅长定位“慢在哪里”“挂在哪里”；AI runtime trace 还要回答“为什么它这么答”“它基于什么上下文答”“哪一步把问题带偏了”“这次失败能不能被 replay”。

所以不是说传统 Web 没有 trace，而是传统 distributed trace 的默认数据模型不够解释 AI 行为。它可以作为底层基础设施，比如继续用 OpenTelemetry 的 trace/span 结构，但 span 的 schema、artifact 存储、版本快照、replay/diff 能力，需要针对 AI runtime 重新设计。

一个合理的 AI trace，应该把一次用户请求建模成 trace tree 或 DAG。每次请求是一条 trace，请求里的每个步骤是一个 span：prompt rewrite 是 span，context build 是 span，model call 是 span，tool call 是 span，postprocess 是 span，final response 也是 span。每个 span 都有明确的 input、output、metadata、timing、error 和 artifact 引用。

大概像这样：

{

  "trace_id": "t_123",

  "spans": [

    {

      "name": "prompt_rewrite",

      "input": {"prompt": "赛博朋克风格头像"},

      "output": {"prompt": "cyberpunk portrait, neon light, detailed face..."},

      "latency_ms": 42

    },

    {

      "name": "image_generation",

      "metadata": {

        "model": "sdxl-v1",

        "sampler": "DPM++ 2M",

        "seed": 391028,

        "steps": 30,

        "cfg_scale": 7.5

      },

      "input": {

        "prompt_ref": "artifact://prompts/abc",

        "reference_image_ref": "artifact://images/ref_001"

      },

      "output": {

        "image_ref": "artifact://images/out_001"

      }

    }

  ]

}

注意，这不是简单把日志 JSON 化。结构化 log 只是第一步，真正重要的是 trace 语义：父子关系、执行顺序、输入输出、artifact 引用、版本快照和可重放能力。

当然，传统 log 仍然有价值。系统错误、基础设施异常、权限失败、HTTP 状态码、数据库错误，这些还是 log 的主场。我的观点不是 trace 取代 log，而是 AI 应用的核心 debug 面不能停留在传统 log 上。

如果一个 AI 应用只是在业务系统里包了一层模型调用，那传统 log 和 trace 可能还够用。但只要进入 RAG、多轮记忆、工具调用、agent workflow、多模型路由、AI 生图工作流、在线评测这些场景，光靠 log 很快就会变成翻散落文本：信息可能都在，但没有结构、没有因果、没有上下文快照、没有重放能力。

所以“AI debug 需要 runtime trace”不是改名字，也不是术语洁癖，而是因为 AI 应用的行为主体已经从确定性代码，扩展到了运行时生成的上下文、参数、工具和模型决策。debug 方法必须跟着变。

总结：

传统 log 和 distributed trace 更擅长记录程序路径、系统异常和链路性能；AI runtime trace 要记录的是一次智能行为到底是怎么被构造出来的。

一点拙见，请佬友们批评指正