19 篇博文 含有标签「debugging」

一个客服 Agent 在 12% 的工单中生成了幻觉式的故障排查步骤。HTTP 日志全部显示 200 OK。延迟正常。错误率平稳。从每一项传统指标来看，系统都是健康的——但它却在大规模地悄悄捏造答案。

当工程师最终对决策层进行插桩后，根本原因在几分钟内便浮出水面：检索到的文档块相似度得分全部低于 0.4，对上下文的置信度为 0.28，而模型输出的置信度却显示为 0.91。这是一个巨大的不匹配——在传统日志中完全不可见，但在捕获了决策状态的追踪中一目了然。

这就是将传统日志应用于 LLM 系统时的根本问题。I/O 日志告诉你系统运行了。AI 原生日志告诉你它是否推理正确。

一位我上季度合作过的 Staff Engineer 发现了一个在过去六周内已经被“修复”过三次的 bug。由三位不同的工程师处理，涉及三个不同的文件。三次 CI 运行都顺利通过。三次都采用了由 Agent 生成并被接受的补丁。每一个补丁都让失败的测试通过了，也让用户报告的错误消失了。但每一个补丁都只是把 bug 转移到了别处，潜伏在那里，直到被另一个表现面再次触发。当它第四次出现时，它导致的数据损坏已经静默累积了 40 天。

这个 bug 只是分页游标中一个简单的“差一错误”（off-by-one）。Agent 对于“症状会消失”的判断是正确的，但它对“原因”的判断是错误的。而那些优秀的、资深的、动机良好的工程师们，在理解失败机制之前，就各自接受了一个通过测试的补丁。

这就是“智能代理调试陷阱”（agentic debugger's trap）：你的 Agent 生成修复方案的速度，超过了你构建评估该方案正确性所需的心智模型（mental model）的速度。补丁速度超过了诊断速度。Bug 数量下降了，CI 面板变绿了，而你交付的代码库，其失败模式你却不再理解。

晨会上出现了一个回归问题：支持代理昨晚回答错了三个客户问题。有人说：“我们试试在这个路径上用 Opus，看看能不能解决。”四十分钟后，评估通过率回升了，团队关闭了工单，而该路径上的推理账单悄然翻了三倍。六周后，同样形式的回归出现在另一个路径上，并采用了同样的修复方法。你的团队刚刚训练出了一种巴甫洛夫反射：质量回归 → 增加算力。更大的模型是你的技术栈中最昂贵的调试工具，而你现在却首先想到它。

问题不在于更大的模型没有帮助。它们确实有——有时甚至很大。问题在于，更大的模型是一种绝对占优的“掩盖”策略。当提示词指令冲突、检索返回了过时的块、工具描述被误读，或者评估集没有覆盖失效的分布时，更强大的模型会绕过这些故障而不修复其中的任何一个。下一次回归仍具有相同的根本原因，账单已经复加，而底层系统变得更加脆弱，而非更加稳健，因为升级带来的缓冲空间让所有人都不再去探究底层逻辑。

智能体用 400 毫秒回答了一个简单的问题，然后因递归限制错误（recursion-limit error）崩溃。Trace 显示了 25 次工具调用。从上到下阅读 Trace，工程师会得出结论：智能体糊涂了 —— 以略有不同的顺序反复调用那几个工具，始终无法收敛。这个结论是错误的。智能体并没有糊涂。它陷入了一个死循环：工具 A 调用了模型，模型选择了工具 B，工具 B 的实现再次调用模型来格式化其输出，而格式化程序又选择了工具 A。Trace UI 将四个嵌套调用渲染为扁平列表中的四个兄弟调用，导致唯一能发现问题的开发者也无法察觉这个循环。

这就是工具重入（tool reentrancy），这是一种你的函数调用层几乎肯定没有建模的 Bug 类别。并发安全的代码对此已有数十年的原语支持：记录同一线程嵌套获取次数的重入互斥锁（reentrant mutexes）、语言层面的递归限制、堆栈检查 API，以及一种文化共识：任何回调运行时的函数都需要一个明确的契约，规定允许何种重入。工具调用层默认采用“发后即忘”（fire-and-forget）模式。运行时没有可供检查的调用栈，调度前没有循环检测器，工具定义上没有重入属性，Trace UI 的形式像日志而非图。结果就是，任何超过十几个条目的工具目录都会悄悄变成框架无法察觉的递归。

用户将一份冗长且复杂的错误报告粘贴到你的 AI 助手。它看起来像是一个经典的空指针问题，其措辞和代码布局与数以千计的 Stack Overflow 帖子如出一辙。模型自信地做出了响应，引用了常用的修复方案，听起来非常权威。用户向它表示感谢。然而，错误依然存在。这份报告实际上关于的是竞态条件 (race condition)；空指针的表述只是用户描述症状时的偶然方式。

