一位用户拨通了你的客服 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 流水线并非请求-响应对，它是一棵决策树：上下文检索、提示词组装、可选工具调用、模型推理、后处理、条件分支。出现问题时，你需要看到完整的树，而不仅仅是叶子节点。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
