SWE Atlas: Benchmarking Coding Agents Beyond Issue Resolution¶

会议: NeurIPS 2026
arXiv: 2605.08366
代码: https://github.com/scaleapi/SWE-Atlas
领域: 代码智能
关键词: 代码智能、软件工程评测、编码智能体、变异测试、代码重构

一句话总结¶

SWE Atlas 构建了涵盖代码库问答、测试编写和代码重构三大真实软件工程工作流的 284 项专家任务基准，引入结合程序化运行检查与原子细粒度评分准则的混合评测体系，全面评估编码智能体在功能正确性之外的软件工程质量与架构可维护性。

研究背景与动机¶

大语言模型作为编码智能体的迅速普及，推动了软件工程评测范式从基础函数级代码补全向端到端功能修复演进。现有的 SWE-bench Pro 或 TerminalBench 等基准着重于提升修复 GitHub Issue 或终端任务的难度与长程执行能力。然而，工业界真实软件开发并不等同于单一的功能补丁修补，它涵盖了代码库可维护性、防范未来退化以及架构理解等多维度工程素养。过度聚焦于功能性缺陷修复，容易导致模型沦为只懂打补丁的修补器，却缺乏作为专业工程师维护代码库长期健康度、遵循最佳工程实践和编写鲁棒测试的能力。

开发人员在真实开发场景中使用编码智能体的行为研究表明，三大关键工作流在现有基准中被严重忽视：其一是前置的代码库问答与架构理解，要求智能体综合分析复杂结构并进行运行时验证；其二是测试编写，需要采用对抗性思维预判边界异常与实现变异覆盖，而非被动满足预设断言；其三是代码重构，要求在保证行为绝对等价的前提下优化代码组织与接口边界。这些工作流不仅具有欠指定、目标导向的现实特征，且传统的单一单元测试通过率难以度量工程设计的优雅性与严谨性。

针对现有基准在专业工程实践维度上的评测盲区，本文提出 SWE Atlas，旨在填补功能修复之外的软件工程评测空白。核心 idea：构建包含代码库问答、测试编写与重构的 284 项专家级真实工作流任务，采用“程序化测试/变异验证 + 细粒度原子 Rubric 专家评审”的双重评估范式，从功能正确性与工程架构质量两个维度全面衡量编码智能体的专业能力。

方法详解¶

整体框架¶

SWE Atlas 选取 18 个采用 Copyleft（GPL）开源协议且持续活跃维护的代码库，由专业资深软件工程师手工设计了 284 个贴近生产实际的单轮任务。每个任务均运行在隔离的 Docker 容器沙箱内，预置真实的编译运行环境并清空版本历史以防信息泄露。评测框架根据不同任务流的特性，分别组合程序化运行验证（回归测试、变异测试）与 LLM 评审准则（Rubric-as-a-Judge），兼顾确定性功能验证与多维度工程质量审计。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["欠指定工程任务输入<br/>自然语言目标与运行时环境"] --> B["三类真实软件工程工作流"]
    B --> C["运行时代码库问答流程<br/>深层探索、起服发请求与运行追踪"]
    B --> D["对抗性测试编写流程<br/>定位目标、编写用例并生成 Manifest"]
    B --> E["保行为代码重构流程<br/>跨文件结构重组、契约继承与无用符号清理"]
    C --> F["双重评测体系架构"]
    D --> F
    E --> F
    F --> G["程序化功能验证<br/>变异插桩检测 / 回归测试套件"]
    F --> H["结构化 Rubric 评审准则<br/>原子化二元检查点与反模式惩罚"]
    G --> I["最终通过判定：功能正确且满足全部必要工程准则"]
    H --> I

关键设计¶

1. 三类真实软件工程工作流：突破单一功能修复局限

传统评测普遍假设任务具备完全明确的描述，而真实软件开发任务通常具有欠指定和目标导向的特征。SWE Atlas 设计了三大工作流以覆盖软件工程的全生命周期： 1. 代码库问答（Codebase Q&A，124 项）：模拟开发者在新代码库上手、系统架构设计、运行时异常排查以及安全审计时的深度提问。任务要求智能体不能仅依赖静态文本分析，必须实际启动应用服务、构造请求追踪执行数据流，并给出具备运行时实证支持的详尽分析报告。 2. 测试编写（Test Writing，90 项）：智能体接收自然语言形式的测试目标与执行脚本，需要自主探索定位待测模块，并编写覆盖单元测试、集成测试及端到端验收测试的高质量测试套件。智能体在提交测试补丁的同时，需一并输出清单文件（Manifest）列举所有新增测试点。 3. 代码重构（Refactoring，70 项）：给定代码重复、逻辑分散或模块迁移的目标需求，64% 的任务附带高层次接口规范。智能体须跨文件迁移逻辑、设计清晰的模块边界并联动调整调用链，同时彻底清理冗余的旧定义、工具函数和导入项。

