Real-SWE 基准揭示 AI 编程评分与企业实际工作的差距

Specific Labs 发布了包含 640 次智能体运行的 Real-SWE 基准，而排名最高的配置仅完成了其被分配工作中的 38.8%。

这一结果与公开编程排行榜形成了令人不安的反差。智能体看起来越来越能够处理代码库级问题，但多数 Real-SWE 尝试都在私有生产系统中失败了。

这种差异并不只是因为 Real-SWE 包含更难的编程难题。其任务要求智能体重建业务规则、理解陌生架构，并协调代码与关联服务之间的变更。

这一差异至关重要，因为企业聘请软件工程师，并不是为了让他们解决孤立、脱离上下文的练习题。企业需要工程师在修改已经处理客户数据、权限、账单和基础设施的系统时，保持既有行为不被破坏。

因此，Real-SWE 对高公开基准分数所暗示的承诺提出了挑战。它所问的是：智能体能否进入一个未知的企业代码库，在不依赖熟悉的公开资料的情况下，完成具有经济价值的工作。

早期答案令人警醒。该基准表明，编程模型能够生成看似可信的补丁，但并不支持在重要的企业工作流中进行无人监督部署。

Real-SWE 基准究竟改变了什么

Real-SWE 将评测目标从公开代码库问题转向具有企业特定规则和运营依赖关系的私有系统。

Specific Labs 于 2026 年 9 月 12 日公布了这一基准。该公司将其描述为：在从运营企业获得授权的私有生产代码库上，对前沿模型进行评测。

初始版本涵盖十项任务和八种模型与运行框架配置。每种配置针对每项任务进行八次独立尝试，共产生 640 次计分运行。

这种重复运行设计很重要。一次成功的补丁可能掩盖明显的不稳定性，而八次尝试可以显示智能体是否能可靠地解决同一类问题。

公开排行榜报告的是 pass@1，即单次尝试解决任务的概率。Specific Labs 会对分配给每项任务的八次运行结果取平均值。

Fable 5.1 配合 Claude Code 以 38.8% 领跑初始排名。GPT-6 Astra 配合 Codex CLI 以 33.8% 紧随其后，Gemini 3.8 Flash 配合 Gemini CLI 达到 31.2%。

GLM 5.3 配合 Claude Code 的得分为 28.8%。Grok 4.6 和 Muse Spark 1.3 分别搭配各自的智能体系统，均达到 23.8%。

Kimi K3 配合 Kimi Code 达到 18.8%。在这项特定评测中，GPT-5.6 Sol 配合 Codex CLI 的最终得分为 16.2%。

这些结果评估的是组合，而非纯粹的语言模型。运行框架提供工具、控制交互循环，并塑造模型探索和编辑代码库的方式。

Specific Labs 明确表示，其使用了旨在反映当前工程工作流的原生运行框架。这一选择提升了实际相关性，但也令模型间比较更加复杂。

更高的分数可能反映模型推理能力、运行框架行为、工具可靠性，或三者之间的互动。排行榜无法清晰地分离这些影响。

该基准更深层的变化涉及数据暴露。公开编程测试通常使用开源代码库、公开问题，以及可见的解决方案历史。

私有代码库降低了模型在训练期间接触相关补丁的可能性，也阻止智能体通过公开搜索找到答案。

根据已发布的 Real-SWE results，每项任务都源自与真实私有代码库相关的工作。据称，部分说明直接取自实际工程工作。

这一设计让评测不再像是为模型设计的考试，而更接近于将一名新承包商置于陌生的软件组织之中。

这种区别也改变了失败的含义。一个未成功的补丁可能反映编码能力不足，但也可能暴露出需求发现薄弱或系统理解不完整。

而这恰恰是企业部署变得高风险的领域。补丁可能能够编译、通过明显的测试，却仍然违反了业务中其他地方隐含的规则。

为什么私有企业代码构成不同的测试

核心挑战不是生成更多代码，而是发现业务已依赖的行为，并在多个系统中保留这些行为。

