299 篇博文 含有标签「observability」

你的生产系统中有一个智能体删除了 10,000 条数据库记录。这次删除符合有效的业务逻辑 —— 这些记录被正确标记了。但三个月后，监管机构提出了一个简单的问题：谁授权了这个操作，智能体是根据什么依据做出决定的？你打开日志，找到了 SQL 语句，找到了时间戳，但什么都找不到了。

这就是决策溯源问题。你可以证明你的智能体采取了行动；但你无法证明它为什么这样做，或者这个行动是否曾经得到了一个真正理解自己在批准什么的人的授权。随着自主智能体开始执行跨越数小时、数十次工具调用、且决策具有真实世界影响的工作流，"我们有日志"与"我们有问责机制"之间的鸿沟已经在运营上变得危险。

大多数分布式追踪方案在引入 Agent 之前都运作良好。一旦系统中出现 Agent A 跨微服务边界调用 Agent B——Agent B 调用工具服务器、工具服务器再查询向量数据库——原本连贯的端到端视图就会碎片化为互不相连的片段。追踪后端展示的是一个个孤立的操作，而你失去的是因果链：为什么某件事发生了，哪个用户请求触发了它，以及那 800 毫秒究竟消耗在了哪里。

这不是监控配置问题，而是上下文传播架构问题。它有着特定的技术形态，大多数团队都是在付出代价后才意识到这一点。

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

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

你的 LLM 幻觉率是 3%。但你的用户仍然讨厌它。这并不矛盾 —— 而是衡量标准错误的症状。

幻觉率已成为 LLM 质量的默认头条指标，因为它很容易向利益相关者解释，且在基准测试（benchmark）中计算起来非常简单。但在生产环境中，它与用户真正关心的东西相关性很低：任务是否完成、结果是否值得信赖并足以据此行动、以及系统是否为他们节省了时间？

周一你的提示词还运行正常。周三，用户开始抱怨响应感觉不对劲——答案变短了，下游的 JSON 解析时不时崩溃，原本准确率 94% 的分类器现在徘徊在 79% 左右。你没有部署任何新代码，配置文件里调用的模型名称还是那个。但某些东西变了。

这就是隐形模型漂移：LLM 供应商在不作任何公告的情况下推送静默的、未记录的行为变更。这是 AI 工程中讨论最少的运营风险之一，它会打击那些"做了所有正确事情"的团队——有评估集、有监控、有稳定的提示词工程。模型就在他们脚下悄悄地变了。

凌晨两点，你被告警叫醒。延迟上升，错误率飙升。你 SSH 进去，查看日志——什么都没有。没有指向错误部署的堆栈跟踪，没有第 247 行的空指针异常。只有一串模型输出，这些输出在细微之处、以不可预测的方式出了问题——只有当你连续读了 50 条之后，才能意识到这一点。

这就是 LLM 驱动系统中故障的样子。而传统的"告警-分类-修复"循环根本不是为此而生的。

标准值班手册有三个前提假设：故障是确定性的（相同输入，相同的错误输出）、根因是可定位的（某段代码改了，某项资源耗尽了）、回滚是直接的（还原部署，搞定）。这三点在随机 AI 系统中都不成立。同一个提示词会产生不同的输出。根因通常是一个概率分布，而不是某行代码。而且，你根本无法"回滚"一个第三方提供商昨晚悄悄更新的模型。

你的 AI 功能处于 "up" 状态。延迟正常。错误率为 0.2%。仪表盘显示一片绿色。但在过去的两周里，摘要质量在悄然下降 —— 输出在技术上是连贯的，但事实深度变浅了，始终漏掉用户关心的关键细节。没有人提交 Bug。没有触发告警。直到下一次季度审查、留存数据出来时，你才会意识到这一点。

这是传统 SLO 无法察觉的故障模式。可用性和延迟衡量的是你的服务是否在响应 —— 而不是它是否响应得 好。对于确定性系统，这两者几乎是等价的。对于 LLM 功能，它们可能会在数周内无声无息地分道详镳。

一个市场调研流水线连续运行了 11 天。四个 LangChain Agent —— 一个分析器（Analyzer）和一个验证器（Verifier）—— 来回传递请求，在原始任务上毫无进展，并在被人发现之前累积了 47,000 美元的 API 费用。系统从未返回错误，也没有触发报警。直到损失造成几天后，计费仪表板才发现了这一异常。

这绝非个案。它是典型的 AI Agent 事故。如果你现在正在生产环境中运行 Agent，你现有的 SRE 运维手册（runbooks）几乎肯定没有涵盖这种情况。

当确定性系统崩溃时，你会找到 bug。堆栈跟踪指向某一行代码。代码差异（diff）显示了更改。回顾起来，修复方案显而易见。但 AI 系统并非如此。

当一个由大语言模型（LLM）驱动的功能开始输出更差的结果时，你寻找的不是 bug。你面对的是一个发生偏移的概率分布，它存在于一系列组件构成的堆栈中，而每个组件都引入了各自的方差。是模型的问题吗？是供应商在某个周二进行的无声更新？是架构变更后未刷新的检索索引？是某人为了修复另一个问题而修改的系统提示词（system prompt）？还是三个冲刺（sprint）前就停止捕获回归的评估系统（eval）？

复盘会议变成了责任拍卖会。每个人都出价“模型变了”，因为这是一个无法证伪且无需成本的借口。

凌晨两点，报警器响了。仪表盘显示没有 5xx 错误、没有超时激增、没有异常延迟。然而客服已经被淹没："AI 给出了奇怪的回答。"你打开运行手册——立刻意识到它是为完全不同的系统写的。

这是 2026 年 AI 故障响应的标志性失效模式。系统在技术上完全健康。Bug 是行为上的。传统运行手册假设存在离散的失败信号：堆栈跟踪、错误码、不响应的服务。基于 LLM 的系统彻底打破了这一假设。输出语法正确、延迟正常、内容却完全错误。没有任何告警能捕捉到它。唯一的信号是某些东西"感觉不对"。

这篇文章是我第一次不得不响应生产 AI 故障时希望就存在的手册。

你AI系统健康仪表盘上最危险的指标，是99.9%正常运行时间旁边那盏绿灯。如果你第一次得知模型出问题是通过一张支持工单，那你拥有的不是可观测性——而只是感觉。

传统APM工具构建于一个二元故障的世界：请求要么成功，要么失败。对于LLM驱动的功能，这个模型彻底失效。一个请求可以在300毫秒内完成，返回HTTP 200，消耗token，给出一个自信却完全错误、毫无帮助、或比六周前悄然退化的答案。这些故障状态没有一个会触发你现有的告警。

研究持续表明，延迟和错误率加在一起，覆盖的LLM功能故障空间还不到20%。另外80%隐藏在五种故障模式中，大多数团队只有在用户已经注意到之后才会发现。

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

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