SWE-Rebench五语实测扩军

13款模型、4类Agent，代码评测开始摆脱Python偏科

SWE-Rebench在2026年7月更新了编程模型实测范围：截至7月31日，评测页面已经覆盖13款模型、4类Agent，以及Go、Java、Python、Rust和TypeScript五种编程语言。

SWE-Rebench是一个面向软件工程Agent的真实代码任务评测体系，它不是让模型补完一道孤立函数，而是要求Agent进入可执行的软件仓库，根据问题描述定位缺陷、修改代码，并通过项目测试验证修复结果。换句话说，它考的不是“会不会写一段看起来正确的代码”，而是“能不能把一个真实项目修好”。

这次扩展真正值得关注的不是模型数量从个位数增加到13款，而是评测矩阵同时引入了模型、Agent框架和编程语言三个变量。过去的代码榜单经常把模型能力压缩成一个百分比，但在真实开发中，同一个模型换一套检索、编辑和测试策略，结果可能完全不同；同一套Agent从Python项目迁移到Rust或Java项目，也可能迅速暴露工具链和上下文管理问题。

这不是一张榜单，而是一组工程能力切片

五语言评测的价值在于，它能把模型的“Python高分”拆解成更具体的工程能力。Go、Java、Python、Rust和TypeScript分别代表了不同的依赖管理、类型系统、构建流程和错误反馈方式，模型面对的并不是五套语法题，而是五种不同的软件工程环境。

| 语言 | 典型工程难点 | Agent容易暴露的问题 | |---|---|---| | Python | 动态类型、依赖环境、测试约定差异 | 修改看似合理，但在运行时或边界输入上失败 | | Go | 模块管理、接口约束、并发语义 | 能通过编译，却破坏接口行为或并发安全 | | Java | Maven/Gradle、类型层级、大型多模块项目 | 构建耗时长，检索范围大，容易遗漏跨模块影响 | | Rust | 所有权、生命周期、trait约束、严格编译器 | 为通过编译进行局部绕行，却没有解决根因 | | TypeScript | 类型声明、前后端依赖、异步控制流 | 混淆编译期类型正确与运行时行为正确 |

Rust尤其适合检验Agent是否真的理解代码。Rust编译器能提前拦住一批所有权、借用和类型错误，因此模型很难仅靠“生成一个大概能跑的补丁”蒙混过关；但编译通过也不等于行为正确，Agent仍要理解测试、状态变化和异常路径。

Java则更像一场上下文管理压力测试。大型Java仓库常常具有较深的调用层级、接口继承关系和多模块构建配置，模型需要在有限上下文内找到真正相关的文件，而不是把整个仓库无差别塞进提示词。对Agent而言，搜索顺序、符号定位和增量测试往往比一次生成多少代码更重要。

TypeScript考验的是模型能否区分类型系统与运行时系统。一个补丁可能让类型检查恢复正常，却在Promise链、前端状态更新或Node.js运行时中制造新问题；反过来，使用过多类型断言也可能只是把错误藏起来，而不是修复错误。

13款模型乘以4类Agent，不应简单理解成52个同质结果

Agent是让模型执行检索、编辑、运行命令和读取测试反馈的软件系统。在软件工程评测里，基础模型负责理解与决策，Agent则决定模型能看到什么、能调用哪些工具、以什么节奏修改和验证代码。

因此，13款模型与4类Agent构成的是一套多变量实验，而不是简单的“52次聊天”。即使评测页面展示了大量模型与Agent组合，也不能默认所有组合都拥有完全相同的预算、工具权限、上下文长度和重试策略；在比较结果前，仍需要核对运行配置和评测口径。

模型与Agent之间至少存在四个会显著影响成绩的变量：

1. 仓库检索策略决定模型先读哪些文件，以及能否快速找到跨文件依赖。
2. 编辑机制决定Agent采用整文件重写、补丁修改还是结构化编辑，错误率并不相同。
3. 测试反馈循环决定Agent能否根据编译器和测试日志迭代，而不是一次提交后结束。
4. 计算预算决定可使用的模型调用次数、上下文规模和修复轮数，高预算通常更容易获得高分。

这也解释了为什么单独讨论“最强代码模型”越来越不准确。一个推理能力更强但操作仓库效率较低的模型，可能输给一个能力稍弱、却与Agent工具链配合更好的模型；一个擅长Python的Agent模板，迁移到Java后也可能把大量预算浪费在构建和无效检索上。

V2实验已经显示：跨语言能力差距远大于单项榜单看起来的差距

