EvoCode-Bench：在多轮迭代交互中评估编码代理

# EvoCode-Bench：在多轮迭代交互中评估编码智能体

**来源：** https://arxiv.org/html/2605.24110

**作者：** Haiyang Shen¹²\*, Xuanzhong Chen¹³\*, Wendong Xu¹⁴\*‡\\ddagger Yun Ma²†\\dagger, Liang Chen¹†\\dagger, Kuan Li¹†\\dagger  
¹UniPat AI, ²北京大学, ³清华大学, ⁴香港大学  
邮箱：{haiyangshen, xuanzhongchen, wendongxu, liangchen, kuanli}@unipat.ai, [email protected]  
\* 同等贡献。‡\\ddagger 编码项目负责人。†\\dagger 通讯作者。

###### 摘要

编码智能体越来越多地被用作迭代式开发合作伙伴，但大多数基准测试仍然是在一次规范说明后进行一次最终评估。这遗漏了一个基本问题：当需求变化时，智能体能否保持其自身代码库的正常工作？我们提出了EvoCode-Bench，一个包含26个有状态编码任务和227个评估轮次的基准测试。每个任务保留智能体工作空间，持续5-15轮，通过可观察行为来表述需求，并使用累积可执行测试来检查新需求以及仍然有效的前期需求。我们使用两个指标评估了13个编码智能体：MT@4，一个四次尝试失败即停止的多轮分数；以及SR，一个从参考完成的前驱状态开始的单轮分数。对于大多数智能体，SR比MT@4高出22-40分。这种差距也改变了排名：SR最高的智能体（78.9）在持续执行中仅排第三（44.0 MT@4）。即使是最强的智能体，在多轮指标上也仅能达到约50%的成功率，并且在第5轮时，聚合通过率下降至第一轮性能的一半以下。失败分析显示了分层的依赖行为：较弱的智能体早期失败，而较强的智能体存活足够长，暴露出规范追踪和回归失败。我们发布了基准数据和Harbor多轮基础设施。

## 1 引言

