FeatureBench：填补大模型端到端复杂功能开发评测空白，中科院自动化所与华为联合推出新基准

在 Princeton 发布 SWE-Bench 之后，利用真实世界代码仓库与可执行测试来评估大语言模型的软件工程能力，已成为学术界与工业界的共识。围绕 SWE issue 的评测范式迅速发展，催生了一系列 SWE 系列基准，在刻画模型修复缺陷的能力方面发挥了重要作用。

然而，真实的软件工程实践远不止于修复缺陷。大量关键工作发生在功能级别的端到端开发中：这通常意味着更长的代码路径、更复杂的跨文件依赖，以及对长期上下文与整体系统行为的深入理解。换言之，能够修复缺陷并不意味着能够交付一个完整的功能。

为填补这一空白，中国科学院自动化研究所与华为联合提出 FeatureBench（Benchmarking Agentic Coding in End-to-End Development of Complex Features），聚焦于测试驱动开发的评测范式，并构建了一套覆盖数据构建、推理与评测的端到端基础设施。相关数据、管线代码与执行镜像均已完整开源，旨在为评估和推动更强大、更全面的智能体编码模型提供新的基准。

• 论文标题：FeatureBench: Benchmarking Agentic Coding for Complex Feature Development
• 项目主页：https://libercoders.github.io/FeatureBench/
• arXiv 论文：https://arxiv.org/abs/2602.10975
• Hugging Face 数据集：https://huggingface.co/datasets/LiberCoders/FeatureBench
• GitHub 代码库：https://github.com/LiberCoders/FeatureBench
• Docker 镜像：https://hub.docker.com/u/libercoders

高精准度：动态追踪驱动的精准功能级代码抽取

FeatureBench 的任务构造以真实代码仓库中的单元测试为切入点。在成熟的软件工程实践中，单元测试通常覆盖完整的功能路径或其关键组成部分，并隐式刻画了功能的行为边界与实现假设，因此天然适合作为定位功能范围的自然入口。

不同于仅将单元测试作为结果评估手段的既有评测方式，FeatureBench 在任务构造阶段便引入单元测试，用其反向定位并抽取与目标功能强相关的实现代码，从而形成要求代码智能体补全功能本身的评测任务。具体而言，系统首先在真实代码仓库中自动发现并筛选可执行的单元测试，将这些单元测试所测内容视为目标任务功能，作为后续的“失败到通过”测试；同时，引入“通过到通过”测试，用于约束任务构造过程中对非目标功能的潜在破坏。

在测试执行过程中，FeatureBench 利用动态追踪技术，从“失败到通过”单元测试出发，捕获执行路径上的函数调用与对象依赖关系，并在对象粒度上对相关实现进行标注与分类。随后，系统仅会抽取并移除既与“失败到通过”测试强相关、又不会影响“通过到通过”测试持续通过的实现代码，其余部分保持不变。被移除代码的接口签名等信息则通过规则自动从原生代码抽取，并在后续作为任务描述的一部分提供给模型。

需要强调的是，研究团队在构造评测任务之初，便考虑到了功能级实现任务因接口模糊可能导致任务不可解的问题——对于功能开发问题，若给予智能体的任务描述本身是模糊的自然语言，则极有可能出现智能体实现了逻辑等价的功能，但因接口不匹配而无法通过已固定单元测试的情况。

因此，在每条任务中，FeatureBench 都提供了源自原生代码库的接口描述。所有接口签名均通过规则自动抽取自原生代码库。对于那些原生代码库缺少详细接口描述的任务，FeatureBench 构建了一套自动化工作流，让大语言模型根据预设的必要信息合成详细的接口描述，所有合成描述均在后续进行了人工检验。

通过这一过程，FeatureBench 构造出的是一类更接近真实开发场景的评测任务：模型需要在保持所有“通过到通过”测试通过的前提下，仅依据给定的接口描述与仓库上下文信息，补全缺失的功能实现。

