SWE-CI：通过持续集成评估智能体维护代码库的能力 SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration
首个基于持续集成循环的仓库级基准，评估LLM智能体在长期代码演进中维护代码质量的能力
前置知识
持续集成（Continuous Integration, CI）
持续集成是现代软件工程实践的核心方法论，开发人员频繁地将代码变更集成到共享仓库中，每次集成都通过自动化构建和测试来验证。CI的核心理念是尽早发现问题、快速反馈，避免长期分支导致的集成地狱。在本文中，CI被抽象为一个迭代循环：智能体修改代码→运行测试→根据失败反馈再次修改，这个循环模拟了真实开发团队的持续集成流程。
SWE-CI整个评估框架都建立在CI循环之上，理解CI的迭代反馈机制是理解本文评估范式的前提。传统基准只看单次修改是否正确，而SWE-CI关注的是在多轮迭代中代码质量如何变化，这正是CI的核心价值所在。
EvoScore（演进得分）
EvoScore是本文提出的核心评估指标，用于衡量智能体在多轮代码演进中维持功能正确性的能力。其数学定义为各轮迭代的归一化变化量 $a(c_i)$ 的加权平均，权重为 $\gamma^i$，其中 $\gamma \geq 1$ 使得后续迭代获得更高权重。当 $\gamma = 1$ 时退化为简单平均；当 $\gamma > 1$ 时更强调长期稳定性。这个指标的设计直觉是：真正可维护的代码应该在后续演进中保持易于修改。
EvoScore是本文区别于所有现有基准的核心创新，它将维护能力从不可见变为可度量。理解其数学定义和设计动机是理解实验结果的基础，也是理解为什么某些模型在不同 $\gamma$ 设置下排名会发生变化的关键。
归一化变化（Normalized Change）
归一化变化 $a(c)$ 是EvoScore的基本构建单元，用于衡量单轮迭代中代码质量的变化。当代码改进时（通过的测试数 $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$ 表示破坏了所有初始通过的测试。这种非对称归一化确保无论基线和目标的绝对数值如何，改进和退化都在统一的 $[-1, 1]$ 尺度上可比。
归一化变化是计算EvoScore的基础，理解其非对称设计（改进和退化用不同分母归一化）对于理解论文的回归分析和长期演进评估至关重要。
回归（Regression）
在软件工程中，回归指代码变更导致先前通过的测试用例失败的现象。在长期维护场景中，回归尤其有害，因为其影响会在后续迭代中累积放大。本文定义了零回归率（zero-regression rate）作为模型稳定性的指标，即在整个维护过程中未发生任何回归的样本比例。实验表明大多数模型的零回归率低于0.25，说明当前LLM在控制回归方面仍有明显不足。
回归是衡量代码维护能力的关键负面指标。传统基准中回归不可见（因为只看最终结果），而SWE-CI通过多轮迭代使回归的影响显性化，这是本文诊断价值的核心体现。
Architect-Programmer 双智能体协议
本文设计的双智能体协作协议，模拟真实软件团队中的架构师和程序员角色分工。架构师（Architect）负责：总结测试失败、定位根因、设计高层需求文档；程序员（Programmer）负责：理解需求、规划实现方案、编写代码。关键设计选择是程序员由需求文档驱动而非直接由测试差距驱动，这与真实CI流程中的快速迭代理念一致。架构师被要求只输出不超过5个最紧急的需求，避免单次迭代中的过度设计。
双智能体协议是SWE-CI评估框架的执行机制，理解其角色分工和交互方式对于理解基准如何实际运行、以及如何解释实验结果（如不同模型在架构师vs程序员角色上的表现差异）至关重要。
快照式评估 vs 演进式评估
快照式评估是现有代码生成基准（如HumanEval、SWE-bench）的共同范式：智能体接收单一完整需求，一次性生成解决方案。在这种范式下，硬编码补丁和优雅设计可能通过相同的测试套件，可维护性的差异完全不可见。演进式评估是本文提出的新范式：需求从当前代码库动态生成 $r_i = \text{require}_T(c_i, c^*)$，代码库随之更新 $c_{i+1} = \text{code}_T(c_i, r_i)$，早期决策的后果会传播到后续迭代中，使长期决策质量变得可观察。
这是本文最根本的范式创新。理解这两种评估方式的区别是理解本文动机、方法和贡献的核心。快照式评估看不到的问题（如技术债务累积），在演进式评估中会自然暴露出来。
研究动机
现有代码生成基准几乎全部采用快照式评估范式，只能衡量智能体生成功能正确代码的能力，无法评估代码维护能力。从HumanEval、MBPP到SWE-bench、Terminal-bench，这些基准的共同协议是：智能体接收一个完整的单一需求，一次性产出解决方案。在这种范式下，一个写出硬编码补丁的智能体和一个写出优雅、可扩展代码的智能体可能通过相同的测试套件——它们在可维护性上的差异完全不可见。然而在真实世界中，软件很少一夜写成，而是长期维护的结果。Lehman定律揭示软件质量随维护进行而固有地退化，经典文献表明维护活动占软件生命周期总成本的60%到80%。现有基准的这种根本性局限，使得评估LLM在长期代码维护中的能力成为一个亟待解决的空白。
本文的目标是本文的具体目标是设计并构建SWE-CI，一个基于持续集成循环的仓库级基准，用于评估LLM智能体在长期代码演进中维护代码质量的能力。SWE-CI包含100个任务，每个任务来自一个真实代码仓库，基线代码库和目标代码库之间平均间隔233天和71个连续提交，涉及至少500行源代码修改。通过Architect-Programmer双智能体协议，智能体需要通过数十轮分析和编码迭代来系统地解决这些任务。核心评估指标EvoScore通过追踪功能正确性随时间的变化来代理衡量可维护性，使得早期决策利于后续演进的智能体获得更高分数，而累积技术债务的智能体分数持续下降。
与已有工作不同的是，本文的独特切入角度在于一个关键洞察：可维护性只能通过长期演进而非单次快照来揭示，因为过去决策的后果会在连续变更中累积。这个洞察直接指导了SWE-CI的设计：不是简单地增加测试用例数量或提高任务难度，而是从根本上改变评估范式——从单次快照变为多轮演进。具体而言，SWE-CI引入了三个核心创新来填补现有空白：（1）演进式评估协议，让需求从当前代码库动态生成而非固定不变；（2）EvoScore指标，通过未来加权均值将长期维护能力量化为单一标量；（3）Architect-Programmer双智能体协作，模拟真实CI流程中的角色分工。这种设计使得SWE-CI能够诊断出快照式基准完全无法看到的问题，例如回归控制能力、技术债务累积倾向、短期收益与长期稳定的权衡等。
核心方法
SWE-CI的方法论建立在一个简洁而深刻的直觉之上：可维护性可以通过追踪功能正确性随时间的变化来揭示。整体技术路线分为数据构建和评估协议两大部分。在数据构建方面，研究团队从GitHub上4,923个Python仓库中筛选出8,311个候选基线/目标提交对，经过环境构建和质量过滤后最终保留100个高质量样本。每个样本代表一个真实仓库中跨越平均233天的代码演进历程。在评估协议方面，SWE-CI采用Architect-Programmer双智能体协作模式，模拟真实软件团队的持续集成循环：架构师分析测试差距并生成高层需求，程序员理解需求并实现代码修改，这个循环迭代进行直到达到最大轮数或目标。评估的核心是EvoScore指标，它对各轮迭代的归一化变化进行未来加权平均，使得能够持续维持代码质量的智能体获得更高分数。
SWE-CI的核心创新在于将可维护性从不可见变为可度量。与所有现有基准的本质区别在于：现有基准（如SWE-bench）评估的是智能体在单一时间点解决单一问题的能力，而SWE-CI评估的是智能体在多轮时间序列中维持代码质量的能力。具体来说，SWE-CI引入了演进式评估范式：需求不是固定的，而是从当前代码库与目标代码库的差距中动态生成的，即 $r_i = \text{require}_T(c_i, c^*)$。这意味着智能体在第 $i$ 轮的输入不仅取决于原始需求，还取决于它自己在前 $i-1$ 轮中的所有决策。早期决策的后果（无论是好是坏）会自然地传播到后续迭代中，使得维护能力变得可观察。这种设计的精妙之处在于：一个写出硬编码补丁的智能体可能在早期轮次中表现良好，但在后续轮次中会因为代码结构僵化而频繁失败；而一个投资于代码质量的智能体虽然早期可能较慢，但在长期演进中会表现更稳定。这种差异在快照式评估中完全不可见，但在SWE-CI中会通过EvoScore自然地体现出来。
方法步骤详情
SWE-CI的方法包含两个主要流程。第一个是数据构建流程，分为四步：Step 1 仓库收集——从GitHub搜索所有Python仓库，筛选条件包括维护至少3年、星标超过500、包含配置和依赖文件及单元测试、采用MIT或Apache-2.0等宽松许可证，筛选后保留4,923个仓库。Step 2 提交跨度提取——只保留主分支，比较连续提交的依赖变化，识别依赖不变的最大子序列，丢弃修改行数低于1,000的对，得到8,311个候选对。Step 3 环境构建——为每个候选对自动生成Dockerfile，快照运行环境，执行测试验证正确性，引入自修复机制动态注入缺失依赖，保留1,458个候选对。Step 4 用例过滤——运行基线代码库的测试套件、比较基线和目标的测试通过数差异（至少差5个）、按时间跨度和中间提交数排序选取前100个。第二个是评估流程，采用Architect-Programmer双智能体协议迭代进行：架构帧行为分为总结（审查所有失败测试、识别根因）、定位（检查源代码、归因到具体缺陷）、设计（制定改进计划、生成需求文档，限制不超过5个最紧急需求）三步；程序员行为分为理解（将高层需求转化为代码规格）、规划（计划实现方案）、编码（实施修改）三步。每轮迭代中，当前代码库和目标代码库分别在相同环境中运行测试，比较测试报告计算归一化变化 $a(c_i)$，最终通过EvoScore公式 $e = \frac{\sum_{i=1}^{N} \gamma^i a(c_i)}{\sum_{i=1}^{N} \gamma^i}$ 聚合为单一标量。
技术新颖性
SWE-CI的技术新颖性体现在多个层面。首先，在评估范式层面，这是首个将软件工程中的持续集成理念系统性地引入代码智能评估的工作。虽然SWE-bench等基准已经将评估从单文件扩展到仓库级，但它们仍然停留在快照式评估，而SWE-CI开创了演进式评估的新范式。其次，在指标设计层面，EvoScore通过未来加权均值巧妙地将长期维护能力量化为单一标量。权重参数 $\gamma$ 的引入允许研究者灵活地调整对短期收益和长期稳定的偏好，这在现有基准中是没有先例的。第三，在数据构建层面，SWE-CI的四步数据构建流程（仓库收集→提交跨度提取→环境构建→用例过滤）系统性地解决了从海量仓库历史中提取高质量评估样本的挑战，特别是自修复机制和依赖不变子序列的识别方法具有独立的方法论价值。第四，在协议设计层面，Architect-Programmer双智能体协议不仅模拟了真实软件团队的协作模式，更重要的是通过需求文档作为中间层隔离了架构师和程序员的职责，使得评估可以分别诊断智能体在需求理解和代码实现两个维度的能力。这种设计使得SWE-CI不仅是一个评估工具，更是一个诊断工具，能够提供传统基准无法提供的细粒度洞察。
实验结果
SWE-CI的实验覆盖了来自8个提供商的20个模型，总消耗超过100亿token，揭示了六个关键发现。观察1：LLM的代码维护能力正在加速提升——在同一提供商内，新模型总是获得更高分数，2026年后发布的模型增幅尤为显著，Claude Opus系列在整个观察期领先。观察2：不同提供商对代码维护能力的重视程度差异显著——通过改变 $\gamma$ 值观察排名变化，MiniMax、GPT和DeepSeek偏好短期收益（$\gamma$ 增大时排名下降），而Kimi、GLM和Qwen偏向长期可维护性（$\gamma$ 增大时排名上升），Doubao和Claude因整体性能优势或劣势足够突出而相对稳定。观察3：当前LLM在长期代码维护中控制回归的能力仍然不足——大多数模型的零回归率低于0.25，仅两个Claude-opus模型超过0.5，表明大多数模型难以在整个维护过程中可靠地避免回归。观察4：随迭代推进，回归率增加但回归幅度减小——12个模型中回归率与迭代次数正相关，11个模型中回归幅度与迭代次数负相关，研究者推测这是因为简单需求在早期解决后，模型在后期更多地对困难问题进行试错。观察5：LLM在表面代码风格上优于人类，但在真正的代码可维护性上不足——15个模型在Pylint评分上胜过人类oracle代码，但全部20个模型在MI评分上都不及人类，说明LLM更擅长学习显式的局部编码规范而非隐式的全局代码质量标准。观察6：LLM生成的补丁比人类更简洁，但以可维护性为代价——所有20个模型的修改行数都少于人类对应方案，结合较低的MI评分，说明人类额外的代码行不是冗余的，而是通过抽象、封装和模块化对代码质量的有目的投资。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SWE-CI整体维护能力评估（100个任务，20个模型） | EvoScore（γ=1，归一化变化的平均值） | Claude Opus系列领先，具体分数未在论文中给出单个数值 | 20个模型来自8个提供商的对比 | 2026年后发布的模型相比前代有显著提升，Claude Opus系列在整个观察期保持领先 |
| 零回归率（Zero Regression Rate） | 在整个维护过程中未发生任何回归的样本比例 | Claude-opus模型超过0.5 | 大多数模型低于0.25 | Claude-opus显著优于其他模型，但整体水平仍然偏低 |
| 代码风格质量（Pylint评分） | LLM代码 vs 人类oracle代码的胜率 | 15/20模型胜过人类 | 人类oracle代码 | 大多数模型在表面编码规范上已超越人类 |
| 代码可维护性（MI评分） | LLM代码 vs 人类oracle代码的胜率 | 0/20模型胜过人类 | 人类oracle代码 | 所有模型都不及人类，揭示了LLM在深层代码质量上的系统性不足 |
局限与改进
SWE-CI存在几个值得注意的局限性。首先是数据规模的限制：最终基准仅包含100个样本，虽然每个样本都代表了实质性的长期演进（平均233天、71个提交），但相对于SWE-bench等包含数百甚至数千个样本的基准，样本量仍然较小，可能影响统计结论的稳健性。其次是编程语言的限制：当前基准仅覆盖Python仓库，而真实软件项目涉及多种语言（如Java、TypeScript、Rust等），不同语言的维护特性可能有显著差异。第三是评估协议的简化：Architect-Programmer双智能体协议虽然模拟了真实CI流程，但省略了代码审查、团队协作、部署等环节，这些环节在真实软件维护中同样重要。第四是环境构建的局限：虽然引入了自修复机制，但仍有大量候选对因环境问题被丢弃（从8,311个候选对减少到1,458个再到最终100个），这可能导致幸存者偏差。第五是EvoScore指标的局限：虽然 $\gamma$ 参数允许调整对短期和长期的偏好，但指标本身假设了线性的演进过程，无法捕捉非线性的维护模式（如大规模重构后的突然改善）。最后，实验中所有模型使用相同的最大迭代轮数（20轮），这可能对某些模型不公平——更高效的模型可能在较少轮次内完成任务，而更谨慎的模型可能需要更多轮次。
独立分析的弱点
SWE-CI有几个值得深入分析的弱点。第一，样本量过小是最大的统计学弱点：100个样本虽然每个都很有代表性，但在进行细粒度分析（如按仓库类型、按演进复杂度分组）时统计功效不足，置信区间较宽。改进建议：可以通过自动化环境构建流程的优化（如使用更通用的容器技术、引入更多依赖解析策略）来扩大候选池，目标是将最终样本量扩展到500-1000个。第二，仅覆盖Python语言限制了基准的普适性：Python的动态特性和丰富的测试生态可能使任务相对容易，而静态类型语言（如Java、Rust）的维护挑战可能不同。改进建议：优先扩展到Java和TypeScript，这两个语言在工业界广泛使用且有成熟的测试框架。第三，双智能体协议中架构师和程序员使用相同的基础模型，这限制了对角色特化能力的评估。改进建议：允许架构师和程序员使用不同模型，可以研究跨模型协作的效果，也更接近真实团队中不同角色可能使用不同工具的场景。第四，EvoScore的未来加权设计虽然有理论依据，但 $\gamma$ 的最优值缺乏经验验证：论文展示了不同 $\gamma$ 下的排名变化，但没有提供选择 $\gamma$ 的指导原则。改进建议：可以通过与人类专家对代码质量的主观评价进行相关性分析，来确定 $\gamma$ 的最佳取值。第五，数据构建过程中的过滤条件（如修改行数至少1000行、测试通过数差异至少5个）可能引入选择偏差，使得样本偏向于大型、复杂的功能变更，而忽略了小规模但关键的维护任务（如安全补丁、性能优化）。改进建议：可以引入分层采样，确保不同规模和类型的维护任务都有代表。
未来方向
SWE-CI开启了多个有价值的研究方向。作者提出的方向包括：将SWE-CI作为催化剂推动下一代编码智能体的发展，这些智能体不仅要写出能工作的代码，还要写出能持久的代码。基于已有成果可延伸的方向包括：（1）多智能体协作优化——当前的Architect-Programmer协议是固定的两角色分工，可以探索更灵活的多智能体拓扑（如引入审查者角色、支持并行开发分支）；（2）维护策略学习——利用SWE-CI的多轮评估特性，通过强化学习训练智能体学习长期最优的代码修改策略，而不是贪婪地追求每轮的即时测试通过；（3）可维护性预测——利用EvoScore的细粒度信号，训练模型预测代码修改对未来可维护性的影响，这可以作为代码审查工具的智能辅助；（4）跨语言迁移——将SWE-CI的评估范式扩展到其他编程语言，研究不同语言生态中维护能力的差异和共性；（5）人机协作维护——探索人类开发者和LLM智能体在长期代码维护中的协作模式，研究如何利用SWE-CI的诊断能力来指导人机分工。
复现评估
SWE-CI在可复现性方面做得较好。代码和数据均已开源：Hugging Face数据集托管在 https://huggingface.co/datasets/skylenage/SWE-CI，GitHub仓库在 https://github.com/SKYLENAGE-AI/SWE-CI。每个样本都附带完整的源代码和预构建的Docker环境，确保评估环境的一致性。使用pytest和pytest-json-report作为测试框架，测试超时设置为3600秒，最大迭代轮数为20，使用iFlow CLI作为默认执行环境，这些参数都明确记录。然而，完全复现实验仍有几个挑战：（1）算力需求——论文报告总消耗超过100亿token，这对大多数研究团队来说是巨大的计算成本；（2）API稳定性——实验评估了20个模型，其中一些商业模型的API可能随时间变化，不同时间点的复现结果可能有差异；（3）Docker环境兼容性——虽然提供了预构建环境，但不同操作系统的Docker行为可能略有差异，特别是涉及网络依赖的场景；（4）随机性——LLM的输出具有随机性，即使使用相同参数，多次运行的结果也可能不同，论文未报告标准差或置信区间。总体而言，SWE-CI的可复现性在同类工作中属于较好水平，但完全精确复现仍有实际困难。
论文图表
