本文翻译自 SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration，原载于 Hacker News。
引言：从「修 Bug」到「维护代码」的范式转变
大语言模型（LLM）驱动的 AI Agent 在自动化软件工程任务方面已经展现出强大的能力，SWE-bench 等基准测试证明了这一点。但这里存在一个关键问题：现有的基准测试都聚焦于静态的、一次性的任务，而现实世界中的软件开发是一个长期维护的过程。
想想你日常的工作状态：需求不断变更、功能持续迭代、代码库在数月甚至数年间不断演进。这种动态的维护过程，恰恰是当前基准测试所忽略的。
阿里巴巴和中山大学联合团队提出的 SWE-CI 基准测试，正是为了填补这一空白。
为什么需要新的评估范式？
现有基准的局限性
从 HumanEval、MBPP 到 SWE-bench，再到 Terminal-bench 和 τ-bench，这些基准测试构建了一个多粒度、多场景的代码智能评估生态。但它们都采用了一个共同的范式：快照式评估（snapshot-based evaluation）。
在这种范式下，Agent 接收一个完整的需求，然后一次性生成解决方案。问题在于：
- 一个写出了硬编码的脆弱修复的 Agent
- 另一个写出了干净、可扩展代码的 Agent
两者可能通过相同的测试套件。它们在可维护性上的差异，在这种评估范式下是不可见的。
Lehman 定律与软件维护成本
经典的软件工程研究告诉我们：
- Lehman 定律指出：软件质量在维护过程中会内在地下降
- 维护活动占软件生命周期成本的 60%-80%
只有当代码库必须演进时——新需求到来、接口变更、模块需要扩展——早期设计决策的代价才会显现。一个习惯于产出结构混乱代码的 Agent，会发现每一次后续修改都变得更加困难，最终无法跟上变化。
这带来了一个关键洞察：Agent 的代码维护能力只能通过长期演进过程来揭示，过去决策的后果会在连续的变化中累积。
SWE-CI：首个基于 CI 循环的代码库级基准
核心设计理念
SWE-CI 的核心创新在于从静态的、短期的功能正确性转向动态的、长期的可维护性。
每个任务由真实仓库中的 base commit 和 target commit 定义，平均跨越 233 天和 71 个连续 commits 的真实演进历史。Agent 需要从 base commit 出发，通过多轮迭代最终通过 target commit 的所有测试。
数据构建流程
SWE-CI 的数据构建经过四个精心设计的步骤：
Step 1: 仓库收集
├── GitHub 上所有 Python 仓库
├── 维护时间 >= 3 年
├── Stars >= 500
├── 包含配置文件和单元测试
└── 开源许可证（MIT/Apache-2.0）
→ 筛选后：4,923 个仓库
Step 2: Commit 区间提取
├── 仅保留主分支
├── 识别依赖不变的最大子序列
└── 排除修改行数 < 1000 的区间
→ 得到：8,311 个候选对
Step 3: 环境构建
├── 自动生成 Dockerfile
├── 运行单元测试验证
└── 自修复机制注入缺失依赖
→ 得到：1,458 个候选对
Step 4: 案例过滤
├── 验证测试可启动
├── 测试通过数差异 >= 5
└── 按时间跨度和 commit 数排序取 Top 100
→ 最终：100 个任务
最终数据集包含来自 68 个不同仓库 的 100 个样本，每个样本的 base/oracle 代码库之间至少涉及 500 行源代码修改（不含测试文件）。
双 Agent 评估协议
SWE-CI 采用 Architect-Programmer 双 Agent 协议来模拟真实世界的持续集成循环：
Architect Agent（架构师）
职责：基于测试差距生成高层需求文档
工作流程：
- Summarize（总结）：审查所有失败的测试，识别根本原因
- Locate（定位）：检查源代码，将失败归因于具体缺陷
- Design（设计）：制定改进计划，输出需求文档
文档规范：
- 增量式：每次不超过 5 个最紧急需求
- 高层级：描述预期行为，将实现选择留给程序员
Programmer Agent（程序员）
职责：根据需求文档维护代码
工作流程：
- Comprehend（理解）：将高层需求转化为明确的代码规范
- Plan（规划）：规划实现这些规范所需的编程工作
- Code（编码）：实践计划，实现需求
这种设计刻意让 Programmer 由需求文档驱动而非直接由测试差距驱动，这与持续集成的快速迭代理念保持一致。
EvoScore：可维护性的量化指标
ISO/IEC 25010 标准将可维护性定义为：软件在不引入缺陷或降低现有质量的情况下被有效修改的程度。关键在于，可维护性无法在单个快照中观察——它只能通过连续修改来体现。
为此，SWE-CI 引入了 EvoScore（Evolution Score）：
首先定义 归一化变化（Normalized Change）：
当改进基准时：a(c) = (n(c) - n(c₀)) / (n* - n(c₀))
当退化时：a(c) = (n(c) - n(c₀)) / n(c₀)
其中 n(c) 是代码库 c 通过的测试数量，c₀ 是基准代码库，c* 是目标代码库。
然后通过未来加权平均聚合 N 次迭代：
EvoScore = Σᵢ γⁱ · a(cᵢ) / Σᵢ γⁱ
当 γ > 1 时，后期迭代获得更大权重。这直接反映了 ISO 定义：真正可维护的代码库是那些随着演进仍然易于修改的代码库。一个牺牲短期速度换取更干净、更可扩展设计的 Agent，将获得更高的 EvoScore。
实验结果：三个关键发现
研究团队对来自 8 个提供商的 18 个模型进行了全面评估，总消耗超过 100 亿 tokens。
发现 1：LLM 的代码维护能力正在加速提升
在同一个提供商家族内，新模型总是获得更高的分数。2026 年之后发布的模型比其前代表现出更大幅度的提升，这表明当前 LLM 的代码能力正在从静态的 Bug 修复快速演进到持续的长期代码维护。
在所有评估的模型中，Claude Opus 系列在整个观察期内保持领先，GLM-5 也是表现突出的强劲选手。
发现 2：不同提供商对代码可维护性的重视程度不同
通过调整 γ 值来观察模型排名的变化：
- γ < 1：早期迭代权重更高，奖励优先考虑即时收益的模型
- γ > 1：后期迭代权重更高，奖励优化长期改进的模型
结果显示：
- MiniMax、DeepSeek、GPT：倾向于长期收益
- Kimi、GLM：倾向于短期回报
- Qwen、Doubao、Claude：在不同设置下保持相对稳定
这种差异可能反映了不同提供商采用的训练策略，而同一提供商内部的相对一致性表明其内部训练流水线基本稳定。
发现 3：当前 LLM 在长期维护中仍难以控制回归
回归（Regression） 是衡量软件质量稳定性的核心指标——如果一个单元测试在代码更改前通过但更改后失败，这个更改就被认为引入了回归。
SWE-CI 测量了在整个代码维护过程中没有发生回归的样本比例（零回归率）：
- 大多数模型的零回归率 低于 0.25
- 只有 Claude-Opus 系列 中的两个模型 超过 0.5
这表明，尽管 LLM 在基于快照的代码修改任务上表现出显著进步，但在完全自动化、长期、多轮的软件开发和维护场景中仍面临重大挑战。
对开发者的启示
如果你正在使用 AI 辅助编程
- 不要只看一次性任务的表现：一个模型在「修复这个 Bug」上表现出色，不代表它在「长期维护这个代码库」上同样出色
- 关注代码质量而非只是功能正确：让 AI 生成代码时，要审查其可扩展性和结构设计
- 警惕回归风险：在多轮迭代中，务必运行完整测试套件，防止 AI 的修改破坏已有功能
如果你正在评估 AI 编程工具
- 选择符合实际场景的基准：如果你的使用场景涉及长期维护，SWE-bench 可能不足以反映真实能力
- 考虑引入 EvoScore 式的评估：将后期迭代表现纳入考量，而非只看最终结果
- 关注零回归率：对于生产环境，稳定性比单次成功率更重要
总结
SWE-CI 的出现标志着 AI 代码能力评估的一个重要转折点：从「能否写出正确的代码」到「能否维护健康的代码库」。这对于我们理解和改进 AI 辅助编程工具具有重要意义。
关键要点：
- 范式转变：从快照式评估到演进式评估，从功能正确性到长期可维护性
- 真实数据：100 个任务来自真实仓库，平均跨越 233 天和 71 个 commits
- 双 Agent 设计：模拟真实 CI 循环，让过去决策的后果在后续迭代中累积
- EvoScore 指标：未来加权设计，奖励真正可维护的代码
- 现状揭示：即使是 SOTA 模型，在长期维护场景下仍面临回归控制的挑战
论文资源：
- Hugging Face: https://huggingface.co/datasets/skylenage/SWE-CI
- GitHub: https://github.com/SKYLENAGE-AI/SWE-CI