这是在生产环境 LLM 系统中捕捉难度最高的一类 Bug。模型没有拒绝回答，没有推诿。它没有幻觉出一个虚假的 API。它只是极其流畅地解决了错误的问题，而下游的所有环节——包括用户、你的评估流水线、你的护栏 (guardrails)——都看到了一个看似合理且切中要害的回答，然后继续下一步。我将此称为模式匹配失败 (pattern-matching failures)：模型锁定了查询的表面特征，并针对与实际提出的问题相邻的问题给出了一个自信的答案。

某用户提交了一个支持工单："你们的 AI 助手告诉我合同续签截止日期是 3 月 15 日，实际上是 2 月 28 日，我们因此错过了截止日期。"你调出日志，响应已生成，模型没有报错，所有指标都是绿色。但你根本不知道它检索了哪份文档、模型读取了什么内容，也不知道那个日期究竟来自上下文还是完全被幻觉出来的。

这就是数据血缘的缺失。这不是监控问题，而是从一开始就埋下的架构问题。

你的检索精度提升了。重排分数改善了。生成器的忠实度指标比上个季度更好。然而用户却在抱怨系统越来越差。

这是生产级 AI 工程中最令人困惑的故障模式之一，而且发生频率远超团队预期。当你构建一个复合 AI 系统——检索结果送入重排器，重排器送入生成器，生成器再送入验证器——你就继承了一个根本性的归因问题。端到端质量是唯一真正重要的指标，却也是最难付诸行动的。你无法修复"系统变差了"。你需要修复某个特定组件。而在一个四阶段流水线中，这件事出乎意料地困难。

当一名律师在联邦备案文件中引用不存在的法庭案例时，这一事件被广泛报道为“ChatGPT 产生了幻觉”。当一家咨询公司的政府报告中包含虚假脚注时，复盘报告写道“AI 伪造引文”。当一个医疗转录工具在医疗笔记中插入暴力语言时，解释仅仅是“模型产生了幻觉”。在每一个案例中，代价昂贵的失败都被归结为一个由三个词组成的根本原因，这使得修复变得不可能。

“模型产生了幻觉”在 AI 领域等同于在堆栈跟踪中写下“未知错误”。它描述了发生了什么，却没告诉你为什么发生或如何修复。每一次幻觉都有一个可诊断的原因——通常属于四个类别之一——且每个类别都需要不同的工程响应。理解这种区别的团队能够交付可以优雅降级的 AI 系统。而不理解的团队则在不断地通过提示词玩“打地鼠”游戏。

在AI工作中遇到困难的工程师，最常见的问题不是缺乏技术知识，而是他们一直在问错误的问题。他们想知道的是："这能用吗？"但他们真正应该问的是："这个系统的失败率是多少，这个失败率对于这个使用场景来说是否可以接受？"

这一转变——从二元正确性转向可接受的失败率——是有经验的AI工程师思考问题的核心差异。听起来简单，其实不然。由此延伸的一切都是不同的：你如何调试、如何测试、如何部署、监控什么、以什么为信心基础。没有完成这一转变的工程师会一直在与工具对抗并且不断失败。

你的智能体在最终成功之前三次调用了错误的工具，而你的追踪仪表板准确地向你展示了哪些工具被调用、调用的顺序以及完整的延迟分析。但追踪无法展示真正关键的部分：为什么智能体认为这些工具调用是正确的决策、它试图完成什么目标，以及它在做出每一个错误决定时基于什么样的假设。

这就是 2026 年智能体可观测性核心存在的鸿沟。从业者在工具调用追踪上投入了大量资源。工具已经成熟，OpenTelemetry 语义规范已经确立，仪表板也非常精美。但智能体调试总是会撞上同一堵墙：你可以完全洞察智能体做了什么，却无法看到它为什么这么做。

2026 年 3 月，一次由 AI 辅助的代码变更导致一家大型零售商损失了 630 万个订单，北美订单量暴跌 99% —— 这场长达六小时的生产事故追溯到一次未经适当审查就部署的变更。这并非什么新颖的攻击，也没有什么离奇的故障模式。系统只是执行了 AI 告诉它的指令，而在数百万客户遇到错误之前，没有任何值班人员拥有足以理解其错误原因的心理模型（mental model）。

这就是“调试退化”（debugging regression）。AI 生成代码带来的生产力提升是前置且在仪表盘上清晰可见的。而成本则是后置的，直到凌晨 3 点告警把你叫醒时，它才显露真身。

你正在值班，凌晨三点，告警触发：过去一小时内 AI 聊天功能的用户满意度下降了 18%。你打开日志，却看到……什么都没有。每个请求都返回了 HTTP 200，延迟正常，没有任何报错。

这就是 AI 事故的体验。传统值班的肌肉记忆——grep 堆栈跟踪、找到异常、部署修复——在这里完全失效。系统并没有崩溃，它做的正是它被设计来做的事。只是输出结果是错的。