一个 Real-SWE 示例要求智能体修复发票税务问题。简短的描述隐藏了涉及业务配置、客户豁免、地理规则和外部税务服务的多个条件。

智能体必须判断何时使用已存储的税率，何时根据买方目的地计算税款。它还必须识别不征税的账户。

它还必须保留豁免、正确记录发票总额，并在不中断发票处理的情况下报告被拒绝的地址。已结算交易必须回传给税务机关。

欧洲交易还增加了一项与 VAT 注册相关的要求。完成这项工作可能涉及 TypeScript 服务、TaxJar 环境和 InfluxDB 分类账。

这些单独的操作都不代表什么罕见算法。困难在于协调它们，同时不遗漏条件或破坏已有行为。

这种模式贯穿企业软件。一个听起来局部的请求，往往会跨越 API、数据库、后台任务、配置、测试和运营工具。

Real-SWE 环境可暴露包括 Docker、Kubernetes、GitHub、PostgreSQL、MySQL、Redis、Slack、电子邮件和客户支持系统在内的服务与工具。

每项任务仅获得其工作流所需的服务。即便如此，智能体仍必须判断哪些系统包含相关证据，哪些只是干扰。

该基准报告的指令长度中位数为 1,742 个字符。这短于详细的实现规范，因此智能体必须从可用代码和上下文中推断结构。

参考解决方案中位数修改了 11 个文件。该基准的比较数据表明，这高于 FrontierCode 和 DeepSWE 报告的六文件中位数。

这一差距有助于解释为什么代码库导航至关重要。即使模型找到了一个明显的实现点，仍可能遗漏验证、持久化、配置或下游使用方。

Specific Labs 表示，十项任务中有六项的解决率低于 15%。没有任何受测配置解决全部任务。

失败分析将遗漏需求列为最常见的类别。其他观察到的失败包括未经验证的假设、集成错误、回归问题，以及编辑了错误文件。

这些类别更像是常规工程审查意见，而不是语法错误。它们表明，智能体经常生成看似合理的局部修改，却没有建立对系统的完整模型。

时间本身并不能区分成功者与失败者。该基准称，98 次持续不足十分钟的运行中有 70 次失败，失败率为 71.4%。

在持续时间更长的运行中，542 次中有 398 次失败，比例为 73.4%。因此，更长的运行时间并不会自动修复薄弱的探索过程或错误假设。

不应将短时与长时运行的比较视为额外推理永远无益的证据。更难的任务可能会产生更长的尝试，从而形成一个重要的混杂因素。

不过，这一结果削弱了一种方便的解释。这些智能体失败，并不只是因为每次运行都在模型来得及完成输入解决方案之前结束。

更可信的机制是上下文形成不完整。智能体必须识别需求、定位其实现、追踪依赖关系，并验证整个变更。

这一工作流受益于持久的代码库知识。工程团队出于同样原因，早已维护架构说明、事故历史、决策记录和技术文档。

可搜索的 engineering knowledge base 可以减少人类重复进行发现工作的负担。智能体系统也越来越需要等效的上下文层。

Real-SWE 并未证明持久记忆能够解决这些任务。它确实说明了，面向企业工程而言，无状态代码生成是一种不完整的模型。

公开编程评分遭遇私有代码现实

核心竞争在于基准中可见的编程能力，与在模型从未接触过的系统中可靠执行的能力之间。

SWE-bench 通过要求模型在代码库快照中解决真实 GitHub 问题，改变了编程评测。相较于孤立的函数生成测试，这是一次重大改进。

原始基准将问题描述、代码库状态和基于执行的评分结合起来。它推动该领域转向能够探索、编辑和测试软件的智能体。

然而，这些代码库和问题历史是公开的。随着模型进步、评测数据流传，污染问题变得越来越难以排除。

当模型的训练数据包含基准任务、相关补丁或近似副本时，就会发生污染。高分随后可能混合了泛化能力、识别能力或记忆能力。

SWE-bench Verified 试图通过人工审查提升任务质量。其 verified dataset 在筛查问题描述和测试后保留了 500 个样本。

