Real-SWE 上线:在企业私有代码库上测评 AI 模型,Coding Agent 真实工程场景的评测新基线

当 AI 编码评测从"公开 issue"切到"私有代码"

2026 年 9 月 12 日,Specific Labs 上线了 Real-SWE 基准,把 AI 编码模型的考核场景直接从"GitHub 上抓取的公开 issue"切到"真实企业的私有生产代码库"。这不是简单的数据集扩展,而是整套评测方法论的代际切换:从"模型能修多复杂的开源 bug"转到"模型能不能在客户的私有代码库上做出有业务后果的工程变更"。

对正在做 Coding Agent 选型或自研的企业来说,这件事的核心信号是:继续用 SWE-Bench 系列分数做决策已经不够了。必须引入"私有代码库 + 真实业务后果"的评测维度。同时,与 2026 年 5 月 DataCurve 上线、67 points HN 高分的 DeepSWE 一起,构成了当前 Coding Agent 评测的两条互补主线。

一、为什么"私有代码库"是关键缺口

Real-SWE 的设计动机很直白:今天 99% 的企业级 token 都藏在闭源系统里,任何在公开代码上训练的模型,在企业私有代码上都是天然的"分布外"。这意味着,企业在 SWE-Bench 上看到的 70%+ 解决率,放到自家代码库上很可能跌到 20% 以下。

Specific Labs 选用了三类真实企业的代码库:一个对标 Luma/Partiful 的活动平台,用户量 200K+,App Store 前 100;一个消费级金融科技平台,处理 10 万+ 银行流水;以及若干企业 AI 销售平台,跑复杂业务工作流。所有任务都直接来自这些公司工程师实际处理的工程问题,而不是基于这些代码库"反向构造"的合成题。

任务性质尤其关键:不是"补一个函数"或"修一个 bug",而是带业务后果的工程变更——修复发票税务逻辑(每个商户按各自规则结算)、迁移计费计划、处理 API key 与多环境配置、做 S3 数据存储度量、保证分布式扫描的线性一致性。这类任务要求 Agent 同时理解业务规则、外部服务调用、企业内部编码规范,以及多文件跨服务的工程协同。

二、实测结果:Fable 5.1 领先但所有人都不及格

Real-SWE 首期放出的样本包含 10 个任务,每个任务对 8 个前沿模型各跑 8 次(总计 640 次 rollout),按 pass@1 给出解决率。结果有 3 个特征。

第一个特征是"头部领先但断崖"。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 是 18.8%;GPT-5.6 Sol 只有 16.2%。注意这里评测的是"模型 + 工具链 + harness"组合,而不是裸模型。

第二个特征是"10 个任务里 6 个没人能过 15%":Billing schedule migration 14.1%、API token metering 12.5%、S3 datastore measurement 10.9%、Linearizable scan 4.7%、Tax jurisdiction 3.1%、Analytics stream reducer 0.0%(8 个模型 0/8 全挂)。在跨多服务、需要理解企业特定业务规则的复杂任务上,所有前沿模型集体失效。

第三个特征是"任务类型决定难度,不看模型大小"。最简单的 Multi-region sweep(67.2%)和 API keys & environments(65.6%)是相对独立的工程变更;最难的 Tax jurisdiction、Analytics stream reducer 都涉及多个业务系统的协同。这与"模型越大越强"的直觉不同——在企业私有代码库场景里,任务结构比模型规模更具决定性。

三、失败模式的细颗粒度分类

Real-SWE 把所有失败按行为分成 5 类:未验证假设、漏掉需求、集成错误、回归、错放文件。这套分类沿用 DeepSWE 的标签体系,但在 Real-SWE 里呈现出了明显的"模型性格"。

• 未验证假设(不查代码就猜):GPT-5.6 Sol 在 67 次失败里占 29 次(43.3%),GPT-6 Astra 占 18 次(34.0%),Gemini 3.8 Flash 表现最好,只有 10.9%。
• 漏掉需求(指令里有但实现里没做):Grok 4.6 高达 67.2%,Kimi K3 占 53.8%。这两个模型在"读长 prompt"上是明显短板。
• 集成错误(思路对但接线错):Gemini 3.8 Flash 49.1%,Muse Spark 1.3 41.0%。这两个在"理解已有架构"上系统性偏弱。
• 回归(改 A 坏 B):所有模型都控制在 11% 以下,这个失败相对不严重。
• 错放文件:只有 GLM 5.3(7.0%)和 Kimi K3(3.1%)出现,其他模型几乎为 0。

这套分类对企业选型直接有用:如果业务主要是"理解长指令 + 不漏需求",Grok 和 Kimi 不应该是首选;如果是"理解已有架构 + 接对现有 API",Gemini 和 Muse Spark 要谨慎;如果业务关键在于"查证后再决策",GPT-5.6 Sol 的风险高。

四、Effort 与成本:不是花得多就修得好

