论文笔记：EvoClaw — 代码智能体的”长跑”难题：从单点任务到持续演化

一句话总结

EvoClaw 发现了一个令人警醒的事实：12 个顶级代码智能体在独立任务上能拿到 >80% 的分数，但在连续演化场景下最高只能到 38%——暴露了现有评估体系对”时间维度”的系统性忽视。

核心问题：评估的是快照，不是生命体

现有代码智能体评估体系（HumanEval → SWE-bench → Commit0 → ProgramBench）有一个共同假设：每个任务是独立存在的。

• Agent 在一个干净的代码快照上修一个 bug
• 修完评分，reset，换下一个任务
• 任务之间没有任何依赖关系

但真实世界不是这样的：

• 今天的实现决策，约束明天的重构空间
• 快速通过的测试，可能在第三步引入技术债务
• 一个模块的捷径，导致另一个模块必须重写

EvoClaw 的核心论点是：现有 benchmark 测不出这个，因为它们根本不建模时间。

方法：Milestone DAG + 持续演化环境

里程碑（Milestone）粒度

EvoClaw 选择了”里程碑”作为任务粒度——比 commit 粗（避免噪声），比 release 细（保留依赖结构）。

里程碑定义：一组在功能上内聚的提交，共同推进一个具体的开发目标。

例如：实现”用户认证模块”可能由 5 个提交组成，它们合起来是一个里程碑。

为什么不用 commit？因为 commit 太细太乱（很多是 typo fix），且线性序列引入虚假的先后依赖。

为什么不用 release？因为 release 包含了成百上千个相互依赖的提交，粒度太粗，依赖关系被压平。

DeepCommit：从噪声 git 历史中重建里程碑 DAG

这是论文最有技术含量的部分——把一团乱的 git 历史自动重建为可执行的里程碑有向无环图。

三阶段管道：

Phase 1：提交历史预处理

• 收集主分支 commit、PR commit、GitHub API 数据（PR、Issue、Release）
• 静态分析：构建 commit 级 DAG（通过 git blame 追踪行级依赖）、符号级修改统计、文件级共变更矩阵

Phase 2：里程碑 DAG 构建（4 步 LLM Agent 流程）

1. 种子发现：LLM Agent 评估 commit 语义 + DAG 拓扑结构，找出”引入不同开发主题的基础性提交”
2. 里程碑整合：并行子 Agent 把种子扩展为完整里程碑，合并共享文件修改、时间接近、PR/Issue 引用的提交；冲突由协调 Agent 解决
3. 依赖推断：直接依赖（行级文本依赖）+ 隐性依赖（符号调用关系，无共同 hunk），都由 LLM Agent 验证
4. 里程碑分解：过大的里程碑按功能边界拆分，过小的合并，最终控制每个里程碑的代码行数变异系数 CV < 1.0（实际达到 0.96）

Phase 3：运行时环境解析

• MainAgent 编排：平衡测试床质量和解析成本
• MilestoneAgent：在基础 release tag 上按拓扑顺序 cherry-pick 提交，处理冲突
• EnvAgent：从 CI/CD 工作流生成 Dockerfile，必须通过三个硬门：源码编译成功 → 测试框架收集成功 → 里程碑 patch 引用的测试被捕获
• 修复模块循环直到每个里程碑达到稳定状态

评估框架：持续演化 + 隔离评分

三个核心组件：

1. 依赖驱动的任务流：里程碑 M_i 只有在其所有前置里程碑完成后才解锁——真实模拟了软件工程的依赖约束
2. 持续演化环境：Agent 的修改持久化到代码库，下一个任务在前一个任务的状态上继续——早期决策真实约束后期选择
3. 快照隔离评分：开发在持久环境进行，完成后快照传入隔离容器评分——可复现，且 Agent 工作环境不被中断

评分指标：

Recall_m = N_fixed,m / N_required,m    （F2P 测试通过率）
Precision_m = (N_fixed,m + ε) / (N_fixed,m + N_broken,m + ε)  （P2P 回归率）
Score_m = 2 × Precision × Recall / (Precision + Recall)
Final Score = (1/|M|) × Σ Score_m

结果：单点强 ≠ 连续强

核心数据：

这 42+ 百分点的落差说明什么？

• Agent 在独立任务上能解决问题
• 但在需要考虑历史约束、需要维护代码库健康的任务链上，错误会累积、技术债务会压垮后续开发

具体问题：

• 早期为了快速通过测试走了捷径，导致后期需要重构
• 修改了某个模块，破坏了另一个模块的假设，但这个破坏在单任务评估中不会被发现
• 随着里程碑增多，代码库的可维护性下降，Agent 开始犯更多错误

深层洞察：技术债务是一种”误差累积”

EvoClaw 揭示了一个在传统软件工程中很经典、但在 AI Agent 研究中很少被正式建模的现象：技术债务是一种误差累积。

在单任务评估中，每次任务都是独立的——债务不会传递，错误不会累积。这就像在一个没有记忆的强化学习环境中训练——每次都是新鲜的 start state。

但真实的软件开发是一个部分可观测的、状态ful 的、带历史依赖的序列决策过程。Agent 今天的决策，通过代码库的当前状态，影响明天能做的事。

EvoClaw 的里程碑 DAG，本质上是对这个”依赖图”的显式建模。

局限与开放问题

1. 成本：完整评估一次约 $500（Claude Opus 4.5），限制了大规模实验
2. 语言覆盖：5 种语言（Go、Rust、Java、TypeScript、Python），但每种数量有限
3. 无法测出所有类型的技术债务：只建模了可测试的功能依赖，架构层面的隐性耦合很难被 F2P/P2P 测试捕获
4. 里程碑粒度仍有主观性：虽然 CV 控制了大小分布，但里程碑的”功能内聚性”由 LLM 判断，可能有噪声

关联论文

• SWE-bench：Commit 级别的独立任务评估，EvoClaw 的前身
• SWE-CI：链式 commit-to-commit CI 轮次，但没有里程碑粒度和 DAG 依赖
• SlopCodeBench：测量结构性腐化，但粒度是手工设计的任务
• FeatureBench / SWE-Dev：独立特征级任务，同样缺少时间维度

结论：EvoClaw 最重要的贡献不是具体的算法或数据集，而是一个问题定义——它清楚地说明了”为什么现有 benchmark 测不出代码智能体的长跑能力”，并且提供了第一个可用的测量工具。对未来的 Agent 评估来说，”持续演化”应该成为标配设置，就像”多轮对话”之于对话系统一样。