可观测性与追踪：重建一次 AI 请求为何得到这个结果

一个退款助手收到用户的退款请求，接口返回 HTTP 200，日志里没有异常栈，所有调用看起来都成功了。这仍然可能是一场严重失败：助手可能检索到了一版已经废止的退货政策并据此答复；可能在把订单号传给退款工具时传错了参数；可能第一次调用超时后自动重试，而实际上第一次已经创建了退款，重试又创建了一笔；也可能流畅地向用户承诺了它根本没有权限执行的动作。在这些场景里，传输层的一切指标都是绿色的，用户却拿到了错误的结果或错误的承诺。

问题的根源在于 HTTP 200 的语义边界。200 只确认请求在传输层面被接收并得到了响应，它不承诺响应的语义正确、证据可靠、权限成立或业务动作成功。一个由检索、生成、工具调用、策略判断组合起来的 AI 系统，其失败往往恰恰发生在传输层之外：模型收到了错误的输入、检索返回了过期的证据、工具被传错了参数、重试引入了重复副作用、生成内容与权限不符。这些失败不产生异常栈，传统的以日志为主的可观测性手段对它们几乎无能为力。

传统日志擅长记录机器异常：进程崩溃、空指针、连接超时都会留下痕迹。但 LLM 驱动的系统还需要记录三类传统日志覆盖不到的东西：语义失败（回答虽然通顺但内容错误）、证据路径（这条结论依据的是哪一条检索结果、哪个版本）、动作结果（工具调用之后外部系统实际发生了什么）。缺少这些记录，事故发生后工程师只能靠猜测。

可观测性在这里有一个需要澄清的边界：它并不是“看见模型脑内的真实思考”。模型内部的激活和中间状态无法被可靠地读出，任何声称能直接观察模型思维的说法都超出了工具实际能做到的范围。可观测性重建的是模型外部的因果链：模型实际收到的版本化输入是什么、实际发出了哪些调用、外部系统对这些调用给出了什么观察、最终产生了哪些副作用。有了这条链，工程师才能把一次错误结果归因到具体环节：是输入本身错了，还是检索到的证据错了；是生成环节偏离了证据，还是工具调用参数错误；是策略规则设计不当，还是环境数据在两次请求之间发生了变化。

这套记录是否足够，可以用一个核心测试来检验：值班人员在不需要复现用户敏感原文的前提下，能否仅凭 trace 回答四个问题——失败发生在哪一步、这一步使用了哪个版本、当时的结论基于什么证据、这次操作产生了什么状态变化。能回答，说明这条因果链是可定位、可回放、可验证的；不能回答，说明系统在关键环节上是不可见的，无论它的 200 响应多么频繁。

由此可以给出 AI 可观测性这一层的输入与输出。输入是沿请求链路收集的事件流：版本化的请求、检索结果、模型输入输出、工具调用、策略决策以及每一步的副作用。输出则是一条可以被定位、回放和验证的因果时间线，它把“用户得到了这个结果”拆解为“哪一步、用哪个版本、基于什么证据、改变了什么状态”。trace 记录的是实际发生的输入、动作和状态变化，它从不声称读取模型思维。同时，敏感原文并不是默认必须保存的——记录哪些字段、脱敏到什么程度，是由隐私策略决定的，而非可观测性的必然代价。

很多团队在事故发生后都会陷入同一个困境：日志系统里明明存了海量记录，真正要定位问题时却仍然只能靠猜。原因不在于日志太少，而在于日志只是四种可观测信号中的一种，每一种回答的问题不同，任何单独一种都无法覆盖完整的诊断链条。

日志记录的是离散事件，回答的问题是“某一步发生了什么”。比如退款工具返回了 permission_denied，这个事件会在日志里留下明确的一条记录，值班人员可以据此确认权限确实被拒绝过。日志的价值在于它忠实保存了某一时刻某一步的具体结果，但日志本身不能告诉你这件事是大规模发生还是个别现象。

