Real-SWE：在私有企业代码库上评测AI模型

Real-SWE：在私有真实企业代码库上对 AI 模型进行基准测试

今天我们发布 Real-SWE，一个在私有、真实的企业代码库（codebase）上评估前沿 AI 模型的基准测试。每道任务都来自我们从真实公司获得授权的私有生产代码库。这些都是其工程师日常需要处理的问题，附带既有产品所带来的一切上下文与复杂性。

私有代码库智能体（agent）必须在其代码和解决方案无法在公开互联网上获取的专有系统中穿行。

承担具有业务后果的工作正确处理计费、计算税费、迁移客户。这些改动会影响业务运转方式，往往横跨多个服务。

公司特有的复杂性每家公司都有自己的规则和代码写法。智能体必须理解这些约定，并做出与既有代码相容的改动。

一个编程智能体真的能在现实中胜任软件工程师的工作吗？

模型与工具链（harness）分辨率

| 排名 | 模型 | 工具链 | 分辨率（Resolution rate） |
|---|---|---|---|
| 1 | Fable 5.1 | Claude Code | 38.8% |
| 2 | GPT-6 Astra | Codex CLI | 33.8% |
| 3 | Gemini 3.8 Flash | Gemini CLI | 31.2% |
| 4 | GLM 5.3 | Claude Code | 28.8% |
| =5 | Grok 4.6 | Grok Build | 23.8% |
| =5 | Muse Spark 1.3 | Muse Code | 23.8% |
| 7 | Kimi K3 | Kimi Code | 18.8% |
| 8 | GPT-5.6 Sol | Codex CLI | 16.2% |分辨率等同于 pass@1，对每道任务做 8 次独立运行后取均值。图中显示了 95% 置信区间。

专家编写或合成的任务固然可以设计精良，但它们并非真实公司工程师需要处理的原原本本的任务。我们的任务在两个维度上有所不同：底层的编程工件（coding artifact）和指令的具体程度。两者都带来了挑战当今前沿模型的复杂性。

我们使用原生工具链（native harness）来反映企业工程师的实际工作方式，评估的是"模型 + 工具链"的组合，而非孤立的模型本身。

真实公司的任务需要公司特有的上下文

正确计费取决于业务规则和外部服务。

> 修复发票计费，使每个商户收取正确的税费，且被豁免的客户不被征税。

完整指令计费系统下周一重新开放，而该服务开出的每张发票现在都没有税。平台上的每家商户的税费处理方式各不相同：有的自行维护一个税率，有的希望对每张发票按买家所在地通过我们的税务主管部门接口定价，有的则完全不征税；而对于我们持有豁免资格的客户，无论其商户如何配置，都不收费。所谓"对目的地定价"，意味着拿着买卖双方地址、定价明细以及该商户所属的产品类别去访问税务接口，根据商户所在的账户使用沙箱或生产环境的接口；接口拒绝处理的地址必须上报，但不能因此中断发票开具。税率、税额和总额需出现在开出的发票上；发票结清后，按该发票编号向接口回执销售记录，以便报税对账。欧洲双方之间的发票需同时显示双方的 VAT 注册号。税务接口与账本可通过 TAX_JAR_URL、PROD_TAX_JAR_URL 和 INFLUX_URL 访问。

沙箱中的服务

- TJ TaxJar 沙箱
- TJ TaxJar 生产环境
- InfluxDB 账本
- NestJS 服务
- TypeScript

智能体在代码、基础设施与业务工具间穿行

Real-SWE 任务环境中跨代码、基础设施和业务工具使用的各类工具与服务。每个任务只暴露其工作流所需的服务。

AWS 模拟器、Docker、Kubernetes、GitHub、Linear MCP（Model Context Protocol，模型上下文协议）、PostgreSQL、MySQL、MongoDB、Gel、Redis、Go、Python、Node.js、Vitest、Slack、Intercom、Google Drive、Email、ClickUp

代码库选择

我们通过严格的筛选流程来挑选代码库，专注于拥有大量真实用户、强大工程团队和严苛生产负载的真实公司。以下分析的样例任务来自这些代码库，包括：

