Tracing

很多 AI 系统排障难，不是因为一点线索都没有，而是因为线索太碎。

你可能知道：

1. 这次回答不对
2. 这次延迟很高
3. 这次工具调用失败了

但你还是很难立刻回答一个最关键的问题：

这一次请求，从输入到输出到底经历了什么。

这就是 Tracing 要解决的事。

1. Tracing 到底是什么

Tracing 直接看成链路追踪。

它最核心的价值，是把一次请求在系统里走过的完整路径串起来，让你能看到：

1. 它经过了哪些步骤
2. 每一步花了多少时间
3. 哪一步失败了
4. 哪一步虽然没报错，但结果已经开始偏

在 AI 系统里，这件事比传统接口更重要，因为链路通常更长、更复杂。

2. 为什么 AI 场景特别离不开 Tracing

一条看似简单的问题，背后可能已经经过：

1. Prompt 组装
2. 历史消息裁剪
3. 知识检索
4. 重排
5. 工具调用
6. 模型生成
7. 输出校验

如果没有链路追踪，你通常只能看到最终结果不对，却不知道问题到底卡在：

1. 输入组织
2. 检索结果
3. 工具参数
4. 模型决策
5. 输出后处理

3. 一条最小链路怎么理解

flowchart LR
    A[用户请求] --> B[组装上下文]
    B --> C[检索 / 工具 / 模型调用]
    C --> D[输出结果]
    D --> E[记录链路节点]

更贴近真实一点，它真正想表达的是：

1. 每一步都留下上下文
2. 每一步都能看耗时和结果
3. 最后能把整条链路还原出来

4. Tracing 和 Observability 到底差在哪

这两个词非常容易被混。

把这两个词分开：

1. Observability 更偏看整体趋势和系统健康度
2. Tracing 更偏看单个请求到底走了什么路径

比如：

1. “最近 P95 延迟突然升高”更像是 Observability 发现的问题
2. “这一条请求慢，是卡在检索还是卡在模型生成”更像是 Tracing 要回答的问题

一个更像看地图，一个更像沿着某一条路线回放。

5. 在 AI 系统里，哪些节点最值得追

更实用一点，通常最值得重点追的是：

1. Prompt / 上下文组装
2. 检索召回结果
3. 重排结果
4. 工具调用参数和返回
5. 模型调用耗时和结果状态
6. 输出校验和拦截节点

并不是所有细节都要无上限记录，但关键节点最好能看清。

6. 为什么只靠日志通常不够

因为日志更像散落的记录，而 Tracing 更强调把一次请求的步骤串成一条线。

没有链路视角时，你可能会遇到这些问题：

1. 日志都在，但不知道它们属于同一次请求
2. 知道某一步失败了，但看不到它前面的上下文
3. 知道整体变慢了，但不知道最慢的是哪一段

所以链路追踪真正解决的，是“把碎片化信息组织成一条可读的因果路径”。

7. 最容易踩的几个坑

7.1 只追模型调用，不追前后链路

这样出了问题，还是很难分清是模型不稳，还是上下文、检索、工具把结果带偏了。

7.2 链路里信息很多，但没有关键节点摘要

如果每条请求都记一大堆细节，却没有关键步骤视图，排障时反而很难读。

7.3 有链路数据，但没有和评估、可观测性接起来

这样你可以回放单次问题，却很难判断它是不是一类普遍问题，也很难判断改完之后有没有系统性提升。

8. 一段更稳的总结

Tracing 解决的是“单次请求到底经历了什么”这个问题。它让 AI 系统从只看最终结果，变成能把 Prompt、检索、工具、生成、校验这些中间步骤完整串起来。很多排障难题最后不是没人努力，而是根本没有链路可追。