指标则把离散事件聚合成时间序列，回答的问题是“规模和趋势是否异常”。p95 延迟、越权拦截率都是典型的指标：它们不关心单个请求的细节，而是暴露系统整体的走向。当“错误承诺率上升”出现在仪表盘上时，工程师知道有某种错误正在扩散，但仅凭这条曲线无法得知是哪些请求、哪个版本出了问题。

追踪记录的是带有父子结构的 span，回答的问题是“一次请求如何跨组件流动”。退款请求会沿着检索、模型、工具、重试这样的链路传递，trace 把这整条路径串成有顺序、有层级的关系，让人能看到请求在哪里分叉、在哪里等待、在哪里失败。指标找到了异常规模，trace 才能接着找到受影响的请求和版本。

评测标签则从样本层面判断质量，回答的问题是“结果好不好、属于哪类失败”。它标注的是资格错、引用不支持这类语义判断，是唯一能确认“回答内容错误”而不只是“执行出错”的信号。

四者在一次诊断中是接力的：指标发现“错误承诺率上升”，trace 找到受影响的请求和版本，日志解释具体返回了什么，评测标签确认这是语义失败而非执行失败。缺少任何一个层级都会留下盲区——只有 trace，你不知道问题是否普遍；只有指标，你不知道如何复现。反过来理解这四类信号的输入输出：输入分别是离散事件、聚合趋势、跨组件路径和样本质量判断，输出分别是 log、metric、trace 和评测标签。日志解释某一步发生了什么，指标发现规模和趋势，trace 串联一次请求，标签判断结果好坏；四者通过 trace ID 和版本关联在一起，才能互相印证。只保留其中一种信号，诊断能力就被限制在它擅长的那一个问题里，事故时自然只能靠猜。

用户的一次提问往往会在后台触发十次模型调用与工具调用，分布在不同的服务、进程甚至不同的机器上。trace 要解决的核心问题就是：当这些调用散落各处时，怎样让它们仍然属于同一条因果链，并且事后能还原出调用之间的先后与归属关系。

追踪的最小结构单元是 span。每个 span 对应一个有明确边界的操作：一次检索、一次模型推理、一次工具调用、一次重试。整棵树的根叫做 trace，它对应的是用户的整体任务；span 之间的关系用父子结构表达——根 span 之下挂着检索 span 和模型 span，模型 span 之下又挂着工具 span，工具超时之后的重试 span 则以工具 span 为父级。图 1 展示的就是退款助手 trace 中检索、模型、工具和重试这几类 span 的父子关系。

仅仅画出层级还不够，诊断需要三类信息落在 span 上：父子关系说明调用归属，事件时间说明先后顺序，幂等键则用来识别重复。退款重复创建这类事故之所以能被诊断，靠的正是时间与幂等键：第一次工具调用和重试调用拥有同一个幂等键，当业务数据库里出现两条副作用记录却只有一次预期操作时，两者的时间差和幂等键会直接暴露重复。缺了幂等键，重试产生的副作用就无从判断是一次操作的两次记录，还是两次独立的操作。

span 数据要能完整还原链路，每个 span 必须记录开始与结束时间、父 span 引用、状态以及属性。但结构本身不会自动跨进程：trace context 必须显式地跨 HTTP、队列和后台任务传播。一个请求通过 HTTP 进入服务，被放入消息队列，再由后台 worker 消费——context 若在某一跳丢失，后续的 span 就会从树上断裂，成为没有父级的孤点，整条因果链也随之断开。

还有一条容易被忽略的证据规则：模型生成文本里声称“我调用了一次工具”，这句话本身不是证据。模型的输出可能描述一个从未发生的调用，或者遗漏一次确实发生的调用。真正构成调用证据的是工具 span 和业务数据库里的状态变化。由此可以归纳追踪结构的输入与输出：输入是用户任务以及跨越 HTTP、队列和后台任务的调用，输出是一棵以根 trace 为顶点、以父子关系连接的 span 树；每个 span 记录时间、父级、版本、状态和实际副作用，context 负责跨边界传播。工具 span 与业务状态才是调用发生的证据，模型事后声称做过什么不能替代系统记录。