图：从单元测试出发，结合动态追踪定位功能相关对象，抽取并移除实现，生成缺失版本代码库与标准补丁，并在沙盒环境中执行评测。

强可执行性：基于错误历史回溯的任务构造机制

然而，在真实代码库中直接移除实现代码，往往会引入大量困难且复杂的工程问题。复杂系统中存在大量隐式依赖、初始化逻辑与运行时假设，一旦相关代码被删除，程序甚至可能在单元测试执行之前就已无法启动，导致构造出的任务失去可执行性。

为解决这一问题，FeatureBench 首次在任务构造过程中引入了错误历史回溯机制，将“可执行性”作为代码抽取过程中的硬约束，以保障过程的稳定性与结果的可执行性。系统会在每一次抽取操作后记录可回溯的中间状态，并即时验证任务的可执行性；一旦发现删除某部分代码导致程序无法运行、测试环境失效或“通过到通过”测试失败，构造流程将自动回退至最近一次可正常执行的状态，并据此重新调整后续的抽取策略。

通过这一机制，FeatureBench 能够在无需人工干预的前提下逐步收敛，稳定完成功能相关实现的抽取，确保每一个生成的评测实例均满足“可执行、可验证”的基本要求，使得在真实代码仓库中大规模、持续地自动化构造任务成为可能。

强验证机制：由目标对齐、验证闭环与长链路复杂性构成的评测约束

在复杂功能的评测中，“更难”往往并不意味着“更可靠”。一些现有基准虽然引入了真实仓库和较长代码路径，但评测结果仍易受多种噪声干扰：

一方面，评测目标通常依赖人工接口或自然语言描述，导致不同模型对实现目标形成不同理解，使得评测结果混合了能力差异与任务理解偏差。

另一方面，现有工作对于抽取出的功能是否真正可验证、可执行往往并不透明：模型的失败可能源于无关功能被破坏或依赖链被意外切断，而非功能本身尚未实现，使得评测分数难以反映真实的功能开发能力。

此外，为了控制难度或保证可执行性，任务构造过程中常会对真实代码路径与依赖关系进行裁剪，使得看似复杂的任务在实际实现中并不包含真实系统中的长程依赖，进一步削弱了评测结果的指示意义。

针对以上问题，FeatureBench 并未通过额外设计规则或人工后处理进行筛选，而是将噪声控制前移到任务构造阶段，首次通过在真实代码仓库中施加三重约束，在保证任务复杂性的同时，使评测结果更稳定、可对齐且更具可解释性。

1) 目标对齐（评测的公平性）

FeatureBench 中所有顶层对象的接口签名均通过规则自动抽取自原生代码库，而非人工编写或模型生成。由于接口定义直接来源于真实实现，这一设计显著降低了由人为抽象或描述不一致所引入的实现歧义，使不同模型在评测时面对的是同一组可精确定义的功能目标，而非依赖对任务意图的主观理解。

2) 验证闭环（评测的完备性）

3) 长链路复杂性（评测的长程性）

FeatureBench 的任务构造遵循从单元测试 → 顶层对象 → 关联对象与深层依赖的逐级展开过程。顶层接口仅刻画了功能的外部行为，其背后往往对应大量跨文件、跨对象的实现细节与隐式依赖关系。

因此，FeatureBench 中的任务通常涉及更长的代码路径与更广泛的修改范围，对智能体的长程推理能力、系统级理解能力以及对既有行为约束的整体把握提出了更高要求。

高复杂度：面向真实功能的大规模可执行评测实例

基于自动化数据构建管线，研究团队在 3 天之内，系统性构建了 3825 个可执行的沙盒环境与候选任务实例，覆盖 24 个来自真实世界、涵盖不同应用场景的 GitHub 仓库。所有实例均可直接运行，为后续筛选与评测提供了统一的可执行基础。

在此基础上，通过进一步施加统一的筛选约束，包括代码时间范围（2022 年 5 月之后）、测试覆盖强度（测试点数量大于 10）以及功能抽取规模（抽取代码行数超过 100 行），以确保任务在复杂度与代表性上的一致性。经过人工验证，最终确定了 FeatureBench 的正式评测数据集：

