智能体能力悬崖：为什么你的模型升级让简单的 95% 变得完美，却让困难的 5% 成了你最糟糕的季度

你上线了新模型。综合评估通过率从 91% 提升到了 96%。产品团队在全体员工大会上宣布这是一次重大胜利。六周后，可靠性团队却迎来了有史以来最糟糕的一个季度——并不是因为故障变多了，而是因为现在每一个故障都需要三名工程师花上两天时间才能解决。

这就是智能体能力悬崖 (agent capability cliff)，它是生产环境 AI 中最反直觉的失败模式之一。模型升级并不会均匀地提升所有任务的表现。它们将增益集中在大部分流量上——即那些旧模型原本就能在大部分时间内处理正确的简单和中等案例——而长尾中真正困难的输入却只看到了微乎其微的改进。你的失败面缩小了，但剩下的每一次失败都是能力边界案例，这些案例旧模型也处理不了，而且简单的提示词工程 (prompt engineering) 也无法修复。

这个“悬崖”并不是新模型的缺陷。它是我们衡量模型改进的方式（混合难度评估集的平均通过率）与值班排班中实际遇到的问题（最难流量的残差集，现在已经没有了以前占据主导地位的简单故障的缓冲）之间的不匹配。

为什么平均值掩盖了悬崖

数学逻辑很简单，但团队总会忽略它。假设你的评估套件有 1,000 个案例，简单、中等、困难的比例约为 60/30/10。旧模型在这些类别的得分分别为 98%、90% 和 40%。新模型的得分分别为 99%、96% 和 45%。整体通过率从 90.4% 提升到 95.7%——五个百分点的飞跃，看起来是一次强力升级。

现在看看残差（故障案例）。在旧模型中，105 个失败案例里，12 个来自简单类别，30 个来自中等，60 个来自困难。在新模型中，只有 6 个简单案例和 12 个中等案例失败了——但仍然有 55 个困难案例失败。困难类别在失败案例中的占比从 57% 飙升至 75%。在生产环境中，这意味着升级后的值班频道里，绝大部分都是工程师最缺乏直觉处理的案例，因为以前那种由简单路由错误、中等歧义和困难逻辑错误构成的混合模式，已经坍缩成了几乎全是困难逻辑错误。

研究界早已意识到这一点。一篇针对前沿模型的故障聚焦评估指出，综合基准测试分数虽然便于排名，但掩盖了与实际部署相关的系统性失败模式。《Capability Frontier》论文更正式地阐述了这一点：没有一个模型能在所有基准测试中占据绝对优势，且综合排名对权重方案高度敏感。用产品术语来说，综合数据上“5% 的提升”只是测试组合分层方式带来的产物，而非全面的性能提升。

没人提醒你的值班模式变化

升级后，即使综合质量指标在向好发展，事故类型的分布也会发生让团队猝不及防的变化。

事故变少了，但每一个都更难。 使用新模型的团队报告称，常规类别问题的平均修复时间 (MTTR) 减少了 40–60%，但剩下的故障集几乎全是边界问题。在这些案例中，模型需要对不寻常的文档结构进行多步推理，或者两个工具的能力存在细微重叠导致规划器选错，亦或是用户的意图确实存在歧义，而旧模型中“通过澄清问题来对冲”的启发式策略，在新模型中为了“直接尝试”而被训练掉了。

调试直觉不再适用。 针对旧模型编写的排障手册——“如果输出看起来像 X，检查检索器；如果看起来像 Y，检查系统提示词”——会失效，因为旧的失败模式特征源自简单和中等案例。困难类别的失败有其独特的指纹，而你的运行手册从未记录过它们，因为你以前总是忙于修复那些低成本的错误。

严重程度难以简单量化。 当事故发生时，合规领域的一个面向客户的错误答案，其严重程度与常识问答中的五十个错误答案完全不同。来自在事故响应密集领域运行 AI 的团队建议明确指出，严重程度框架只能引导判断，而不能取代判断——这是能力悬崖对残差风险特征影响的直接结果。

领导层基于错误的信号进行模式识别。 “我们升级了，质量提高了”在综合层面确实是真的，因此高层的叙事会以标题数字为主。试图对现在的 100% 困难案例失败率表示担忧的可靠性工程师会被告知要“见好就收”。这种叙事与运营之间的鸿沟，正是最糟糕季度的开端。

难度分层通过率：在发布前暴露悬崖的评估纪律

如果悬崖是由综合平均引起的，那么药方就是分层报告。在做出任何升级决策之前，每个生产评估套件都应该发布按难度等级拆解的通过率。

一个适用于大多数智能体产品的可行分层方案：

• 简单 (Easy)： 任何体面的模型都应该处理正确的案例。常规分类、范围明确的检索、输入明确的单步工具调用。目标通过率在 98% 以上。
• 中等 (Medium)： 模型表现存在差异的情况。轻微歧义、两步推理、在相似选项中选择工具。目标通过率 85–95%。
• 困难 (Hard)： 即使是最好的模型也经常失败的情况。对对抗性文档布局的多步推理、潜在的约束冲突、要求模型先拒绝再重定向的指令、来自先前事故的极端情况。目标是尽力而为，但要明确追踪增量。
• 前沿探测 (Frontier probes)： 目前没有任何模型能解决的案例。保留这些案例是为了防止评估饱和掩盖进度，并在新模型确实突破天花板时提供早期信号。

来自提示词回归社区的一个实用规则：如果你的评估集中 90% 是简单案例，那么 95% 的通过率是毫无意义的；套件中至少应有 30% 是困难或对抗性案例。同类手册中的另一条规则：2% 的整体下降可能掩盖了某个单一类别中 15% 的溃败，因此务必按类别拆分分数，并报告每个层级的增量，而不仅仅是综合得分。

重点不在于为了困难层级的表现而阻碍发布——那个类别的数据永远会比领导层希望的要难看。重点在于让这个数字与综合数据一起可见，这样房间里的任何人都不会把“平均值上升”误认为“难题变容易了”。

加载中…