上周二，我上线的一个智能体在对话中途认定用户名叫"导出表格"。实际上不是。七轮之前，一个工具返回结果里，用户名位置出现了带引号的表头，模型默默把这个字符串当成了事实。之后每轮都在悄悄崩坏——道歉语气、微妙幻觉、一次拒绝里还引用了"您的账户，导出表格"。

单次调用日志一切正常。延迟绿灯。令牌消耗平稳。唯一的办法是把整段对话重建成因果图，顺着污染往前追。

打开网易新闻 查看精彩图片

这就是"8轮问题"。我交付过的最昂贵的bug类别，而我试过的大部分可观测性工具都是为"请求相互独立"的世界设计的。它们不是。

为什么请求级监控在撒谎

传统应用性能监控（APM）假设请求是一个封闭单元：进来，做点事，出去，聚合下p99和错误率，系统健康度就清楚了。这个模型对无状态服务够用，对智能体则是公开失效。

智能体请求携带的状态不在HTTP负载里。它携带对话本身。它携带前几轮写入上下文的工具结果。它携带模型自己之前的输出，而这些输出现在正在训练下一次推理。

一轮调用在局部看起来完全正确——JSON合法、工具调用成功、回复合理——却可能是你的智能体接下来40分钟用户对话里悄悄脱轨的精确时刻。

我现在盯三个数字比盯延迟还紧：

• 轮次间意图漂移：第N轮还匹配用户最初的需求吗？

• 工具结果污染率：工具响应里有多少次包含看起来像指令的字符串？

• 会话成功率，而非请求成功率：用户实际拿到想要的东西了吗？

这些从聚合单次调用的指标面板里统统看不见。你需要跨越整个会话的追踪，而且结构要能让你从失败点往回走。

有用的追踪到底长什么样

OpenTelemetry生成式人工智能特别兴趣小组一直在收敛到生成式人工智能语义约定，这是好事。主流形态是：每个工具调用、每次大语言模型（LLM）调用、每次检索都是一个子跨度，挂在轮次下，轮次挂在会话下。这么做，你的追踪树就能讲述推理链的故事。

这里有几个常见错误：

别把提示词放进跨度属性。属性会被索引、有大小上限，还会作为个人身份信息（PII）直接漏进可观测性后端。用跨度事件。事件可以在采集器端被采样、脱敏或丢弃，不用碰应用代码。这一个改动能帮你省掉之后的合规谈话。

按轮次挂父子跨度，别只按调用挂。如果每次LLM调用都是根跨度，你就丢了对话结构。第3轮和第7轮之间的父子关系才是你真正想追踪的东西。