Recoleta Item Note
SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration
SWE-CI 是一个面向代码库长期演化维护能力的新基准，不再只看一次性修复是否通过测试，而是评估智能体在持续集成式多轮迭代中能否持续保持代码质量。论文的核心贡献是把“可维护性”变成可测对象，并用真实仓库长期提交历史构造了 100 个任务。
Summary
SWE-CI 是一个面向代码库长期演化维护能力的新基准，不再只看一次性修复是否通过测试，而是评估智能体在持续集成式多轮迭代中能否持续保持代码质量。论文的核心贡献是把“可维护性”变成可测对象，并用真实仓库长期提交历史构造了 100 个任务。
Problem
- 现有代码基准多采用单次快照式评测，只衡量功能正确性，无法区分“临时补丁”与“可长期演化的设计”。
- 真实软件开发主要是长期维护与需求迭代，而维护成本占软件生命周期总成本的 60%–80%，因此只测一次性修复并不贴近工业现实。
- 缺少能够显式观察技术债累积、回归控制和后续修改难度的仓库级评测基准。
Approach
- 提出 SWE-CI：首个基于 Continuous Integration 循环的仓库级代码维护基准，从真实 GitHub Python 仓库中抽取 base commit → target commit 的长期演化片段。
- 数据集包含 100 个任务，来自 68 个仓库；每个任务平均跨越 233 天、71 个连续提交，且源码改动至少 500 行（不含测试），强调非平凡长期演化。
- 设计 Architect–Programmer 双智能体协议：Architect 根据当前代码与目标代码的测试差距，生成不超过 5 条高层增量需求；Programmer 再按需求理解、规划并修改代码，形成最多 20 轮 的 CI 式迭代。
- 提出两级指标：normalized change 用 �[-1,1]� 区间衡量当前代码相对基线与目标的测试进展/回归；EvoScore 对各轮结果做未来加权平均，用更高权重强调后期迭代表现，从而把长期可维护性纳入评分。
- 为保证可复现性，论文为样本自动构建 Docker 环境，并加入缺失依赖的自修复流程；最终从 4,923 个仓库筛到 8,311 个候选跨度、再到 1,458 个可运行候选，最终选出前 100 个任务。
Results
- 论文对 8 家提供商的 18 个模型进行了大规模评测，总消耗超过 100 亿 tokens；结果显示，同一提供商内部新模型通常优于旧模型，说明代码维护能力在持续提升。
- 在总体表现上，作者声称 Claude Opus 系列在整个观察期内“明显领先”，GLM-5 也表现突出；但正文摘录未给出具体 EvoScore 数值。
- 在长期维护稳定性方面，大多数模型的 zero-regression rate（全程无回归比例）低于 0.25；只有 两个 Claude-opus 系列模型超过 0.5，表明当前模型普遍仍难以在长期多轮维护中稳定避免回归。
- 通过调节 EvoScore 的未来权重参数 γ，作者发现不同提供商对“短期收益 vs 长期可维护性”的偏好不同：MiniMax、DeepSeek、GPT 更偏长期收益，Kimi、GLM 更偏短期收益，Qwen、Doubao、Claude 相对稳定。
- 最强结论是：即便最先进模型在静态修复上已有明显进步，它们在长期、自动化、多轮代码库维护上仍存在显著差距；SWE-CI 能比快照式基准更好地诊断这种差距。
Link
Built with Recoleta
Run your own research radar
Turn arXiv, Hacker News, OpenReview, Hugging Face Daily Papers, and RSS into local Markdown, Obsidian notes, Telegram digests, and a public site.