EvoClaw：评估AI代理在持续软件演化中的能力 EvoClaw: Evaluating AI Agents on Continuous Software Evolution
提出DeepCommit流水线和EvoClaw基准，揭示前沿模型在持续软件演化中的性能崩溃现象
前置知识
里程碑DAG（Milestone DAG）
将软件开发历史从线性提交序列重构为有向无环图（DAG）结构，其中每个节点代表一个功能内聚的开发目标（里程碑），边编码依赖约束。里程碑级别的粒度在提交级（过于细碎、噪声多）和发布级（过于粗糙、丢失依赖细节）之间取得平衡，既保留细粒度开发依赖，又封装现实的功能目标。
理解里程碑DAG是理解EvoClaw评估范式的基础，它决定了任务的依赖结构和评估方式
连续任务评估（Continuous Task Evaluation）
与传统的独立任务评估（如SWE-bench）不同，连续任务评估要求代理在持久化的代码库上持续演化，前一个任务的修改会保留到后续任务中。代理必须维护代码库的长期健康，因为早期的技术债务或潜在缺陷会累积并阻碍未来进展。
这是EvoClaw的核心评估范式，暴露了现有代理在长期维护中的根本缺陷
Recall与Precision指标
Recall衡量功能实现完整性：代理成功实现的必需功能变更比例（Recall_m = N_fixed,m / N_required,m）。Precision衡量修改可靠性：状态变更为改进（而非回归）的比例（Precision_m = (N_fixed,m + ε) / (N_fixed,m + N_broken,m + ε)）。两者的调和平均构成最终得分。
这对指标能区分「实现功能但引入回归」和「保持稳定但无进展」两种失败模式
错误雪球效应（Snowball Effect）
在持续软件演化中，未解决的回归错误通过依赖链传播到下游里程碑，导致错误累积速度超过代理修复速度。早期缺陷通过依赖关系污染后续任务，最终使整个开发停滞。
这是解释代理在持续环境中性能崩溃的核心机制
DeepCommit流水线
自动化代理流水线，通过三个阶段重构软件演化轨迹：提交历史预处理、里程碑DAG构建、可执行环境解析。使用静态分析、LLM代理驱动的里程碑构建和运行时验证，确保合成的里程碑可执行和可测试。
DeepCommit是构建EvoClaw基准的核心技术，解决了从嘈杂git历史中提取可验证演化序列的难题
研究动机
现有基准测试将软件开发视为独立任务，忽略了真实软件演化中的时间依赖性和技术债务。在SWE-bench等基准中，代理在每个任务后环境重置，允许它们采取权宜之计满足即时测试却默默积累技术债务。在持续集成环境中，早期实现决策约束后续决策，但现有评估无法捕捉这种跨任务错误传播。例如，代理可能通过硬编码解决当前问题，却破坏了未来功能的扩展性，这种失败模式在当前独立评估中完全不可见。
本文的目标是建立能够评估AI代理长期软件维护能力的基准，量化代理在连续依赖约束下的性能退化程度，揭示从独立任务到持续演化的性能差距，为开发更可靠的自主软件代理提供评估框架。具体目标包括：首先，量化代理在连续任务中的Recall（功能实现完整性）和Precision（修改可靠性）表现；其次，分析错误传播机制，理解为什么代理在长期演化中性能崩溃；第三，评估不同代理框架和模型在成本效益方面的权衡；最后，为改善代理的长期维护能力提供实证依据和行为指导。
与已有工作不同的是，本文抓住了现有基准忽略的关键维度：软件演化的时间结构。与SWE-bench的提交级粒度（噪声多、语义连贯性差）和SWE-EVO的发布级粒度（过于粗糙、丢失依赖细节）不同，本文提出里程碑级别的粒度，既能保留细粒度开发依赖，又能封装现实的功能目标。更重要的是，本文首次建立了「开发历史中累积」的评估范式，而非「在快照上独立评估」。
核心方法
本文提出DeepCommit+EvoClaw的完整解决方案。DeepCommit就像一位考古学家，从嘈杂的git历史中挖掘出清晰的开发轨迹：首先通过静态分析提取提交级别的依赖关系，然后用LLM代理将相关提交聚合成「里程碑」（功能内聚的开发目标），最后构建可执行的Docker环境确保每个里程碑可测试。EvoClaw则基于这些里程碑构建评估框架：代理必须按依赖顺序实现一系列功能需求，每个任务的代码修改会保留到后续任务，模拟真实软件开发的连续性。
核心创新是「里程碑级别粒度」的软件演化建模。与现有方法的本质区别在于：提交级方法（如SWE-CI）过于细碎，很多提交是琐碎的修复，且线性序列编码了虚假依赖；发布级方法（如SWE-EVO）过于粗糙，将数百个相互依赖的提交压缩为单个更新。里程碑级别既能保留细粒度开发依赖和代码库结构演化，又能封装现实的功能目标，其依赖关系自然形成DAG结构。
方法步骤详情
方法分为三个主要阶段：（1）提交历史预处理：收集主分支提交及其PR/Issue/发布元数据，通过LLM代理配置源目录、测试模式和排除规则，提取三个结构信号：提交级DAG（用git blame捕获行级文本依赖）、符号级修改（识别类和函数变更）、文件级共变更统计（反映演化耦合）。（2）里程碑DAG构建：四阶段LLM代理驱动过程——种子发现（识别引入开发主题的基础锚点提交）、里程碑整合（用并行子代理扩展里程碑边界）、依赖推断（从行级依赖和符号分析中推断边）、里程碑分解（将过大里程碑分解为功能独立的子里程碑）。（3）运行时环境解析：MainAgent协调多代理工作流，为每个里程碑生成可复现的Docker镜像，确保源代码编译、测试框架收集成功，并捕获尽可能多的相关测试。
技术新颖性
技术新颖性体现在三个方面：首先，首次提出里程碑级别的软件演化粒度，在功能连贯性和演化感知之间取得最优平衡；其次，DeepCommit是首个自动化代理流水线，能从原始提交历史重构可验证的里程碑DAG，通过静态分析、LLM推理和运行时验证的协同确保质量；第三，EvoClaw的评估框架采用「开发历史中累积」范式，首次量化了跨任务错误传播，揭示了Recall线性增长而Precision饱和的根本不对称性。
实验结果
实验评估了12个前沿模型在4个代理框架上的表现，揭示了根本性的性能差距。在连续任务评估中，Claude Opus 4.6（OpenHands框架）取得最高得分38.03%，但解决率仅8.46%；在Claude Code框架下得分36.29%，解决率11.57%。相比之下，独立任务评估中所有模型得分超过80%，表明困难源于长期错误累积而非任务本身复杂性。关键发现：（1）Recall线性增长但Precision饱和——代理保留实现新功能的能力，但无法防止回归累积；（2）错误雪球效应——未解决的回归通过依赖链传播，最终使开发停滞；（3）任务复杂性效应——后期里程碑和更深DAG层性能显著下降；（4）探索行为关键——成功演化依赖于主动的代码库探索和严格的测试验证，而非盲目试错。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 连续软件演化 | Score (%) | 38.03（Claude Opus 4.6） | 独立任务评估 >80% | 性能下降约50% |
| 连续软件演化 | Resolve Rate (%) | 13.37（Gemini 3 Pro） | 独立任务评估 >80% | 解决率下降约67% |
| 成本效益 | 每演化范围成本($) | 12.10（Gemini 3 Flash） | 114.96（Gemini 3 Pro） | 成本降低90% |
| 探索效率 | 探索工具调用数 | 7,667（Claude Opus 4.6） | 2,584（Gemini 3 Pro） | 探索量增加200% |
局限与改进
论文承认了几个关键局限：（1）测试套件依赖——依赖于维护良好的可执行测试套件，缺乏丰富测试覆盖的项目无法纳入基准；（2）过滤偏差——只保留触及源代码且具有非平凡依赖的提交，可能偏向依赖丰富的演化；（3）数据污染风险——高影响力开源项目的提交历史可能出现在前沿模型的预训练语料中；（4）人类监督依赖——DeepCommit的两个阶段仍需人类专家监督；（5）规模限制——当前流水线针对源代码金补丁低于约3万行的发布范围。
独立分析的弱点
独立分析发现以下弱点：（1）里程碑构建的自动化程度不足——DeepCommit仍依赖人类专家在关键决策点的指导，限制了流水线的可扩展性和自动化程度；（2）测试套件质量要求过高——需要F2P和P2P测试信号，这排除了大量缺乏完善测试的开源项目；（3）评估成本过高——使用Claude Opus 4.5进行完整评估成本约500美元，限制了大规模实验和模型迭代；（4）错误传播分析的粒度有限——虽然引入了错误链概念，但根因分析仍依赖另一个LLM代理，可能引入偏差。改进方向：开发完全自动化的里程碑构建算法，降低对测试套件的依赖，优化评估效率。
未来方向
作者提出的未来方向包括：持续刷新基准以缓解数据污染，将DeepCommit应用于私有仓库。基于当前成果可延伸的方向：（1）开发主动技术债务管理策略，让代理能识别和修复回归而非仅实现新功能；（2）研究上下文压缩和状态管理技术，改善代理在长期任务中的记忆保持；（3）探索多代理协作模式，让不同代理负责功能实现和回归检测；（4）将评估框架扩展到更复杂的软件架构（如微服务、分布式系统）。
复现评估
论文提供了良好的可复现性支持：代码（DeepCommit流水线和EvoClaw基准）已在GitHub开源，数据集在HuggingFace发布，排行榜网站提供实时结果。然而，完全复现面临挑战：（1）需要访问前沿LLM的API（Claude Opus 4.5、GPT 5.3等），成本较高；（2）运行时环境解析需要Docker和特定仓库的配置；（3）人类监督阶段难以自动化复现。总体而言，对于有充足计算资源的研究团队，复现是可行的。
论文图表
