330 篇博文 含有标签「observability」

传统的 HTTP 请求只有一个关键的延迟：从请求到响应的时间。那个数字的 p95 就是契约。SRE 监视它，SLO 是针对它编写的，当它退化时就会有人收到告警。一个数字，一个仪表盘，一个真相。

流式 AI 功能在响应变为流的一刻就打破了这一模型，而大多数团队还未察觉。现在有了两种延迟，而且它们是发散的。首字延迟（Time-to-first-token） 是用户在任何事情发生前盯着加载图标的时间。完成时间（Time-to-completion） 是直到回答完全写完的时间。它们受不同力量的影响，由不同的杠杆修复，并且用户感受到的情感权重完全不同 —— 而几乎每个团队都只衡量第二个指标，因为那是 HTTP 框架免费提供给他们的数字。

当你第一次尝试像调试服务那样调试 Agent 时，你会发现以往的肌肉记忆完全派不上用场。你设置了一个假设的断点——虽然 IDE 中没有面板可以放置它，但你在脑海中想象了一个——就在 planner 选错工具的那一步。你使用相同的输入重新运行。这一次，planner 选择了正确的工具。你再次运行。它又选了一个你从未见过的第三种工具。Bug 是真实存在的，你的同事今天早上复现了两次，而你用了十五年的调试器突然间变成了博物馆里的陈列品。

这里失效的心智模型并不是“使用调试器”，而是背后更深层的假设：即一个程序在给定相同输入的情况下，会产生相同的执行过程。现代调试器中的每一项功能——断点、单步跳过 (step-over)、观测表达式 (watch expressions)、条件断点、热重载——都是建立在这种确定性之上的。你暂停执行是因为暂停是有意义的。你向前单步执行是因为下一步是可预知的。你检查一个变量是因为它的值是一个事实，而不是从某种分布中随机抽取的结果。

你的状态页显示为绿色。你的错误率为零。你的 p95 延迟看起来比上周略好。而在上周二，eval-on-traffic 指标在悄无声息中下降了四个点，整整九天都没人发现原因。因为当质量回退最终突破告警阈值时，已经有四个交织在一起的根因叠加在一起，团队已经无法分辨是哪一个最先引发了下滑。

这是 2026 年成熟智能体系统的主要故障模式，它不是任何单一组件的 bug。它是团队刻意构建的防御栈——那些出于好心、一个接一个添加的安全网——所产生的累积效应。主模型返回了垃圾内容；重试成功了。重试失败了；更便宜的回退（fallback）模型给出了答案。回退模型的输出格式错误；包装器（wrapper）将其重写为看起来合理的形状。包装器记录了一个软告警（soft warning）。没有人针对软告警设置告警。用户收到一个看似正确、交付流畅，但实际上比系统设计初衷要差的答案。

鲁棒层起作用了。质量表现却崩塌了。而告警机制是为鲁棒层存在之前的世界构建的。

你正在对接的采购团队最终会提出一个重置你架构的问题：“我们可以自带模型 API 密钥吗？”回答“可以”能赢得订单。但回答“可以”同时也意味着你的信任边界、成本边界和运营边界发生了转移 —— 而大多数产品团队只有在合同签署、第一个月的使用产生了一个没人知道如何回答的服务工单后，才会发现这一点。

BYOK 在公司内部推销时被视为一个开关。客户粘贴一个密钥，你的代码从保险库（Vault）读取它而不是从你自己的账户读取，然后推理流程照常进行。但这并不是一个开关。这是一场由销售驱动的架构重构，它会波及成本分摊、安全事件响应、可观测性、速率限制、模型版本锁定以及值班问责。那些在没有意识到这一点的情况下就交付产品的团队，最终会在一年后为了修复这些问题而重构整个平台层，而付费企业客户则在焦急等待。

