拒绝“大声失败”的 Agent：过度补偿的回退机制如何掩盖生产环境的质量回退

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

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

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

无人审计的补偿栈

如果你列出智能体在生产流量中每小时发出的“静默补偿”，你会发现它们的数量比你记得添加的要多。有针对 429 速率限制响应的指数退避重试。有针对 503 供应商不可用的重试。当主模型的断路器触发时，有从主模型切换到更便宜备选模型的回退。如果结构化输出解析失败，有尝试使用更简单 Schema 的工具回退。有修复截断输出的 JSON 修复环节。在编排器中，有“如果本轮查找无结果则使用前一轮工具结果”的分支。有防止下游出现空值的“默认空字符串”路径。当拒绝分类器触发时，有通过更委婉的措辞引导模型的内容政策重试。还有在请求的版本被中途废弃时触发的模型版本固定覆盖。

每一个补偿都是为了响应真实的事故而添加的。每一个在 Slack 讨论串、事故复盘文档或代码注释中都有其合理性。而且从个体来看，添加它们都没有错。

问题在于集体效应。每一个补偿都隐藏了一个系统原本应该暴露的故障模式。429 重试隐藏了供应商的容量问题——这很有用，除非由于你的使用模式发生变化且无人察觉，导致限流率本身正在发生偏移。模型回退隐藏了主模型的能力下降——这很有用，除非主模型下降的原因是你本来想要调查的。JSON 修复环节隐藏了格式偏移——这很有用，除非格式偏移是 Prompt 在新模型版本下悄然失效的征兆。防御层将每一个信号变成了“非事件”（non-event），而这些非事件堆叠起来，形成了一个其实际故障面对于运营它的团队来说是不可见的系统。

这就是生产型智能体中的“可靠性演戏”。仪表盘显示“可用”。但交付的东西越来越不是你所宣传的东西。

为什么评估套件无法捕捉它

本能的反应是：“好吧，我们有 eval-on-traffic，那应该能捕捉到质量回退。” 它确实会。但最终才会。问题在于“最终”是否足够快。

Eval-on-traffic 捕捉的是相对于基准线的累积质量漂移。从结构上讲，它无法告诉你漂移发生的原因。当评估信号移动了四个点并触发告警时，回退已经运行了数小时或数天，底层状态已经发生了多次变化（昨天下发了模型迁移，今天早上合并了 Prompt 修改，供应商的回退模型本身也经历了一次悄无声息的更新），此时你的溯源问题变成了多个重叠变更的 N 路连接（n-way join）。

更糟糕的是，评估套件在构建时并没有关于回退触发的假设。在主模型上以 95% 置信度评分良好的案例，在回退模型上通常也评分良好——这就是为什么该回退模型最初被批准为备选的原因。而那些能区分两者的案例——即主模型的额外能力至关重要的边缘案例——从未被明确特征化，因为没有人为“回退模型能力不足时的查询”编写评估切片（eval slice）。而这个切片恰恰是当前静默质量下降的重灾区，而你的通用 eval-on-traffic 并没有关注它。

这就是“eval-on-traffic”与“感知回退的 eval-on-traffic”之间的差距。前者问的是“系统是否在产生好的输出？”后者问的是“考虑到系统走的是哪条路径，它是否在产生好的输出？”如果你不将质量信号与补偿信号结合起来，你就是在假设每一次调用都走的是理想路径（happy path）来给系统评分。而系统正通过那些无人关注、未被路由到仪表盘的软告警，大声地告诉你事实并非如此。

故障模式可见性预算

解决这个问题的准则比智能体（agents）还要久远——它是 SRE 中的“故障模式可见性”概念，经改造后用于 AI 功能的可靠性。重新定义：每一次静默补偿（silent compensation）都是一个“质量预算项”，而非可靠性的胜利。一旦动用，你就欠系统一个遥测数据，用以指明你买了什么以及付出了什么代价。

实际上，这意味着每一个后备路径（fallback path）发出的都应是结构化事件，而非一行日志。该事件指明了正在补偿的内容（“主模型返回了格式错误的 JSON”）、补偿措施是什么（“使用减少的 max_tokens 和更严格的 schema 进行重试”），以及衡量下游影响的基准（“输出质量切片：结构化输出正确性”）。该事件具有采样率、质量影响评估和路由标签。它是一个一等公民的追踪跨度（trace span），而非一个 warn 日志。

一旦事件结构化，你就可以执行团队所需的操作。你可以询问：“每个补偿路径的激活率是多少，按功能界面、模型版本和客户群细分？”你可以询问：“当后备路径 X 触发时，该功能界面的流量评估（eval-on-traffic）在一小时内是否存在明显的漂移？”你可以询问：“在最近的发布窗口中，哪些补偿的激活量高于基准值，发生了什么变化？”这些问题能将原本耗时四天的取证分析转化为半小时的查询。