同样的输入昨天成功、今天失败，是 AI 系统事故里最常见的形态。要回答“是什么变了”，需要比较的不是前后两次输出的文本，而是一组可以复现的版本证据。记录的目标不是保存尽可能多的内容，而是保存最小的一组字段，足以在事故发生后逐项对比昨天与今天的差异。

这些字段可以按诊断用途分成几个族：

关联类字段让同一次请求的所有记录能跨组件串联，也让重复记录可以被去重。版本类字段支持发布前后的差异比较，也决定回滚应该回到哪个版本。输入证据类字段用来重建模型当时实际可见的信息——模型收到的是脱敏后的意图、被选中的候选文档 ID 及其在文档内的跨度。行为类字段记录工具名、参数摘要和幂等键，用于审计外部副作用。结果类字段把质量评估连接到具体请求，而不是只盯着状态码。

除此之外还要记录采样参数、检索查询、索引/嵌入/重排版本、工具 schema 与响应状态、策略规则、token 数、费用和最终验收结果。每一类字段都服务于“昨天与今天的哪一项不同”这个比较问题：发布号不同说明部署变了，提示哈希不同说明指令变了，索引版本不同说明证据库变了，检索查询与候选文档 ID 不同说明模型看到的信息变了，工具参数与幂等键不同说明副作用路径变了。

记录方式上有一个重要取舍：保存内容哈希或受控引用，而不把原始敏感文本复制进每一个日志系统。哈希和稳定 ID 同样能支持差异定位——哈希一致说明内容未变，哈希不同则指向具体变化——同时避免原文在多个系统中扩散。记录太少，事故无法复现；记录全部原文，又会扩大隐私面。两者的平衡点就是：存版本证据和引用，不存不必要的原文。

还有一个明确的排除项：不要把自由思维链当作事实真相来记录。模型的自由思维链可能不忠实于它实际做了什么，其中还可能包含敏感数据，并且逐 token 存储成本很高。需要留存的只是简洁的决策摘要和实际可观测的动作记录。归纳起来，复现字段的输入是应用、模型、提示、参数、索引、候选、工具、策略和验收各自的版本，输出是最小可比较的版本证据加上受控内容引用；哈希和稳定 ID 支持差异定位，同时避免原文复制到每个日志系统；自由思维链不作为事实证据。

一次退款请求端到端花了 1.42 秒，超过了 SLO。要定位慢在哪里，先要回答一个容易答错的问题：根 trace 的时长等于所有 span 时长相加吗？不一定。

在示例 trace 中，检索用了 180ms，模型调用用了 620ms，工具调用用了 90ms，退避与重试用了 310ms，另外编排本身用了 220ms。如果这些阶段全部串行执行，总和正好是 180 + 620 + 90 + 310 + 220 = 1420ms。但 span 之间并不总是串行的：如果检索与安全分类并行执行，两个 span 的时间重叠，根 trace 的时长就只由关键路径决定——即决定最终完成时刻的那条最长依赖链——而不是所有子 span 的时长之和。把全部 span 相加得到的数字是工作量，不是端到端时间。于是延迟分析的关键公式是：

Tcritical = 串行阶段的时长之和 + 并行阶段中最长依赖路径的时长

其中 Tcritical 是端到端的墙钟延迟。串行阶段直接相加，并行阶段取决定完成时间的最长路径；两者之和才是根 trace 的实际时长。

有了这个分解，就可以把本次各阶段的耗时与历史 p95 逐项对比：

检索低于历史水平，模型完整生成也低于 p95，只有首 token 略慢。真正的异常在工具与重试：工具调用本身 90ms 加退避与重试 310ms 共 400ms，而历史 p95 只有 110ms。总时长 1420ms 超过 SLO，主因是工具重试，而不是模型生成。

