RoadmapBench：跨版本升级的长期代理式软件开发评测（1分钟阅读）

# RoadmapBench: 跨版本升级评估长期多目标智能体软件开发

来源：https://arxiv.org/html/2605.15846

许新博¹², 杨瑞涵³, 沈海阳¹², 许文东¹⁴, 高博飞², 吴若宇¹², 石珂安¹², 谢炜楚², 陈玄中¹⁵, 吴明⁶, Jason Zeng⁶, Michael Heinrich⁶, Elvis Zhang⁷, 陈亮¹†, 李宽¹†, 常宝宝²†

¹UniPat AI  
²北京大学  
³复旦大学  
⁴香港大学  
⁵清华大学  
⁶0G Labs  
⁷Pipeline Lab

###### 摘要

编码智能体正越来越多地部署在真实软件开发中，单个版本迭代需要跨多个文件的协同工作数月之久。然而，现有基准大多聚焦于Python仓库中的单问题缺陷修复，且评估结果仅为粗略的通过/失败，未能捕捉真实工程规模下的长期、多目标开发。为弥补这一空白，我们提出**RoadmapBench**，一个包含115个长期编码任务的基准，这些任务基于17个仓库和5种编程语言的真实开源版本升级。每个任务将智能体置于源版本的代码快照上，并提供多目标路线图指令，要求其实现目标版本中引入的功能，中位修改量为跨51个文件的3,700行代码。我们对十三个前沿模型进行了系统评估，发现即使是最强的Claude-Opus-4.7也只解决了39.1%的任务，而最弱的模型仅解决5.2%，这与现有的缺陷修复基准形成鲜明对比，表明长期软件开发仍然是一个很大程度上未解决的问题。

*

图1:RoadmapBench排行榜。使用OpenHands评估的在115个跨5种语言和17个仓库的多目标软件演化任务中表现最佳的模型的解决率。即使是最好的模型也只解决了39.1%的任务。

## 1 引言

表1:与相关编码基准的比较。范围:任务粒度。子任务评分:目标级完成度评分。解决方案: oracle补丁大小(LoC)。

| 基准 | #任务 | 语言 | 范围 | 子任务评分 | 解决方案 |
|------|-------|------|------|------------|----------|
| SWE-bench Verified [OpenAI, 2024] | 500 | Python | 提交 | ✗ | ~33 LOC |
| SWE-bench Pro [Deng等, 2025] | 1,865 | 多语言 | 提交 | ✗ | ~107 LOC |
| FeatureBench [Zhou等, 2025] | 200 | Python | 提交 | ✗ | ~790 LOC |
| TerminalBench [Merrill等, 2026] | 89 | 多语言 | 任务 | ✗ | ~280 LOC |
| SWE-EVO [Thai等, 2025] | 48 | Python | 版本 | ✗ | ~611 LOC |
| NL2Repo [Ding等, 2025] | 104 | Python | 仓库 | ✗ | ~3,000 LOC |
| **ROADMAPBENCH** | **115** | **多语言** | **版本** | **✓ (平均5个目标)** | **~3,700 LOC** |

大型语言模型(LLMs)的快速进步[Anthropic, 2026a; OpenAI, 2026; Google DeepMind, 2025]催生了新一代编码智能体，能够在交互式开发环境中规划、编辑、执行和验证软件[Yang等, 2024; Zhang等, 2024; Huang等, 2025; Wang等, 2025]。随着这些智能体超越孤立的代码生成和缺陷修复，核心挑战日益转向持续的、多目标的软件开发。因此，评估正从**短期**缺陷修复转向**长期**功能实现。这引出了一个关键问题：**如何评估智能体在跨数周或数月、多目标、人类规模的开发工作上的表现？**

现有基准未能跟上这一转变(表1)。当前大多数基准仍是短期的：SWE-bench [Jimenez等, 2024] 和 SWE-bench Pro [Deng等, 2025] 评估孤立的软件工程问题，oracle解决方案分别约为33行和107行，比真实工程规模低一到两个数量级。长期基准的尝试仍然稀少，且每个任务仅简化为一个二元结果，忽视了真实版本升级自然具有的多目标结构——开发者需要在单个发布周期内协调多个重大变更。

