无真值情况下的智能体 SLO：为无法实时评分的输出建立错误预算

你的智能体平台连续一年每季度都达到了 99.9% 的“响应成功率”SLO。但工单量增加了 40%。受智能体引导的用户群体的留存率却在下降。轮值运维感到无聊，产品经理在恐慌，而管理层评审一直在问，为什么仪表盘显示一切正常，而支持队列却显示情况一团糟。仪表盘没有撒谎。它只是衡量了错误的东西 —— 因为编写 SLO 的 SRE 将成功定义为“模型 API 返回了 200”，而这正是遥测系统最初唯一能表达的成功定义。

这是智能体可靠性工程的核心问题：成功的信号不是状态码。它是一种关于智能体是否针对特定任务做了正确事情的判断，而这种判断在请求时是无法获得的，通常在会话时也无法获得，有时只有在几天后，当用户提交工单、修改输出或悄无声息地流失时，才能揭晓。你无法在一个尚不存在的列上标记“200 对比 500”的布尔值。

常见的反应是等待获得基准真相（ground truth）后再宣布 SLO。这是错误的。可靠性工作不会在你构建标注流水线时暂停。正确的做法是针对你明知不完美的代理指标（proxies）编写错误预算，将它们命名为代理指标，设定团队在指标触发时的响应策略，并在产生基准真相后将其回填到计算中。这篇文章将探讨如何在不自欺欺人的情况下做到这一点。

为什么延迟 SLO 的策略失效了

经典的 SRE 框架假设你衡量的 SLI 与你真正关心的用户满意度之间存在紧密循环。延迟是一个典型的例子：一个耗时 800ms 而非 200ms 的请求会让用户不高兴，这一点你可以在请求时、在同一个遥测流中确认，无需任何标注。SLI 不是用户满意度的代理指标 —— 对于延迟敏感型系统，它几乎就是同一个变量。

智能体功能在各个维度上都违背了这一假设。用户希望从智能体那里得到的是正确、有用、符合上下文的任务完成结果。而你的平台能观察到的是一系列工具调用、令牌（token）流和 HTTP 状态码。这些都不是正确性。模型可能返回 200 状态码但给出一个自信的错误答案；它可能工具调用失败，但优雅地恢复并给出一个有用的响应；它可能在正确的情况下（好事）或错误的情况下（坏事）转给人工处理，而仪表盘将这两种情况都记录为“升级（escalations）”。

更深层次的问题在于时机。延迟在请求内部是可观察的。工具错误在会话内部是可观察的。智能体是否做了正确的事，有时只有在用户明天回来修改产出物，或者根本不回来时才能判定。一个基准真相有 24 小时到 30 天滞后的 SLO，在结构上与基准真相位于响应头中的 SLO 完全不同。假装它们相同，正是导致团队出现仪表盘与工单数据背离的原因。

你可以实时衡量的代理 SLI

代理 SLI 是一个与真实成功相关的变量，你可以在已有的遥测流中观察到它。这些都不是真相。但如果将其中每一个都纳入组织公认的代表可接受降级的预算中，它们就足以支撑发布。

适用于大多数智能体产品的代理指标：

• 升级率 (Escalation rate) — 智能体会话转人工的百分比。上升的升级率很少是好消息，但下降的也不一定是好事。过度谨慎的阈值会导致一切都升级；太宽松的阈值则会让错误答案通过。跟踪这个比率，并同时跟踪“升级原因的分布”。
• 重试率 (Retry rate) — 用户在短时间内重新发送或重新组织提示词的会话百分比。重新提示是用户在告诉你上一次回答没对；这是你在无需标注的情况下，能收集到的最清晰的会话内不满信号之一。
• 放弃率 (Abandonment) — 没有明确结束动作（购买、保存、发送、接受）就结束的会话百分比。放弃率比重试率噪音更大 —— 用户放弃的原因可能与质量无关 —— 但与基准线相比的持续偏差是有意义的。
• 产出物的编辑距离 (Edit-distance on artifacts) — 当智能体生成用户可以修改的东西（草稿、配置、查询）时，用户随后修改的大小是衡量初稿偏差程度的量化代理指标。零编辑意味着接受；90% 的编辑意味着用户想要件外套，智能体却给了个衣架。
• 工具调用失败聚合率 (Tool-call failure cluster rate) — 不仅是工具调用是否失败，还包括它们是否以智能体无法恢复的模式失败。健康的重试是循环的一部分；无限制的重试风暴则是可靠性事件。