编码智能体已从代码补全工具演变为能够规划、编辑文件、执行命令以及与开发环境交互的系统。诸如Claude CodeAnthropic (2026 (https://arxiv.org/html/2605.24110#bib.bib36))、CursorAnysphere (2026 (https://arxiv.org/html/2605.24110#bib.bib37))、CodexOpenAI (2026 (https://arxiv.org/html/2605.24110#bib.bib38))和WindsurfWindsurf (2026 (https://arxiv.org/html/2605.24110#bib.bib39))等产品现在被用于调试、数据分析、服务部署和基础设施管理等任务。在这些场景中，智能体必须在一个持久的工作空间内操作：每次编辑都会改变文件、依赖项、接口和测试，这些都会被后续交互所继承。这使得编码成为评估使用工具的智能体的一个有用场景，因为决策会留下可执行的痕迹，并且正确性可以通过行为来检查。

当前的评估只部分匹配了这种场景。函数级基准测试Chen等人 (2021 (https://arxiv.org/html/2605.24110#bib.bib1))、Austin等人 (2021 (https://arxiv.org/html/2605.24110#bib.bib2))、Jain等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib3))、Zhuo等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib4))通过一次生成来评估局部化的编程能力。仓库级基准测试在真实代码库中测试修复、补全和功能添加Liu等人 (2024a (https://arxiv.org/html/2605.24110#bib.bib5))、Jimenez等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib6))、Yang等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib7))、Li等人 (2024b (https://arxiv.org/html/2605.24110#bib.bib31))、Hai等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib32))、Ding等人 (2026 (https://arxiv.org/html/2605.24110#bib.bib34))。SWE-GymPan等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib10))将软件工程任务转变为训练环境。环境级基准测试如AppWorldTrivedi等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib12))和Terminal-BenchMerrill等人 (2026 (https://arxiv.org/html/2605.24110#bib.bib23))评估与可执行环境交互的智能体。多轮评估在对话、工具使用和通用智能体设置中也有研究Zheng等人 (2023b (https://arxiv.org/html/2605.24110#bib.bib18))、Kwan等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib25))、Laban等人 (2026 (https://arxiv.org/html/2605.24110#bib.bib24))、Yao等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib19))、Lu等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib15))。这些努力使编码评估更加真实，但它们通常的单位仍然是一个任务规范说明后跟一个终端评估。持久编码增加了一个不同的要求：后续轮次必须在智能体自身产物的基础上构建，同时保留所有活跃的需求。

实践中，用户以迭代的方式与编码智能体交互：他们添加输出格式、纠正行为、引入约束、弃用早期需求。与对话不同，对话中早期糟糕的回答往往可以通过文本纠正，编码则将决策具体化为文件布局、模式、API和依赖选择。这些承诺限制了后续工作，并可能产生回归。针对这种场景的基准测试需要跨轮依赖、累积可执行测试以及能够识别不断演变的工作空间何时首次停止满足活跃规范的评分机制。

为了弥补这一空白，我们引入了EvoCode-Bench，一个针对交互式、持久多轮会话中编码智能体的基准测试，在这些会话中需求会演变并有时相互冲突。EvoCode-Bench包含26个多轮任务和227个评估轮次，每个任务有5到15轮。该基准测试按两个轴分组：*交互风格*，描述用户如何跨轮次沟通，以及*工程活动*，描述每轮要求进行的代码变更类型。由于正确的智能体可能构建不同的内部设计，EvoCode-Bench评估行为而非实现路径：指令陈述可观察的需求，验证脚本通过执行而不是检查代码结构来验证这些需求。第3节 (https://arxiv.org/html/2605.24110#S3)介绍了完整的分类法和任务构建流程。

我们使用Terminus-2框架Harbor Framework Team (2026b (https://arxiv.org/html/2605.24110#bib.bib41))和Harbor执行协议Harbor Framework Team (2026a (https://arxiv.org/html/2605.24110#bib.bib40))评估了13个领先的编码智能体。我们扩展了Harbor，使得一个Docker工作空间和一个智能体会话在跨轮次时保持持久，同时交换累积验证器并记录状态谱系。评估提供了三个发现。首先，对于大多数智能体，SR比MT@4高出22到40分，并且这种差距重新排名了模型：Opus-4.6具有最高的SR（78.9），但MT@4仅排名第三（44.0）。其次，EvoCode-Bench即使对最强的模型也颇具挑战性：只有两个智能体超过了多轮信用的一半，并且顶级智能体在长轨迹上仍然失败很多。第三，性能随着交互深度的增加而迅速下降。失败分析显示了分层依赖的崩溃模式：较低层级的智能体通常会错过早期需求，而较强的智能体则在后期轮次中挣扎于冲突解决、自我纠正和回归管理。这些结果表明，在不断演变的需求中保持正确性应作为一个单独的评估目标。

#### 贡献。我们贡献了：（i）一个针对交互式持久多轮编码任务的定义，包含演变和冲突的需求；（ii）EvoCode-Bench，包含26个任务、227个评估轮次、持久工作空间、参考增量、累积验证器、失败即停止评分以及双轴分类法；（iii）开源的Harbor多轮扩展，用于连续会话、验证器交换、参考快进、快照/恢复谱系以及失败即停止核算；（iv）一个13智能体的评估，表明单轮性能可能夸大持久可靠性并改变模型排名。

## 2 相关工作

#### 代码生成与修复基准测试
代码评估基准测试已经从函数级生成Chen等人 (2021 (https://arxiv.org/html/2605.24110#bib.bib1))、Austin等人 (2021 (https://arxiv.org/html/2605.24110#bib.bib2))，经过带有库调用的指令遵循Jain等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib3))、Zhuo等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib4))，发展到仓库级任务解决。SWE-benchJimenez等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib6))和SWE-bench MultimodalYang等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib7))要求智能体解决真实问题；RepoBenchLiu等人 (2024a (https://arxiv.org/html/2605.24110#bib.bib5))评估仓库级补全。另一条线研究仓库级生成：EvoCodeBenchLi等人 (2024a (https://arxiv.org/html/2605.24110#bib.bib30))、DevEvalLi等人 (2024b (https://arxiv.org/html/2605.24110#bib.bib31))、RepoExecHai等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib32))、CodeSZan等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib33))、NL2Repo-BenchDing等人 (2026 (https://arxiv.org/html/2605.24110#bib.bib34))和NoCode-benchDeng等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib35))各自推进了仓库构建和功能实现的不同方面。SWE-GymPan等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib10))将软件工程任务转变为训练环境。最近的两项工作增加了顺序结构：SWE-EVOZhao等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib42))要求在单个规范说明下实现一个完整的软件发布，并带有累积回归测试；SlopCodeBenchGarg等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib43))评估跨顺序递增检查点的代码质量。虽然两者都在单个会话中测试持续的正确性，但它们依赖于固定的或递增的规范说明，没有交互式用户对话或需求修订。EvoCode-Bench通过其固有的交互式多轮设计区别于它们：需求通过模拟的用户对话跨轮次演变和冲突，累积验证器在每一轮检查智能体自身累积的工作空间。这明确衡量了固定规范说明基准测试所不衡量的回归避免、冲突解决和需求变更下的增量适应能力。

#### 自主编码智能体评估
近期关于自主智能体的研究探索了能够规划、执行shell命令并与开发环境交互的系统。SWE-agentYang等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib8))和OpenHandsWang等人 (2025b (https://arxiv.org/html/2605.24110#bib.bib9))提供了智能体-计算机接口；而Terminal-BenchMerrill等人 (2026 (https://arxiv.org/html/2605.24110#bib.bib23))和AppWorldTrivedi等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib12))评估了可执行环境交互。AutoCodeRoverZhang等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib11))、AgentlessXia等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib21))和SWE-DevDu等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib20))针对仓库修复或功能开发。然而，这些场景通常仍然基于单个任务规范说明和单个轨迹来定义成功。我们的工作将迭代交互引入了这个循环。基于HarborHarbor Framework Team (2026a (https://arxiv.org/html/2605.24110#bib.bib40))构建的EvoCode-Bench支持跨轮次的持久环境、累积测试和状态核算。

#### 多轮交互评估
多轮评估涵盖对话、通用智能体和工具使用。MT-BenchZheng等人 (2023b (https://arxiv.org/html/2605.24110#bib.bib18))、MT-EvalKwan等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib25))和LMSYS-Chat-1MZheng等人 (2023a (https://arxiv.org/html/2605.24110#bib.bib26))研究对话交互；Laban等人Laban等人 (2026 (https://arxiv.org/html/2605.24110#bib.bib24))表明跨轮次分布信息会急剧降低性能。AgentBenchLiu等人 (2024b (https://arxiv.org/html/2605.24110#bib.bib13))、OSWorldXie等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib17))、BFCLPatil等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib16))、τ\\tau-benchYao等人 (2024 (https://arxiv.org/html/2605.24110#bib.bib19))和ToolSandboxLu等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib15))评估顺序决策或有状态工具使用。在编码领域，具体研究已经调查了多轮生成、依赖排序的代码流和安全性Zheng等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib27))、Wang等人 (2025a (https://arxiv.org/html/2605.24110#bib.bib28))、Rawat等人 (2025 (https://arxiv.org/html/2605.24110#bib.bib29))。EvoCode-Bench是互补的：它通过在每一轮后执行累积测试来评估仓库级开发链，确保每个中间产物都经过行为验证。

## 3 EvoCode-Bench

本节将EvoCode-Bench定义为面向持久多轮编码的基准测试。主要设计选择是将编码视为一个不断演变的工作空间，而非孤立的提示：每个响应都会改变后续轮次继承的文件、依赖项、接口和测试。EvoCode-Bench在所有轮次中保持一个工作空间和一个智能体会话，通过累积测试携带活跃需求前进，并记录累积实现首次违反活跃规范的轮次。

### 3.1 任务定义与分类法

参见图注 图 1：EvoCode-Bench概览。(a) 每轮包含一个指令、参考解决方案和经过人工审核与预言机验证的累积测试。(b) MT@4在轮次间保持一个Docker环境和智能体会话，并带有失败即停止终止。(c) SR在目标轮次之前快进到参考状态。

一个EvoCode-Bench任务在一个持久Docker容器中执行N轮（图1 (https://arxiv.org/html/2605.24110#S3.F1)b）。在第i轮，智能体收到指令Ii\\mathcal{I}\_{i}，并将工作空间Wi−1\\mathcal{W}\_{i-1}编辑为Wi\\mathcal{W}\_{i}。验证器T1:i\\mathcal{T}\_{1:i}测试截至第i轮的所有活跃需求；只有在通过后才发出下一个指令。每轮产生ri∈{0,1}r_{i}\\in\\{0,1\\}。如果ri=0r_{i}=0，评估停止，后续轮次获得零分。失败即停止评分使失败点可解释。允许智能体在失败后继续将混淆两种不同的能力：从无效工作空间中恢复与保持一个有效、演变的状态。EvoCode-Bench在其主要多轮分数中衡量后者；附录F.5 (https://arxiv.org/html/2605.24110#A6.SS5)讨论了面向恢复和参考快进的替代方案。

#### 二维分类法。
多轮编码任务在沟通风格和工程压力两方面都不同。EvoCode-Bench沿两个轴标记每个任务：交互风格和工程活动。

#### 交互风格。
第一个轴捕捉需求的存在位置。**探索性**任务以详细请求开始，然后使用简洁的后续指令，测试从先前对话和仓库状态中恢复意图的能力。**契约性**任务在每一轮提供详细的行为规范，包括对先前行为的修订。**文档驱动**任务将持久语义放置在项目产物中，如规范文件或`AGENTS.md`，测试智能体是否将仓库文档视为活跃规范的一部分。

#### 工程活动。
第二个轴捕捉