SWE-CI：基于持续集成评估智能体代码库维护能力

归一化变更定义如下： $$ a(c) = \begin{cases} \dfrac{n(c) - n(c_0)}{n(c^*) - n(c_0)} & \text{if } n(c) \geq n(c_0),\[6pt] \dfrac{n(c) - n(c_0)}{n(c_0)} & \text{else}. \end{cases} $$

当智能体在基础代码库上有所改进时（$n(c) \geq n(c_0)$），分子通过总差距 $n(c^) - n(c_0)$ 进行归一化，因此当且仅当智能体完全消除了差距时，$a(c) = 1$。当智能体出现回归且低于基线时（$n(c) < n(c_0)$），分子改用 $n(c_0)$ 归一化，因此 $a(c) = -1$ 对应破坏了所有初始可通过的测试。这种非对称归一化是刻意设计的：无论 $n(c_0)$ 和 $n(c^)$ 多大或多小，改进与回归都能在统一、可比较的尺度上表示——即 $a(c) \in [-1, 1]$。

EvoScore（演进得分）

ISO/IEC 25010 标准将可维护性定义为：软件能够在不引入缺陷、不降低现有质量的前提下被有效修改的程度。其核心含义是：可维护性无法在单一快照中体现，它只能通过持续的迭代修改表现出来。基于这一原则，给定从 $N$ 轮迭代中得到的代码库序列 $(c_1, \dots, c_N)$，我们通过未来加权平均将其聚合为一个标量指标——EvoScore（演进得分）： $$ e = \frac{\sum_{i=1}^N \gamma^i a(c_i)}{\sum_{i=1}^N \gamma^i} $$

在 EvoScore 中，我们设置 $\gamma \ge 1$，从而给后续迭代更大的权重。其设计思想与 ISO 定义直接对应：一个真正具备可维护性的代码库，应当在持续演进中依然保持易于修改。相比于那些急于通过早期测试、却不断累积技术债务进而阻碍后续迭代的智能体，为更清晰、可扩展的设计而牺牲短期速度的智能体会获得更高分数。当 $\gamma = 1$ 时，EvoScore 退化为归一化变更的平均值；随着 $\gamma$ 增大，该指标会更看重长期稳定性，而非短期收益。

数据集构建

如图 1 所示，我们的目标是获取多组基础代码库/标准答案代码库对，并让智能体将前者迭代演进至后者，以此衡量其在整个过程中的代码维护能力。每一组这样的配对都可以看作是同一代码库中按时间顺序排列的两次提交。具体而言，SWE‑CI 的构建过程精心设计如下：

首先，我们在 GitHub 上搜索所有 Python 代码库来扩大数据范围，随后应用筛选条件：代码库至少已持续维护三年以上；获得超过 500 星标；包含配置与依赖文件以及完整的单元测试集；采用 MIT 或 Apache-2.0 等宽松开源协议。经过这些筛选后，剩余 4923 个代码库。

对于每个通过筛选的代码库，我们仅保留其主分支，将提交历史简化为线性序列。随后，我们沿着该序列比较连续提交之间的依赖关系，并找出所有依赖保持不变的极大子序列。每个这样的子序列的两个端点自然构成一组候选的基础代码库/标准答案代码库对。我们进一步剔除总修改代码行数低于 1000 行的配对，因为这类配对的演进距离不足。该过程最终得到 8311 组候选配对。

对于每一组候选配对，我们基于标准答案代码库的配置与依赖，自动生成 Dockerfile，并对构建出的运行环境进行快照。随后在该环境中执行标准答案代码库的单元测试集，以验证其正确性。为了提高数据留存率，我们引入了自修复机制：当测试集因缺失依赖而无法启动时，系统会检测故障并动态将所需依赖注入 Dockerfile，以构建新环境。该机制大幅提升了有效候选配对的数量。因其他原因导致测试失败的配对则被丢弃。此步骤结束后，剩余 1458 组候选配对及其运行环境快照。

最后，我们再进行三轮过滤以保证最终数据集的质量。首先，在步骤 3 构建的运行环境快照中，我们使用标准答案代码库的测试集对基础代码库进行测试，任何无法启动测试的候选配对均被剔除。其次，我们对比基础代码库与标准答案代码库在同一测试集上的测试报告；通过测试数量之差少于 5 个的候选配对被移除。经过这两步自动化过滤后，剩余 137 组候选配对。在最后一轮中，我们按照时间跨度与中间提交次数对剩余候选配对进行排序，并选取前 100 组构成最终的 SWE-CI 基准评测集。

