智能体的 SLO 与错误预算

正确性在 SLI 必须通过的三项测试上全数不及格。

一个服务水平指标是"好事件 / 有效事件"的比值，你能从遥测里廉价地、近实时地算出它。经典 SRE 指标轻松达标——200 是好、503 是坏，不需要任何东西去解读。"智能体答对了"在每一条上都不及格，而这些不及格是结构性的，不是你能补上的工具缺口。

• 没有标签。在生产里没人知道正确答案；用户正是因此才来问的。离线评测之所以有标签，是因为标签是你亲手构造的——而这恰恰使它成为一件离线仪器。
• 代理指标是一个自带错误率的模型。用一个 LLM 裁判去给线上流量打分，会给你一个数字；而这个数字会随裁判模型更换、提示分布漂移、或裁判自己被流畅度骗到而移动。一个度量装置会独立于被度量系统而漂移的 SLI，撑不起一份预算。LLM 裁判很有用，但它不是仪表。
• 延迟量级完全不对。人工裁定或下游结果确认要以天计。而燃烧率告警假定你在几分钟内就能知道消耗了多少。一份只能事后对账的预算是会计练习，不是运营控制。
• 分母也不稳定。对智能体来说，"有效事件"包含了它本该拒绝的请求、本身就有歧义的请求，以及用户中途改主意的请求。经典 SLI 白得一个干净的分母；智能体没有，而一个建立在漂移分母之上的目标值，会因为与智能体毫无关系的原因而移动。

把指标分成三层，只给第一层配预算。

有用的重构是：你手上不是"一个有度量问题的质量信号"，而是三种延迟不同、可信度不同、职责也不同的信号。区别对待，每一种都会变得可用。

• 第一层，机械层。确定性、从 trace 算出、秒级可得：请求可用性、尾部端到端延迟、任务完成率（循环带着结果终止，而不是撞上步数上限、超时、未处理的工具错误或"拒绝继续"）、工具调用错误率、重试率，以及每任务成本对其上限的占比。它们的行为与经典 SLI 完全一致，配得上真正的目标值和真正的错误预算。
• 第二层，代理层。快、便宜、与质量相关但不是质量：会话内的用户重试、智能体输出与用户最终采用版本之间的编辑距离、完成前的放弃、升级转人工，以及点踩率。延迟以分钟计、有噪声、方向上诚实。它们该配的是为变化而非绝对水平调校的告警阈值，因为它们的基线孤立来看毫无意义。
• 第三层，裁定层。抽样流量由裁判或人打分，以及在存在的情况下——那个被确认的下游结果：真的成立的预订、没有被重开的工单、没有被拒付的退款。延迟以天计、样本量小、可信度高。它们属于每周的控制图和你的发布闸门，永远不属于值班传呼。
• 三层都发布，并且在每个数字旁边标注它属于哪一层。智能体指标造成的组织性伤害有一半来自"一个第三层的数字被当成第一层来读"。在数字旁边写上"抽样，n=200，滞后 3 天"，是一个能熬过每一次组织调整的一行修复。

机械层比团队预想的更强。尤其是任务完成率，它能捕捉相当大一部分真实退化——一次模型变更让智能体一直循环到步数上限、一次工具 schema 漂移引发一串错误、一次提示词编辑让它开始拒绝一个常见请求——这些全都在秒级、确定性地显形，且不需要任何裁判参与。

目标值从消费方的需要推导出来，并把"未知"记为失败。

靠挑一个整数定出来的目标值，是凌晨三点没人愿意为之辩护的数字。从下游契约推导它，然后写清楚未达标时会发生什么——正是后半句才让它成为 SLO 而不是仪表盘。

• 问清楚：智能体失败时，消费方会怎么办。如果一次失败的运行会静默回落到一个尚有余量的人工队列，你的可用性目标可以很宽松；如果一次失败意味着一笔被放弃的结账，那就不行。目标值是智能体所处工作流的属性，不是智能体的属性。
• 延迟目标看尾部，并按任务类别分开设。混合负载上的单一 p95，会被那一周占比最高的类别主导。智能体的延迟是真正多峰的——一次单工具查询和一次十二步的调研运行是共用同一个端点的两种服务——所以要么按类别拆开目标值，要么就接受这个数字毫无意义。
• 把"完成了但无法核验"记在你的失败一侧。如果智能体跑完了，却没有任何下游产物确认那个副作用，那不是成功，那是未知。会预订、会写入、会付款的系统，其结果是可查询的，因而没有借口；把未知当作通过，正是一条坏掉的写路径能连续两周保持绿灯的原因。这与核验结果而非轨迹是同一套纪律。
• 给拒绝率一个独立目标，且是双向的。拒绝率上升是退化；拒绝率下降可能是一次安全回归。两者在"把拒绝算作干净终止"的完成率指标里都看不见，所以要单独测量，并且给出一个目标区间而不是一个上限。
• 把每任务成本放进 SLO 集合，而不只是放进财务复盘。一个每任务 token 花费翻倍的智能体，坏在了可用性永远显示不出来的地方，而它是少数几种带有直接线性成本的智能体故障之一。把这个目标值与循环层成本控制里那个 fail-closed 上限配成一对。

