EvoCode-Bench：多轮迭代任务下编码 Agent 真实能力评测，回归才是最大瓶颈

如果你正在给团队选编码 Agent，单轮基准测试的分数已经不够用了。Philipp Schmid 解读的 EvoCode-Bench 基准揭示了一个关键事实：把任务拆成多轮迭代、让需求持续变更后，模型排名会重新洗牌，而过半失败不是因为做不出新功能，而是弄坏了已经通过的功能。

单轮基准与真实使用差距在哪

大多数编码基准的工作方式相同：给 Agent 一个任务，让它干活，检查结果。Agent 可能跑几十次工具调用，但用户只输入一次，评估也只做一次。

这不是大多数人使用 Agent 的方式。你构建一个东西，产生新想法，需求变化，重构代码……EvoCode-Bench 就是专为测试这种循环设计的。

EvoCode-Bench 是一个新的多轮编码基准，包含 26 个任务、227 个连续轮次（每任务 5-15 轮），覆盖五个领域：ML/MLOps、构建系统、数据工程、云安全与科学计算。三个设计让它与众不同：

• 持久工作区：一个容器贯穿任务全生命周期。第 1 轮的代码、依赖和架构决策在第 15 轮依然存在。
• 演化规格：每个新输入带来新指令，要么扩展代码库、修正逻辑，要么与早期需求冲突（故意打破此前假设）。
• 累积测试：每轮结束后，测试套件检查所有需求而不只是新增需求。弄坏了之前轮次的东西，直接失败。

单轮评估（SWE-bench 模式）是：提示→Agent 工作→通过/失败→容器丢弃。多轮评估（EvoCode-Bench 模式）是：提示 1→Agent 工作→测试 1→提示 2→Agent 工作→测试 1+2→提示 3→Agent 工作→测试 1+2+3，依此累积。

实例：8 轮迭代构建一个 CLI 工具

一个代号 d1_w5 的任务要求 Agent 用 Go 构建 CLI 构建编排器 buildctl，共 8 轮。看前几轮怎么运作：

第 1 轮：用户提示要求构建支持依赖解析、并行执行与内容寻址产物缓存的 CLI 工具，完整规格定义了 TOML 配置解析、拓扑排序、缓存键计算（命令+环境+输入文件哈希的 SHA-256）、4 个 CLI 命令（build/graph/clean/status）、JSON 报告格式以及循环/缺依赖/超时的错误处理。Agent 搭建 Go 模块、实现流水线引擎、写 CLI。验证时框架挂载 round-1/tests/test.sh（24 个测试用例）运行，测试脚本验证后即删除，Agent 无法提前读到评分标准。

第 2 轮：用户要求”增加流水线组合与变量替换”：TOML 新增 imports 字段支持跨文件组合（含传递导入、循环检测、命名冲突报错），新增 [variables] 段支持命令中的 ${VAR_NAME} 展开。Agent 在同一持久容器和代码库里添加导入解析与变量展开。验证时测试套件同时检查第 1 轮需求（缓存、排序、错误处理）和新的导入/变量特性。

第 5 轮：用户要求”build 默认改为快速失败：任一目标失败就不启动额外目标，未启动目标标记为 cancelled（区别于 skipped），加 —keep-going 标志恢复旧行为”。这直接反转了第 1 轮”独立目标应继续运行”的规格。Agent 必须重构执行引擎、给 JSON 报告加新状态类型、更新汇总计数，且不能破坏导入、变量、缓存键计算等既有功能。测试套件仍检查全部既有需求，只是第 1 轮的失败处理测试适配了新规格。

四个关键发现

单轮分数严重高估可靠性。 研究者测试了两种模式：每轮从人类完成的干净代码库开始（SR），或 Agent 维护自己的工作区跨轮延续（MT@4）。Agent 在干净代码上执行指令很在行，但在自己过去的工作上继续构建就明显变差。低档模型差距约 4 倍（8.4% MT → 33.1% SR）；前沿模型仍有 1.4-1.8 倍差距。超过 57% 的多轮失败发生在”从干净状态出发模型能轻松解决”的轮次上。

排名在压力下洗牌。 Claude Opus 4.6 单轮得分最高（78.9%），但多轮跌至第三（44.0%），落后于 Opus 4.7（54.0%）和 GPT-5.5（52.4%）。所有模型的通过率从第 1 轮的 46.7% 降到第 5 轮的 21.3%，第 10 轮只剩 7.7%。轮次越多，累积决策越多，失败越多。

失败模式按模型档次分层。 低档 Agent 失败得早——根本没实现要求的功能（87-90% 的失败）。中档 Agent 能处理初始轮次，但规格一变，只加新逻辑而不完全移除被替代的旧行为（28.6% 的失败，第 5 轮达峰）。高档 Agent 走得更远，但最终弄坏已经正常工作的东西——回归在第 2 轮就占失败的 35%。

回归才是真正的瓶颈。 Agent 很少因为做不出功能而失败，而是因为弄坏了本来正常的东西。规格变化时，Agent 编辑代码处理新需求，但改动触及共享代码路径，意外破坏了早期行为，且 Agent 不总是回头验证旧功能是否还能用。

结构化追踪有帮助。 在持久文档（如项目计划或规格文件）中追踪需求的 Agent，成功率翻倍以上。

基准自身的局限

样本小：26 任务 227 轮，几个高难任务可能扭曲总分。全有或全无计分：单次回归就把整轮归零，即使 98% 测试用例通过；论文也报告了逐用例分数，显示被判二进制失败的轮次中 Agent 常拿到 >80% 的断言准确率。无恢复循环：fail-stop 计分下单轮失败终止整个试验，剩余轮次自动零分，基准不测试 Agent 能否从坏状态恢复。交互是静态的：“用户”是固定脚本，没有澄清提问、没有”这不是我要的”、没有歧义。基础设施敏感：论文自己的结果显示容器节流、kubelet 错误等基础设施问题可以污染分数。

选型启示

对要用 Agent 做长期迭代开发的团队，看多轮基准的排名比单轮更有参考价值。如果你的场景是”一次提需求一次交付”，单轮分数仍然适用；但只要需求会变、代码要持续演进，就应该关注回归率指标，并在工作流里加入结构化需求追踪——这是基准数据里少数被验证能直接翻倍成功率的手段。

原文信息

• 作者：Philipp Schmid（@_philschmid），Google DeepMind 工程师
• 原文发布日期：2026-07-27 原文地址：