这正是只看平均总延迟会出错的地方：平均总延迟把 1420ms 归给“这次请求慢了”，若进一步想当然地认为慢在模型，就会把工具超时的锅扣到模型头上。要避免这种误判，延迟必须拆到 TTFT（首 token 时间）、每 token 时间、检索、工具、排队和重试等粒度，并且观察 p50、p95、p99 而不只是平均数——长尾用户的体验不会由平均数代表，p99 才能暴露最慢的那批请求。

归纳延迟案例的输入与输出：输入是各 span 的开始结束时间、依赖关系，以及排队、计算、网络和重试的耗时；输出是关键路径墙钟延迟 Tcritical。串行阶段相加，并行阶段取决定完成的最长依赖路径；所有 span 时长之和是工作量，不等于端到端时间。1.42 秒的主因是工具重试，而不是模型平均生成。

点赞率下降之后，真正的问题不是“质量变差了”，而是怎样知道变差发生在哪些任务、哪个版本、哪类失败上。一个孤零零的满意度曲线回答不了这个问题，质量指标必须能沿两个方向展开：向下连接到具体 trace，向两侧切开成有意义的切片。

连接的方式是把质量判断异步回写到 trace 上。离线评分器或延迟到达的人工标签可以给每个请求打上资格正确、引用支持、越权、工具完成、人工改判这类语义标签。因为这些标签附着在具体请求上，聚合时就可以按任务、语言、风险、模型、提示、索引和客户群切片，仪表盘上的每一个点都能下钻到已脱敏的样本和实际执行路径。指标因此不再是一团平均数，而是一条可以追踪到证据的线索。

在线代理指标同样有价值，但要清楚它们的性质：拒答率、转人工率、用户重问、工具撤销和引用点击这些信号响应很快，却并非真值。满意度可能偏爱那些自信地过度承诺的回复；转人工率下降也可能是升级规则本身坏了，用户根本点不到人工入口。所以每个代理指标都需要附带可能的替代解释，并用抽样人工评审或最终业务状态来校验，否则仪表盘上的绿色只会掩盖真实问题。

从指标到根因的完整路径可以这样展开：监控发现“引用失败率从 2% 升到 7%”，这只是信号，什么也证明不了。沿着这个点下钻到具体 trace，发现失败请求全部来自索引版本 index p17，且对应 retrieval span 里没有检索到任何文档，这时才形成一个可检验的根因候选：新索引在检索环节丢了文档。信号、切片、trace 证据三者合在一起，假设才立得住。

由此归纳语义监控的输入与输出：输入是异步回写的资格、引用、越权、工具完成和人工改判标签，输出是按任务、语言、风险、模型、提示、索引和群体切片的质量趋势。代理指标只提供根因线索，点赞、转人工和重问都可能有替代解释；必须下钻到脱敏 trace，并用人工或最终业务状态校验，质量结论才算成立。

每天一千万条流量不可能全量保存，可观测系统的存储预算迫使我们必须采样。但采样如果做得随意，会同时造成两种破坏：要么漏掉事故，要么让保存下来的样本无法用来估计真实比例。

一个常见疑问是：只随机保留 1%，会不会恰好把事故漏掉？答案是纯粹的均匀采样确实可能漏掉罕见事件，所以不能对全部流量一视同仁。合理的做法是分层：对常规成功 trace 采用低比例的头部采样，对错误、高风险、极慢和新版本流量提高尾部采样比例。尾部规则有一个时间上的约束——一条 trace 是否属于“错误或极慢”只有等它完成后才能判断，所以尾部采样决定必须在 trace 完成之后做出，不能提前拦截。更关键的是必须记录每条 trace 被纳入的概率：估计总体失败率时需要按这个概率加权，否则样本中错误的比例不能直接当总体比例用。如果只保存失败的请求，那么样本中的失败占比永远是 100%，无法据此估计生产环境真实的失败率。

按纳入概率加权的率估计可以用如下形式表达。设每条被保留 trace i 的结果为 yᵢ（失败取 1，成功取 0），它的保留概率为 pᵢ，则加权后的总体率估计为：