- 一款 Luma/Partiful 的竞品，拥有 20 万以上用户，App Store 排名前 100
- 一个消费级金融科技平台，处理 10 万份以上的银行流水
- 企业级 AI 销售平台，支持复杂业务工作流我们优先选择为满足真实用户或业务需求而写的代码，而非纯粹为制造基准任务而写的代码。生产工程要求理解既有架构、维护依赖的行为，并在真实运营约束下进行修改。

简短的指令也可能需要改动大量文件

我们的任务描述所需的改动，让智能体在代码库及周边工具中自行发掘实现细节。验证器所需的任何行为都必须被明确写出或可被合理发现。这导致我们的提示词略欠明确，与 DeepSWE 和 Terminal Bench 相当，但又不至于遗漏指令。

这类工作跨职能且复杂：单次改动可能涉及应用的多个部分。智能体必须理解既有业务逻辑和公司的编码模式，同时保证周边系统正常运行。

提示词长度 · 中位数一条典型的 Real-SWE 指令长度为 1,742 字符。

| 基准 | 字符数 |
|---|---|
| FrontierCode | 2,056 字符 |
| DeepSWE | 1,975 字符 |
| Terminal-Bench 3 | 1,584 字符 |
| FrontierSWE v2 | 992 字符 |
| Real-SWE | 1,742 字符 |参考方案修改的文件数 · 中位数Real-SWE 中为 11 个文件，而 FrontierCode 与 DeepSWE 为 6 个。

| 基准 | 修改文件数（中位数） |
|---|---|
| FrontierCode | 6 |
| DeepSWE | 6 |
| Real-SWE | 11 |以上均为中位数。FrontierCode 与 DeepSWE 使用 Cognition 公开的对比数据；FrontierCode 包含任务描述与代码库准则。我们对 Terminal-Bench 3 的 74 个任务、FrontierSWE v2 的 34 个任务以及 Real-SWE 的 8 个仓库支撑的样例任务的指令文件进行了测量。字符数四舍五入到整数。Terminal-Bench 3 与 FrontierSWE v2 未提供可对比的"文件修改数"数据。

模型即便在短轮次（rollout）中也会失败

- 71.4% 的轮次失败；73.4% 的较长轮次失败在充斥既有业务逻辑和编码模式的代码库中，对多个系统进行分诊（triage）并理解需求，是非常困难的。

短于 10 分钟

- 短于 10 分钟：98 次轮次中，70 次失败（71.4%），28 次通过（28.6%）。

10 分钟或更长

- 10 分钟或更长：542 次轮次中，398 次失败（73.4%），144 次通过（26.6%）。

为什么这很有意思每道任务都取材于或逐字取自私有真实代码库。我们觉得这类任务非常有意思，原因有三：

私有代码库上的任务天然属于分布外（out of distribution）这类编程任务在互联网上任何地方都找不到，其他任何 AI 模型都不太可能曾在其上训练过。真实企业中 99% 的词元（token）都对前沿模型隐藏。

这类任务是经济上可行的工作这里的每项任务都与支出直接相关，曾被分派给拿薪水的工程师去完成。大多数基准测试考察的是有趣的、实验性的能力，而这些能力往往不太可能在现实中普及。

公司特有的工程模式很重要AI 写出的代码能否达到真实企业的水准？我们的结果表明，我们离这一现实还很远。许多企业关心编码规范和模式。我们发现，当今的模型在理解公司编码模式方面较弱，经常遗漏需求或不验证自己的假设。

分析

以下是我们基准中少量样例任务的分析。如果你对样例感兴趣，可在此申请访问。

X% 的任务分辨率低于 15%选择一个任务以查看模型结果。百分比为总体分辨率。

| 任务 | Fable 5.1 | GPT-6 Astra | Gemini 3.8 Flash | GLM 5.3 | Grok 4.6 | Muse Spark 1.3 | Kimi K3 | GPT-5.6 Sol | 分辨率 |
|---|---|---|---|---|---|---|---|---|---|
| Multi-region sweep | | | | | | | | | 67.2% |
| API keys & environments | | | | | | | | | 65.6% |
| Entitlement overage lines | | | | | | | | | 50.0% |
| Customer identity migration | | | | | | | | | 40.6% |
| 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 次轮次。

