6 篇博文 含有标签「distributed-tracing」

一名用户反馈 Agent 回答正确，但数据库从未更新。你打开可观测性工具，搜索用户端对话中标记的 trace ID，发现了一个清晰的树状结构——五次 LLM 调用，四次工具决策，一个最终回答。没有任何错误。接着你搜索负责数据库写入的工具服务，发现了另一个 trace，虽然墙钟时间窗口相同，但 trace ID 不同，根 span 不同，且没有关联回溯。你搜索网关日志。又发现了三个孤立追踪（orphan traces）。在聊天 UI 中看起来像是单次连贯交互的 Agent 运行，在你的追踪后端却分裂成了一片森林。

本应将这一切串联起来的请求头是 traceparent。它是一个 55 字节的 W3C 标准字符串，分布式系统中的每个 span 都用它来识别其父节点。然而，在大多数生产环境的 LLM Agent 技术栈中，它在用户请求与用户真正想要的副作用（side effect）之间，至少会被丢弃一次。

你打开了一个运行缓慢的对话追踪。模型调用竟然在用户点击发送前的 800 毫秒就开始了。你责怪了用户的笔记本电脑，关闭了标签页，继续处理其他事情。

这不仅仅是一个用户的时钟出了问题。这涉及大约三分之一的流量，而且每一个跨越客户端边界的调试会话都在读取一个根本不存在的时间线。浏览器时钟是用户可设置的，经常不同步，偶尔甚至会偏差好几天。大多数可观测性技术栈附带的检测 SDK 会使用设备报告的任何时间来标记客户端 span，通过 traceparent ID 将它们与同步服务器时钟标记的服务器 span 链接成一棵树，然后将结果交给你的值班工程师，就好像这两半具有可比性一样。它们并不具有可比性。

一位用户拨通了你的客服 Agent。他们说话，Agent 倾听，用户在通话中途上传了一张错误截图，Agent 同时对图片和转写文本进行推理，最后通话以一封总结修复方案的邮件收尾。三天后用户投诉过来：修复没有生效，邮件也从未送达。你打开可观测性栈，发现三个独立 UI 里躺着三条互不相干的追踪。语音流水线给你一条 ASR 追踪。视觉流水线给你一段图片上传的 span。LLM 调用给你一条带 token 数和工具调用的聊天追踪。这些仪表盘里没有任何东西告诉你：它们其实是同一次对话。

这就是没人愿意写的那种复盘。不是因为数据缺失——每一个模态都老老实实记录了它该记录的东西——而是因为跨模态的"接合"从来就没建起来。每条流水线都从自家模型供应商默认配置里长出了自己的追踪约定，而把它们绑在一起的那一次对话轮次，只存在于设计这个 Agent 的那位工程师的脑子里。

你打开一个失败运行的追踪（trace）。Span 树非常漂亮：用户请求、规划者 Agent 的推理、三次工具调用、Token 计数、延迟，所有这些都整齐地嵌套在一起。然后规划者交接给一个专家 Agent —— 追踪到此结束。并不是出现了错误 Span。它只是停止了。接下来的内容是来自专家 Agent 的另一个、无根的追踪，它从思考的中途开始，没有父级，没有可见的输入，也与导致它的请求没有任何联系。

Bug 就存在于那个间隙中。一直以来都是如此。交接是一个 Agent 的假设与另一个 Agent 的理解相遇的地方，也是你的追踪无法跟随的唯一地方。

这不是日志记录的问题。你的 Agent 可能在两端都正确地发出了 Span。问题在于追踪上下文（trace context）—— 将 Span 缝合成一个故事的线程 ID —— 没能在从调用者到被调用者的跳转中幸存下来。你技术栈中的每个 HTTP 客户端和 gRPC 存根都会免费传播该上下文。但你的 Agent 交接没有这样做，因为没有人告诉它去这样做。

一名监管人员给你发了一封邮件，只问了一个问题：该用户是否授权了这笔交易？六小时后，三名工程师正在聊天频道里，试图将聊天界面的对话日志、规划代理（planner agent）的推理追踪以及工具的 API 记录关联起来。聊天日志记录了轮次 ID（turn ID）和用户可见的消息，但没有工具调用的细节。规划器追踪记录了工具调用的记录，其时间戳与聊天日志相差几百毫秒。工具日志记录了 API 调用及其自身的关联 ID（correlation ID），而该 ID 在代理的记录中无处寻觅。下游服务的日志则有另一个 ID，且没有回溯链接。团队最终通过关联用户 ID 和大致的时间戳重建了答案，祈祷没有什么关键信息因错过一个轮次而产生偏差，最后向法务部门提交了一份 PDF 文件。

这就是审计追踪不匹配（audit trail mismatch）。每一层的负责人（owner）都认为自己的日志没问题——而且从单体来看，它们确实没问题。缺失的产物是那个本应存在的“关联视图（joined view）”，并且没人为它的缺失负责。团队只有在发生事故、客户升级投诉或监管机构强制要求关联数据时，才会发现它并不存在。

一张支持工单送达：「你们的 AI 对我的保险条款给出了完全错误的建议。」你查看日志，找到了时间戳和用户 ID，最终模型响应也原文呈现在那里。但你根本不知道是哪个提示词版本产生了这条输出、检索步骤取回了哪些上下文片段、中间是否调用过工具，也不知道你过去一个月部署的三个模型版本中究竟是哪个处理了这个请求。你能读到输出，却无法解释它。

这就是归因鸿沟——大多数 AI 团队在首次上线模型功能后六到十八个月都会撞上这道墙。问题不在模型或提示词，而在可观测性基础设施。传统日志记录的是请求-响应对，而 LLM 流水线并非请求-响应对，它是一棵决策树：上下文检索、提示词组装、可选工具调用、模型推理、后处理、条件分支。出现问题时，你需要看到完整的树，而不仅仅是叶子节点。