233 篇博文 含有标签「observability」

当你的财务团队第一次问，为什么单个用户在回答一个价值 0.1 美分的问题时产生了两美分的账单，那个电话讨论的不会是模型，而是发票上那行十二个月前还不存在的项目：推理 Token (reasoning tokens)。在账单上它们看起来像输出 Token，在大多数服务商那里也按输出 Token 的费率计费，而且它们没有天然的上限。一个在非推理模型上只需产生 400 个 Token 回复的查询，可能会悄无声息地消耗 8,000 个内部思考 Token 才能得出答案——唯一注意到这一点的人是核对支出的人。

在 API 时代的大部分时间里，“使用的 Token 数”是一个诚实的数字。你输入提示词，得到响应，账单是两者的清晰函数。推理模型打破了这种直觉。模型现在在发出调用者将阅读的答案之前，会生成一个隐藏的、可计费的、仅内部可见的思维链，而该链的大小取决于模型自身对问题难度的评估。用户可见的输出可能只有一句话，而账单可能长达十页。

我上个季度接触的一个团队上线了一个他们称之为“路由项目”的东西：在他们的旗舰模型前端放了一个微型 BERT 分类器，用来判断查询是否足够简单，以便分流给更便宜、更快速的备选方案。这个项目在三周内就回本了。成本仪表盘上绿光一片。旗舰模型的评估套件——包含三百个对抗性案例、每周的评分运行等等——依然在每个周五稳稳通过。

上线六周后，某个特定产品界面的留存率下降了四个百分点，没人能找到原因。旗舰模型表现正常。延迟也正常。结果发现，路由竟然将 71% 的查询发送到了廉价模型。这种情况从第二周就开始了。对于大多数用户来说，这个廉价模型才是真正的产品，而这个廉价模型根本没有任何评估套件。

这是我在 2026 年看到的采用 LLM 路由进行成本控制的团队中最常见的失败模式：评估规范被绑定在系统的昂贵长尾部分，而廉价的头部部分——即承载大部分请求量、定义了产品体验的部分——却处于盲跑状态。

你的 AI 技术栈中最危险的数据存储是那个无人设计的存储。这一切始于一次冲刺期间的 Slack 消息：“真实用户是捕捉真实 Bug 的唯一途径 —— 让我们把一定比例的生产流量接入评估流水线，以便我们可以每晚进行回放。”六名工程师给这条消息点了赞。九个月后，该存储桶包含了 430 万条追踪（traces），当失败率上升时，评估任务会呼叫值班人员，而失败案例会被逐字发送到一个有 40 人阅读的 Slack 频道。这些追踪包含电子邮件地址、公司内部名称、部分信用卡卡号、员工电话号码，以及用户解释其愤怒原因的客户支持对话记录。

没有人梳理过数据流。没有 DPIA（数据保护影响评估）涵盖它。上季度的隐私审查查看了模型供应商的 API；但它没有查看你的评估任务。然后，一份数据主体删除请求送达，团队发现“删除该用户的所有数据”这句话已经无法对应到他们实际能做的任何事情。

一位产品经理（PM）带着一张幻灯片走进 AI 功能评审会，上面写着：“参与度 +12%，会话时长 +8%，留存率上升 3 个百分点。” 房间里的人纷纷点头。而在两个工位之外，客服主管正盯着另一张图表：涉及 AI 界面的工单增加了 22%，最常见的处理逻辑是“用户放弃，由人工客服协助”。这两个数字都是真实的，且都来自同一个产品。PM 的仪表盘建立在这样一个假设之上：AI 功能产生的事件形状与它所取代的按钮完全相同。事实并非如此。仪表盘统计的数据与用户实际体验之间的差距，正是 AI 功能在众目睽睽之下悄然失败的原因。

确定性功能的操作手册将交互视为点击流：用户触发一个事件，系统做出反应，用户继续操作。AI 功能具有不同的事件形状——一个包含阶段、重试、转向人工以及遥测数据永远无法看到的离线判断的“任务弧”（Task Arc）。将确定性仪表盘套用在这个任务弧上，就像是用 2018 年的面试流程来筛选 2026 年的工作职位。数字在上升，但这些数字本应预测的结果却在下降。