• FeatureBench Full：包含 200 条评测任务。单任务最多抽取 4495 行代码，最多涉及 76 份不同代码文件。
• FeatureBench Lite：从 Full 集中进一步筛选出 30 条任务，作为低成本评测子集，便于社区进行快速对比实验与方法迭代。

整体来看，FeatureBench Full 中的任务在代码规模、依赖广度与测试约束强度上，均显著高于典型的缺陷修复基准测试，更贴近真实工程环境中功能级开发的复杂度分布。

FeatureBench 的复杂度显著高于典型缺陷修复基准测试，覆盖跨文件、跨对象、长程依赖的真实功能实现。

高区分度：功能级任务评测重新拉开模型能力差距

研究团队在 FeatureBench 上对多种主流智能体框架与多种模型配置进行了系统评测。

评测结果显示，在以缺陷修复为核心的 SWE-Bench 场景中，主流高性能模型的整体表现已呈现出明显的能力收敛趋势：不同模型之间的解决率差距相对有限，难以进一步刻画其在更复杂工程任务中的能力差异。

相比之下，当评测任务推进到功能级端到端开发时，模型与智能体之间的差距被显著放大。以 Claude Opus 为例，其在 SWE-Bench Verified 上的解决率已达到 74.4%，而在 FeatureBench Full 上的解决率为 11%；与此同时，其他模型在 FeatureBench 上的表现分化更为明显，呈现出远高于 SWE-Bench 场景的区分度。

这一现象表明，FeatureBench 并非简单地提高了任务难度，而是通过引入跨文件、跨对象的长程依赖结构，以及严格的 P2P 约束，将评测焦点从局部缺陷修复能力推进到系统性功能交付能力。在这一设定下，即便在缺陷修复任务中表现接近的模型，也会在功能级开发能力上呈现出明显差异。

缺陷修复任务上前沿模型能力已收敛，但功能级任务中仍体现出显著的能力分化。

Lite 数据集上的模型表现。

高易用性：一行命令启动完整评测流程

为降低 FeatureBench 的复现与评测门槛，研究团队同步开源了一套覆盖推理、评测与数据构建的完整基础设施。通过统一的运行环境与标准化配置，用户无需繁琐的环境搭建，即可在本地或集群中一键启动完整评测流程，从推理执行到结果统计实现端到端复现。在这一设计下，FeatureBench 不再只是一个静态数据集，而是一个可长期演进、可持续扩展的评测平台。

• 推理模块：提供了统一的智能体抽象接口，对主流代码智能体框架进行了标准化适配。用户只需进行最小化配置，即可将自定义智能体接入现有管线。该模块同时内置了断点续传、并发执行等机制，以降低实验管理成本。
• 评测模块：以实际测试执行结果为唯一依据，对模型生成的代码补丁进行自动化评测，严格统计 F2P/P2P 测试的通过情况，确保评测结果具有良好的可复现性与可比性。
• 数据构建管线：完整开源了 FeatureBench 的原生任务生成流程，覆盖从代码仓库拉取、单元测试发现与筛选、动态追踪到对象级代码抽取与后验验证的全链路步骤。借助该管线，可以在无需人工干预的情况下持续、自动地生成新的可验证任务。

结语

FeatureBench 是代码智能体评测领域的一次关键突破，它系统性地将评测范式从“短补丁、少文件、单 PR 的缺陷修复”，推进到了“跨文件、跨对象、长程依赖的真实功能开发”。更重要的是，FeatureBench 通过测试驱动的自动化任务构造流程，在保证公平性与完备性的同时，大幅提升了任务复杂度，并为基准测试的持续扩展与防数据污染提供了一条可行路径。

同时，FeatureBench 作为一套面向真实软件工程场景的可执行数据生成与验证基础设施，也将为后续智能体训练与强化学习提供数据支持。

关注“鲸栖”小程序，掌握最新AI资讯