SWE-Bench ProMax：用大型多语言重构任务重新衡量编程智能体

导语

AI 编程智能体正在从“补全一段代码”走向更长链路的软件工程任务，但评测体系却开始显得不够用了。现有 SWE-bench 系列基准曾推动了代码修复能力评估，但论文指出，这类基准正面临两类压力：一是前沿模型在部分任务上已经接近饱和；二是评测质量受到质疑，例如近期审计发现，SWE-bench Verified 中不少未解决实例的测试存在问题，可能把正确答案拒之门外，或把题目没有说明的要求强加给模型。

SWE-Bench ProMax 的提出，正是为了把评测难度推向更接近真实工程的方向：大规模、多文件、多语言的代码重构。

核心要点

• 任务类型从修 Bug 转向重构：代码重构要求在保持行为不变的前提下，对多个文件进行协调修改。这比定位单个缺陷更考验智能体对项目结构、依赖关系和代码意图的理解。
• 覆盖七种编程语言：基准包含 Python、Java、TypeScript、Go、C、C++ 和 Rust，避免只在单一生态内衡量模型能力。
• 来自真实提交：170 个实例取自真实软件项目提交，而不是人工构造的小题，更贴近日常维护场景。
• 强调人工治理质量：研究团队对任务进行多阶段专家筛选，重写 issue 描述，使需求更清晰；同时人工审查测试套件，剔除过窄或过宽的测试。
• 规模更大：每个实例平均涉及 11.4 个修改文件和 261.6 行代码，凸显其跨文件、长上下文和工程协同特征。

意义与影响

这项工作的价值不只在于“更难”，而在于重新定义什么才算有用的编程智能体评测。真实开发中，许多高价值任务并不是简单修复一个断言，而是清理架构、迁移接口、统一实现方式或重组模块边界。这些任务要求模型理解原有行为，并在不破坏功能的前提下做系统性改造。

同时，论文把测试质量问题放在基准设计的中心位置。对于代码智能体来说，测试既是评分器，也是训练和优化方向的隐性指挥棒。如果测试本身含糊、偏窄或越界，排行榜就可能奖励错误能力。SWE-Bench ProMax 通过重写任务说明和人工审查测试，试图让评测更可信。

当然，素材中尚未给出完整模型排名或性能结论，因此它目前最值得关注的是基准构建方法本身。随着编程智能体进入真实仓库维护阶段，类似 ProMax 的评测将更能区分“会写代码片段”的模型与“能理解并改造工程系统”的智能体。

来源：Hugging Face Daily Papers