最终的 SWE‑CI 基准评测包含来自 68 个不同代码库的 100 个样本。平均每组基础/标准答案代码库对覆盖 233 天的真实开发周期，包含 71 次连续提交。在每组代码库对中，从基础版本到标准答案版本的变更至少涉及 500 行源码修改（测试文件修改不计入）。每个样本都附带完整源码与预构建的 Docker 环境，以保证实验可复现。这些数据表明，SWE‑CI 捕捉的是真实、大规模、长期的代码演进过程，而非微小的增量改动。

评估协议

如图 1 所示，SWE‑CI 采用基于演进的评估。为支持这一设定，我们提出了架构师–程序员双智能体协议。架构师负责识别功能差距并提出需求；程序员负责实现这些需求。二者的协作复现了真实开发中的持续集成（CI）循环，从而能够细粒度地观测智能体维护代码的能力。

架构师智能体

根据当前代码与标准答案代码之间的测试差距，架构师负责以自然语言生成一份高层次需求文档。我们通过提示词让架构师按三步执行：

1. 总结：审查所有失败的测试，定位根本原因，并识别需要进一步检查的源码文件；
2. 定位：分析源代码，将失败归因于当前实现中的具体缺陷；
3. 设计：根据这些缺陷制定改进方案，并生成最终的需求文档。

需求文档还遵循两条撰写规范：

1. 增量式：文档只包含最多 5 个最紧急的需求，避免单次迭代过度设计；
2. 高层次：需求只需用自然语言描述代码的预期行为，将具体实现选择交给程序员。

这些规范的核心目的，是确保需求文档符合真实世界持续集成流程的实际需要。

程序员智能体

程序员的职责是根据需求文档对代码进行维护。其行为同样被规范为三个步骤：

1. 理解：理解高层次的自然语言需求，并将其转化为明确的代码规范。
2. 规划：规划实现这些规范所需的开发工作。
3. 编码：将规划付诸实践，尽力完成需求。

在该协议中，程序员由需求文档驱动，而非直接由测试差距驱动——这是一个刻意的设计选择，与持续集成的快速迭代理念保持一致。为此，架构师需要从全部失败用例中提炼出最紧迫的需求，让程序员专注于快速、有针对性的开发，而不会被整体变更规模压垮。

实验结果

我们使用 pytest 和 pytest-json-report 作为测试框架，每次测试运行的超时时间为 3600 秒。iFlow CLI 作为默认的智能体框架，双智能体评估协议中的最大迭代次数设置为 20。除非另有说明，架构师智能体与程序员智能体共享相同的底层基座模型。

观察 1：大语言模型的代码维护能力正呈加速提升趋势

我们对来自 8 个厂商的 18 个模型进行了全面评估，结果呈现出一致规律：在同一厂商的模型系列中，新版本模型总能取得更高分数，2026 年之后发布的模型相比前代提升幅度尤为明显。这表明，当前大语言模型的代码能力正快速从静态缺陷修复，向持续、长期的代码维护方向演进。在所有评估模型中，Claude Opus 系列在整个观测周期内均保持显著领先，GLM-5 同样表现突出。

观察 2：不同厂商对代码可维护性的重视程度存在差异

我们通过改变 $\gamma$ 的取值来观察模型排名的变化。当 $\gamma < 1$ 时，EvoScore 会对早期迭代赋予更高权重，更青睐那些能通过代码修改快速获得即时收益的模型。反之，当 $\gamma > 1$ 时，后期迭代会获得更高奖励，更有利于面向长期优化（即更重视代码可维护性）的模型。我们发现，不同厂商的模型偏好差异显著，而同厂商的模型则表现出一致的倾向。具体来说：MiniMax、DeepSeek 和 GPT 更偏向长期收益；Kimi 和 GLM 更偏向短期收益；而 Qwen、豆包（Doubao）与 Claude 在不同设置下表现相对稳定。我们推测这反映了不同厂商在训练策略上的差异，而同一家厂商内部模型的一致性则说明其内部训练流程相对稳定。

观察 3：当前大语言模型在长期代码维护中，仍难以有效控制回归问题

回归（regression）是衡量软件质量稳定性的核心指标——如果某个单元测试在代码修改前能通过，修改后却失败，就认为本次修改引入了回归。在软件维护中，回归问题必须被严格监控。一旦发生回归，不仅会直接影响用户体验，在长期维护中，随着修改次数的累积，还可能导致系统质量持续下降。为此，我们在 SWE-CI 中统计了在整个代码维护过程中完全没有出现回归的样本占比，称为零回归率（zero-regression rate），用于评估模型在持续维护场景下的稳定性。实验结果表明，大多数模型的零回归率都低于 0.25，只有 Claude-opus 系列中的两个模型超过 0.5。这说明当前大语言模型在长期代码维护中，仍难以可靠地避免回归问题。这意味着，尽管大语言模型在基于单轮快照的代码修改任务上已取得显著提升，但在全自动、长期、多轮的软件开发与维护场景中，仍面临巨大挑战。