2. 运行时代码库问答流程：强制结合静态推理与动态执行

以往的代码库问答基准大多只需智能体静态阅读少量文件即可拼凑出答案，无法评测复杂系统的运行时调试能力。SWE Atlas 在构建代码库问答任务时，专门设计了依赖动态状态的深层技术问题。在这一设计下，智能体必须在沙箱环境中完成代码构建、拉起后端服务或进程、发送真实请求并观察错误堆栈或日志。评审体系不仅考核回答的完整性（Answer Comprehensiveness），还引入了负向准则（Negative Rubrics），对缺少运行时证据、凭空脑补静态假说的回答施加惩罚，迫使模型展现出端到端的探索与排错能力。

3. 对抗性测试编写流程：清单忠实度校验与变异测试双重门禁

为了防止智能体通过编写无论断或无效断言的虚假测试来刷高测试通过率，SWE Atlas 在测试编写中引入了变异测试（Mutation Testing）。评测分为三个阶段：首先通过判定智能体提交的 Manifest 清单是否忠实反映其修改代码；随后将智能体新增的测试分别在未经修改的基线代码和经过变异打桩（Mutation Patch）的代码上执行。变异补丁采用专家手写的桩函数替换（例如抛出未实现异常或返回空操作），合格的测试必须在基线代码上全部通过、并在代码被破坏时精准报错拦截。最后，再由评测准则检查测试对业务边界、错误条件和异常路径的覆盖充分性。

4. 保行为代码重构流程：跨文件依赖感知与架构保洁审计

大规模代码重构的痛点在于破坏隐式依赖与产生技术债务。SWE Atlas 重构任务的代码改动规模显著超越以往基准，改动行数中位数达到真实工程级别。评测管道首先在包含隐藏测试的完整测试套件上运行智能体补丁，严格要求基线测试与新增测试均无任何退化（Regression Test Pass），并禁止篡改测试用例本身。在此基础上，通过细粒度 Rubric 深入审查重构质量，涵盖代码可维护性（Code Maintainability，是否真正消除重复并合理提取模块）、工件清理（Artifact Cleanup，废弃旧符号、无用导入是否彻底清除）以及负向扣分项（是否引入破坏性公共接口变更或代码坏味道）。

5. 结构化 Rubric 评审准则：原子化独立打分消除主观偏差

针对软件工程中难以用单元测试衡量的定性维度（如模块放置合理性、代码规范、文档维护等），SWE Atlas 构建了专家编写的原子化 Rubric 检查表。每个 Rubric 项均为独立的二元是非题（YES/NO），评测模型仅需根据上下文判断代码补丁或回答是否满足特定要求。全数据集平均每项任务包含 10.5 至 17.4 条评分准则，划分为必须满足的准则（Must-have Rubrics）与仅作定性诊断的参考准则。三位独立专家的严格跨评估显示，LLM 裁判（Opus 4.5）与人类专家在 Cohen's \(\kappa\) 上达到 0.88，不同评测模型间的宏观 F1 超过 0.87，证明了原子评测准则的高一致性与低波动性。

实验关键数据¶

主实验¶

论文在统一的沙箱基准环境中评测了当前前沿闭源模型及主流开源权重模型。对于前沿模型，评测涵盖了厂商原生脚手架（Codex CLI、Claude Code、Gemini CLI）与统一的极简脚手架（mini-SWE-agent），指标包括平均单次通过率 Pass@1（Wilson 95% 置信区间）、3 次试验全部通过的可靠性指标 Pass3，以及各子工作流的 Pass@1。

模型与脚手架配置	总体 Pass@1 (%)	一致性 Pass3 (%)	代码问答 Q&A (%)	测试编写 TW (%)	代码重构 RF (%)
GPT-5.4 (Codex)	43.49 \(\pm\) 3.32	29.2	40.80	44.36	44.29
Opus 4.7 (Claude Code)	41.89 \(\pm\) 3.31	29.2	40.30	38.51	48.57
GPT-5.3 Codex (Codex)	37.38 \(\pm\) 3.25	24.3	32.60	38.98	42.38
Opus 4.6 (Claude Code)	34.93 \(\pm\) 3.20	22.9	33.30	36.67	35.58
Sonnet 4.6 (Claude Code)	31.63 \(\pm\) 3.12	14.4	31.20	31.76	32.21
Gemini 3.1 Pro (Gemini CLI)	25.23 \(\pm\) 2.91	13.9	16.03	31.23	33.81
统一 mini-SWE-agent
Opus 4.7 (mini-SWE)	38.94 \(\pm\) 3.25	27.1	36.02	43.25	38.60
GPT-5.4 (mini-SWE)	38.00 \(\pm\) 3.26	28.9	36.30	40.00	38.46
Opus 4.6 (mini-SWE)	31.83 \(\pm\) 3.12	21.1	30.00	36.08	29.61
GLM-5 (开源第一)	24.03 \(\pm\) 2.87	11.6	20.50	28.74	24.24
Kimi K2.5	19.05 \(\pm\) 2.64	9.9	13.10	25.77	20.95
Gemini 3 Flash	15.65 \(\pm\) 2.44	7.7	8.20	30.30	10.00
MiniMax M2.5	15.20 \(\pm\) 2.41	6.0	10.30	18.60	19.52

