233 篇博文 含有标签「observability」

你的 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 语义规范已经确立，仪表板也非常精美。但智能体调试总是会撞上同一堵墙：你可以完全洞察智能体做了什么，却无法看到它为什么这么做。

每个正在基于LLM构建系统的工程团队，都在做基础设施决策时忽视了一项隐性成本。你会追踪token数量、延迟和API开支，但几乎没有人追踪其运行的推理工作负载的碳排放——而这个缺口正在迅速收窄，来自监管和市场两个方向的压力都在增加。

AI系统现在占全球温室气体排放的2.5–3.7%，已正式超过航空业2%的贡献，且每年增长15%。仅2024年，运行AI专用服务器的美国数据中心就消耗了53–76 TWh的电力——足以为720万户家庭供电一年。这种规模已不再是假设，工程团队需要了解自身贡献的预期正成为真实的组织压力。

一个运行多智能体市场调研流水线的团队花了 11 天时间观察他们的系统正常运行——绿色的仪表盘、零错误、正常的延迟——而 4 个 LangChain 智能体却在无限循环中互相博弈。等到有人扫了一眼账单仪表盘时，这一周 127 美元的预估成本已经变成了 47,000 美元。这些智能体从未崩溃。API 从未返回过错误。每一个基础设施告警都保持沉默。

这就是 AI Oncall 的核心问题：你的系统在运维层面可以显示为绿色，但在其本应完成的任务上却发生了灾难性的失败。传统的监控旨在检测崩溃、延迟飙升和错误率。AI 系统可以在满足所有基础设施 SLO 的同时，悄无声息地产生错误输出、无限期地循环执行任务，或者在不产生任何有用结果的情况下消耗数千美元的计算费用。错误代码的缺失并不代表结果的正确。

METR 于 2025 年发布的一项研究，邀请 16 位经验丰富的开源开发者预测 AI 工具能让他们效率提升多少。他们猜测会快 24%。该研究随后对 246 个真实任务（包括修复 bug、开发功能、代码重构）进行了测量，这些任务被随机分配到"允许使用 AI"和"禁止使用 AI"两组。结果是：使用 AI 的开发者实际上慢了 19%。研究结束后，参与者再次接受调查。他们仍然认为 AI 让自己效率提升了 20%。

这种感知生产力与实测生产力之间的差距，并非某项研究的特例。这是大多数团队目前衡量 AI 功能时所面临的核心问题。那些看起来像成功的信号，在很多情况下衡量的是工具的新鲜感，而非其实用价值。而上线后的头 30 天，是最不适合观察的时间窗口。

当团队第一次将 LLM 接入日志管道时，演示效果非常惊人。你只需粘贴一段堆栈跟踪（stack trace），GPT-4 就能用通俗易懂的语言解释根本原因。因此，接下来的自然选择显而易见：将其自动化。将所有日志都发送给模型，让它寻找问题。

这就是你每月烧掉 125,000 美元，并用“幻觉”来骚扰值班工程师的方式。

计算过程简单而残酷。一个中型生产系统每天产生大约十亿行日志。按每条日志条目大约 50 个 token 计算，每天就是 500 亿个 token。即使按照 GPT-4o 折扣后的每百万输入 token 2.50 美元计算，在不计算输出成本、重试或推理开销的情况下，你每天也要支付 125,000 美元。对流式日志进行实时的前沿模型分析不是一个优化问题 —— 而是架构选型错误。

构建生产级 AI 系统的团队往往通过同一种方式发现“对齐税”：有人投诉延迟，另一个人将其追踪到审核流水线，于是原本隐性的成本项突然变得显而易见。到那个阶段，安全层已经层层堆叠 —— 拒绝分类器、输出过滤器、毒性评分器、人力介入队列 —— 却没有任何人对它们进行过单独测量。拆解它们是痛苦、昂贵且在政治上充满争议的，因为现在看起来你是在反对安全。

更好的路径是从第一天起就将安全开销视为一等公民的工程指标。对齐税是真实的，它是可衡量的，并且具有复利效应。150 ms 的防护栏检查听起来还可以，直到你在智能体工作流中将三个检查串联在一起，并纳闷为什么你的 P95 延迟达到了 4 秒。

你的支付服务拥有 99.9% 的可用性 SLA。请求要么成功，要么以文档记录的错误代码失败。当出现故障时，你清楚地知道哪里出了问题。

现在，想象你发布了一个封装了 LLM 的智能发票解析 API。在一个周一早晨，你最大的客户打来电话：“你们的 API 返回了一个有效的 JSON 对象，但在涉及外币的发票中，total_amount 字段的值差了十倍。” 你的服务返回了 HTTP 200。你的可用性仪表板显示绿色。根据每一个传统的 SLA 指标，你都没有违反任何规定。但你确实搞砸了——而且在契约语言中，你甚至找不到词汇来描述到底哪里出了错。

这就是当今大多数 AI API 部署的核心鸿沟。管理你的 API 承诺 的契约为确定性系统而写，而 LLM 并非确定性系统。