超越首次提示的智能体评估

原文链接：https://www.philschmid.de/evocode-bench

大多数编程基准测试的工作方式都一样。你给智能体一个任务，让它工作，然后检查结果。智能体可能会执行数十次工具调用，但只有一次用户输入和一次最终评估。

这并不是我们大多数人在使用智能体的方式。你构建了一些东西，然后有了新想法、需求发生变化、你进行重构……EvoCode-Bench 正是为了测试这种循环而设计的。

EvoCode-Bench 是一个新的多轮编程基准测试，包含 26 个任务，跨越 227 个连续的轮次（每个任务 5–15 轮）。它跨五个领域评估智能体：ML/MLOps、构建系统、数据工程、云/安全以及科学计算。有三个特点使其有趣：

• 持久化工作区： 一个容器存在于任务的整个生命周期中。第 1 轮的代码、依赖和架构决策在第 15 轮仍然存在。
• 演进式规范： 每次新的输入都会带来新的指令，要么扩展代码库，要么纠正逻辑，要么与早期需求冲突（有意打破先前的假设）。
• 累积测试： 每一轮之后，测试套件会检查所有需求，而不仅仅是新的需求。破坏之前轮次中已工作的东西，就会失败。

单轮评估（SWE-bench）：
  [提示] → [智能体工作] → [通过/失败] → 容器丢弃

多轮评估（EvoCode-Bench）：
  [提示 1] → [智能体工作] → [测试 1] →
  [提示 2] → [智能体工作] → [测试 1+2] →
  [提示 3] → [智能体工作] → [测试 1+2+3] → ...

示例：在 8 轮中构建一个 CLI 工具

其中一个任务（d1_w5）要求智能体在 Go 中构建 buildctl，一个 CLI 构建编排器，共 8 轮。以下是前几轮的工作方式：

第 1 轮：

• 用户提示： “在 Go 中构建一个名为 buildctl 的 CLI 工具，用于编排多目标构建管道，具有依赖解析、并行执行和内容寻址工件缓存功能。” 完整规范定义了 TOML 配置解析、拓扑排序、缓存键计算（命令 + 环境 + 输入文件哈希的 SHA-256）、4 个 CLI 命令（build、graph、clean、status）、JSON 报告格式以及循环、缺失依赖和超时的错误处理。
• 智能体： 创建 Go 模块，实现管道引擎，编写 CLI。
• 验证： 框架挂载 round-1/tests/test.sh（24 个测试用例）并针对 CLI 运行。测试脚本在验证后被移除，这样智能体就无法读取未来的评分标准。

第 2 轮：

• 用户提示： “添加管道组合和变量替换。” 具体来说：TOML 中新增的 imports 字段，用于跨文件组合管道（支持传递性导入、循环检测、名称冲突错误），以及一个 [variables] 部分，在命令、输入和输出中支持 ${VAR_NAME} 展开。
• 智能体： 在同一个持久化容器和代码库中，添加导入解析和变量展开。
• 验证： 测试套件现在检查同时满足第 1 轮的需求（缓存、排序、错误处理）和新的导入/变量特性。

第 5 轮：

• 用户提示： “将构建改为默认失败快速。当任何目标失败时，不要启动其他目标。未启动的目标状态为 cancelled（与 skipped 不同）。添加 –keep-going 标志以恢复旧行为。”
• 这与第 1 轮的说法相反，第 1 轮说独立目标在兄弟目标失败时应继续运行。智能体必须重构执行引擎，向 JSON 报告添加新的状态类型，并更新摘要计数，同时不破坏早期轮次的导入、变量、钩子或缓存键计算。
• 验证： 测试套件仍检查所有先前的需求（缓存、排序、导入、变量），但第 1 轮的失败处理测试已调整为适应新的规范。

关键洞察

单轮分数严重高估了可靠性。 研究人员测试了两种模式：一种是从干净的、由人类完成的代码库开始每一轮（SR），另一种是智能体跨轮次维护自己的工作区（MT@4）。智能体在干净代码上遵循指令表现良好。当构建在自身过去的工作基础上时，它们表现得明显更差。对于低端模型，差距约为 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%。轮次越多，累积的决策越多，失败也就越多。

失败模式因模型层级而异。 低端智能体早期失败，它们根本没有实现要求的内容（87–90% 的失败）。中端智能体处理了初始轮次，但当规范发生变化时，它们添加了新的逻辑，但没有完全移除被替换的旧行为（28.6% 的失败，在第 5 轮达到峰值）。高端智能体走得更远，但最终破坏了一些原本正常工作的东西，回归在第 2 轮占失败的 35%。

回归是真正的瓶颈。 智能体很少因为无法构建功能而失败。它们失败是因为破坏了已经正常工作的东西。当规范发生变化时，智能体编辑代码以处理新的需求，但这些编辑触及共享的代码路径并意外地破坏了早期行为。智能体并不总是重新验证旧的东西是否仍然有效。

结构化有帮助。 那些在持久化文档（如项目计划或规范文件）中跟踪需求的智能体，其成功率增加了一倍以上。

局限性

数据集较小。 26 个任务，227 轮。一些困难的任务可能会使总分产生偏差。

全有或全无评分。 单一回归会使整个轮次得分为零，即使 98% 的测试用例通过。该论文也报告了每个案例的分数，显示智能体在二分类失败的轮次中通常能达到 >80% 的断言准确率。

没有恢复循环。 在失败即停止评分模式（MT@4）下，单个失败轮次会终止整个试验——所有剩余轮次自动得零分。该基准测试并不测试智能体是否能够从崩溃状态中恢复。

静态交互。 “用户“是一个固定的脚本。没有澄清问题，没有“这不是我的意思”，没有歧义。

基础设施敏感。 论文自身的结果显示基础设施问题（容器节流、kubelet 错误）可能会破坏分数。

• 论文：EvoCode-Bench: Evaluating Coding Agents in Multi-Turn Iterative Interactions

• 代码与数据集：UniPat-AI/EvoCodeBench

• 排行榜：Results