智能体能力悬崖：为什么你的模型升级让简单的 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% 的溃败，因此务必按类别拆分分数，并报告每个层级的增量，而不仅仅是综合得分。

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

能力边界探测：在进入生产环境前寻找“悬崖”

难度分桶衡量的是你已知案例中的“悬崖”。能力边界探测则试图找出那些你尚未知晓的案例。这之所以重要，是因为你真实的生产环境长尾（Long Tail）几乎总是比你最难的评估分桶还要困难——你的评估集是由人类策划的，当覆盖范围看起来完整时，人类就会停止添加案例；而生产环境的流量却不会。

能持续发现新悬崖案例的探测策略包括：

能够从先前的失败中生成边缘案例的自适应基准测试。 每一个事故都会被模板化为一系列类似的输入：失败模式相同，但表现形式不同。随着时间的推移，这将产生一个动态的困难层评估集，它会在模型最薄弱的地方生长，而不是停留在原始基准测试的形态。现代评估栈明确支持这一点——生成具有不同复杂度和新颖性的新问答对，自动生成干扰项以挑战推理链，并让评估成为一个动态的目标。

人设（Persona）与输入分布的变化。 对于评估中的每一个困难案例，生成十个变体：不同的用户人设、不同的措辞、不同的文档长度、不同的工具输出格式。如果模型通过了标准形式但在变体上失败了，那么即使综合数字看起来不错，它在该项能力上也是脆弱的。

针对后 5% 而非平均水平的回归探测。 你的评估报告应该明确展示困难层中任何出现回归的案例，即使综合指标有所提升。在实践中，少数困难层的回归会隐藏在大规模的综合增长中，而这些回归就是未来的事故。要在案例层面而非分桶层面暴露它们，以便评审人员可以阅读失败文本并决定其是否可以接受。

有预算限制的长程任务。 遵循 RE-Bench 和 τ-Bench 推广的模式，在具有真实预算的多步任务上评估智能体（Agent）——比如 8 小时的计算时间、50 次工具调用，或者任何与你产品类似的指标。在这些任务上的表现能比任何单轮评估更好地预测生产环境在困难层的行为，因为生产中的悬崖案例几乎总是涉及长程路径或工具编排，而非单次提示词的质量。

针对悬崖状残差重新架构 On-Call 流程

即使是完美的评估流程也无法消除悬崖——你仍然会发布升级，而困难的长尾仍然会是你的事故来源。解决办法是针对这一现实重塑 On-Call 流程，而不是假装工作内容和以前一样。

按事故特征而非严重程度进行路由。 由于残差集中在困难分桶中，通用的分诊轮值会浪费那些真正能解决这些案例的专家的精力。处理得好的团队会将困难层事故路由给一小部分已经内化了失败模式的工程师，即使这会导致 On-Call 负载分布不均。

针对能力类别而非错误代码编写 Runbook。 旧的 Runbook 根据可见症状索引故障：工具选错、引用缺失、输出格式错误。新的 Runbook 应该根据底层能力进行索引：“针对嵌入表格的多跳推理”、“监管领域的拒绝与重定向”、“具有重叠目录的工具选择”。当你遇到新事故时，将其匹配到一个能力类别，并继承该类别的集体调试历史。

为特定模型的 On-Call 适应期留出预算。 每一个重大的模型升级都需要一段 On-Call 变得更难（而非更易）的时期，即使指标显示并非如此。为升级后 4–6 周的艰难报警期做好计划并配置相应的人力，比另一种方案要划算得多——另一种方案是领导层一直指着绿色的综合增长数字，而资深工程师却因职业倦怠而离职。

预先承诺困难层的底线。 在升级发布之前，就最低可接受的困难层通过率达成明确共识。如果新模型提高了综合指标，但使困难层跌破了底线，那么即使产品端想要降低延迟或成本，该升级也不予通过。预先承诺可以避免一种极其普遍的动态：即一旦发布已经在进行中，由悬崖主导的残差就会被事后协商为“可接受”。

悬崖对模型选择策略意味着什么

更深层的教训是，“新模型更好”通常是针对你分布中简单和中等难度的核心部分而言的。它对你的产品是否更好，取决于你的事故究竟源自何处。对于大多数度过了试点阶段的生产 AI 系统来说，事故几乎完全来自困难层。

这重新定义了一些常见的决策：

• 在边界上的升级总会带来某些代价。 最近发布的模型已经明确了这一点——例如，Claude Opus 4.7 在智能体编码和诚实度上有所提高，但相对于 4.6，在 Web 搜索基准测试上有所回归。如果你的困难层主要由 Web 搜索任务主导，那么这次“升级”对你的 On-Call 来说就是一次降级。综合指标的增长对你而言无关紧要。
• 版本固定（Model Pinning）是一种风险管理工具，而非守旧习惯。 那些固定特定模型版本（而非使用 -latest 等动态别名）并在切换前通过分层评估体系运行新版本的团队，能够捕获那些可能在几天或几周后才以神秘事故形式出现的悬崖回归。
• “综合最佳模型”是一个不连贯的概念。 没有模型能在所有基准测试中占据统治地位；能力是针对成本、延迟和任务类别的帕累托边界。对于你的产品，正确的模型是在事故集中的能力类别中能最大化困难层通过率的模型——即使存在更贵或综合指标更好的模型。

值得警惕的预警信号

衡量这种 “断崖” 现象最可靠的早期指标，是随着时间推移，聚合指标与高难度层级（Hard-tier）指标之间不断扩大的差距。如果聚合指标在上升，但高难度层级指标持平或在倒退，那么随后的每一次升级都会让 On-call 的压力变得更大，即便仪表盘上的数据看起来越来越漂亮。大多数团队并没有意识到这一点，因为他们没有对高难度层级进行独立跟踪。

修复方法成本低且持久：对评估进行分层、报告分桶增量（Bucket Deltas）、预设高难度层级的底线，并针对断崖式的残差（Residual）配置 On-call 人力。另一种选择是发布下一个显示为绿色的聚合指标，在全体大会上为此庆祝，然后让可靠性团队自己去琢磨，为什么在指标显示一切正常的情况下，他们的季度表现却在恶化。

“我们发布了新模型，质量得分提高了” 应该是复盘报告（Postmortem）的开场白，而不是胜利的宣言。