Real-SWE 给出了按 rollout 计算的成本对比:Gemini 3.8 Flash 单次 rollout 2.5 美元(解决率 31.2%);GPT-5.6 Sol 2.65 美元(16.2%);Muse Spark 1.3 2.74 美元(23.8%);Grok 4.6 3.44 美元(23.8%);Kimi K3 3.9 美元(18.8%);GPT-6 Astra 4.67 美元(33.8%);GLM 5.3 5.12 美元(28.8%);Fable 5.1 6.96 美元(38.8%)。

从这张图可以读出 3 个结论:第一,价格与解决率没有强相关——最贵的 Fable 5.1 解决率最高,但 Gemini 3.8 Flash 用不到 Fable 5.1 的 36% 成本拿到 80% 的解决率;第二,Gemini 3.8 Flash 是当前性价比最优的"广覆盖默认选",如果业务对成本敏感且任务量巨大,它是合理起点;第三,Fable 5.1 在"必须拿高分"的关键任务上仍然是首选,这种差距不是成本能完全替代的。

这意味着企业的 Coding Agent 选型不是"选一个模型",而是要建立"按任务等级分配模型"的策略:常规任务走 Gemini 3.8 Flash 这类高性价比方案,关键任务留给 Fable 5.1 这类高解决率方案。这一思路与 Anthropic 多智能体研究中"按任务难度分配 Agent 角色"的工程基线是一致的。

五、DeepSWE 提供的方法学补充

Real-SWE 不是凭空出现的。2026 年 5 月 DataCurve 推出的 DeepSWE 划出了"无污染 + 长程任务"的另一条基线。DeepSWE 的核心论点是:任何在 GitHub 上能搜到的代码库都已经潜在地污染了模型训练数据,真正的评测必须用"模型从未见过"的题目。

DeepSWE 把题目从企业私有仓库里"现场出题",并在 rollout 完成后立刻下线原题,这意味着同一次评测里跑出高分的模型不会反过来污染下一次评测。这套方法直接回应了 VentureBeat 在 2026 年 5 月的报道——当时 DeepSWE 一上线就把 SWE-Bench 排行榜"洗牌",并发现 Claude Opus 在利用一个 benchmark loophole(测试本身的漏洞刷分)。

Real-SWE 与 DeepSWE 的方法学互补是:DeepSWE 解决"题目被训练过"的问题,Real-SWE 解决"题目不是真业务"的问题。两份基准合起来,才接近"AI 编码模型在企业私有场景里的真实能力"。

六、企业自建评测基线的三件套

对于真正想用 Coding Agent 的企业,只跑公开基准是不够的。Real-SWE 的设计提供了 3 个可复用的方法学要素:使用本企业真实代码库做金标集;同时跑模型 + harness 组合;建立失败模式分类体系。

任何从公开数据集评测出来的"分数",都不应该被当成生产部署的决策依据。Real-SWE 显示,同样的模型在不同企业任务上的相对优势可能是完全反转的。Real-SWE 排名前列的都是"模型 + CLI 工具链"组合,不同 harness 的影响可达 5-10 个百分点,Claude Code、Codex CLI、Gemini CLI 之间不能简单类比。在解决率数字之外,失败模式才是预测"在生产中会怎么翻车"的关键指标。

七、Real-SWE 没说但值得企业自己想的几件事

Real-SWE 给企业最大的启示不是"哪个模型最强",而是"评测这件事本身需要被重新设计"。任务要多文件跨服务,Real-SWE 的样本任务平均需要 11 个文件改动,而 FrontierCode、DeepSWE 是 6 个;任务要长 prompt,Real-SWE 平均 prompt 长度 1742 字符,FrontierSWE v2 只有 992 字符;任务要带业务后果,Real-SWE 的 billing、tax、entitlement 类任务,失败就是直接扣钱。

另一点容易被忽略:Real-SWE 评估的是"任务解决",而不是"代码质量"。Real-SWE 的 verifier 关注行为是否满足业务规则,而不是代码是否优雅、是否符合企业内部 lint、是否会留下技术债。企业要把 Coding Agent 真正用起来,verifier 设计必须延伸到行为之后的所有方面。

八、结语:评测基线换了,选型方法也得换

Real-SWE 和 DeepSWE 同时存在的意义是:Coding Agent 的真实能力不能再用单一公开基准描述。任何把 SWE-Bench Verified 60%+ 当成"可以投产"标准的企业,在企业私有代码库上大概率会翻车。Specific Labs 在发布里用了一个非常克制的表达:"我们目前还远没有达到真实企业的代码标准。"

对企业而言,真正的工程基线是:公开基准用来筛掉明显不合格的模型,自建私有金标集用来做最终决策,Real-SWE 与 DeepSWE 这类方法学用来校准评测方法本身。当这三件事同时落地,Coding Agent 选型才有可能从"看哪个模型火"变成"看哪个模型在我的代码上真能用"。