[Paper] SWE-CI：通过持续集成评估代理在维护代码库方面的能力

Source: arXiv - 2603.03823v1

概览

本文介绍了 SWE‑CI，一个新的基准，用于评估基于 LLM 的编码代理在长期维护真实代码库方面的表现。
与其只衡量一次“此补丁能否编译？”的时刻，SWE‑CI 迫使代理处理持续数周的开发历史，模拟软件团队每天都在经历的持续集成（CI）周期。

关键贡献

• 首个仓库级 CI 基准 – 100 个来自开源项目的真实任务，每个任务平均覆盖 233 天和 71 次提交。
• 长期可维护性关注 – 将评估从一次性功能正确性转向在多次迭代更改中的持续代码质量。
• 多轮交互协议 – 代理必须执行重复的分析、编码、测试和调试步骤，模拟真实 CI 流水线。
• 综合指标套件 – 包括构建成功率、测试套件通过率、代码风格合规性以及回归引发的缺陷计数。
• 开源基准套件和评估框架 – 使现有和未来的 LLM 代理的可重复比较成为可能。

方法论

1. 任务选择 – 作者从流行的 GitHub 仓库中挖掘自然演化窗口，在其中引入新功能或 bug‑fix 并随后进行改进。每个窗口成为一个基准任务。
2. CI 仿真环境 – 对每个任务，构建基于 Docker 的 CI 流水线（checkout、依赖安装、测试运行、lint、构建）。通过简单的 API 将流水线暴露给代理。
3. 代理交互循环 – 代理接收当前仓库状态和高级变更请求（例如 “为 API 添加分页”）。它可以：
   • 运行静态分析 / 测试，
   • 提出代码编辑，
   • 提交更改，
   • 观察 CI 反馈，
   • 迭代直至流水线通过或达到步骤上限。
4. 评估指标 – 成功在多个维度上衡量：
   • 功能正确性（测试套件通过），
   • 构建稳定性（迭代过程中没有破坏构建），
   • 可维护性（代码变动、圈复杂度、lint 违规），
   • 回归安全性（不存在新引入的测试失败）。

整个过程完全自动化，能够在相同条件下对不同 LLM 代理（如 GPT‑4、Claude、CodeLlama）进行大规模比较。

结果与发现

*在代理迭代期间引入的新失败测试数量。

关键要点

• 现代 LLM 代理最终可以将 CI 流水线变为绿色，但它们通常需要多轮来回循环——远多于旧基准中衡量的单次修复。
• 即使是最好的代理，也仍会在约每 10 个任务中产生一次回归，凸显了长期推理和依赖感知方面的差距。
• 代码质量指标（例如，环形复杂度）在迭代中略有下降，表明代理更倾向于让构建通过，而不是保持架构卫生。

实际影响

• DevOps 流水线工具 – SWE‑CI 展示了 LLM 代理可以作为“助理机器人”集成，当 CI 作业失败时自动提出修复方案，降低平均修复时间（MTTR）。
• 持续代码审查增强 – 通过让代理接触完整的提交历史，团队可以利用它们建议符合现有设计模式的重构，而不仅仅是孤立的补丁。
• 按需特性原型 – 开发者可以将高层规格交给 LLM 代理，让它在 CI 循环中迭代，并在几次自动化循环后获得可投入生产的分支，加速冲刺速度。
• 基于基准的模型选择 – 公司现在可以在可维护性指标上评估 LLM 提供商，这些指标在生产环境中至关重要，从而选择能最小化回归风险的模型。

限制与未来工作

• 仓库范围 – 基准目前聚焦于 Python 和 JavaScript 项目；编译语言（如 C++）的语言特定细微差别仍未测试。
• CI 复杂性 – 真实世界的流水线常包含集成测试、性能基准和安全扫描，这些在当前的测试框架中未被完整捕获。
• 人为介入 – 本研究假设完全自主的代理；未来工作应探索开发者选择性介入的混合工作流。
• 度量粒度 – 虽然套件跟踪构建成功率和测试通过率，但更深入的架构度量（例如模块耦合）可以为长期可维护性提供更丰富的洞察。

通过揭示这些不足，作者为下一代基于 LLM 的开发助理设定了明确议程——这些代理不仅能编写代码，还能在软件演进过程中保持代码健康。

作者

• Jialong Chen
• Xander Xu
• Hu Wei
• Chuan Chen
• Bing Zhao

论文信息

• arXiv ID: 2603.03823v1
• 分类: cs.SE, cs.AI, cs.CL
• 出版日期: 2026年3月4日
• PDF: Download PDF