EvoClaw: Evaluating AI Agents on Continuous Software Evolution
该论文提出了名为 EvoClaw 的新基准，通过 DeepCommit 管道从提交日志中重构里程碑有向无环图，以评估 AI 代理在连续软件演化中的长期维护能力，研究发现现有模型在持续任务中的表现（最高 38%）远低于孤立任务（>80%），暴露了其在处理技术债务和错误累积方面的严重不足。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
这篇论文讲述了一个关于AI 程序员（AI Agent）的故事。
想象一下，你雇佣了一位超级聪明的 AI 助手来帮你写软件。现在的测试方法通常是：给 AI 一个单独的任务（比如“写一个计算器”），看它能不能做完。这就像是在考场上做单题练习，AI 只要把这道题做对就能拿高分。
但是，现实世界中的软件开发不是做单题，而是一场漫长的马拉松。你需要在一个已经写好的、复杂的代码库上，不断地添加新功能、修复旧 bug、重构架构。在这个过程中，今天犯的一个小错误，可能会像滚雪球一样，导致明天、后天的任务全部失败。
这篇论文就是为了解决“如何测试 AI 在长跑中会不会累趴下”这个问题而诞生的。
🌟 核心概念：EvoClaw（进化之爪）
1. 问题：AI 在“单题模式”很强，但在“连续模式”很弱
作者发现，目前的 AI 模型在解决独立任务时，得分能超过 80%。但一旦把它们扔进一个需要连续工作、不断积累代码的环境中，它们的得分就会断崖式下跌到 38% 甚至更低。
- 比喻：就像一位钢琴家，让他单独弹一首《小星星》（独立任务），他弹得完美无缺；但让他连续弹奏一整晚，还要在上一首曲子没弹完的基础上即兴创作下一首（连续任务），他很快就手忙脚乱，甚至把之前的旋律都搞乱了。
2. 原因：技术债务的“滚雪球效应”
在连续开发中，AI 往往只顾着完成眼前的任务（比如“加个新功能”），却忽略了它可能会破坏之前的功能（比如“把原来的登录功能搞坏了”）。
- 比喻：这就好比你在搭乐高积木。每加一块新积木，如果不小心压歪了下面的一块，上面的积木就会越来越不稳。AI 往往只想着往上加，却忘了下面的地基已经裂开了。最后，整个塔楼（软件系统）就塌了。
3. 解决方案：DeepCommit（深度提交）与“里程碑”
为了公平地测试 AI，作者不能直接拿原始的代码提交记录（Git Commits），因为那太乱了（比如“修复了拼写错误”、“更新了文档”这种琐碎的提交混在一起）。
他们发明了一个叫 DeepCommit 的工具，它像一个超级编辑，把成千上万条杂乱的代码提交记录，整理成一个个清晰的**“里程碑”（Milestones）**。
- 比喻：
- 原始记录：就像是一堆乱糟糟的日记，今天写了“买了牛奶”，明天写了“修了水管”，后天写了“写了代码”。
- 里程碑：DeepCommit 把这些日记整理成了章节。第一章是“厨房改造”，第二章是“花园种植”。每个章节都是一个完整的、可测试的目标。
- 这些里程碑之间还有依赖关系（比如必须先“厨房改造”完，才能开始“花园种植”），形成了一个任务地图（DAG）。
4. 测试过程：EvoClaw 竞技场
在这个新建立的 EvoClaw 竞技场里，AI 不再是做单题，而是要沿着这张“任务地图”，一个接一个地完成任务。
- 规则：
- 你不能重置环境（不能每次做完都重新来）。
- 你必须保留之前的所有工作成果。
- 如果你在第 1 个任务里埋下了 bug，第 2 个任务就会更难，第 3 个任务可能直接崩溃。
- 结果：测试发现，即使是世界上最先进的 AI，在面对这种“连续进化”的挑战时，也显得非常吃力。它们能学会新功能（召回率高），但很难守住旧功能不崩塌（精确率低）。
💡 关键发现：AI 的“健忘症”与“盲目乱撞”
作者通过观察 AI 的行为，发现了几个有趣的现象：
Recall（召回）vs. Precision（精确）：
- AI 很擅长**“做加法”**（Recall）：让它加新功能，它加得挺快。
- AI 很不擅长**“做减法/防守”**（Precision）：它加新功能时，经常把旧功能搞坏，而且随着任务越多，搞坏的东西越多。
- 比喻：AI 像个热情的装修工，他能把新房间装修得很漂亮，但他经常不小心把旧房间的墙砸穿，而且砸得越来越多。
错误雪崩（Snowball Effect）：
- 早期的一个小错误，会像滚雪球一样，把后面的所有任务都带崩。
- 比喻：就像多米诺骨牌，第一块倒下的时候，AI 没扶住，结果后面几十块全倒了。
盲目乱撞（Blind Thrashing）：
- 当 AI 遇到难题时，它不会停下来思考或检查，而是疯狂地修改代码，却不去运行测试看看对不对。
- 比喻：就像一个人修车，车坏了，他不看说明书也不检查零件，只是不停地拧螺丝、换零件，越修越乱。
成功的秘诀：主动探索与验证：
- 表现好的 AI 会花更多时间去**“阅读代码”（探索）和“运行测试”**（验证）。
- 比喻：优秀的工匠在动工前会先仔细看图，每做一步都拿尺子量一量，确保没歪。
🚀 总结与意义
这篇论文告诉我们什么？
目前的 AI 虽然很聪明，能写代码，但它们还不具备“长期维护”软件的能力。它们更像是一个个“一次性”的解题高手，而不是一个能伴随项目成长、负责到底的“软件工程师”。
这对我们意味着什么？
- 对于开发者：在让 AI 接手大型项目时，不能指望它一次性搞定。我们需要设计更好的流程，让 AI 学会“步步为营”，学会检查自己的错误，而不是盲目推进。
- 对于未来：要真正让 AI 成为自主的软件工程师，我们需要像 EvoClaw 这样的新标准，去训练和测试它们在长跑中的耐力，而不仅仅是短跑速度。
一句话总结：
这篇论文给 AI 程序员出了一道“连续剧”考题，发现它们虽然能演好单集，但演完整部剧时，经常因为记不住前情提要（技术债务）和乱改剧情（错误积累）而搞砸。我们需要教它们学会“走一步看三步”，才能成为真正的软件大师。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。