Snorkel AI评测：Fable 5.2编码失败从终端崩溃转向策略误判

Snorkel AI的AI布道者Jonathan Schlosser和高级研究科学家Ankit Aich在26项匹配的前沿编码任务上对比了Fable 5.2与5.1。Fable 5.2的pass@1达到71.4%，比5.1的53.1%高出18个百分点。但数字本身不是这篇评测最有用的部分——真正值得关注的是失败原因的结构性变化。

5.1的失败是机械性的。在97条失败轨迹中，42%的原因是过早终止——模型已经写出了大部分正确方案，尝试通过终端执行一次大文件写入，会话崩溃，无法恢复已经构建的状态。25%是输出格式错误，26%是工具调用参数错误。共同特征是：解决方案存在，但交付它的那一步失败了。

5.2几乎消除了这一整类问题。在121次试验中，没有一次过早终止，没有一次格式失败，只出现了一次工具参数错误。可靠性提升显著：5.1只在26项任务中的6项上每次试验都通过，5.2在15项上做到了这一点。当5.2能解决一个任务时，它通常在单次尝试中就成功了。

然而剩余的失败呈现出完全不同的面貌。在40次有根因分析的失败试验中，35%归因于策略选择错误，28%归因于推理缺陷，23%归因于误读任务要求。这些不是执行层面的失误，而是规划层面的判断问题。

更关键的是，这些推理错误是稳定而非随机的。评测发现，推理缺陷集中在两项任务上，每一次尝试都独立地得出相同的错误结论。这意味着模型不是偶尔犯错，而是系统性地误读了预期行为。它正确地执行了一个错误的计划，甚至用自己的检查验证了错误的答案，所以内部检查通过而外部验证器失败。

这一发现对实际使用有直接含义。5.1时代，用户遇到失败可以通过多次采样来弥补——崩溃是随机的，重试往往能绕过。但5.2的剩余失败是确定性的：一个稳定的误读五次尝试都失败，额外采样不会恢复。正如评测作者所指出的，这一类失败与Opus 5在同一任务集上暴露的问题属于同一类别，且更难通过脚手架工程来修复，因为失败的运行执行干净、自我验证也通过，只是验证的对象是错误的前提。

需要说明的是，这是Snorkel AI自己的评测，任务集由该团队创建，26项匹配任务来自30项原始任务中两个模型都至少有三次干净运行的子集。作者也承认，这一模式是否在未来模型代际中持续存在尚未经过检验。但就当前这批前沿编码代理而言，瓶颈已经从执行层面的随机崩溃转移到了规划层面的稳定误判。