当你的智能体具有自愈能力时，MTBF 已死

我上个季度交流过的一个团队，他们的所有仪表盘都显示绿色。工具错误率稳定在 0.3%。端到端成功率为 98%。SLO 预算几乎没动过。但他们的 Token 支出却是预计的四倍，而且没人能解释原因。当他们最终对每个 Trace 的重试深度进行埋点时，情况发生了反转：成功请求的中值实际上进行了 2.7 次工具调用，而不是架构图里承诺的 1.0 次。智能体（Agent）并没有失败。它是在同一个 Span 内部不断失败又不断恢复，而成功率指标根本无法体现这一点。

这是传统可靠性词汇无法涵盖的智能体可靠性部分。MTBF（平均故障间隔时间）假设故障是断续的、可观测的事件，你可以在两次故障之间进行计数。你测量间隔，计算平均值，并在间隔缩短时发出警报。这对于硬盘、网络和确定性服务都很有效。但对于那些在单个用户可见的操作内部进行重试、重定向、降级并静默恢复的系统来说，它失效了。

经典模型在“系统正常工作”和“系统出现故障”之间有一道整齐的界限。智能体抹去了这道界限。现代智能体的运行是一个尝试图谱，返回绿色状态的叶节点隐藏了智能体为了达到目的所做的一切。一个通过的 Trace 可能包含三次失败的工具调用、一次重新提示（re-prompt）、一次降级到更廉价的模型以及最终成功的检索——而所有这些都被压缩成了一个 200 响应和一位满意的客户。你多年来一直关注的指标，在不知不觉中已被重新定义。

故障分布不再有间隙

MTBF 是一个依赖于故障 之间 时间的计算。必须存在“之间”。在确定性服务中，“之间”很容易界定：服务要么正常，要么宕机，间隙非常明显。在智能体中，这些间隙消失了。智能体的运行时结构被设计为将故障吸收为正常操作的一部分。超时变成了重试。Schema 不匹配变成了带有修正示例的重新提示。工具错误变成了切换到另一个工具。在旧定义下，这些每一个都是故障。但在新架构下，它们都不算数，因为用户得到了他们想要的。

这不是运行时的 Bug。这正是其核心所在。自愈（Self-healing）正是你选择智能体框架而不是普通 LLM 调用所追求的特性。代价是故障信号被掩盖了。你不再有一连串离散的故障来计算间隔——你面对的是一个持续的恢复成本分布，而 SLO 唯一能看到的只是那些完全脱离恢复机制的尾部。等到 MTBF 发生变化时，系统可能已经退化数周了。

数学逻辑在更细微的层面上也是错误的。MTBF 假设故障事件大致上是独立的——这就是为什么你可以取平均值并让它具有参考意义。智能体的故障是系统性的。当模型对工具的 Schema 产生错误理解时，对该工具的每次调用都会以同样的方式失败，三次重试会犯三次同样的错误。重试分布是相关的，而不是独立的，对它取平均值产生的数字并不能描述你现有的系统。

应该衡量什么

替代指标集由三部分组成，只有结合起来看才有意义。

恢复后成功率 (Success-rate-after-recovery) 是用户可见的质量信号。它是用户获得正确答案的频率，无论智能体为了产生这个答案消耗了多少次内部故障。这正是你现有的成功率指标自认为在衡量的东西，但在大多数技术栈中，它都被污染了——静默失败并产生错误但看似合理的回答的智能体也被计入了成功。为了使该指标可信，你必须在动作级别而不是响应级别定义正确性。ReliabilityBench 的框架在这里很有用：通过最终状态而非输出文本来定义正确性。预订真的发生了吗？行真的更新了吗？邮件真的发送到正确的地址了吗？回答的文本只是见证，而非事实。

单次成功的恢复成本 (Recovery-cost-per-success) 是隐藏的成本。对于每个成功的 Trace，计算超出最优路径的工具调用次数、重试次数、降级跳转以及消耗的 Token。这个指标能捕捉到那些看起来健康但消耗了预期支出四倍的系统。恢复成本是一个你可以列入预算的数字，也是一个可以放在仪表盘上与收入并列的数字。当恢复成本上升而成功率持平时，说明底层发生了一些变化——工具变慢了、模型变笨了、Schema 漂移了，或者用户行为发生了转变——而智能体正在悄悄补偿，没有告诉你。

每个 Trace 的恢复尝试分布 (Recovery-attempt distribution per trace) 是潜在风险指标。绘制出每个 Trace 在成功前经历了多少次恢复跳转。一个健康的系统大部分 Trace 的恢复次数为零，少部分为一次，超过两次的几乎没有。一个退化的系统，其尾部会变厚。关键在于，这个指标在成功率变动 之前 就会发生移动。它是针对一类缓慢退化的早期预警通道，而 MTBF 只有在这些退化已经造成破坏后才能捕捉到。要将分布的形状视为信号，而不仅仅是其平均值——具有五次以上重试 Trace 簇的双峰分布与统一向一次重试偏移的情况是完全不同的问题。