遗漏需求是最常见的失败

失败按提交行为观察归类，使用跨模型一致的分类法，遵循 DeepSWE。

| 模型 | 未经核实的假设（Unverified assumption） | 遗漏需求（Missed requirement） | 集成错误（Integration error） | 回归（Regression） | 错误文件（Wrong file） |
|---|---|---|---|---|---|
| Fable 5.1 | 24.5% | 36.7% | 34.7% | 4.1% | — |
| GPT-6 Astra | 34.0% | 28.3% | 34.0% | 3.8% | — |
| Gemini 3.8 Flash | 10.9% | 29.1% | 49.1% | 10.9% | — |
| GLM 5.3 | 28.1% | 38.6% | 26.3% | — | 7.0% |
| Grok 4.6 | 24.6% | 67.2% | 8.2% | — | — |
| Muse Spark 1.3 | 19.7% | 36.1% | 41.0% | 3.3% | — |
| Kimi K3 | 15.4% | 53.8% | 27.7% | — | 3.1% |
| GPT-5.6 Sol | 43.3% | 31.3% | 16.4% | 9.0% | — |

没有模型能解决所有任务

每个方格代表一次轮次：每行为一个任务，每列为一次试验，每个模型对每个任务有 8 次试验。

颜色图例：通过（Pass）、未经核实的假设、遗漏需求、集成错误、回归、错误文件。

不同模型失败的方式不同

百分比为占每个模型失败轮次的比例，而非所有轮次。

未经核实的假设在系统上基于猜测进行构建，而非在工作区中核对。

- GPT-5.6 Sol：43.3% 的失败轮次
- GPT-6 Astra：34.0% 的失败轮次
- GLM 5.3：28.1% 的失败轮次
- Grok 4.6：24.6% 的失败轮次
- Fable 5.1：24.5% 的失败轮次
- Muse Spark 1.3：19.7% 的失败轮次
- Kimi K3：15.4% 的失败轮次
- Gemini 3.8 Flash：10.9% 的失败轮次遗漏需求遗漏了指令所要求的行为。

- Grok 4.6：67.2% 的失败轮次
- Kimi K3：53.8% 的失败轮次
- GLM 5.3：38.6% 的失败轮次
- Fable 5.1：36.7% 的失败轮次
- Muse Spark 1.3：36.1% 的失败轮次
- GPT-5.6 Sol：31.3% 的失败轮次
- Gemini 3.8 Flash：29.1% 的失败轮次
- GPT-6 Astra：28.3% 的失败轮次集成错误方向正确，但与周边系统的连接方式错误。

- Gemini 3.8 Flash：49.1% 的失败轮次
- Muse Spark 1.3：41.0% 的失败轮次
- Fable 5.1：34.7% 的失败轮次
- GPT-6 Astra：34.0% 的失败轮次
- Kimi K3：27.7% 的失败轮次
- GLM 5.3：26.3% 的失败轮次
- GPT-5.6 Sol：16.4% 的失败轮次
- Grok 4.6：8.2% 的失败轮次回归在改动过程中破坏了既有行为。

- Gemini 3.8 Flash：10.9% 的失败轮次
- GPT-5.6 Sol：9.0% 的失败轮次
- Fable 5.1：4.1% 的失败轮次
- GPT-6 Astra：3.8% 的失败轮次
- Muse Spark 1.3：3.3% 的失败轮次
- GLM 5.3：0% 的失败轮次
- Grok 4.6：0% 的失败轮次
- Kimi K3：0% 的失败轮次错误文件将改动落到运行中的应用从未调用的地方，例如一次性脚本。

- GLM 5.3：7.0% 的失败轮次
- Kimi K3：3.1% 的失败轮次
- Fable 5.1：0% 的失败轮次
- GPT-6 Astra：0% 的失败轮次
- Gemini 3.8 Flash：0% 的失败轮次
- Grok 4.6：0% 的失败轮次
- Muse Spark 1.3：0% 的失败轮次
- GPT-5.6 Sol：0% 的失败轮次

