当你的智能体具有自愈能力时，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 簇的双峰分布与统一向一次重试偏移的情况是完全不同的问题。

加载中…