消融与评测维度对比¶

为量化程序化测试与软件工程质量准则之间的鸿沟，下表对比了仅依赖程序化检查（测试编写中的变异击杀、代码重构中的回归测试通过）与加入强制性 Rubric 评审后的综合通过率差异。

任务类型与检查维度	纯程序化检查通过率 (%)	必须 Rubric 准则通过率 (%)	质量差距 (pp)	核心瓶颈特征
测试编写 (TW)	~50 - 65%	~35 - 45%	10 - 15 pp	断言偏弱，仅测正常路径，缺少反向与状态不变检查
代码重构 (RF)	60 - 80%	30 - 48%	15 - 40 pp	未完成跨文件全面解耦，残留冗余依赖与死代码
代码问答 (Q&A 证据)	-	46% (Claude 缺失运行证据)	-	倾向于静态代码推理解释，缺乏实际应用运行采样

关键发现¶

工程质量显著滞后于功能正确性：所有模型在纯测试通过率上表现良好，但在细粒度工程准则下断崖式下跌。在重构任务中，仅凭回归测试各模型通过率高达 60–80%，但加上代码可维护性与死代码清理等 Rubric 审查后，得分直降 15–40 个百分点，暴露出大量半吊子重构。
可靠性严重不足（Pass@1 vs Pass3）：即便是表现最强的 GPT-5.4 与 Opus 4.7，其 Pass3 相比 Pass@1 也下降了约 30%–50%（从约 43% 降至 29%），开源模型降幅更超过 50%，说明当前的智能体在复杂软件工程场景中缺乏稳定的复现能力。
测试用例“多而不精”：智能体在测试编写中倾向于堆砌大量快乐路径（Happy Path）测试，而断言普遍偏弱；当被测函数被变异替换为桩函数后，弱断言依然能够成功通过，导致变异击杀率低下。优秀的模型反而倾向于编写更少但针对性更强、覆盖异常边界的精简测试。
多智能体协作提升代码探索深度：在代码库问答任务中，支持子智能体派发的 Claude Code 架构（Opus 4.6 平均每轮派发 2.64 个子代理，覆盖 96.5% 的试验）显著扩展了对大型仓库不同模块的并行探索和运行时跟踪，相比单智能体循环表现出更高的信息完备度。

亮点与洞察¶

从打补丁到全生命周期软件工程：跳出了 SWE-bench 类的单向 Issue 修复框架，首次系统性地将代码库问答、变异测试编写与架构重构列为主流基准，建立了面向专业软件工程师素养的评测标准。
程序化验证与原子 Rubric 相互锚定：采用变异打桩测试解决测试生成评测中的假阳性问题，利用 Manifest 校验杜绝测试范围伪造，辅以高一致性原子 Rubric 解决工程规范难以自动化评测的难题。
探索与运行时执行策略的分化：前沿模型展现出了差异化的规划偏好，GPT-5.4 倾向于前置全仓代码搜索与架构分析，而 Opus 4.7 则在轨迹末期密集调用运行时构建、启动与测试命令以验证实现假说。

局限与展望¶

单轮交互限制：目前基准任务均为单轮触发，尚未涵盖真实工业级开发中的多轮代码评审反馈、需求澄清讨论和人机协同迭代等复杂场景。
任务领域覆盖仍可扩展：评测主要集中在应用代码层面，尚未覆盖运维部署（DevOps）、基础设施配置、网络系统以及底层固件安全等同样关键的软件工程垂直方向。
开放开源仓的潜在污染风险：尽管任务均由专家重写且进行了变异设计，且记忆力筛查显示解法与上游 PR 的 Jaccard 相似度仅为 0.1–0.5，但基于公开 GitHub 仓库构建的基准长期仍面临预训练数据泄漏的潜在挑战。

评分¶

新颖性: ⭐⭐⭐⭐⭐ 突破单一缺陷修复框架，首次系统性构建覆盖 Q&A、测试与重构的复合工程质量评测体系。
实验充分度: ⭐⭐⭐⭐⭐ 涵盖 284 项专家任务、多款前沿闭源与开源模型、双重脚手架对比及详尽的变异和裁判一致性消融。
写作质量: ⭐⭐⭐⭐⭐ 结构清晰严密，论述深入，深入分析了智能体作为“工程师”而非“修补匠”的失败模式。
价值: ⭐⭐⭐⭐⭐ 为编码智能体在真实工业开发环境中的落地与评估指明了关键方向，提供了极其宝贵的指导依据。