投入与前沿

更高的成本并不保证更高的分辨率成本（美元）| 输出词元（Output tokens）| 估算的前沿（Estimated frontier）| 分辨率（%）

横轴为每次轮次的成本（美元，对数刻度），纵轴为分辨率（%）。

- Gemini 3.8 Flash：31.2% · $2.50；Gemini CLI
- GPT-5.6 Sol：16.2% · $2.65；Codex CLI
- Muse Spark 1.3：23.8% · $2.74；Muse Code
- Grok 4.6：23.8% · $3.44；Grok Build；用量统计不完整，实际成本可能更高
- Kimi K3：18.8% · $3.90；Kimi Code；用量统计不完整，实际成本可能更高
- GPT-6 Astra：33.8% · $4.67；Codex CLI
- GLM 5.3：28.8% · $5.12；Claude Code
- Fable 5.1：38.8% · $6.96；Claude Code| 模型 | 分辨率 | 估算成本 |
|---|---|---|
| Fable 5.1 | 38.8% | $6.96 |
| GPT-6 Astra | 33.8% | $4.67 |
| Gemini 3.8 Flash | 31.2% | $2.50 |
| GLM 5.3 | 28.8% | $5.12 |
| Grok 4.6 | 23.8% | $3.44 |
| Muse Spark 1.3 | 23.8% | $2.74 |
| Kimi K3 | 18.8% | $3.90 |
| GPT-5.6 Sol | 16.2% | $2.65 |估算的单次轮次成本范围为 $2.50 至 $6.96。

| 排名 | 模型 | 估算成本（美元） |
|---|---|---|
| 1 | Gemini 3.8 Flash | $2.50 |
| 2 | GPT-5.6 Sol | $2.65 |
| 3 | Muse Spark 1.3 | $2.74 |
| 4 | Grok 4.6 | $3.44 |
| 5 | Kimi K3 | $3.90 |
| 6 | GPT-6 Astra | $4.67 |
| 7 | GLM 5.3 | $5.12 |
| 8 | Fable 5.1 | $6.96 |

输出词元 · 工具调用 · 墙钟分钟

按任务划分的每次轮次平均值。

| 任务 | Fable 5.1 | GPT-6 Astra | Gemini 3.8 Flash | GLM 5.3 | Grok 4.6 | Muse Spark 1.3 | Kimi K3 | GPT-5.6 Sol |
|---|---|---|---|---|---|---|---|---|
| Entitlement overage lines | 34k | 13k | 78k | 68k | 7k | 36k | 30k | 12k |
| Multi-region sweep | 30k | 13k | 67k | 53k | 3k | 43k | 9k | 8k |
| Tax jurisdiction | 78k | 24k | 95k | 141k | 12k | 67k | 39k | 22k |
| API token metering | 95k | 31k | 134k | 177k | 15k | 152k | 69k | 31k |
| API keys & environments | 71k | 32k | 102k | 125k | 16k | 104k | 44k | 25k |
| S3 datastore measurement | 62k | 22k | 106k | 121k | 13k | 71k | 32k | 25k |
| Customer identity migration | 67k | 25k | 97k | 90k | 20k | 76k | 66k | 24k |
| Billing schedule migration | 26k | 15k | 70k | 58k | 6k | 38k | 19k | 13k |
| Linearizable scan | 86k | 33k | 106k | 172k | 261k | 141k | 71k | 37k |
| Analytics stream reducer | 88k | 29k | 88k | 169k | 315k | 137k | 55k | 30k || 模型 | 总体 |
|---|---|
| Fable 5.1 | 64k |
| GPT-6 Astra | 24k |
| Gemini 3.8 Flash | 94k |
| GLM 5.3 | 117k |
| Grok 4.6 | 67k |
| Muse Spark 1.3 | 87k |
| Kimi K3 | 43k |
| GPT-5.6 Sol | 23k |

评估设置

每个智能体都在独立的沙箱中运行。所有任务均采用 Harbor 格式，验证器在评分时注入。验证器借鉴自代码库中现有的测试套件，或直接逐字使用这些测试。