RateWeighted = Σ(yᵢ / pᵢ) ÷ Σ(1 / pᵢ)

分子 Σ(yᵢ / pᵢ) 的含义是：一条以概率 pᵢ 保留的失败 trace，在总体中代表 1/pᵢ 条同类 trace，把它计入分子就相当于把每个观察到的失败放大回总体的规模；同理，分母 Σ(1 / pᵢ) 把所有保留样本放大回总请求数。两者相除得到的就是对总体失败率的估计。这种 Horvitz–Thompson 风格的加权让尾部采样合法化——只要每条 trace 的纳入概率被如实记录，采样偏好再多也能在估计时被修正回来。

基数问题威胁的是另一个方向：指标标签。时序系统要求标签组合数量有限，直接把用户 ID、完整 prompt 或文档 ID 作为指标标签，会让时间序列的基数爆炸，同时把敏感信息散播到每个监控系统。正确做法是让高基数字段留在受控的 trace 存储中，指标只用任务类型、语言、风险等级这类有限枚举值做切片。此外，极低频的灾难性事件不能依赖普通采样，无论采样比例多高，一年发生一次的故障都可能落在样本之外，因此这类事件需要走专门的安全事件通道单独上报。

采样偏差还有一种隐蔽的来源：只抽“用户点踩”的请求做质量分析，会漏掉用户根本没有意识到的错误，尤其是那些流畅的幻觉——用户觉得回答很好，实际上证据是编造的。所以除了投诉驱动的采样，还必须保留随机审计样本。归纳采样估计的输入与输出：输入是每条 trace 的结果 yᵢ 和保留概率 pᵢ，输出是 Horvitz–Thompson 风格加权率 RateWeighted；尾部采样可以多保留错误和高风险流量，但必须记录纳入概率；只保存失败样本不能直接估计生产失败率，极低频灾难另走安全事件通道。

从调试角度看，全量保存 prompt 和附件当然最方便，但这不能成为默认可接受的方案。prompt、附件和工具参数里可能混着 PII、健康信息、商业秘密和凭证，把它们复制进日志系统，等于同时扩大了访问者范围、数据所在区域、保留期和泄漏面：日志被多少人看到、落在哪个司法辖区、保存多久、从哪些入口可能流出，全都随之膨胀。

隐私治理的正解是逐字段决策，而不是全有或全无。先按诊断目的定义必要字段：如果订单哈希和错误码就足以复现一次事故，就不必保存姓名与原文；如果确实需要内容审查，就把加密原文放进独立的受控存储，用短期授权访问，而不是堆在通用日志里。每个观测字段都要经过一次决策——脱敏、哈希化、加密隔离还是干脆不采集——决策的输入包括该字段的诊断目的、敏感等级、访问者、地域和保留期。

采集环节的纪律比事后清洗更可靠：字段要在采集前就完成分类，原文与密钥默认关闭；脱敏要放在入口处结构化执行，因为事后再用正则清洗很容易遗漏嵌套在工具参数深层结构里的敏感值。访问环节按角色限制，并记录每一次查看，生产环境与开发环境隔离。生命周期方面要定义保留期、删除流程、地域要求和用户删除请求的处理，而且删除必须覆盖派生索引——只删原始记录、不删索引里的副本，等于没有删。

还有一条容易被忽略的工程测试：trace 管道本身要经过异常路径测试，确认管道出错时不会把未脱敏的 payload 打进备用日志。故障时最危险的往往是兜底日志，因为兜底逻辑常为了“不丢数据”而放弃脱敏。

过度脱敏同样会损坏证据。如果把所有数字一律抹掉，金额错误这类故障就再也无法诊断。正确的粒度是保存类型、范围或稳定代号：不保存具体金额，但保存金额字段的类型和取值范围；不保存姓名，但保存稳定的用户代号。这样诊断需求和隐私风险可以在每个字段上分别权衡。