这项审查本身就显示出构建编程评测的难度。OpenAI 报告称，68.3% 的受筛样本因规格、测试或相关问题而被移除。

经过筛选的基准仍然有用，但并未消除公开暴露问题。模型开发者仍可以研究代码库、任务、评分行为和常见失败模式。

近期审计进一步加大了对新评测设计的需求。OpenAI 在其 2026 年的 benchmark audit 中报告了广泛使用的编程评测存在设计和污染方面的担忧。

该审计还估计，约 30% 的 SWE-Bench Pro 任务存在缺陷。报告的问题包括过于严格的测试、缺失的需求、覆盖不足以及具有误导性的提示。

Real-SWE 通过保持底层代码库和解决方案私有，解决了这一问题的一部分。如果某个精确补丁从未公开发布，模型就无法检索到它。

但私有数据带来了另一种权衡。外部研究人员无法自由检查每个代码库、复现每项任务，或审计隐藏测试。

当一个基准提出具有重大商业意义的主张时，这会降低透明度。读者必须信任基准运营方的授权、匿名化、任务构建和评分流程。

Real-SWE 提供了任务示例、汇总结果、置信区间和失败分类。这些披露有所帮助，但并不等同于可公开复现的评测。

十项任务的规模构成了另一项限制。重复运行衡量了多次尝试之间的一致性，但重复并不会带来更广泛的任务覆盖。

只有十项任务的基准可能对任务选择十分敏感。一种架构、语言组合或业务领域，都可能对排名产生实质影响。

模型与执行框架的配对进一步增加了不确定性。Claude Code 搭配不止一种模型出现，而 Codex CLI 也搭配了多个模型。

这种差异提供了有用的部署信息。但它并非一项受控比较：每个模型并未获得完全相同的脚手架和工具策略。

因此，正确的解读应比“通用模型排名”更为有限。这些分数展示的是具名配置在已记录设置下、本次 Real-SWE 发布中的表现。

它们并不能证明排名最高的模型适合每一家企业，也不能说明排名最低的配置不具备有用的编程能力。

相反，该基准提醒人们，不能将公开分数直接套用于私有部署的预期。这一提醒与评估领域更广泛的重新审视相一致。

METR 在其任务方法论中作出了类似区分。其自包含任务有意为模型提供明确的成功标准，并尽量减少对组织历史的依赖。

METR 指出，真实工作往往依赖过往对话、隐性知识以及对既有代码库的熟悉程度。其方法论所比较的智能体，更接近于低上下文条件下的外部承包商。

Real-SWE 则进一步深入这一低上下文问题。它在保留可执行评测的同时，引入了企业特有的约定和运营关系。

这正是该基准最重要的反转。仅凭在公开 issue 上的强劲表现，已不足以证明模型能够可靠地实现企业级自主执行。

排行榜给买方带来的压力不亚于模型厂商

Real-SWE 让企业评估团队承受压力，因为厂商分数无法替代在买方自身环境中的测试。

评估编程智能体的公司通常面临信息不对称。厂商了解自己的模型，而买方了解自己的代码库、工作流和风险承受能力。

公开排行榜为双方提供了共同参照。它们简化了比较，但当部署环境与基准不一致时，这种简化就可能带来危险。

Real-SWE 让这种不匹配显而易见。即便是其最强配置，在全部评估任务中，每十次尝试也有超过六次失败。

买方不应将这一数字直接换算为预期的生产失败率。十项基准任务无法代表所有代码库或工程组织。

但这个数字仍会改变采购讨论。团队需要的是关于自身代码可靠性的证据，而不只是公开 issue 历史上的表现。

这意味着要根据具有代表性的、此前已完成的工作建立内部评估。合适的任务可以包括已知结果的漏洞修复、迁移、权限变更和集成工作。

参考解决方案不应成为唯一可接受的实现。评审者必须区分功能正确性与仅仅表面上类似于工程师原始补丁的实现。

隐藏测试同样需要审查。如果验证器编码了未明确说明的实现细节，基准可能会惩罚一个有效的替代方案。