你智能体系统提示词中的工具描述是一个六个月前的评估产物（eval artifact）。它说 search_pricing 返回“带有结构化定价的最新库存数据”，规划器（planner）对此深信不疑，因为自描述调优的那天起，提示词中的任何内容都没有更新过。而实际上，在过去的 40 分钟里，search_pricing 端点的 p95 延迟一直保持在 11 秒，因为上游供应商正在对你的账户进行限流。而那个被提示词描述为“可能略微陈旧”的更便宜的 search_cache 工具，只需 200 毫秒就能返回同样的答案。但规划器还是选择了 search_pricing，因为描述读起来仍和评估时一样，且规划器没有任何关于目前调用这两个工具成本的信号。

这就是静态工具描述的结构性失效。规划器是在根据一个已经发生变化的世界快照做出路由决策。工具选择实际上并不是一个能力问题——大多数生产环境中的智能体都有两三个在回答内容上高度重合的工具——它本质上是一个“等待成本”问题，而等待成本正是你的提示词模板所看不见的东西。

传呼机在凌晨 3:02 响起。你眯起眼睛盯着手机，预料着那些常见故障：数据库故障转移、CDN 边缘节点失联，或者是某个八个月没人碰过的服务出现了 500 报错峰值。然而，警报显示的是：summarizer.eval-on-traffic.helpfulness rolling-1h: 4.21 → 4.05 (Δ -0.16)。没有 HTTP 错误。没有延迟峰值。没有服务宕机。系统在过去一小时内处理的每一个请求都返回了 200，并且响应体解析正常。然而，情况显然比午夜时分变糟了，而值班轮换要求你查明原因。

这种值班任务是标准的运维手册中从未提及的。出故障的东西并没有“坏掉”——它只是退化（regress）了。你多年来追踪的错误预算是以可用性和延迟来衡量的，而触发此次报警的故障模式在两者中都不可见。报警是真实的，客户受到的影响也是真实的，而你通常的诊断循环——检查部署日志、检查依赖图、查找错误的发布版本、执行回滚——在你意识到那个“错误的发布”可能只是昨天下午 4 点上线的一个 30 行系统提示词（system-prompt）的修改时，便碰了壁。在代码审查中，那次修改看起来完全无害。

用户打开你的聊天窗口，提了一个问题，得到一个评估套件打分为 4.6（满分 5 分）的回答。接着，他们换了一种说法问了同样的问题。同样的回答，同样的分数。他们又试了一次，这次用了人们在怀疑机器没在听时常用的套话——“我实际上想做的是……”——然后他们关闭了标签页。从模型的视角来看，这是三个干净的问答轮次。从仪表盘的视角来看，这是一个活跃的会话。但从用户的视角来看，这是一个连续三次失败的产品，而且以后再也不会打开了。

这就是“单轮评估”（per-turn evaluation）无法察觉的失效模式。孤立来看，每一轮对话似乎都是正确的。裁判（Judge）给了赞。幻觉检测器保持沉默。相关性评分很高。然而，整个对话作为整体并没有解决任何问题——而这正是用户真正评估你的单位。

太平洋时间凌晨 2 点，你的评估套件（eval suite）在平静的提供商环境下全绿通过。上线前一晚 11 点，QA 进行了冒烟测试。功能正式发布。到了周二上午 10 点（东部时间），你的 p95 延迟比你签字认可的仪表盘高出了 40%，你的智能体（agent）在一个包含六步的计划中丢掉了最后一个工具调用，而你的支持信箱塞满了听起来如出一辙的工单：“今天早上 AI 表现很奇怪。” 谁都没错。模型也没错。错的是评估集 —— 它从未见过饱和的提供商环境，因此对于当队列深度翻倍、截止时间预算（deadline budget）崩溃时功能会如何表现，它无法给出任何参考建议。

提供商负载不仅仅是一个伴随质量副作用的延迟问题。它是你的模型和智能体循环接收到的输入的一种分布偏移（distribution shift），而你所信任的每一个质量信号，都是建立在这个分布中错误的那一截之上的。解决办法不是换一个更快的区域或更好的模型。解决办法是停止假装你的评估框架是在与你用户相同的世界中进行采样。