SWE-Rebench V2是该体系面向大规模、多语言软件工程任务收集的升级版本，核心目标是用统一的可执行契约，把不同语言生态中的真实任务转化为可训练、可复现和可诊断的环境。

公开论文实验曾比较Python、JavaScript、Go、Rust和Scala任务，并报告pass@1与pass@3。pass@1是模型在一次尝试中成功解决任务的比例，pass@3则是在最多三次尝试中至少成功一次的比例；后者不仅反映模型能力，也反映重复尝试能带来多大收益。

| 模型 | Python | JavaScript | Go | Rust | Scala | pass@1 | pass@3 | |---|---:|---:|---:|---:|---:|---:|---:| | Claude Opus 4.5 | 36.1% | 26.7% | 15.0% | 28.9% | 19.4% | 25.2% | 32.7% | | GLM 4.7 | 27.2% | 26.1% | 17.2% | 24.4% | 11.7% | 21.3% | 26.7% | | MiniMax M2.1 | 26.1% | 26.1% | 15.6% | 20.6% | 7.8% | 19.2% | 27.0% | | Gemini 3 Flash | 25.6% | 25.0% | 11.7% | 21.1% | 7.2% | 18.1% | 27.7% | | DeepSeek v3.2 | 23.3% | 24.4% | 12.2% | 21.7% | 5.6% | 17.4% | 25.0% | | GPT-5.2 | 20.6% | 24.4% | 11.1% | 21.7% | 7.2% | 17.0% | 25.0% |

这组数据不是本次五语言实时页面的完整13模型榜单，而是理解SWE-Rebench多语言评测价值的重要历史参照。两者的语言集合也不完全一致：V2公开实验包含JavaScript与Scala，本次扩展则强调Go、Java、Python、Rust和TypeScript，因此不能把两个表格里的分数直接拼接或横向排名。

跨语言落差比模型之间的总分差距更值得看。以Claude Opus 4.5为例，Python任务得分为36.1%，Go只有15.0%，相差21.1个百分点；GLM 4.7在JavaScript上为26.1%，Scala为11.7%，相差14.4个百分点。这意味着所谓“代码能力”仍然高度依赖语言生态，模型在高资源语言中学到的模式并不会自动迁移到另一套构建系统和类型约束中。

多次尝试也无法完全弥补工程理解不足。Claude Opus 4.5的pass@1为25.2%，pass@3为32.7%，增加三次机会后提升7.5个百分点；Gemini 3 Flash从18.1%升至27.7%，提升9.6个百分点；MiniMax M2.1从19.2%升至27.0%，提升7.8个百分点。重试确实有效，但多数失败并不是简单的采样运气问题，而是定位错误、环境配置、测试理解或跨文件推理没有完成。

SWE-Rebench与传统代码跑分的区别，在于“答案必须在仓库里成立”

传统代码生成基准通常给出明确的函数签名、输入输出和单元测试，模型只需要在较小的搜索空间内生成实现。HumanEval、MBPP和LiveCodeBench在衡量基础编码与算法能力上仍有价值，但它们难以模拟开发者维护一个陌生仓库时面对的噪声。

真实软件工程任务通常没有明确告诉Agent应该修改哪个文件。GitHub issue可能只描述一个异常现象，真正原因却藏在配置加载、接口实现或版本兼容逻辑里；Agent不仅要生成补丁，还要判断错误能否复现、现有测试覆盖了什么，以及修改是否影响其他模块。

SWE类评测因此更接近“接手工单”，而不是“参加算法考试”。一个能写出漂亮函数的模型，未必能处理依赖冲突、读取长日志、理解历史兼容逻辑并控制修改范围；一个在单文件任务中表现普通的模型，也可能因为工具使用更稳定，在真实仓库里取得更高成功率。

与Multi-SWE-bench相比，SWE-Rebench更强调持续收集和训练基础设施

Multi-SWE-bench是字节跳动Seed团队推出的多语言真实代码修复基准，覆盖Java、TypeScript、C、C++、Go、Rust和JavaScript七种语言，共包含1,632个真实修复任务，并将任务划分为简单、中等和困难三个等级。

SWE-Rebench V2则把重点放在大规模、语言无关的任务采集管线，以及可复现的交互式训练环境。公开介绍显示，其任务规模超过32,000个，并覆盖20种编程语言，同时为任务准备可执行环境和实例级诊断信息。前者更像经过筛选和分级的考试卷，后者则试图建设一座能够持续生产训练任务、运行环境和评测样本的工厂。