OpenAI 的基准审计显示，这种情况发生得相当频繁。评估质量要求经验丰富的工程师对照指令、测试、参考变更和智能体执行轨迹进行比较。

组织还应测试完整配置。Real-SWE 对模型与执行框架配对评分的决定，反映了编程智能体在实践中的运行方式。

代码库搜索、Shell 访问、测试执行、上下文管理和重试策略都可能显著改变表现。只衡量底层模型会忽略这些依赖关系。

安全性也应纳入同一评估。访问私有源代码会引发关于数据保留、提供商控制、密钥暴露、日志记录和权限的问题。

即使一个智能体能解决更多任务，若它获得的访问范围超出组织可安全授予的程度，它仍可能并不适用。能力与部署风险必须一并评估。

审查负担是另一项关键指标。一个最终可用的补丁，可能需要大量人工调查，以至于几乎没有生产力收益。

团队应记录智能体遗漏需求、引入回归或需要纠正性提示的频率。这些指标与 Real-SWE 的失败类别高度对应。

他们还应跟踪方差。一次成功的演示几乎无法说明智能体能否在下一次尝试中复现结果。

Hacker News 的基准讨论呈现了这一问题的两面。一些参与者欢迎重复的 pass@1 试验，因为它们能够揭示一致性。

另一些人认为，当前工具仍然最适合通过紧密的人机协作来使用。按照这种观点，熟练操作人员仍是被评估系统的一部分。

这种“半人马”模式将人类与 AI 智能体配对。人类提供判断、上下文和审查，智能体则负责探索、起草和机械性的改动。

Real-SWE 并未比较自主智能体与专家—智能体团队。因此，其结果不应被解读为编程助手缺乏实际价值的证据。

它们表明的是更具体的一点：受测配置尚不能可靠地替代经验丰富工程师所承担的上下文理解与验证工作。

这一差别对部署主张至关重要。辅助工程师与自主负责一项企业变更，是两种不同的能力门槛。

买方应要求厂商说明其证据支持的是哪一种门槛。仅靠公开分数无法回答这个问题。

Real-SWE 的数字并不能证明什么

该基准提供了有意义的警示，但其规模较小的私有样本不足以支持关于所有模型或企业代码库的广泛结论。

首先，Real-SWE 的任务来自 Specific Labs 选定的公司。公开示例包括一款消费级应用、一个金融科技平台和企业销售软件。

Specific Labs 表示，其中一款应用服务超过 20 万名用户。另一个平台据称处理超过 10 万份银行对账单。

这些细节确立了商业相关性，但相关公司仍保持匿名。读者无法独立评估其工程质量、架构或领域复杂度。

其次，基准的隐私属性阻碍了完整的公开复现。这种隐私保护了获授权代码并减少了直接污染，但也使验证权集中。

独立评估者需要受控访问，以确认任务来源、验证器质量、环境一致性和评分方式。缺乏这类审查时，部分不确定性不可避免。

第三，排行榜将不同模型与不同原生执行框架结合。这类似于实际产品使用方式，但削弱了关于底层模型智能水平的结论。

一个配置可能因为搜索策略失效、工具调用出错，或上下文管理丢弃了相关证据而失败。这些都是产品失败，但并不是完全相同类型的失败。

第四，该基准以自动解决为主要结果指标。通过验证器是必要条件，但企业可接受性可能还需要更多。

生产环境审查可能会考虑可维护性、可观测性、安全性、迁移安全性、代码风格和未来运营负担。二元的通过结果无法完整捕捉这些维度。

反过来，一个有效补丁也可能无法通过不完善的验证器。SWE-bench 审计的历史表明，隐藏测试可能拒绝合理的解决方案，或忽略不完整的方案。

Real-SWE 表示，所需行为必须被明确说明，或能够被合理地发现。这一标准是合理的，但“能够被合理地发现”仍需要判断。

第五，匿名商业任务可能偏向于那些探索模式与基准相匹配的模型或执行框架。不同的代码库结构可能会颠覆部分排名。