每个将智能体（agent）投入生产环境的团队，最终都会遇到类似的事故。智能体进入了一个无法退出的状态。它在六个小时内反复调用同一个工具，只是参数在表面上略有不同。它在两个前提条件互斥的计划之间摇摆不定。它每隔两百毫秒重试一次瞬时的 429 错误，一直持续到天亮。它生成了一个包含百万 token 的计划，却从未执行。等到有人察觉时，token 账单已达四位数，下游 API 被限流，客户会话已超时十二次，而值班工程师正被针对同一根因的三个不同告警狂轰滥炸。

每个团队首先想到的解决方法都是步骤计数预算（step-count budget）。将智能体限制在 20 次迭代。限制在 50 次。定个数字，然后上线。步骤预算确实让事故报告消失了，但它并没有消除底层问题 —— 一旦你理解了其中的机制，你就会发现步骤预算相当于智能体世界里的家用保险丝：它是在损害造成之后才熔断的，保险丝盒本身现在成了维护负担，而下次发生故障时，你的本能反应是换一个更大规格的保险丝，而不是去追究到底哪里短路了。

一个团队负责摘要生成器。另一个团队负责摄取这些摘要的搜索排序器。第三个团队负责一个路由，根据排序器的置信度分数在不同的智能体人格之间进行选择。这些团队都没有共同的值班轮换，也没有人参加同一个站会，他们之间唯一的契约就是“上一个功能的输出是下一个功能的输入”。周二，摘要团队收紧了一个提示词，以修复销售演示中反馈的幻觉问题。六小时后，搜索排序器的质量骤降。到周三早上，路由开始将任务交给错误的智能体人格。复盘报告会将原因记录为“提示词变更”，但实际原因是团队的 AI 功能已经悄然组成了一个没人绘制过的有向图。

这是最常见的 AI 故障形式，它不会触发你为 AI 故障构建的任何警报。模型没有宕机。被修改功能的评估套件显示为绿色。Token 成本曲线很平稳。真正断裂的是两个功能之间的接口，你的依赖工具将其视为纯文本，因为在 API 边界它确实只是纯文本——并且将其视为惰性的，因为纯文本不携带版本、Schema 或弃用策略。

上个季度评分 92% 的评估集（eval set）现在评分达到了 94%，团队称之为进步。事实并非如此。该评估集中的标签是根据标注员脑海中早已模糊的准则（rubric）编写的。模型评分所针对的产品已经发生了变化。标准已经发生了变化。标注员自身的校准（calibration）也发生了变化。表面上 2% 的提升，实则是静态产物与动态产品之间无声的差距，且只要团队不更新，这种差距每周都会扩大。

标注漂移（Annotation drift）是成熟 LLM 评估方案中一种隐蔽的失效模式。它不会表现为回归（regression）——回归是简单的情况，因为数值会下降，从而触发人员调查。它表现为一个持续显示绿色的数字，而其原本衡量的内容在底层已经腐烂。已经建立了评估集、编写了准则并招募了标注员的团队面临的风险最大，因为他们信任自己构建的系统，从而停止了对基础的审计。

一个健康的评估集（eval set）本应是成熟的标志。但在任何一个周一，它也可能意味着排队等待的 1,000 个失败案例，而人工审核员只有 8 小时，且每个案例的处理效率大约是 50 个。这笔账很残酷：大约每 20 个失败案例中只有一个会被阅读。剩下的 19 个只能等待。至于哪 19 个在等，哪一个能被选中，完全取决于文件加载的顺序。

大多数团队将其称为“审核失败案例”。但它更像是一场按字母顺序加权的抽奖。一个影响 2% 生产流量且位于文件顶部的失败案例会得到关注。而一个影响 40% 生产流量但位于文件底部的失败案例，即便能被看上一眼，也要等到周五下午。团队在周二发布了针对小问题的修复方案，并在周四写了一份回顾（retro），纳闷为什么仪表盘上的指标毫无变化。