AI 调用链的可观测性：三个必须记录的字段

AI 应用出问题时的第一反应往往是「模型不行」。但复盘多了会发现，大部分故障出在调用链路的中间层：网关超时配置、重试策略、上下文拼接。没有可观测性，这些问题永远以「模型不稳定」的名义背锅。

为什么传统 APM 不够用

传统 APM 追踪的是服务间调用：耗时、状态码、QPS。AI 调用链多了几个维度：token 计量、上下文构成、模型行为的不确定性。同一个请求重发三次可能得到三个不同质量的回答——「调用成功」不等于「结果可用」，这是 AI 链路可观测性的核心矛盾。

三个必须记录的字段

1. 上下文指纹。 记录每次请求实际发送的上下文构成：系统提示词版本、注入的检索片段、截断位置。排查「为什么模型答错了」时，第一件事是确认它到底看到了什么——检索片段拼接顺序错、截断把关键信息截掉，这类问题在最终 prompt 里一眼可见，在生产里却经常被忽略。

2. 失败语义分类。 状态码之外，给每次调用打业务语义标签：正常完成、长度截断、内容拦截、格式违约（要 JSON 给了散文）、空响应。这五类的处置策略完全不同——截断可以重试，格式违约该修提示词，内容拦截重试一万次也没用。混在一起叫「失败率」，运维就无从下手。

3. 决策快照。 Agent 类应用要额外记录决策点：当时挂载了哪些工具、模型选择了哪个、为什么终止。这是事后还原「为什么这一步做错了」的唯一依据。只记最终动作不记决策上下文，等于只存了案发现场没有存动机。

落地的最小成本做法

不需要上重型平台，起步三件事：在网关层把上述字段写进结构化日志（一条请求一行 JSON）；给失败语义分类建一张日环比报表；抽查 1% 的完整请求样本存档供回放。这三件事的工程量一周以内，换来的是排查时间从天级降到小时级。

结语

模型能力每年都在涨，但调用链的工程质量不会自动升级。上下文指纹、失败语义分类、决策快照——把这三个字段记全，大部分「模型不稳定」的锅就能还给它该在的地方。