SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

本文提出了首个基于持续集成循环的仓库级基准测试 SWE-CI，旨在通过模拟真实世界中长达数月的代码演进历史，将大模型智能体的评估范式从静态的短期功能正确性转向动态的长期代码可维护性。

要点

这篇论文介绍了一个名为 SWE-CI 的新项目，它的核心目的是测试 AI 程序员是否真的“懂”如何长期维护代码，而不仅仅是会“修”代码。

为了让你更容易理解，我们可以把写软件比作盖房子和装修。

1. 以前的测试：只考“一次性装修”

以前的 AI 测试（比如 SWE-bench），就像是一个突击检查。

• 场景：考官给 AI 一张图纸（需求），说：“这里有个窗户坏了，你把它修好。”
• AI 的做法：AI 可能会用强力胶水把窗户粘上，虽然窗户能关上了（功能通过了），但胶水干了之后窗户就再也打不开了，或者下次想换个窗帘都拆不下来。
• 问题：这种测试只看“窗户现在关没关”，却不管“这窗户以后好不好用”。在现实世界里，软件不是一次性建好的，而是要不断升级、打补丁、换功能的。如果 AI 写的代码像“胶水粘的窗户”，过几个月新需求来了，整个房子可能就塌了。

2. SWE-CI 的测试：考“长期管家”能力

SWE-CI 把测试变成了一场长达 233 天的“房屋改造马拉松”。

• 场景：AI 接手了一个已经住了 233 天、经历了 71 次装修的旧房子（真实代码库）。
• 任务：AI 不能一次性把房子改完。它必须像真正的建筑工头一样，分几十个小步骤：
  1. 先看看哪里漏水（分析代码）。
  2. 修补一下（写代码）。
  3. 跑个测试（检查有没有把墙弄塌）。
  4. 再根据新需求，继续修补下一处。
• 核心挑战：如果 AI 为了赶进度，今天随便糊弄一下（比如用胶带粘水管），明天新需求来了要换水管，它就会发现根本拆不动，最后导致整个系统崩溃。
• SWE-CI 的评分标准：不仅看你今天修好了没有，更看你在修了 70 次之后，房子是不是还结实、好不好改。

3. 独特的“双工头”模式

为了让测试更真实，SWE-CI 设计了两个 AI 角色配合工作，就像现实中的建筑师和施工队：

• 建筑师（Architect Agent）：
  • 它的任务是看问题、定计划。它不看具体的砖怎么砌，而是看“这里漏水了，我们需要加个防水层”。它负责把复杂的 bug 变成清晰的“施工任务单”。
• 施工队（Programmer Agent）：
  • 它的任务是干活。它拿着任务单，去改代码、加功能。
• 为什么这样设计？ 这模拟了真实公司里，产品经理/架构师提需求，程序员写代码的流程。如果“建筑师”没看清问题，或者“施工队”为了省事乱干，房子迟早会塌。

4. 实验结果：AI 还在“练级”中

作者用 100 个真实的“房屋改造”案例测试了各种顶尖 AI 模型，结果发现：

• 进步很快：现在的 AI 确实比一年前强多了，修房子的速度变快了。
• 但“眼高手低”：很多 AI 为了快速通过今天的检查，会写一些“短视”的代码（比如为了跑通测试，把代码写得死板、难修改）。
• 后果严重：一旦进入长期维护阶段（比如第 50 次修改时），这些 AI 就会因为之前的“烂尾工程”而崩溃，甚至把原本没坏的地方也弄坏了（这叫回归错误）。
• 数据说话：大多数 AI 在长期维护中，很难保持“零事故”（即不引入新 bug）。只有极少数顶尖模型（如 Claude Opus 系列）表现得稍微好一点，但也远未达到人类资深工程师的水平。

总结

SWE-CI 就像给 AI 程序员发了一张长期居住证，而不是一日游门票。

它告诉我们：现在的 AI 很擅长做一道数学题（一次性修 bug），但还不太擅长经营一家公司（长期维护复杂的软件系统）。未来的 AI 不仅要能“写代码”，更要学会“写那种以后好改、好扩展的代码”。这才是软件工程的真正核心。

技术摘要

论文标题

SWE-CI：通过持续集成评估智能体在代码库维护中的能力

1. 研究背景与问题 (Problem)

• 现有基准的局限性：当前的大语言模型（LLM）智能体在软件工程任务（如静态 Bug 修复）上表现强劲（例如 SWE-bench 等基准）。然而，现有的评估范式大多基于**“快照式”（Snapshot-style）**：即给定一个完整的需求和初始代码，智能体一次性生成补丁。
• 现实世界的差距：真实的软件开发是一个长期的、动态的过程，涉及复杂的需求变更和长期的功能迭代。
  • 可维护性缺失：在快照式评估中，一个“硬编码”的脆弱修复和一个“结构清晰、可扩展”的修复可能都能通过测试，导致**可维护性（Maintainability）**的差异被掩盖。
  • 技术债务累积：只有当代码库需要长期演进（新需求、接口变更）时，早期糟糕的设计决策才会导致后续修改成本剧增，甚至导致智能体无法跟上迭代节奏。
• 核心问题：目前缺乏能够评估智能体在长期代码演进中维持代码质量能力的基准。

2. 方法论 (Methodology)

2.1 核心概念：基于演进的评估范式

SWE-CI 提出了一种**基于演进（Evolution-based）**的评估范式，取代了传统的快照式评估。

• 流程：智能体从基础代码库（Base Commit）开始，通过多轮迭代（CI 循环），逐步演化至目标代码库（Oracle Commit）。
• 机制：
  1. 需求生成：根据当前代码与目标代码的功能差距，动态生成需求文档。
  2. 代码修改：智能体根据需求修改代码。
  3. 测试验证：运行测试，观察结果。
  4. 循环：将修改后的代码作为下一轮的输入，直到通过所有目标测试。
