边界体系的第 6 章。前几章让系统「承诺了边界、设了度量」，这一章回答一个更基础的问题：当用户投诉「它答错了/它乱调工具」时，你能不能回答「它当时到底做了什么」？ 答不上来，边界管理就缺了最后一块——可回放性。传统后端出问题可以查日志、看调用链；AI 系统的链路更长（检索、工具、模型、后处理），还夹着「模型怎么想的」这个黑盒，所以追踪要专门设计。
AI 链路追踪和传统追踪差在哪
- 多一跳语义层：除了「调用了什么服务」，还要记录「检索了什么、工具传了什么、模型看到了什么上下文」——排错的大部分信息在这一跳。
- 成本与质量并重：每次调用的 token、延迟、拒绝/降级标记，既是排错依据也是效果数据（效果度量的在线部分）。
- 输入输出含敏感信息：prompt 和回答可能带用户数据，记录前必须脱敏（这条是红线，见LLM 应用安全）。
记录什么：一张「调用记录表」贯穿全链路
每个用户请求生成一个 request_id，把它贯穿：网关 → 编排 → 检索 → 工具 → 模型 → 输出。每个环节记四类字段：
| 环节 | 记什么 |
|---|---|
| 入口 | request_id、功能、用户维度、耗时 |
| 检索（如有） | 查询改写前/后、召回了哪些文档、命中分 |
| 工具（如有） | 调了哪个工具、入参、返回状态与摘要 |
| 模型调用 | 模型名/路由、输入输出（脱敏后）、token、首 token 延迟 |
| 结果 | 成功/拒绝/降级/转人工标记、是否带引用 |
落地提示：埋点从第一行代码就开始，别等上线再补（补埋点 = 重写一遍）。工具可以直接用 Langfuse 自托管，它把 trace、成本、评测串起来了（工具行实测）；也可以自建表，规则一致即可。
回放台：追踪的终极用途
记录只是手段，回放才是目的。把 request_id 对应的完整链路还原出来（当时用户问了什么、检索到了什么、模型怎么答的），用来做四件事：
- 幻觉定位：投诉「答错了」，回放一看是「检索到了过期文档」——定位到第几层，比猜强一百倍（幻觉三层治理每层都能用回放验证）。
- 成本归因：某个功能成本暴涨，回放看是不是上下文越滚越大、模型路由走错（成本篇的排查动作）。
- 降级复盘：为什么走了降级？回放看触发了什么条件（超时？预算帽？），反推阈值合不合理。
- 评测回流：被投诉、被纠错的案例一键变成评测集新条目（效果度量的闭环）。
落地清单
- request_id 贯穿全链路，四类字段全记录（脱敏后）
- 检索/工具/模型各成 span，可展开可回放
- 回放台按 request_id 一键还原
- 投诉/纠错案例回流评测集
- 追踪与成本/效果面板打通