为"危害"跑第二份预算，因为一个可用性完美的智能体照样在造成损害。

这一部分在经典 SRE 里没有对应物，也正是原封不动搬运 SRE 手册会留下窟窿的原因。一个还活着的 Web 服务，大体上并没有在伤害你；一个还活着的智能体则在采取动作，而动作就是产品本身。可用性与危害接近于两根独立的轴，因此需要两份独立的预算。

• 按动作类型具体定义危害事件。一次被回滚的写入。一条发错收件人的消息。一笔越出政策的退款。一张关掉后一天内被重开的工单。一次本该发生却没发生的升级。它们可数、有归属，而且正是你的管理层真正害怕的那些事件。
• 用"已采取动作数"而非"已服务请求数"作分母来做预算。一个在错误率不变的情况下把动作量翻倍的智能体，危害也翻了倍，而以请求为分母的指标会把它报成持平。分母必须是那个能伤到人的东西。
• 按可逆性而非频次加权。三份被撤回的草稿和一笔不可逆的对外付款，不是同一起事故。至少保留两档——可恢复与不可恢复——配不同的预算，并让不可逆那一档的预算接近于零。可逆性正是让你有余地去跑一个智能体的东西。
• 危害预算耗尽的后果是收缩自主度，不一定是停服。这是第二份预算最有用的性质。当它被烧穿，正确的应对通常是把受影响的那一类动作挪到人工审批之后，或者收窄工具范围，而智能体继续服务其余一切。这是一种可用性预算表达不出来的分级控制。
• 把每一起危害事件回灌成回归测试。该事件已经包含了 trace、输入和错误结果。一起没有变成测试用例的事故一定会重演，而智能体事故响应存在的主要意义就是把这个闭环变成强制的。

第一层用燃烧率告警，第二层用变化检测，第三层永远不告警。

标准的多窗口燃烧率告警在机械层上原样可用，在其余层上则效果很差或根本不成立。把告警机制与信号的延迟匹配好，就是"一次有意义的传呼"与"一个不再看告警的值班表"之间的大部分差别。

• 第一层配多窗口燃烧率。一个快窗口抓宕机、一个慢窗口抓持续渗漏，且快告警需要慢窗口附议才呼人。智能体没有改变这里的任何东西。
• 第二层配变化检测，不配阈值。"重试率是 8%"什么也不说明；"重试率从 4% 移到 8% 并持续了两小时"才说明问题。用滚动基线加一个偏移检验，这正是质量回归检测所搭建的机器——同时记住每一个第二层信号都被流量构成所混淆，所以在相信一次移动之前，永远先分段。
• 第三层守发布闸门，永不传呼。一个滞后三天的裁定分数无法为值班决策提供依据，而把它挂上传呼只会训练值班组忽略告警。它的岗位是灰度发布与版本化里的晋级闸门，以及每周复盘。
• 也要对输入分布告警。用户在问什么发生了变化，是一个先于任何质量信号到达的先行指标，而且它能解释相当大一部分本来会被误诊为模型回归的波动。从 trace 里算它很便宜，而且它让上面那条"先分段"成为可能。
• 每条告警都要写明版本三元组。模型、提示、工具 schema。没有它，每次事故的头二十分钟都花在"到底什么变了"上，而对智能体来说答案经常是"我们这边什么都没变"——是某个厂商在你脚下改了东西。

只有当花掉预算会改变你被允许发布什么时，错误预算才真的存在。

预算不是一次度量，而是一份事先谈妥的决定。它写于事故之前——没人承压、也没有哪次发布悬而未决的时候——从而把一场争论变成一次查表。跳过这一步，你造出来的就只是一块非常精致的仪表盘。

• 把政策写成一张后果表，并让那个能推翻它的人签字同意。预算健康：发布、放宽自主度、抬高限额。预算烧掉一半：发布需过评估闸门并走金丝雀。预算耗尽：冻结行为变更、回滚到上一个已知良好的三元组，且下一个工作项是可靠性。
• 给智能体的回滚目标是一个固定的三元组，不是一个 git commit。行为是（模型、提示、工具）这三者合起来的；在厂商已经悄悄升级了模型的情况下回滚你的代码，什么也恢复不了。这就是为什么"固定版本"这条纪律是"拥有 SLO"的前置条件。
• 让自主度成为第一根拉杆，排在全面停机之前。在"正常运行"与"急停开关"之间有一条很宽的带：收窄工具范围、对高风险动作类别加人工审批、降低步数上限、切到更便宜的兜底路径。把它们设计成配置开关，让值班无需发布即可伸手够到——这正是面向智能体的特性开关存在的目的。
• 把计划内的消耗做进预算，并且真的花掉它。一份从不被消耗的预算，说明目标值太松或团队太保守，两者都值得知道。有意为之的实验——金丝雀里的新模型、一次范围放宽——正是预算存在的理由。
• 每季度拿目标值与现实对一次。智能体负载的形状比经典服务变得更快，因为人们带来的任务会随着信心一起生长。一个按上季度流量构成设定的目标值，量的是一个你已经不再运行的服务。

相关：追踪与可观测性是这一切据以计算的遥测，事故响应与失控遏制讲预算被快速烧穿时怎么办，智能体可观测性是地基。