8 个前沿模型 vs 10 个真实企业任务：残酷基准测试

如果你相信厂商的公告，编码 Agent 似乎已经是一个被解决的问题了。OpenAI 把 GPT-6 Astra 描述为其迄今最强大的模型。每个实验室都发布了一份排行榜，最新版本在上面清除了一切障碍。

然后，一个名为 Real-SWE 的基准测试本周登上了 Hacker News，一天内获得了 271 个点赞和 151 条评论，大多数工程师说的都是「终于有了与我所见相符的数据」这样的话。设置简单而残酷。Specific Labs 团队从私有、真实的企业代码库中提取了 10 个真实任务。不是玩具仓库，不是 SWE-bench 谜题——那类题目网络上有一半的人已经背熟了。是真实的任务，真实的工程师花了几周时间处理的任务。他们给 8 个前沿模型各 8 次尝试机会，然后根据实际合并的 PR 进行评分。

表现最好的模型 Claude Fable 5.1 完成了其中 38.8%。OpenAI 的 GPT-6 Astra：33.8%。GPT-5.6 Sol，OpenAI 今年早些时候的旗舰产品：垫底，仅 16.2%。有一个任务——分析流归约器——在所有 8 个模型的 64 次尝试中全部失败。

在继续之前完整披露：我自己没有运行过这个基准测试。以下所有内容均来自 Real-SWE 结果页面、基准测试作者在 Hacker News 帖子下的评论，以及该讨论中构建了同一测试私有版本从业者。但这个基准测试中的失败数据比我今年见过的任何排行榜都有用，因为它不仅仅说明谁赢了，而是说明了每个人是如何输的。

Real-SWE 实际测量的是什么

大多数编码基准测试有一个共同缺陷：任务是公开的，仓库是公开的，解决方案已经泄露到训练数据中。Real-SWE 从三个方向攻击这个问题。

私有代码库。 10 个任务来自从未公开的企业代码库。模型不可能对它们进行记忆。

隐藏的规格说明。 提示给模型的是工单，但评分还会检查人类工程师需要发现的未写明需求。通过测试是不够的。基准测试只在评分时才揭示隐藏的规格说明。

数周级的 scope。 基准测试作者在 Hacker News 上确认，这些是「真实工程师花了几周时间处理的雄心勃勃的任务」，不是一session就能修复的问题。任务带有诸如 Customer identity migration、Billing schedule migration、Tax jurisdiction 和 Linearizable scan 这样的名称。

相对公平的测试规则。 每个模型在其原生提供商测试环境中以高推理模式运行，每个任务 8 次 rollout，评分旁边公布了每次 rollout 的成本估算。

最后一点比看起来更重要。标题解决率和每次 rollout 的成本讲述的是两个不同的故事，当你把它们放在一起时，排名就变了。

排行榜，带价格标签

所有数字均来自 Real-SWE 结果页面的中位数。

Claude Fable 5.1：38.8%，每次 rollout 约 6.96 美元

GPT-6 Astra：33.8%，每次 rollout 约 4.67 美元

Gemini 3.8 Flash：31.2%，每次 rollout 约 2.50 美元

GLM 5.3：28.8%，每次 rollout 约 5.12 美元

Grok 4.6：23.8%，每次 rollout 约 3.44 美元

Muse Spark 1.3：23.8%，每次 rollout 约 2.74 美元

Kimi K3：18.8%，每次 rollout 约 3.90 美元

GPT-5.6 Sol：16.2%，每次 rollout 约 2.65 美元

看第一和第三名之间的差距。Fable 5.1 的得分比 Gemini 3.8 Flash 高出 7.6 个百分点，而每次 rollout 的成本是其 2.8 倍。如果你的 Agent 循环每周让模型处理数十个工单，那么一个命中率略低的中档模型在每个已解决任务上的成本可能低得多。用 Gemini 解决一个任务平均花费约 8 美元计算成本。用 Fable 解决一个约花费 18 美元。Fable 额外的质量是否值得完全取决于在你的工作流中一个失败或未完成的工单有多昂贵。

还有一个惊喜：GLM 5.3，一个开源权重模型，排名第四，领先于 Grok、Muse Spark、Kimi 和 GPT-5.6 Sol。基准测试作者在 Hacker News 上的解释是：「基准测试上的任务是长周期 SWE 任务，GLM 在这方面表现出奇地好。」几位评论者反驳说因为排名与他们的日常使用经验相矛盾，这是合理的。但这种矛盾本身就是发现，它直接指向数据中最有趣的部分。

十个任务中有六个解决率低于 15%

总体分数掩盖了难度的形态。按任务细分后，基准测试不再像一个排行榜，而开始像一张 Agent 不能做什么的地图。

API keys and environments 是最容易解决的任务，总体解决率 65.6%。三个模型在全部 8 次 rollout 中全部通过。这是定义明确的管道工作：轮换密钥、接上环境配置、保持测试绿色。Agent 在这方面确实很擅长。

Tax jurisdiction 崩溃至总体 3.1%。单次最佳结果是 1/8。模型需要理解存在于业务逻辑、监管文档和机构知识中的税务规则，而不是存在于代码中的。

Analytics stream reducer 在 64 次尝试中全部为 0。8 个前沿模型中没有任何一次 rollout 产生了正确的实现。

困难任务之间的模式是一致的：一个 problem 在代码库中越没有被完全指定，每个模型的表现就越差。Tax jurisdiction 需要了解没有任何仓库包含的知识。流归约器需要在改变它的同时在脑海中保持一个分布式系统设计。基准测试作者坦承较低的 success 率是因为「我们给模型的是真实工程师花了几周时间处理的雄心勃勃的任务」。

一位 Hacker News 评论者用一句话总结并获得了广泛认同：「你的项目越接近 CRUD，成功的可能性就越高。」