排行榜展示的 95% 置信区间承认不同运行之间存在抽样变化。但它们无法消除仅选取十项任务带来的不确定性。

第六，发布页面提出了一个广泛主张：大多数企业 token 仍对前沿模型不可见。这一说法支持该基准的动机，但缺乏公开的测量细节。

它应被视为该公司的框架性表述，而非独立确立的统计数据。更稳妥的结论是，大量企业上下文仍保持私有。

最后，较低的自主解决率并不等同于较低的生产力影响。智能体即使无法独立完成任务，仍可通过调查、生成测试、撰写文档或起草补丁来节省时间。

反之亦然。一个完成的补丁可能带来审查成本或细微风险，从而抵消其表面上的速度优势。

这些限制并不意味着 Real-SWE 无关紧要。它们界定了其发现具有价值的条件。

该基准最有力的作用，是作为部署差距的证据。作为模型的决定性排名或工程就业的预测，它则较为薄弱。

Specific Labs 也是企业数据和评估领域的商业参与者。其公司简介描述了一项围绕真实企业环境和数据集构建的业务。

这并不会使该工作失效。但它使独立复现和透明方法论更加重要。

一个可信的基准生态系统需要多个运营方、轮换的私有任务和第三方审计。任何单一排行榜都不应成为最终权威。

决定 Real-SWE 是否重要的三个信号

只有当其私有代码信号经受住规模扩展、独立审查和多次模型发布的考验，Real-SWE 才会产生实质影响。

第一个信号是任务集增长。十项任务可以揭示失败模式，但更大的集合必须覆盖更多语言、架构和业务领域。

扩展应在保留私有来源的同时，公布足够的元数据，让读者理解任务多样性。它还应将基于代码库的样本与其他任务形式区分开来。

如果排名在更广泛的测试集上保持相似，持续存在企业差距的主张就会更有力。排名的大幅变化则会表明，任务选择塑造了发布结果。

第二个信号是独立评估。外部研究人员或模型提供商需要获得受控访问，以审计任务、验证器和执行环境。

一项有价值的审计将检查提示是否包含足够信息、隐藏测试是否接受替代实现，以及参考解决方案是否代表真实的生产工作。

独立评审者的认同将增强人们对报告解决率的信心。若发现测试缺陷，则会缩小或修正该基准的结论。

第三个信号是多次发布中的进展。如果任务泄露、成为训练目标，或在智能体系统适应的过程中维持静态，私有基准就会失去价值。

Specific Labs 将需要新的保留任务和清晰的版本控制。结果应区分模型、执行框架、重试和任务暴露所带来的改进。

若新私有任务上的分数迅速上升，将表明泛化能力有所提升。若收益仅限于旧任务，则说明系统可能是在围绕基准本身进行优化。

企业应在关注整体通过率的同时观察失败构成。减少遗漏需求和未经验证的假设，比生成更漂亮的补丁更重要。

一致性也应提高。一个偶尔能解决任务的模型，在同一提示经常产生回归时，仍难以被信任。

人类—智能体对比会增加另一层有用信息。衡量审查时间和总完成时间，可以显示智能体在尚未实现完全自主的情况下，已在哪些方面创造价值。

Real-SWE 向模型开发者和采购方提出了一个关键问题：智能体能否安全地修改那些其历史、惯例和业务逻辑从未公开的软件？

首批结果表明，当前系统往往还做不到。最佳配置解决的任务不到十次尝试中的四次，而遗漏需求是观察到的失败案例中的主导原因。

这一结论应当推动更好的评估，而非一概否定。只要工程师控制范围、提供上下文并验证后果，编程智能体依然可以发挥价值。

实际的下一步，是在扩大权限之前先测试具有代表性的内部工作。团队应比较不同配置，重复执行每项任务，并研究那些看似合理的补丁为何会失败。

如果 Real-SWE 能推动采购行为从相信公开评分转向要求私有环境中的证据，那么这一基准就具有重要意义。你的下一次编程智能体试用，衡量的是生成的代码，还是企业能够安全接受的已完成工作？