对这些指标最诚实的描述是：“超过此预算将警示与用户不满相关的回退（regression），尽管我们仅凭此信号无法确定我们捕捉到了真实错误中的多少比例。”这句话应该出现在 SLO 文档中。否则，下一季度的评审员会将代理指标视为基准真相，并得出系统运行良好的结论。

黄金样本集：异步真值如何实现闭环

代理指标会告诉你出了问题。但它们不会告诉你智能体响应中到底有多少比例是错误的。为了弥补这一差距，你需要一个黄金样本集（gold cohort）：以已知速率提取的生产流量样本，根据符合你真实成功标准的准则进行异步评分——然后反向传播到 SLO 计算中，这样你就能引用真实的错误率，而不仅仅是代理指标。

关键机制：

• 以生产规模采样，而非以便利性规模。 从内部演示或测试用户中提取的黄金样本集，几乎无法告诉你系统在面对真实提示词的长尾分布时表现如何。生产可观测性的标准做法是，对高流量提取 1–10% 进行在线评分，对高频率采用低成本检查，对低频率采用昂贵的 LLM 裁判评估。根据你的评估预算来选择采样率，而不是根据你的愿望。
• 在请求路径之外进行异步评分。 同步运行的裁判会让你的延迟和推理账单翻倍。在后台针对日志追踪（traces）运行的裁判，不会产生用户感知的成本，并能产生一个持续的质量信号，你可以将其展示在仪表盘上。
• 在信任裁判之前，先针对人工进行校准。 LLM 作为裁判是人工评分的一种可扩展且可行的替代方案，但前提是你已经衡量了裁判与人工审核员在留出集（held-out set）上的一致率。如果你的裁判与人工的一致率为 70%，那么你的“真实”错误率其实也是一个代理指标——只是它比重试率更好。每季度重新校准一次；模型升级会改变裁判的行为，这种改变看起来像质量偏移，但其实不是。
• 反向传播到 SLO。 一旦黄金样本集评分在已知的置信区间内产生评分错误率，SLO 就可以分为两个层级：一个实时报警的快速变动代理预算，以及一个每周更新且供组织审查的慢速变动评分预算。代理指标捕捉回归（regressions）；评分数值捕捉代理指标的谎言。

没人预先提醒的经济现实：建立诚实的智能体 SLO 所需的标注和黄金样本集基础设施，与诚实评估所需的基础设施是同一套。将它们视为分开的预算会导致团队最终两手空空——评估因为“我们有监控”而被削减预算，监控因为“我们有评估”而被削减预算，最终生产中的系统完全没有诚实的衡量标准。

“我们尚不清楚”层级

标准的告警层级有两种状态：绿色（正常）和着火（告警）。智能体 SLO 需要第三种状态——明确的未知——因为请求与真值之间的滞后意味着存在一个窗口期：代理指标显示正常，评分数值尚未送达，而你无法做出任何诚实的结论。

一个可行的层级体系：

• 绿色 —— 代理指标在预算内，评分数值在预算内，支出速率无异常模式。
• 黄色 / 未知 —— 代理指标在预算内，当前窗口的评分数值尚不可用。不要为此呼叫（page）；但要在仪表盘上显示出来，以免评审人员误将“无信号”当成“好信号”。
• 红色代理 —— 至少有一个代理预算的消耗速度超过了 SLO 允许的范围。呼叫值班人员；在假设代理指标出错之前，先调查底层信号。
• 红色评分 —— 评分数值已跨越 SLO。呼叫领导层和模型团队；这等同于真实的停机事故。

