SWE-CI：AI Agent 能维护代码吗？从一次性修 Bug 到长期迭代
SWE-bench 大家都不陌生。过去一年，各家模型在这个 benchmark 上疯狂刷分，Claude 修 bug 的能力已经让不少开发者感叹”饭碗不保”。
但我一直有个疑问：修一个 isolated bug 和维护一个真实项目，是一回事吗？
最近 arXiv 上一篇论文 SWE-CI 给出了一个尖锐的回答：不是。
SWE-bench 的盲区
SWE-bench 的范式是经典的”给你一个 issue，修好它”。Agent 拿到 bug 描述，分析代码，提交 patch，跑通测试。这个流程模拟的是一次性修复 — static, one-shot repair。
但真实的软件开发不是这样的。
一个成熟项目的生命周期是：需求变更 → 功能迭代 → 重构 → 回归测试 → 再迭代。代码不是写完就完了，它需要被维护。而维护意味着你要理解历史决策、处理依赖变化、保持架构一致性 — 这些都是 SWE-bench 不考察的。
SWE-CI 做了什么
SWE-CI 的设计思路很简单但很犀利：用真实项目的 CI 循环来评估 Agent。
具体来说：
- 100 个任务，每个任务对应一个真实开源仓库的演化历史
- 平均跨度 233 天，涉及 71 次连续 commit
- Agent 需要在几十轮分析-编码迭代中系统性地解决问题
- 评估维度从短期的”功能正确性”转向长期的可维护性
这才是真正的软件工程场景。不是”修这个 bug”，而是”这个仓库在过去 8 个月经历了 70 多次提交，你能跟上吗？”
为什么这很重要
从工程角度看，这个 benchmark 揭示了当前 AI coding agent 的一个关键瓶颈：上下文持续性。
一次性修 bug 时，Agent 只需要理解当前代码状态。但在长期维护中，Agent 需要：
- 理解代码演化的轨迹 — 为什么这个模块从 v1 改成了 v2？设计意图是什么？
- 保持架构一致性 — 新增功能不能破坏已有的设计模式
- 处理连锁反应 — 改了 A 模块，B 和 C 是否需要同步调整？
- 积累项目知识 — 70 次 commit 后，Agent 对项目的理解应该比第一次更深
这其实就是资深工程师和初级工程师的区别。初级工程师能修 bug，资深工程师能维护系统。SWE-CI 问的是：AI Agent 目前是哪个段位？
我的判断
坦白说，我认为当前的 Agent 在这个测试上会很挣扎。
原因很简单 — context window 的限制。即使是 200K token 的上下文，面对 70+ 次 commit 的演化历史，Agent 也很难保持全局视角。更关键的是，当前的 Agent 架构大多是无状态的：每次调用都是一个新的开始，没有真正的”项目记忆”。
要突破这个瓶颈，可能需要：
- 持久化的项目知识库 — Agent 需要自己的”笔记本”，记录对项目的理解
- 增量式理解 — 不是每次都从头读代码，而是在已有理解上增量更新
- 架构感知 — 不只是看文件和函数，而是理解模块间的关系和设计原则
这些能力目前还在早期。但 SWE-CI 至少给出了一个清晰的方向：评估 AI Agent 的代码能力，不能只看它修 bug 有多快，还要看它维护代码有多稳。
写在最后
SWE-bench 证明了 AI Agent 能写代码。SWE-CI 在问一个更难的问题：它能不能像一个靠谱的工程师一样，长期维护一个项目？
这个问题的答案，可能决定了 AI coding 的天花板在哪里。
如果你在用多个 AI 模型做开发，推荐试试 OfoxAI（ofox.ai）— 一个账号接入 Claude、GPT、Gemini 等主流模型，不同任务选不同模型。