归纳隐私治理的输入与输出：输入是每个观测字段的诊断目的、敏感等级、访问者、地域和保留期，输出是脱敏、哈希、加密原文隔离或不采集的具体决定。能用类型、范围和稳定代号完成诊断的，就不复制姓名与凭证；需要内容审查的，使用短期授权的受控存储；删除必须覆盖派生索引和备用日志，隐私最小化与调试能力才能同时成立。

仪表盘变红但没有人行动，这不叫可观测，只叫监控展示。可观测性的闭环必须把信号变成行动，再把行动的结果回流成新的证据。

闭环的第一环是告警本身的完备性。每个告警都应绑定一组明确的要素：它所服务的 SLO 目标、触发阈值、持续窗口、负责人、诊断查询、处置步骤和回滚版本。一个没有负责人和处置路径的告警，只会训练人们学会忽略它。告警的触发方式上，burn-rate 告警值得单独说明：它度量错误预算被消耗的速度，能把偶发噪声与正在快速耗尽预算的持续恶化区分开。同时，每一次发布标记都必须出现在时间线上，否则无法判断故障是从哪次部署开始的。

以退款越权率越线为例，响应应当分成两条线推进。先止损：冻结自动退款工具或切回旧策略，让服务回到安全状态。再查因：检查受影响的 trace 是否集中在某个提示版本（prompt h83）、某个 policy 版本或某种语言上。恢复服务与修复模型是两个独立的步骤，不能为了研究根因而延迟止损——先止血，再解剖。确认根因之后，把故障构造为最小回归样本，加入评测候选池，经审核进入下一版的冻结评测集，让这次失败在未来的每次发布中都被重新检验。

可观测性也有明确的失败边界：它只能发现那些被记录、被定义并且被查看的问题。没有埋点的问题它看不见，没有定义指标的问题它测不出，没有人看仪表盘的问题它无从告警。它不能替代权限隔离、幂等设计、评测体系或事故响应演练——这些都是系统设计本身的责任，可观测性只负责让它们的失效变得可见。

归纳响应闭环的输入与输出：输入是 SLO、错误预算、告警窗口、负责人、诊断查询和回滚版本，输出是止损、回滚、根因实验以及经审核的回归样本。告警触发后先恢复安全服务，再研究长期修复；发布标记和受影响 trace 用来验证假设；而权限、幂等和事故演练这类防线，可观测性无法替代，只能配合。

把前面各环节串起来，可观测性从一次用户提问到一次可验证的修复，走过一条完整的因果链，每一步都为下一步提供输入，任何一步断裂都会让链停在原地。

链条从请求入口开始：为用户任务生成 trace context，并让它跨 HTTP、队列和后台任务传播。这一步决定了一次提问触发的那十次调用是否还属于同一条因果链。随后，每个组件在自己的 span 里记录版本、证据和动作——用的是哪个应用发布、哪条提示哈希、哪个索引版本，检索到了哪些候选文档 ID，工具传了什么参数、幂等键是什么。此时数据还是散的，于是质量标签与系统指标按任务、语言、风险、模型、提示、索引和群体切片聚合起来，异常以趋势的形式浮现。

趋势只是信号。出现异常后，下钻到受控的脱敏 trace，把信号变成可检验的假设：受影响的是不是某个版本、某类证据路径、某个工具调用。假设要再回到线上验证——回滚一个版本、消融一个参数，观察指标是否随之恢复，同时完成止损。最后，被验证的失败样本经过人工审核，回流进评测集，成为下一版发布必须通过的回归用例。

这条链上的每个环节都有明确的输入和输出：context 传播的输入是用户任务，输出是贯穿边界的 span 树；span 记录的输入是组件的实际执行，输出是版本、证据与动作的字段；聚合的输入是标签，输出是切片趋势；下钻的输入是异常信号，输出是根因假设；回滚与消融的输入是假设，输出是恢复后的服务；失败回流的输入是被验证的失败样本，输出是进入冻结评测集的回归用例。这样一个问题从“哪里慢了、哪里错了”出发，最终落到“怎样保证不再犯”，才是可观测性完整的闭环。