• 意义：这种机制使得早期决策的后果会在后续迭代中累积，从而暴露智能体的长期决策质量。

2.2 数据构建 (Data Curation)

SWE-CI 包含 100 个任务，构建过程严谨：

1. 仓库收集：筛选 GitHub 上维护超过 3 年、Star 数>500、包含配置/依赖文件及单元测试的 Python 仓库（共 4923 个）。
2. 提交跨度提取：在主干分支上寻找依赖未发生变化的最大连续提交子序列，形成“基础/目标”提交对。
3. 环境构建：自动生成 Docker 环境，并引入自修复机制（自动注入缺失依赖）以确保测试可运行。
4. 案例过滤：
   • 确保基础代码能运行测试。
   • 确保基础代码与目标代码的通过测试数差异至少为 5 个（保证有实质性的演进距离）。
   • 最终选取时间跨度最大、提交数最多的前 100 个案例。

• 统计特征：平均每个任务跨越 233 天 和 71 次连续提交，涉及至少 500 行源代码修改。

2.3 双智能体评估协议 (Dual-Agent Protocol)

为了模拟真实世界的持续集成（CI）流程，SWE-CI 采用 架构师（Architect）- 程序员（Programmer） 双智能体协作模式：

• 架构师 (Architect)：
  • 职责：分析测试失败原因，定位问题，生成高层级需求文档。
  • 策略：遵循“增量”原则（每次最多 5 个紧急需求）和“高层级”原则（描述预期行为而非具体实现），避免过度设计。
• 程序员 (Programmer)：
  • 职责：根据需求文档理解、规划并编写代码。
  • 策略：将高层需求转化为具体代码实现，专注于快速、针对性的开发。
• 迭代：两者通过 CI 循环协作，直到通过目标提交的所有测试。

2.4 评估指标：EvoScore

为了量化长期维护能力，提出了 EvoScore (Evolution Score)：

• 归一化变化 (Normalized Change)：衡量当前代码库相对于初始代码库的测试通过率提升（或相对于基线的回归）。
  • 改进时：归一化到总差距。
  • 回归时：归一化到初始通过数（惩罚更重）。
• 加权平均：
  $$EvoScore = \frac{\sum \gamma_i \cdot a(c_i)}{\sum \gamma_i}$$
  • 引入权重 $\gamma \ge 1$，赋予后续迭代更高的权重。
  • 逻辑：真正的可维护性体现在随着演进，代码依然易于修改。如果智能体为了短期通过测试而积累技术债务，导致后期修改困难，其 EvoScore 会下降。

3. 主要贡献 (Key Contributions)

1. 首个基于持续集成的仓库级基准：SWE-CI 是第一个模拟真实软件长期演进过程的基准，填补了从“静态功能正确性”到“动态长期可维护性”评估的空白。
2. 创新的评估协议：提出了“架构师 - 程序员”双智能体协作模式，模拟真实 CI 流程，能够细粒度地观察智能体在长期迭代中的表现。
3. 新的度量标准：定义了 EvoScore，通过加权未来迭代的表现，有效区分了“短期修复”与“长期可维护”的代码生成策略。
4. 大规模实证研究：构建了包含 100 个高难度任务的数据集，并消耗超过 100 亿 token 对 18 个主流模型进行了全面评估。

4. 实验结果 (Results)

研究对 8 家提供商的 18 个模型进行了评估，主要发现如下：

• 观察 1：维护能力加速提升

  • 同一厂商的新模型得分普遍高于旧模型，2026 年后发布的模型提升显著。
  • Claude Opus 系列在整个观察期内表现最佳，GLM-5 也表现强劲。
  • 表明 LLM 正从单纯的静态 Bug 修复向长期代码维护能力演进。

• 观察 2：不同厂商对可维护性的侧重不同

  • 通过调整 $\gamma$ 值（侧重短期 vs 长期），发现不同厂商的模型偏好差异巨大：
    • 偏好长期收益：MiniMax, DeepSeek, GPT。
    • 偏好短期回报：Kimi, GLM。
    • 表现稳定：Qwen, Doubao, Claude。
  • 这反映了不同厂商训练策略的差异。

• 观察 3：回归控制能力依然不足

  • 零回归率 (Zero-Regression Rate) 是衡量稳定性的关键指标。
  • 结果显示，大多数模型的零回归率 低于 0.25（即 75% 以上的任务在长期维护中至少发生了一次回归）。
  • 仅有 Claude-opus 系列有两个模型超过 0.5。
  • 结论：尽管 LLM 在单次修改任务上进步巨大，但在全自动、长期、多轮的软件维护场景中，控制回归（Regression）的能力仍是巨大挑战。

5. 意义与价值 (Significance)

• 范式转变：推动了代码生成评估从“一次性功能正确”向“长期可维护性”的范式转变，更符合软件工程实际。
• 诊断价值：SWE-CI 能够揭示模型在技术债务累积、长期规划能力上的短板，为模型优化提供明确方向。
• 行业参考：为 AI 辅助软件开发（AI4SE）的落地提供了更严格的验收标准，表明当前模型距离完全自主的长期软件维护仍有距离，特别是在稳定性控制方面。

---

总结：SWE-CI 通过模拟真实的持续集成和长期演进过程，揭示了当前 LLM 智能体在“写代码”方面虽已成熟，但在“维护代码”和“避免长期技术债务”方面仍存在显著缺陷。该基准为未来提升智能体的工程化能力提供了关键的评估工具和方向。