现有代码智能体基准正面临两类压力：任务逐渐趋于饱和，评测本身的可信度也受到质疑。SWE-Bench ProMax 将重点从常见缺陷修复转向跨文件、保持行为不变的代码重构，希望用更长链路、更大改动范围检验智能体处理真实软件工程任务的能力。
为什么改用重构任务
材料援引的一项审计指出，SWE-bench Verified 中尚未解决的实例里，接近 60% 存在测试问题：部分测试过窄，会拒绝原本正确的方案；部分测试过宽，检查了问题描述没有提出的要求。与此同时，前沿模型还可能逐字复现训练数据中的标准补丁，使得高分未必完全来自现场解决问题的能力。
代码重构提供了不同的难度来源。它通常要求在多个文件之间协调修改，同时保持程序原有行为，而不是只修补一个局部错误。这更强调对代码关系、变更边界和工程约束的持续理解，也更接近长周期的软件维护工作。
170 个多语言真实任务
SWE-Bench ProMax 收录 170 个实例，来自真实代码提交，覆盖 Python、Java、TypeScript、Go、C、C++ 和 Rust 七种语言。每个任务平均修改 11.4 个文件、261.6 行代码，体现出明显的跨文件和大范围变更特征。
基准采用专家参与的多阶段整理流程。问题描述不直接沿用原始文本，而是从头改写，以形成更精确、歧义更少的规格；测试套件经过人工审查，移除过窄或过宽的测试；复杂度不足、跨文件范围有限的任务也会被过滤。其设计重点不只是增加任务数量，而是针对既有基准暴露出的规格、测试和数据污染风险改善评测质量。
我的判断
SWE-Bench ProMax 的主要价值，是把代码智能体评测推进到大规模、跨语言重构这一更接近真实工程的场景，并将测试质量纳入基准构建流程。平均改动规模也说明它不只是简单扩大单文件补丁。
但材料没有提供具体模型成绩，暂时无法判断该基准能否有效拉开前沿模型差距，也不能据此评价某个智能体的实际水平。真实提交仍是经过筛选的离线任务，无法覆盖需求反复、团队协作、构建环境和上线风险等生产约束；七种语言的覆盖也不等于覆盖了各自完整的工具链与项目生态。它更适合作为重构能力的专项评测，而不是代码智能体工程成熟度的完整证明。