运维工程师调出一个 trace。模型已返回，span 正常关闭，API 调用显示 stop_reason: end_turn。从平台提供的各种信号来看，这是一次成功的生成。3 分钟后，客户报告说 Agent 煞有介事地写了半个配置文件，宣布操作完成，然后就继续下一步了。Trace 里没有任何预警信号，因为预警信号不在 API 协议里 —— 供应商提供的停止原因只有四到七类，而你的事故排查所需要的答案，恰恰隐藏在这些类别的缝隙之中。

停止原因（Stop reasons）是工程师在故障排查时最先查看的字段，也是最具误导性的字段。这些值是为运行时（runtime）设计的，旨在决定下一步该做什么：这一轮是否完成了？是否请求了工具？是否超出了预算？安全检查是否介入了？它们并不是为了让开发者重建答案出错的原因而设计的，而这两者之间的差异，正是生产团队耗费整个下午的时间所在。

每个 Agent 功能都有一个自主性上限，一旦超过这个上限，用户就会开始检查工作、进行干预，或者彻底放弃该功能。这个上限并不是你模型的属性，而是由你的用户、领域以及出错成本决定的。它不会因为发布演示稿说它该移动就移动。大多数团队都是通过惨痛的教训才发现这个天花板的：发布的功能被设计为完全自主，但采用率却停滞在“Agent 建议，人类批准”的阶段，指标把责任推给模型，而接下来的一个季度则花在调整一个从未成为瓶颈的旋钮上。

这个上限的形状在各种产品中都足够一致，以至于它值得拥有一个名字。Anthropic 自己关于 Claude Code 的使用数据显示，新用户在约 20% 的时间内使用完全自动批准，只有在经过大约 750 次会话后，这一比例才会攀升至 40% 以上。PwC 2025 年对 300 名高管的调查发现，79% 的公司正在使用 AI Agent，但大多数生产部署都运行在“协作伙伴”或“顾问”级别——即模型提议，人类决策——而不是营销所暗示的全自主层级。这些数字背后的故事并不是用户胆小，而是信任是根据可挽回错误的成本进行校准的，而你的产品几乎肯定没有以用户需要的方式让他们看到、撤销或限制这些成本。

一个模型提供商发布了 99.9% 的可用性 SLA。采购团队将其理解为“三个九，每年四个小时的停机时间，对于非 0 级（非核心）工作负载是可以接受的”。六个月后，智能体（Agent）功能上线，值班仪表板显示用户感知的任务成功率约为 98% —— 这个数字没有写进任何合同，在提供商的状态页面上也找不到，而且没有人为此负责。提供商满足了他们的 SLA，而产品却没达到其 SLO。两者同时成立，而这种差距并不是一个 bug —— 这是一个算术问题。

大多数团队都忽略了算术这部分。提供商的 99.9% 是针对同步请求工作负载进行衡量的 —— 一个用户，一个提示词，一个响应，一个计费事件。而智能体并不会产生这种工作负载。一个用户感知的任务会扇出（fan out）为 8 到 20 次推理调用，它会对瞬时错误进行重试，对慢速调用进行对冲（hedge），并聚合部分输出。每一次调用都是对提供商故障分布的一次独立抽样，如果任何关键调用失败，任务就会失败。SLA 覆盖的边界和用户感受到的边界并不是同一个边界。

我认识的一位后端工程师在一个周二的下午盯着一个从未有过波动的 Datadog 图表：其内部日历服务的单用户 429 计数器。投诉的客户并没有改变他们的行为。他们只是开启了助手功能，现在每当用户说“帮我找下周的时间”时，该功能就会针对同一个日历 API 并行启动八个规划线程。速率限制器（Rate Limiter）——每用户每分钟 60 次请求，这个设置非常合理，是多年前针对一个在物理上无法点击得那么快的 UI 编写的——在每次请求的前三秒内就会触发，并悄无声息地破坏了助手一半的响应。