缺失需求是头号杀手

这是值得截图的部分。Real-SWE 将每次失败的 rollout 分类为失败类别，分布因模型而异。两个得分相同的 Agent 可能以相反的方式失败，这改变了你应该雇用哪一个来处理哪一种工作。

缺失需求是总体上最常见的失败。Grok 4.6 在 67.2% 的失败运行中以这种方式失败。Kimi K3 在 53.8%。这些模型写出的代码能工作，但不是被要求的代码。

未验证假设主导 OpenAI 模型。GPT-5.6 Sol 在 43.3% 的失败运行中以这种方式失败，GPT-6 Astra 在 34.0%。模型会猜测一个约束而不是检查它，然后基于猜测进行构建。

集成错误是 Gemini 3.8 Flash 的标志性失败：49.1% 的失败运行破坏了变更与周围系统的连接方式。Muse Spark 1.3 为 41.0%。

回归，破坏先前工作的行为，对每个人来说都很罕见，但对开源权重模型来说最罕见。GLM 5.3、Grok 4.6 和 Kimi K3 都记录了 0% 的回归失败。Gemini 最差，为 10.9%。

把这些放在一起阅读，一个实用的选择指南就浮现出来了。如果你的工单规格完善，风险是破坏现有行为，开源模型看起来比它们的排名所显示的更好，因为它们通过更少触碰来安全地失败。如果你的问题是需求发现，一个假设而不是验证的模型是危险的，无论它的演示多么令人印象深刻。Astra 按数量在排行榜上名列前茅，但三分之一的失败来自基于未检查的猜测进行构建。运行混合设置的评论者从经验中说出了同样的事情：一位从业者使用一个「观察者」模型，其唯一工作是捕捉实现模型的未验证假设，并报告说调换角色会让两者都变得更糟。

Hacker News 讨论对它进行了压力测试

没有基准测试能在 151 条评论中毫发无损，在你引用这些数字之前，这些异议值得了解。

隐私怀疑者问将私有代码库发送到模型 API 是否真的能保持私有。作者确认代码库保持私有，但更深层的观点对你的实验来说站得住脚：无论你发送到托管 API 的任何内容都应该被视为与提供商共享。

排名异议者指出 GLM 击败 Sol 与他们的经验和其他排行榜相矛盾。确实如此，且未解决。这是 10 个任务，不是 500 个。把它当作一个方法论异常出色的数据点，而不是 ground truth。

从业者验证了重要的数字。 多个人独立表示 20% 到 35% 的范围与他们自己代码库上看到的一致。一个人写道约 30% 的数字「与我经验相符。我以为是自己对模型期望太高才发疯。」另一个人构建了这个测试的私有版本，从 vibes 转向数据，报告说开源模型作为审查者「非常值得加入」。

最后那位评论者的设置是整个讨论中可操作的部分，因为这意味着你不需要等待基准测试维护者在你的事实上测试模型。

在一个下午构建你自己的私有评估

以下是从 HN 讨论中整理出的 playbook。它不需要新工具，只需要 git 历史和纪律。披露：这是评论中从业者描述的工作流，作为他们的方法呈现，不是我自己运行过的东西。

选取 3 到 5 个作为干净 PR 落地的历史工单。优先选择有明确起始 commit 和有意义测试套件的。这是最慢的一步；工单到 PR 的历史在真实仓库中很少是整洁的。

将仓库倒回到每个变更之前的 commit。Agent 从与人类工程师相同的起点开始工作。

用 Agent 在该 commit 时需要的一切来沙箱化：依赖项、测试系统的凭证、与你的真实约束匹配的网络策略。缩小它在整个项目外徘徊的能力。

用原始工单作为提示。不打磨，不添加你当时没有写的提示。它的全部意义在于测量模型如何处理实际存在的规格说明。

根据隐藏的规格说明进行评分，而不仅仅是测试。将 Agent 的工作与被接受的 PR 进行 diff，并检查从未进入工单的需求。那是缺失需求和未验证假设会浮出水面的地方。

多次运行每个模型。在 temperature 1 下输出各不相同。一位从业者的建议：平均值不如 10 个垂直样本重要，垂直样本揭示了一个模型的倾向，比如它是否过度工程化，或者是否半途而废。

期望这个练习能改善你的工单。做过这件事的人的反复报告：编写评估任务使他们更擅长编写真实工单，因为他们开始注意到哪些需求只存在于他们脑海中。

即使是在你自己的代码库上做 5 个任务、单个模型的比较，也比任何公共排行榜告诉你更多，因为它是用你的领域、你的约定和你的完成定义来衡量的。

我反复回顾的要点

厂商的故事是编码已基本解决。Real-SWE 的故事是前沿 Agent 解决了约三分之一真正困难的企业工单，没有人能解决那些需要仓库外知识的任务，而且模型以特征分明且不同的方式失败，没有单一排名能捕捉到。

第二个故事更有用。它告诉你 Agent 今天在哪里赚取它们的保持费：规格完善、代码库内的工作，由人类拥有需求发现。它告诉你在选择模型时要注意什么：不是平均分，而是失败模式。它还告诉你对你的技术栈来说最便宜的确定性路径是一个小的私有评估，而不是别人的排行榜。

如果你想要完整数据，带有所有 rollout 和成本的基准测试公开在 withspecific.com/benchmarks/real-swe，Hacker News 讨论也值得完整阅读。

我每周写关于 AI 工程、基准测试和后端开发的文章。订阅是免费的，这意味着下一次深度报道会出现在你的 feed 中，而不是算法的恩赐。

你有没有用你自己的代码库而不是公共基准测试来衡量过任何编码 Agent？有什么让你惊讶的？我正在收集故事，准备写一篇关于私有评估设置的后续文章。