| 维度 | SWE-Rebench最新实测 | SWE-Rebench V2任务体系 | Multi-SWE-bench | |---|---|---|---| | 核心用途 | 比较模型与Agent的真实修复表现 | 大规模收集、训练与诊断 | 标准化多语言修复评测 | | 本次重点语言 | Go、Java、Python、Rust、TypeScript | 面向20种语言扩展 | 7种语言 | | 公开规模 | 13款模型、4类Agent | 超过32,000个可执行任务 | 1,632个任务 | | 主要特点 | 同时观察模型、Agent和语言 | 预构建环境、统一执行契约 | 真实任务、人工筛选、难度分级 | | 适合回答的问题 | 哪种组合在当前任务上更有效 | 如何获得大规模可训练任务 | 模型在标准多语言集合上有多强 |

两类路线并不是相互替代关系。经过人工审核的小型高质量测试集适合做稳定版本对比，大规模自动化任务管线则更适合强化学习和持续训练；真正成熟的代码Agent需要同时面对“不能背答案的测试集”和“数量足够大的训练环境”。

这次扩展最大的意义，是让Agent优化从提示词技巧转向系统工程

五语言覆盖会迫使开发团队正视环境层的问题。Python Agent习惯的快速安装、运行和修改流程，到了Java可能被漫长构建拖慢，到了Rust可能被编译反馈占用大量上下文，到了TypeScript又要处理包管理器、构建工具和运行时版本差异。

高质量代码Agent需要具备语言感知能力。它应该知道何时先运行静态检查，何时执行局部测试，何时读取构建配置，何时停止扩大修改范围；如果Agent对所有仓库都机械执行同一套命令，即使底层模型很强，也会在时间和调用预算上吃亏。

企业选型也不应只看总榜第一。以Java和Go为主的后端团队，应该优先看对应语言中的任务成功率、构建稳定性和修改范围；使用Rust开发基础设施的团队，则更需要检查Agent是否频繁采用规避类型系统的补丁；TypeScript团队还要关注模型能否处理前端、Node.js和类型声明之间的边界。

榜单仍有三个需要警惕的变量

SWE-Rebench的扩展提高了参考价值，但任何软件工程榜单都无法消除任务污染、预算差异和环境偏差。13款模型的名次可以作为观察窗口，却不能直接等价为企业代码库中的实际生产力。

第一，任务时间切分决定了模型是否可能在训练阶段见过相关仓库、issue或补丁。真实GitHub任务比人工题更贴近生产，同时也更容易被公开训练语料覆盖，因此评测需要清楚披露任务日期与去污染策略。

第二，Agent预算决定了比较是否公平。允许更多模型调用、更长上下文和更多测试轮次，通常会提高成功率，但也会增加延迟与成本；如果榜单只展示解决率而不展示每个成功任务的平均成本，用户很难判断方案是否适合大规模部署。

第三，可复现环境决定了失败到底来自模型还是基础设施。Java依赖下载失败、Node.js版本不匹配、Rust工具链变化，都可能让正确补丁无法通过验证；预构建Docker环境和实例级诊断很重要，因为它们能把环境失败与逻辑失败分开。

判断：多语言之后，代码模型的短板会更清楚，而不是更好看

SWE-Rebench扩展到13款模型、4类Agent和五种语言，是一次比“又多测了几个模型”更有价值的更新。它把模型能力、Agent编排和语言生态放进同一张实验桌，让开发者能够观察一个系统究竟是模型不会写、Agent不会找，还是环境根本没有跑通。

这类评测短期内可能让代码模型的成绩显得更低。Python单项榜单中的领先模型，进入Go、Java、Rust和TypeScript仓库后，会面对更复杂的构建链、类型约束和跨文件依赖；20%至30%的任务解决率并不漂亮，却比一个被反复优化到高分的单语言基准更接近现实。

真正值得追踪的指标也将从单一成功率变成三项组合：跨语言稳定性、单位任务成本和首次修复成功率。能在一次尝试中用较低预算完成修复的系统，比依赖大量重试刷出pass@3的系统更适合进入持续集成和日常开发流程。

代码Agent竞争正在从“谁最会生成代码”转向“谁最会维护软件”。SWE-Rebench这次五语言扩军的价值，正是把这两件长期被混为一谈的能力拆开，并提醒行业：能写Python答案，只是起点；能在不同语言、不同构建系统和不同Agent框架中稳定修好真实项目，才接近可用的工程智能。

参考来源

• SWE-Rebench V2社区发布说明：介绍超过32,000个可执行任务、20种编程语言和预构建运行环境等关键信息。