这三个指标共同取代了 MTBF 过去的作用。用户可见的质量、生产该质量的成本，以及成本上升的早期信号。在你的监控栈中，默认情况下一个都没有。它们都需要具有重试深度和恢复类型作为一等属性的结构化 Trace 数据。

没人预算过的 4 倍恢复税

我见过的最常见的失败模式是，团队在上线数月后发现，他们的 Agent 的 Token 成本是预期成本的三到四倍，而仪表盘上的指标却毫无波动。这种模式非常普遍，甚至值得拥有一个专门的名字：隐形恢复税。

这种情况之所以发生，是因为 Agent 运行时在重试方面非常激进。当模型被要求调用一个参数格式错误的工具时，它会发现错误、道歉、重新格式化并重试——而这整个循环都发生在一次响应内部。用户只会看到回复稍微变慢了。汇总仪表盘显示的是一次成功的请求。但 Token 计费器看到的是三次输入上下文和三次输出补全，而不是一次。月底的账单金额将与上线时的人均请求成本预测完全不符。

算术逻辑是残酷的。4 倍的恢复税看起来并不像 4% 的失败率，而更像是 0% 的失败率和 300% 的成本超支。工程团队开始寻找是不是 Prompt 变得太长了，或者是检索拉取了太多的分块（Chunks），或者是模型被悄悄切换了。而真正的核心原因——Agent 在过去六周里一直在默默地从破碎的工具 Schema 中恢复——却从未浮现，因为标准的可观测性堆栈中没有将“恢复跳步”（Recovery Hops）视为一等公民。

修复方法是结构性的。每一次重试、降级、重新提示（Re-prompt）和恢复操作都需要成为 Trace 中独立的 Span，并标记恢复的原因。这不是一行日志，也不是父 Span 上的一个属性，而是一个子 Span。这正是让恢复成本可计算的关键。一旦每次恢复都成为一个 Span，你就可以按原因进行分组，将成本归因于具体诱因，并在无需费力取证的情况下回答类似“本周哪个工具的 Schema 不匹配导致了 30% 的恢复成本？”这样的问题。如果没有 Span 级别的恢复检测，你就是在靠运气运行。

揭示恢复过程而非仅显示结果的可观测性架构

如今大多数 LLM 可观测性堆栈都建立在一个隐含假设之上：即请求是最小关注单元。这个假设继承自 Web 服务监控，但对于 Agent 来说是错误的。真正值得关注的单元是“恢复图谱”：即产生最终结果的尝试和降级路径的结构。揭示该图谱才是架构层面的任务。

三个具体的转变使这变得可行。首先是 Trace 中的重试语义：每一次重试都是一个带有显式 retry-reason 和 retry-attempt 属性的兄弟 Span，而不是堆积在父 Span 上的属性。其次是恢复类型化：区分工具重试、模型降级、重新提示和断路器重连。它们的成本和影响各不相同。第三是恢复感知采样：即使对其他所有内容进行采样，也要 100% 保留具有非零恢复跳步的 Trace。那些成功的“异常”才是最有价值的失败——这些是你无法承受丢失的 Trace。

这种做法通常会带来第二个好处，足以证明其工作价值。恢复感知的 Trace 存储是事后分析的加速器。当某些事情真的彻底崩溃时，“在失败变得可见之前，成功率之下发生了什么？”这个问题突然有了答案。你可以回溯到故障发生前的一周，看到恢复分布在变厚，恢复成本在攀升，以及重试率在悄悄上升的具体工具。以前像“考古”一样的事后分析变成了“取证”。原因一直都在数据中——只是之前的架构没有将其揭示出来。

这对 SLO 意味着什么

如果你使用旧有的确定性服务的 SLO 定义来交付 Agent，那么你就是在盲目飞行。新的 SLO 维度至少需要包含三条线：质量 SLO（定义为经过恢复后对比最终状态 Oracle 的成功率）、成本 SLO（定义为对比架构理想路径的单次成功恢复成本），以及稳定性 SLO（定义为零恢复 Trace 的百分比）。第三个指标是最难承诺的，因为它迫使你承认：恢复是你宁愿不需要的东西——即使它能奏效。

我见过的最健康的生产环境 Agent 并不追求自愈。它们追求的是“不需要自愈”。自愈被视为安全气囊，而不是方向盘。当恢复率攀升时，团队会将其视为一种退化，而不是功能在更卖力地工作。他们会去修复 Schema、重新训练工具描述、简化 Prompt、缩小模型规模——处理任何处于恢复上游的环节——而不是庆祝安全气囊正确弹出。只有当指标堆栈真正将恢复显示为一种“税收”而非“胜利”时，这种姿态才成为可能。

在故障被设计所吸收的架构中，MTBF（平均故障间隔时间）注定无法存活。现在的任务是衡量这种吸收耗费了你多少成本，并在成本波动早于用户感知的质量变化时发出告警。大多数 Agent 平台自带的仪表盘尚未考虑到这一点。那些构建了自己工具的团队——将每一次恢复视为一等可观测对象，像预算延迟一样预算恢复成本，观察分布而不仅仅是平均值——才是那些在上线一年后 Agent 运行成本依然低廉的团队。而那些信任绿色仪表盘的人，将在下个季度难以置信地盯着他们的云账单。