除了范围和粒度，现有基准仍集中在有限的一组被高度重复使用的Python仓库[Liu等, 2023; Du等, 2023]，这加剧了污染风险，因为流行的代码库更可能出现在预训练语料中。

为应对这些挑战，我们提出**RoadmapBench**，一个基于真实开源版本升级的115个长期编码任务基准。每个任务从一个固定到早期版本的仓库快照开始，要求智能体实现下一个版本中引入的行为，中位oracle修改量约为跨多个文件和模块的3,700行代码。我们将每个升级转换成一个包含中位5个子任务的多目标路线图，指定要实现的*内容*，包括API签名、参数语义、默认值和异常行为，同时保留实现细节。每个子任务通过其自己的测试套件验证，并贡献于加权的总体分数，因此部分进度被捕获为连续值而非二元结果。为扩大覆盖范围，我们精选了跨5种编程语言的17个仓库，涵盖数据处理、Web框架、ORM、序列化、GUI工具包和开发者工具，与现有基准无重叠。为确保失败反映真实能力差距而非基准伪影，我们将静态验证与基于归因的推演质量控制相结合，以分离任务侧缺陷与模型侧限制，并迭代修复已确认的任务问题。

我们在RoadmapBench上评估了十三个前沿模型，发现没有模型接近解决该基准。如图1所示，即使是最强的模型Claude-Opus-4.7也只解决了39.1%的任务，而最弱的模型仅达到5.2%。相比之下，这些系统在SWE-bench Verified [OpenAI, 2024]上获得了80%以上的分数。完成分数揭示了一致模式：模型通常在完成几个子任务后在集成边界处停滞，这比单纯的二元结果提供了更清晰的能力层级区分。

总之，我们的主要贡献如下：
- 我们构建了**RoadmapBench**，一个包含115个跨17个仓库和5种编程语言的真实开源版本升级任务的基准，将长期多目标软件开发确立为一个独立的评估场景。
- 我们开发了一个构建流程，将真实版本升级转化为多目标任务，并结合静态验证与基于推演的质量控制，以分离任务侧缺陷与真实模型限制，并迭代修复已确认的问题。
- 我们评估了十三个前沿模型，发现解决率范围从5.2%到39.1%，远低于现有缺陷修复基准的性能，而完成分数揭示了跨领域和难度层级的细粒度能力差异，超越了二元解决指标。

## 2 相关工作

##### 编码智能体。

基于LLM的编码智能体已从单轮代码生成系统演变为在现实开发环境中运行的交互式软件工程智能体[Sapkota等, 2025; Dong等, 2025; Starace等, 2025]。OpenHands [Wang等, 2024] 提供了一个构建通用型软件开发智能体的开放平台，而Terminus 2 [Merrill等, 2026] 则是Harbor框架中用于沙盒环境自主评估的参考智能体实现。商业系统如Claude Code [Anthropic, 2025] 进一步将智能体编码带入了主流软件开发工作流。随着这些系统能力日益增强，对更能反映真实世界软件工程复杂性的基准的需求也在增长。

##### 针对智能体的编码基准。

针对LLM智能体的编码基准已从函数级合成逐步演变为更真实的软件工程任务。HumanEval [Chen等, 2021] 和MBPP [Austin等, 2021] 聚焦于函数级代码生成。SWE-bench系列 [Jimenez等, 2024; OpenAI, 2024; Deng等, 2025] 将评估扩展到真实世界仓库中的问题解决和长期工程任务。后来的基准将评估拓宽到面向功能的开发和系统级交互，包括FeatureBench [Zhou等, 2026] 和TerminalBench [Merrill等, 2026]。最近的工作探索了日益开放和长期的软件工程场景。NL2Repo [Ding等, 2025] 评估从自然语言规范生成完整仓库，不要求智能体演化现有大规模代码库，而SWE-EVO [Thai等, 2025] 研究Python版本演化，但直接从发布说明推导问题陈述，没有明确的指令-测试对齐验证。

