系统没挂，AI却在悄悄变蠢？Grafana想用SLO管住它

周三下午，你的Agent监控面板一片绿。可用性100%，延迟正常，token消耗稳定。但用户投诉在涨——回答越来越不靠谱，只是没人能说清从哪天开始的。

Grafana Labs最近提出了一套思路：把评估、服务等级目标（SLO）和错误预算这套可靠性工程的老办法，搬到AI Agent的行为管理上。幻觉、任务完成度、毒性内容、成本，这些原本模糊的东西，被要求变成可长期监测的量化目标。

问题的根子在于，传统可观测性根本答不上"这个回答对不对"。指标能告诉你Agent响应很快、没报技术错误、烧了多少token，但没有一项能说明答案是否准确、是否有据可依、对用户是否有用。Grafana的做法是：直接评估行为本身，把结果变成可测量的SLI，再拿去和SLO比对。

第一步是评估，不是打分

一次评估，就是检查一次Agent交互是否满足某个行为标准。Grafana举的例子包括：回答是否基于给定上下文、是否完成了用户请求、是否含毒性内容、是否泄露个人信息、是否被提示注入攻破。

评估可以用另一个语言模型当裁判，但在行为能被确定性识别时，正则表达式这类检查同样够用。

这里有个关键分歧：Grafana明确反对搞一个统一的"Agent质量分"。质量是多维的——一个Agent可能引用扎实但很贵，可能有用但偶尔有毒，可能准确但很慢。拆成独立测量，团队才能针对自己应用真正在意的行为分别设目标，而不是把要命的失败藏进一个聚合分数里。

错误预算：允许你烂多少

行为一旦可测，SRE那套概念就能直接套上。Grafana给的例子是：设定一个SLO，要求30天内95%的对话被判定为已完成。剩下那5%，就是错误预算——团队明确决定在这段时间内可以容忍的不可接受行为总量。

这套东西的价值不在百分比本身，而在它带来的决策模型。预算充足时，团队可以放手试提示词、换模型、调Agent行为；预算被消耗，优先级就该从"继续改"转向"先修质量"。这跟SRE团队多年来在可靠性和迭代速度之间做的权衡，本质是同一件事。

Grafana现有的SLO工具也是这个逻辑：用SLI、目标值和时间窗口定义SLO，错误预算由目标值与100%之间的差额算出。

它真正好用的场景，是Agent行为慢慢变坏、而不是突然崩掉的时候。传统告警能抓到失败请求的尖峰，但Agent可以一边正常响应，一边让答案悄悄变得没那么有用。换模型、改提示词、动检索、用户行为漂移，都可能让质量每天掉零点几个百分点。

盯错误预算的燃烧速度，能让这种漂移显形。单次糟糕交互放在30天目标面前不算什么，但持续下滑会稳定吃掉预算。这给出的信号和传统基础设施监控不同：重点不是某一次执行有没有失败，而是系统的整体行为是否正在滑出约定的可靠性边界。

最难的不是建SLO，是定标准

可用性目标有几十年的运维经验垫底，但一个Agent的完成度或引用准确度该定85%、95%还是99%，行业远没有共识。

Grafana的办法是先用评估建立基线，再拿历史结果推荐一个合适的目标，随着Agent成熟逐步收紧。

这背后是可观测性覆盖范围的位移。Grafana自己的Agent Observability工作，就源于监控Grafana Assistant时发现：提示词、模型、工具一变，传统监控就不够用了。在社区讨论中，Grafana工程师区分了离线评估和在线评估——前者用已知场景验证改动，后者拿真实生产交互检验行为。

传统可观测性问的是系统是否可用、是否在技术限制内运转。AI系统多了一层：系统的决策和输出是否还在可接受的行为边界内。这就在评估、可观测性和工程改动之间形成闭环，更像持续的质量测量，而不是传统的应用监控。

一个绕不开的限制

SLO再漂亮，也只在底层测量靠谱时才有意义。如果当裁判的LLM持续误判，算出来的错误预算会给人虚假的精确感。同样，设计糟糕的评估可能奖励Agent产出"技术上满足标准、实际没满足用户意图"的东西。

所以团队仍然需要：有代表性的评估数据集、对可接受行为的清晰定义、尽可能用上的确定性检查、对模糊案例的人工复核，以及对评估器本身的持续验证。SLO提供的是治理机制，它不会让底层质量测量自动变正确。

SLO一直是工程团队平衡可靠性与变更的共同语言：定义什么重要、测量它、设定可接受阈值、用剩余的错误预算指导决策。把这套思路用到AI Agent上，等于把模型从系统可靠性延伸到行为可靠性——一个Agent可以技术上一直在线，运营上却越来越不可靠，因为它的答案在变得更不准、更没依据、更贵或更不安全。

把这些行为当成可测量的服务目标，团队才有机制发现这种退化，并判断什么时候该停止实验、开始修复。意义不在于Grafana又多了一个AI指标，而在于一套成熟的SRE原则，被搬到了一个"系统还活着、但越来越不可信"的环境里。

行业里不止Grafana在动。Anthropic为Agent开发了更正式的评估实践，用定义好的任务、重复试验和多个评分者，衡量Agent能否稳定达成预期结果。它区分了pass@k和pass^k——前者看多次尝试中是否至少成功一次，后者看是否每次都成功，这对"可靠性比最终找到答案更重要"的生产级Agent尤其相关。

OpenTelemetry则在另一层下手，推进Agent遥测的标准化语义约定，让trace、指标和日志能跨框架、跨厂商提供一致的评估基础。三条路径拼在一起，浮现出一个模式：评估判断Agent行为对不对，可观测性提供证据，SLO提供判断行为是否可接受的操作阈值。