设置未知层级的目的是为了防止值班轮换受到噪音干扰，同时确保领导层在真相尚未被评分的窗口期内，不会因绿色的仪表盘而产生虚假的安全感。代理告警应被视为真实信号，而非误报——即使后来证明底层的响应是正常的。代理指标的波动总是有原因的；理解这个原因就是工作内容。

没有真值时的错误预算策略是什么样的

错误预算策略——即规定当预算消耗时团队被允许和被要求做什么的文件——对于智能体系统需要增加一个段落，而无状态 Web 服务则不需要。标准的 SRE 策略大致是：“如果我们消耗了预算，就冻结高风险变更，直到恢复。”这之所以奏效，是因为 SLI 就是事实。

对于智能体系统，该策略必须处理四种标准策略无法涵盖的情况：

1. 代理红色，评分绿色 —— 代理预算消耗了，但随后送达的评分数值显示响应是正常的。调查代理指标波动的原因。不要反射性地放宽代理指标：没有质量下降的代理指标波动通常意味着用户行为改变了（他们提出了更难的问题，正在使用新功能，或者发现了一个边缘案例），这种改变值得去理解。
2. 代理绿色，评分红色 —— 代理指标保持在预算内，但评分数值显示质量下降。这是最危险的失败模式：这意味着你的代理指标失效了，或者它与质量的相关性已衰减。预算冻结适用，并且代理指标本身要进入下一季度的路线图。
3. 两者皆红 —— 标准的消耗响应：冻结、寻找根因、修复、复盘。
4. 评分数值不可用 —— 明确命名为一种状态，并设定截止期限。如果评分数值延迟超过 N 天，策略将升级为“我们没有诚实的可靠性信号”，这本身就是一类事故。

这里的架构认知是，人工智能可靠性工程不是“凭感觉的 SRE”——它需要一种与现有遥测栈不同的观测原语。这个原语就是带有异步真值的评分结果，整个策略必须重写以处理时间滞后和代理/评分的双重性。如果一个团队直接将延迟 SLO 策略原封不动地移植到智能体平台并发布，他们并没有产生智能体 SLO；他们只是产生了一个安慰剂。

本季度该做什么

如果你正在生产环境中运行一个没有明确 SLO 的 Agent 功能，接下来的路并不是等待一个完美的标注流水线。这条路应该是：

1. 从你现有的日志数据中挑选出三个你可以立即衡量的代理 SLI（Proxy SLI）。人工介入率（Escalation rate）、重试率（Retry rate）以及一个特定于产品的信号（如编辑距离、放弃率、完成耗时）是一个合理的起步方案。
2. 将初始预算设定在“当前性能加上团队认为不可接受的回归容忍度”这一水平。不要试图在第一次尝试时就设定正确的预算；迭代循环本身才是重点。
3. 建立一个“黄金样本（gold-cohort）”采样器，将 1–10% 的生产流量拉入评分队列。先用校准后的 LLM 裁判进行评分，再辅以人工审核样本进行二次校准。
4. 按照上述的四种情况结构编写错误预算政策，并确保仪表盘上显示“未知（unknown）”层级。
5. 安排季度复盘，根据评分数据重新验证代理预算。如果相关性已经衰减，那么代理指标本身就是问题所在。

做到这一点的团队可以底气十足地说出那些仅依靠“响应成功率 SLO”的团队无法说的话：当出现问题时，他们能在以天（而非季度）为单位的时间窗内察觉；而当情况看起来异常时，他们能在几分钟内确定是系统发生了变化，还是信号本身发生了变化。这种差距——即“等待用户反馈”与“通过自有遥测数据获知”之间的差距——正是“运营一个 Agent 平台”与“仅仅部署一个 Agent 平台”之间的本质区别。