现有基准仍主要评估孤立任务，而非结构化的长期多目标软件开发过程。RoadmapBench覆盖了跨5种编程语言的17个仓库，每个实例包含约五个结构化子任务以及专门的指令-测试对齐验证。表1总结了现有基准的关键差异。

## 3 RoadmapBench

我们从三个方面描述RoadmapBench：任务定义与评估协议(第3.1节)、数据集统计(第3.2节)和构建流程(第3.3节)。

### 3.1 任务定义

图2:RoadmapBench任务概览。智能体接收源版本仓库快照和路线图式指令，然后在固定的Docker环境中实现指定功能。评估通过针对目标版本引入的行为的加权子任务级测试进行。

如图2所示，每个RoadmapBench任务要求智能体实现真实版本升级中引入的功能。智能体在Docker环境中操作，仓库固定在源版本。它收到一个多目标路线图指令，指定要实现的*内容*：每个目标对应一个不同的新功能单元，并描述预期的行为需求。与真实版本升级中多个重大变更协调在一个发布中一样，这些目标共同捕获一个统一的发展目标。

我们沿两个维度评估每个任务。如果智能体通过所有子任务，则该任务被**解决**，这提供了一个完整的二进制成功度量。为捕捉部分进展，我们额外计算加权奖励：每个子任务有一个反映其实现复杂度的权重，奖励是通过子任务的加权比例。

### 3.2 数据集统计

当前版本包含115个任务，跨越五个编程语言的17个开源仓库(详情见附录E)。Oracle补丁范围从少于300行到超过30,000行代码变更，中位数约为3,700行和51个文件。子任务数量从3到12个不等，中位数为5个，确认任务需要持续的多目标工程而非单功能编辑。图3显示了跨仓库的任务分布和oracle补丁大小。

图3:RoadmapBench数据集概览。(a) 按领域(内圈)分组的每个仓库的任务计数(外圈): 机器学习与数据(36)、Web与RPC(17)、ORM与验证(25)、基础设施与工具(23)、UI与重命名(14)。(b) 每个仓库的真实补丁大小(变更行数)分布，虚线标记了总体中位数3,714 LOC。

### 3.3 数据构建流程

图4:RoadmapBench构建流程。仓库挖掘选择适合任务的版本对；任务构建将发布说明与代码差异对齐，以创建指令和测试。静态验证和基于推演的质量控制在基准包含之前修复任务侧缺陷。

流程分四个阶段(图4)：仓库挖掘、任务构建、静态验证和基于推演的质量控制。

##### 阶段1：仓库挖掘。

我们从社区精选的开源项目列表中跨五种语言汇总仓库，并应用三层过滤器：(1) 基于规则的过滤器保留至少1000颗星、五个或更多标记版本、且在2025年仍有持续发布活动的仓库；(2) 深度搜索识别维护高质量发布文档的仓库(示例见附录G.1)；(3) 专家评审验证文档质量，并选择具有足够代码变更和功能叙事的连续版本对用于任务构建。此过程产出跨五种语言的17个仓库和115个版本对。

##### 阶段2：任务构建。

每个任务在固定在源版本的Docker环境中构建。git历史被保留，但源版本之后的所有分支和标签被修剪，防止智能体通过版本控制检查目标版本代码。我们将源到目标的代码差异与发布说明对齐，以识别外部可见的行为变化，并创建一个多目标路线图指令(instruction.md)，指定要实现*什么*而不揭示*如何*实现。测试从上游测试套件适配以保持行为覆盖，并从代码差异中提取金补丁，根据任务环境进行精炼，并验证直到通过适配的测试。

##### 阶段3：静态验证。

每个任务沿两个维度进行静态检查：**合规性**，验证规范的自包含性、源可追溯性和测试有效性；以及**目标级正确性**，确保每个目标的每个测试行为都被指定，并且没有测试依赖于