打开你的 AI 功能延迟和质量看板，眯起眼睛仔细看。曲线大部分时间是平缓的，偶尔会有一些峰值，你的团队几个月来一直称之为“噪音”或“供应商异常”。现在，按小时和星期几来拆分这些数据。噪音显现出了真面目：在东部时间每个周一上午 9 点到 11 点之间，你的 p95 延迟比周六晚上高出 30–60%，缓存命中率下降 10–20 个点，重试率翻倍，每个任务的 token 支出也在悄然攀升。看板没有撒谎，它只是在做平均。
大多数团队发现这种模式的方式就像发现缓慢漏水一样：通过回溯没人能解释的季度账单。直觉是将其归结为供应商的不稳定性，给推理厂商提个工单，然后就此作罢。但这种模式其实与你的 LLM 供应商无关。事实是，你的 AI 功能现在构建在一堆共享的、对时间敏感的系统之上——模型 API、embedding API、你的 agent 调用的 SaaS 工具、接收 webhook 的客户自身基础设施——而其中每一个系统的周期性负载模式都会发生叠加。你继承了整个依赖链的昼夜曲线，而你的看板向你展示的是所有这些曲线的平均值。
追踪记录看起来很干净。Agent 调用了 get_inventory_status，工具返回了 {"available": 142, "warehouse": "SEA-3"}，模型将这些信息编织成了一个自信的回答。客户下单了。仓库却说该商品自上午 9 点以来一直缺货。缓存的行数据是四小时前的。团队中没人决定过四小时是可接受的 —— 这只是平台团队连接包装器（wrapper）时，缓存框架默认的设置。
这种失效模式经常被误归类为幻觉。模型并没有在胡编乱造；它是在忠实地根据一个过期的工具结果进行推理，而没人费心将该结果标记为过期。追踪记录显示的是一次干净的调用和干净的响应，评估集（eval set）从未见过过期缓存的情况，而这种退化在每一个撞上相同 TTL 窗口的客户身上悄无声息地累积。
一张支持工单送达：「你们的 AI 对我的保险条款给出了完全错误的建议。」你查看日志，找到了时间戳和用户 ID，最终模型响应也原文呈现在那里。但你根本不知道是哪个提示词版本产生了这条输出、检索步骤取回了哪些上下文片段、中间是否调用过工具，也不知道你过去一个月部署的三个模型版本中究竟是哪个处理了这个请求。你能读到输出，却无法解释它。
这就是归因鸿沟——大多数 AI 团队在首次上线模型功能后六到十八个月都会撞上这道墙。问题不在模型或提示词，而在可观测性基础设施。传统日志记录的是请求-响应对，而 LLM 流水线并非请求-响应对，它是一棵决策树：上下文检索、提示词组装、可选工具调用、模型推理、后处理、条件分支。出现问题时，你需要看到完整的树，而不仅仅是叶子节点。
你的智能体返回了 200 状态码。响应流畅、语法完美，但完全错误。欢迎来到智能体调试的世界——在这里，系统永远不会崩溃，永远不会抛出异常，而失败的方式与成功看起来毫无区别。
传统调试假设 Bug 会表现为错误。堆栈跟踪指向出问题的那一行，失败的断言告诉你哪里出了错。但智能体在做出错误决策时并不会崩溃。它们会自信地执行错误的计划，用看似合理的参数调用错误的工具，然后交付一个建立在幻觉基础上的精美答案。Bug 不在你的代码里——它在你的智能体的推理中，而你的调试器根本不知道推理是什么样的。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
