← 返回 TL;DR
现有代码 benchmark（如 SWE-bench）只测「一次性写对」，但真实软件 60%–80% 的成本在长期维护。SWE-CI 是首个建立在持续集成（CI）循环上的仓库级评测：100 个真实任务平均跨 233 天、71 次连续提交，用 Architect–Programmer 双智能体反复「跑测试→定需求→改代码」地演化代码库，并用 EvoScore 给靠后的迭代更高权重，从而把「可维护性」变得可测。结果显示，SOTA 模型功能正确性已强，但长期维护仍吃力——多数模型「零回归率」低于 0.25，仅两个 Claude Opus 系列模型超过 0.5。
论文类型
仓库级代码维护 benchmark（评测方法）
核心指标
EvoScore（未来加权，后期迭代权重更高）
评测开销
>100 亿 tokens，18 个模型 / 8 家厂商
代码与数据
已开源（GitHub + HuggingFace）
01
问题：静态 benchmark 测不出「会不会维护」
主流代码 benchmark——从 HumanEval、LiveCodeBench 到 SWE-bench(Issue→PR 仓库级评测)、Terminal-bench——几乎都在测同一件事：智能体能不能写出功能正确的代码。但论文指出这有一个根本盲区：它们都采用 快照式（snapshot）协议——给一份完整需求、要一次性交付解法。在这种范式下，一个硬编码的脆弱补丁和一段干净可扩展的实现可能通过同一套测试，二者在可维护性上的差异完全不可见。
这种差异只有当代码库必须持续演化时才会显形：新需求到来、接口变更、模块扩展，早期设计决策的代价开始复利式累积——写烂代码的智能体会发现每一次后续修改都更难，最终跟不上节奏。论文援引 Lehman 定律(软件演化经验定律)（软件质量随维护推进而天然衰退），以及经典结论：维护活动占软件全生命周期成本的 60%–80%（Brooks《人月神话》）。由此得到核心判断：智能体的维护能力，只能通过长期演化暴露。
核心洞察
可维护性不是某一时刻的属性，而只能在「一次次修改」的累积后果中显形——所以评测也必须从单点快照，改成长期演化。
02
核心发现：功能正确性已强，长期维护仍弱
作者用超过 100 亿 tokens 评测了来自 8 家厂商的 18 个模型，得到三条核心观察。
1
维护能力正在加速进步
同一厂商家族内，越新的模型 EvoScore 总是越高，且 2026 年后发布的模型提升幅度明显更大；其中 Claude Opus 系列在整个观察期内全程领先，GLM-5 也表现突出。说明 LLM 的代码能力正从「静态修 bug」快速迈向「持续的长期维护」。
2
各厂商对「可维护性」的押注不同
通过调节 γ 观察排名变化：γ<1 偏向立刻通过测试的短期收益，γ>1 偏向长期可维护性。结果 MiniMax、DeepSeek、GPT 偏好长期；Kimi、GLM 偏向短期；Qwen、Doubao、Claude 在不同设定下相对稳定。作者推测这反映了不同厂商训练策略的差异，而厂内一致性说明各自训练流水线相对稳定。
3
回归控制仍是普遍短板
论文用 零回归率(全程不引入回归的样本占比) 衡量稳定性：多数模型零回归率低于 0.25，仅 Claude-opus 系列的两个模型超过 0.5。这说明尽管 LLM 在快照式任务上进步显著，在全自动、长期、多轮的维护场景下仍远未可靠。
| 厂商 | 在 γ 变化下的倾向 | 解读 |
|---|
| MiniMax / DeepSeek / GPT | 偏好长期收益（γ>1 占优） | 倾向牺牲短期速度换取可扩展、可维护的设计 |
| Kimi / GLM | 偏向短期收益（γ<1 占优） | 倾向尽快通过当前测试 |
| Qwen / Doubao / Claude | 跨设定相对稳定 | 排名不随 γ 大幅波动 |
03
方法：归一化变化 + EvoScore，把「可维护性」量化
SWE-CI 把评测从快照式改成 演化式（evolution-based）。每个任务由真实仓库里两个按时间排序的 commit 构成：base 代码库 c0 与 oracle（金标准）代码库 c。智能体从 c0 出发，循环执行 CI 闭环——跑测试、生成需求、修改代码——目标是通过 c 关联的全部测试。
为刻画中间状态，论文先定义 归一化变化(把测试通过数变化映射到 [-1,1)] a(c)：以当前通过的单测数 n(c) 为基础做不对称归一化——改进时（n(c)≥n(c0)）用总差距归一，补满即 a=1；回退时用 n(c0) 归一，全破即 a=-1。这样不论仓库测试规模多大，进退都落在统一可比的 [-1,1] 区间。
a(c)=\begin{cases}(n(c)-n(c_0)) / (n(c_*)-n(c_0)) & \text{if } n(c)\ge n(c_0)
[8pt](n(c)-n(c_0)) / (n(c_0)) & \text{else}\end{cases}
归一化变化 a(c)：n(c) 为代码库 c 通过的单测数。改进按「到金标准的总差距」归一，回退按「基线通过数」归一，统一到 [-1,1]。
03b
在此之上，EvoScore(对各轮 a(c) 做未来加权平均) 把 N 轮迭代得到的代码库序列聚合成单一标量，并对靠后的迭代赋更高权重（γ≥1）：
e=\frac{\sum_{i=1}^{N}\gamma^{i} a(c_i)}{\sum_{i=1}^{N}\gamma^{i}},\qquad \gamma\ge 1
EvoScore：γ=1 时退化为「平均归一化变化」；γ 越大越偏向长期稳定。设计直接对应 [[ISO/IEC 25010|软件质量国际标准]] 对可维护性的定义——真正可维护的代码库，是随演化推进仍易于修改的代码库。牺牲短期速度换干净可扩展设计的智能体会被奖励，急于通过早期测试却累积技术债的则被惩罚。
04
实验设置与双智能体协议
测试框架用 pytest + pytest-json-report，每次测试运行超时 3600 秒；默认智能体框架是 iFlow CLI，双智能体协议最多迭代 20 轮；除非特别说明，Architect 与 Programmer 共用同一基座模型。
Architect–Programmer 双智能体(架构师出需求、程序员写实现) 协议复刻了真实团队的 CI 循环。Architect（架构师）依据当前代码与 oracle 的测试差距，按「总结→定位→设计」三步产出自然语言需求文档，并被约束为两条规范：增量式（一次最多 5 条最紧急需求，避免一轮过度设计）与高层次（只描述期望行为，把实现选择留给程序员）。Programmer（程序员）按「理解→规划→编码」三步落实需求。关键设计是：Programmer 由需求文档而非测试差距直接驱动，以贴合 CI 的快速迭代哲学——让架构师从全部失败中蒸馏出最紧迫的少数需求，程序员则专注快速、有的放矢地开发。
05
数据构造：从全 GitHub 撒网到 100 个长跨度任务
与 SWE-bench 只取少数知名开源项目不同，SWE-CI 在全 GitHub 的 Python 仓库里撒大网，经五级流水线层层筛选，最终得到 100 个高质量、长跨度的演化任务。每个样本都附带完整源码和预构建的 Docker 环境以保证可复现。其中一个亮点是「自修复」机制：当测试因缺依赖无法启动时，自动检测并向 Dockerfile 注入所需依赖重建环境，大幅提高了可用样本的留存率。
| 阶段 | 操作 | 剩余 |
|---|
| ① 仓库收集 | 全 GitHub Python 仓库 + 四项过滤：维护≥3 年、≥500 星、含配置依赖与单测、宽松许可（MIT/Apache-2.0） | 4,923 仓库 |
| ② 提交跨度抽取 | 在主分支线性历史里找「依赖不变」的最大子序列，两端成对；剔除改动 <1,000 行的对 | 8,311 候选对 |
| ③ 环境构建 | 按 oracle 依赖自动生成 Dockerfile 并快照；缺依赖时自修复注入重建 | 1,458 候选对 |
| ④ 案例过滤 | oracle 测试须能在 base 上启动；base 与 oracle 的通过数之差≥5 | 137 候选 |
| ⑤ 最终选取 | 按时间跨度与中间提交数排序，取 top 100 | 100 任务 / 68 仓库 |
06
对实践者的启示
- 别只看 SWE-bench 分数选编码智能体：功能正确性已接近饱和，但它测不出长期维护质量。若你的场景是会长期演化的真实代码库，SWE-CI 这类演化式评测更有诊断价值。
- 把回归率当硬约束盯住：在多轮自动维护里，回归(改动破坏了原本通过的测试) 会随改动累积导致系统性质量衰退。当前多数模型零回归率低于 0.25——监控「是否引入回归」比单看通过率更重要。
- 按需求侧重选模型：要长期可扩展、扛得住后续迭代，优先 Claude Opus 系列，或 MiniMax/DeepSeek/GPT 这类偏长期的模型；只求快速通过当下测试，Kimi/GLM 的短期倾向也许够用。
- 用「架构师 + 程序员」分工而非单体智能体：让一个角色专注从全部失败中蒸馏出≤5 条最紧急的增量需求，另一个专注快速实现，更贴合真实 CI 的迭代节奏。
07
适用边界与局限
- 仅限 Python：数据集只来自 GitHub 的 Python 仓库，结论未必迁移到其他语言或多语言工程。
- 以单测通过数为代理：EvoScore 和归一化变化都建立在「单测通过/失败」上，无法直接捕捉代码可读性、文档、架构优雅度等维护质量的其他维度。
- 「oracle 即终点」假设：把某个未来 commit 当作唯一金标准，但真实演化中并不存在唯一正确的终态，路径多样性被压缩。
- 评测开销巨大：>100 亿 tokens、每次测试超时 3600 秒、最多 20 轮迭代，复现成本高，难以频繁跑大规模对比。
- 框架与基座绑定：默认用 iFlow CLI、且 Architect 与 Programmer 共用基座模型，框架或分工变化都可能改变结论。
- 规模有限：最终仅 100 个任务、68 个仓库，统计功效与覆盖面受限。
08
时效性：2026 年 3 月新作，结论仍成立
这篇论文 2026 年 3 月 4 日发布于 arXiv（cs.SE），来自中山大学与阿里巴巴团队，截至本文整理时（2026 年 6 月）问世仅约三个月。数据集与代码已开源（GitHub: SKYLENAGE-AI/SWE-CI，HuggingFace: skylenage/SWE-CI），目前尚无公开的后续工作或被取代的迹象。
它延续了 2025–2026 年评测从「静态正确性」转向「长期/真实场景」的趋势线（同期有 Terminal-bench、τ-bench 等）。论文榜单提到的 Claude Opus 系列、GLM-5 等模型仍在快速迭代，具体排名很可能随新模型发布而变化，但「长期可维护性与回归控制是当前短板」这一核心结论，在可见的未来仍大概率成立。
SWE-bench
Princeton 提出的仓库级代码评测，要求模型根据 GitHub Issue 生成可通过测试的补丁（Issue→PR 范式），是「静态、一次性修复」的代表性基准。
Lehman 定律
Manny Lehman 提出的软件演化经验定律。核心是：被持续使用的软件若不主动维护，其内部结构与质量会随时间衰退。
归一化变化 (normalized change)
论文指标 a(c)，把当前代码库相对 base 的单测通过数变化映射到 [-1,1]：改进按「到金标准的总差距」归一、回退按「base 通过数」归一，使不同规模的仓库可比。
EvoScore（演化得分）
对 N 轮迭代各自的归一化变化做「未来加权平均」（γ≥1，后期迭代权重更高），度量智能体能否在长期演化中维持/提升代码质量。
回归 (regression)
一处改动导致原本通过的单测变为失败，即破坏了已有功能。
零回归率 (zero-regression rate)
在整个维护过程中「全程没有引入任何回归」的样本所占比例，衡量模型在连续维护中的稳定性。
ISO/IEC 25010
软件质量国际标准，把「可维护性」定义为软件在不引入缺陷或降低既有质量的前提下被有效修改的程度。
Architect–Programmer 双智能体
SWE-CI 的评测协议：Architect 依据测试差距产出高层增量需求文档，Programmer 按需求实现，二者协作复刻真实团队的 CI 循环。