可见性预算还强制进行了一场工程团队一直推迟的对话：每个后备方案必须声明“它被允许隐藏什么”。针对 429 的重试被允许隐藏瞬时的限流波动，但不允许隐藏持续的过度使用——因此，设计中有一个明确的阈值，超过该阈值后，重试将不再静默，而是开始触发告警（paging）。模型后备被允许隐藏暂时的主要故障，但不允许隐藏持续的主要性能退化——因此，设计中有一个熔断器重置窗口，超过该窗口后，后备方案的持续激活将成为一类事故。JSON 修复环节被允许隐藏微小的格式偏移，但不允许隐藏模型版本导致的格式倒退——因此，设计将修复率作为领先指标进行监测，并针对其斜率（变化率）而非绝对水平发出告警。

在代码中，每种补偿旁边都写着一句话：“我应该在什么情况下失败”。如果没有这句话，补偿就是未定义的——因此也是无界的。

对补偿进行混沌测试

一旦有了可见性预算，你就可以对其进行压力测试。这种模式能带来回报，但 SRE 们第一次听说它被应用于 AI 功能时可能会感到脊背发凉：在影子流量中，故意逐个关闭补偿，观察会发生什么故障。

该技术非常直接。将一部分生产流量镜像到影子环境。在影子环境中，禁用一个补偿路径——例如，廉价后备模型路由。让影子环境运行几个小时或一天。将影子环境的行为与生产主路径进行对比：有多少请求彻底失败，有多少产生了明显变差的输出，评估套件评分的质量切片发生了怎样的偏移，延迟又是如何变化的。

你所发现的很少是你预料之内的。你发现廉价后备方案在高峰时段承担了 12% 的流量，而你原以为只有 3%。你发现结构化输出重试路径在针对某个特定工具的调用中触发率为 28%，因为八周前的一次提示词修改导致模型多出了一个没人注意到的尾随逗号。你发现 JSON 修复环节是防止下游仪表板显示空白的唯一支柱——模型已经返回格式错误的输出两个月了，而修复环节才是真正的可靠性支柱，而非备选方案。

这些发现证明了混沌练习的价值。健壮层（robustness layer）承担了无人估算的负载，隐藏了无人命名的退化，并产生了一个如果被公开、团队本会拒绝的质量结果。这种练习并不能修复任何问题——但它迫使团队停止假装底层的主路径是交付产品的唯一途径。

技术背后的组织失效模式

技术模式是可以修复的。组织模式才是它不断重现的原因。

在大多数交付 AI 功能的团队中，SRE 职能奖励的是“健壮性”——正常运行时间、错误率、延迟——并通过绿色的仪表板获得回报。AI 质量职能奖励的是“质量”——评估分数、裁判一致性、客户报告的退化——并通过缓慢提升的指标获得回报。这两个职能向不同的领导链汇报，优化不同的目标函数，且很少出现在同一个事故审查会议中。

补偿栈（compensation stack）存在于两者之间的边界。SRE 增加了重试、后备方案和修复环节，因为增加它们能提升可靠性指标。AI 质量团队在两周后观察到评估指标漂移，却无法将其追溯到特定的变更，因为这种变更不是代码变更——而是一种“梯度”，即无人负责的补偿激活的累积转变。

架构上的修复方法是建立一个单一职能——称之为 AI 可靠性工程，或者组织喜欢的任何名称——它同时负责边界的两侧：专门针对 AI 功能的 SRE 指标、质量指标，以及展示两者相关性的联合仪表板。该职能的运行手册将后备激活的持续增加视为一类事故，而非仪表板上的绿色正常事件。该职能的值班人员会在故障模式可见性预算被突破时收到告警，而不仅仅是在 5xx 错误率上升时。

如果没有这个职能，边界就会一直存在，补偿会不断积累，而团队将继续写着同样的事故复盘报告，针对那些根源在于“系统工作得太出色，以至于拒绝大声报错”的质量退化。

可靠性方案现在就是补偿层

核心观点并非“移除你的回退机制 (fallbacks)”。生产环境中的 Agent 需要它们。服务商会返回 503。主模型偶尔会输出格式错误的 JSON。下游工具会超时。补偿机制正是解决这些问题的正确答案。

核心结论是，现代 Agent 的可靠性方案就是补偿层 —— 而非它所备份的主路径。一个在生产环境中大规模运行 AI 功能的团队，实际上是在运行一组软故障处理程序 (soft-failure handlers)，它们的集体行为决定了用户最终看到的内容。如果这组程序未经审计，那么该团队交付的产品质量实际上是由一堆防御性代码决定的，而这些代码的作者中，目前可能没人能端到端地描述清楚它们。

审计这些补偿机制。明确每一个机制允许掩盖什么。将它们作为一级事件 (first-class events) 进行监控，而不是当作静默修正。针对它们的激活率（而不仅仅是失败率）设置告警。每季度进行一次混沌测试，以便团队重新了解系统到底依赖什么。并让一个职能部门对“可靠性与质量”的共同方案负责，因为这两者之间的界限正是你生产环境中 Agent 每一个隐形退化 (silent regression) 的藏身之处。

拒绝显性失败 (fail loud) 的 Agent 最终还是会失败。问题在于，它是以一种团队可以调试的方式失败，还是在客户续约电话出问题时才被团队发现。