速率限制不是 Bug。契约才是 Bug。那个后端，就像大多数在 2024 年之前编写的内部服务一样，在每一层都植入了一个悄然执行的假设：一个用户意味着一条活动流，其节奏受限于人类的反应时间，拥有一个 cookie 罐、一个 CSRF 令牌和一套在出现问题时可以重新提示的凭据。Agent 一次性粉碎了所有这五个假设，故障表现为一系列看似无关的事件——429 风暴、“最后写入者胜”（last-write-wins）导致的数据损坏、无法取证的审计日志、挂起无头工作线程的重新认证循环——在模式被命名之前，没有人会将它们联系起来。

我一直与平台团队沟通的一个简短总结是：你拥有的每一个后端都与它的调用者有一个未记录的契约，而那个契约是与人类协商达成的。现在 Agent 出现了，要求重新协商。你可以选择在代码审查中主动进行协商，也可以选择在下一次事故期间被动进行。

某家厂商在周二下午向模型别名推送了一个“小幅更新”。到了周四，四家客户公司正在进行事件响应。他们本周都没有部署代码。他们的仪表板上没有任何关于延迟、错误率或任何其他基础设施维度的指标退化。改变的是，在他们固定的别名背后的模型开始返回略有不同的句子、略有不同的 JSON 以及略有不同的拒绝——而他们的团队针对旧行为编写的每一个提示词（Prompt）现在都成了一份没人履行的合约。

这种不对称性就是问题的核心。供应商将这次发布视为一次部署：经过内部测试，通过了一些聚合评估，并在维护窗口内逐步推向 100%。而消费端将其视为一次语义化版本（semver）违规：一个依赖项在生产环境中自动升级，却没有更改其版本字符串，随后最终用户的错误报告接踵而至，主题还带着轻快的“我们这边什么都没改”。

你的推理火焰图（inference flame graph）有一个成本轴，但没有能源轴。这种差距在某天早上之前都没问题，直到客户的采购团队给你发来一份包含 23 列供应商可持续性披露信息的电子表格，其中一列是 每 1,000 次推理的 kgCO2e。你没办法填那一格，你的供应商给出的答案是一篇方法论论文，而交易将在 9 天内关闭。你的平台团队磨练了两年的 token 成本仪表盘突然看起来像是解决了一个错误的问题。

这里的转变并非抽象的。可持续性披露正在从公司层面的汇总转向产品层面的颗粒度。第一波浪潮于 2025 年进入了 CSRD 和 ESRS，而第二波浪潮现在正冲击着 B2B 采购合同。构建了成本可观测性的工程组织即将发现，他们需要针对碳排放的可观测性，而这两者在同一个 span 上并非同一列。

一个用户打开聊天窗口，请求退款，得到“抱歉，此次购买不符合退款条件”的回复后，关闭了标签页，再也没有回来。在内部，智能体生成了一条完美的追踪记录：工具调用、中间推理过程、参考的政策包，以及运行的模型版本。每一个 span（追踪跨度）都进入了可观测性平台。但没有任何内容是用户可以触及的。这里没有标为“请求人工再次审核”的按钮，即使有，后面也没有相应的服务。这个决定在默认情况下就是终局，而非设计使然。

这就是“可争议性差距”（contestability gap），它是监管机构、律师和愤怒的用户接下来要撕开的口子。这也是一个最典型的例子：一个从外部看像是政策问题，而从内部看实际上是工程链路（plumbing）的问题。

智能体自信地报告：“我已将会议改至周四下午 3 点。”用户却盯着原本周二上午 10 点的时段发呆，因为在智能体制订计划到提交更改的这段时间内，用户自己编辑了该事件。“最后写入者胜”（Last-write-wins）策略让自动化的操作覆盖了人类的修改，而用户对助手的信任也因这一次事故而崩塌。这就是双写竞争（dual-writer race），也是智能体工具链从未专门设计应对的 bug 类别。

大多数智能体平台都无意中继承了这一问题。工具层将 update_event 视为一个简单的函数调用：获取 ID，获取新字段，返回成功。底层的提供商 API 十多年来一直提供乐观并发原语（optimistic concurrency primitives）——ETags、版本令牌（version tokens）、If-Match 前提条件——但几乎没有人将它们贯通。模型无法知道它一分钟前所推理的世界已不再是现状，因为由于它所获得的抽象层静默地丢弃了这些信息。