FeatureBench：面向复杂功能开发的智能体编程基准测试 FeatureBench: Benchmarking Agentic Coding for Complex Feature Development
首个聚焦功能级开发的智能体编程基准，揭示最强模型仅11%通过率的巨大挑战
前置知识
Agentic Coding（智能体编程）
指由大语言模型（LLM）驱动的自主编程系统，能够理解高层需求描述，自主规划实现步骤，与编译器、测试框架等外部工具交互，迭代完成复杂的软件开发任务。与传统的代码补全不同，智能体编程强调端到端的自主开发能力，人类仅需提供需求描述并监督最终结果。代表性系统包括 Claude Code、OpenHands 等。
本文的核心研究对象就是评估这类智能体在功能级开发任务上的能力边界，理解这个概念是理解整个论文的基础。
SWE-bench 与 Fail-to-Pass (F2P) / Pass-to-Pass (P2P) 测试
SWE-bench 是当前最主流的智能体编程基准，主要聚焦于从 GitHub issue 中提取的 bug 修复任务。F2P 测试是指在未实现功能前会失败、实现后应通过的测试用例；P2P 测试是指在实现前后都应通过的测试用例，用于验证新功能的实现没有破坏已有功能。这种双测试机制确保了评估的完整性和可靠性。
FeatureBench 的设计灵感来源于 SWE-bench 但超越了它。理解 F2P/P2P 机制有助于理解本文如何构建可验证的评估环境。
依赖图与动态追踪（Dependency Graph & Dynamic Tracing）
在程序分析中，依赖图描述了函数或模块之间的调用关系。动态追踪是指在程序实际运行时捕获函数调用事件和数据依赖的技术。本文利用 Python 内置的 tracing 机制在测试执行过程中记录函数调用，构建函数级别的对象依赖图，从而精确识别哪些代码属于目标功能、哪些属于其他功能。
这是本文自动化工单收集流水线的核心技术，使得能够从代码仓库中自动提取功能级开发任务而不破坏其他功能。
Docker 沙箱环境
Docker 是一种容器化技术，能够创建隔离的运行环境。在本文中，每个评估任务都封装在独立的 Docker 镜像中，包含完整的代码仓库、依赖环境和测试套件。这确保了评估的可重现性，同时防止智能体通过访问外部资源作弊。
可执行环境是实现自动化评估的基础，理解这个概念有助于理解本文评估协议的可靠性。
研究动机
当前智能体编程基准测试存在严重的局限性，无法真实反映 LLM 在实际软件开发中的能力。首先，最广泛使用的 SWE-bench 主要聚焦于 bug 修复任务，其中仅有约 18-22% 的实例对应功能开发请求，而真实软件开发中功能开发才是核心工作。其次，现有基准的任务范围狭窄：PaperBench 仅有 20 个任务，MLE-Bench 有 72 个，GitTaskBench 有 54 个，DevEval 有 22 个手工设计的任务，规模极其有限。第三，基于 Pull Request (PR) 的传统数据收集方法存在根本缺陷——功能开发往往跨越多个 PR 分散在开发时间线上，难以关联识别；许多 PR 缺乏标签，导致功能贡献的识别不可靠；PR 驱动的方法本质上受限于历史提交轨迹，无法灵活组合开发任务。第四，现有基准普遍缺乏自动化的持续更新机制，面临数据泄露风险。
本文的目标是本文旨在构建一个面向功能级真实软件开发的、具有挑战性的、可扩展的智能体编程基准。具体目标包括：（1）将评估范围从 bug 修复扩展到端到端的功能开发，覆盖从零实现和增量开发两种场景；（2）实现基于执行的自动化评估，避免依赖人工检查或 LLM 判断；（3）开发可扩展的测试驱动工具包，能够从任意 Python 仓库自动收集评估实例；（4）支持持续更新以缓解数据泄露问题。
与已有工作不同的是，本文的独特切入角度在于『测试驱动的功能提取』。与依赖 PR 历史轨迹的传统方法不同，FeatureBench 从单元测试出发反向追踪代码依赖，通过构建对象依赖图来精确识别功能边界。这种方法不依赖 PR 的可用性和预定义的提交轨迹，能够从任何具有单元测试的 Python 仓库中灵活提取功能级任务。同时，通过引入 P2P 测试来区分目标功能代码和其他功能代码，确保了提取的功能边界不会破坏已有功能的完整性。这种『从测试到代码』的逆向工程思路，使得基准构建从『依赖人工标注』转变为『自动化流水线』。
核心方法
FeatureBench 的整体思路可以概括为『测试驱动的功能级任务提取与执行式评估』。直觉上，如果一个测试文件专门测试某个功能，那么通过分析这个测试文件在运行时调用了哪些函数、这些函数之间有什么依赖关系，就能精确地画出这个功能的代码边界。技术路线分为三个阶段：第一阶段是环境配置与测试筛选——为每个仓库创建 Docker 环境，执行所有单元测试，筛选出 F2P（实现前失败、实现后通过）和 P2P（实现前后都通过）测试文件；第二阶段是代码补丁提取——通过动态追踪构建函数级依赖图，利用 LLM 区分被测对象和辅助工具，基于 BFS 遍历图来分类『保留』和『提取』的节点，最终生成未开发代码库和对应的代码补丁；第三阶段是任务生成与验证——自动生成包含接口定义和功能描述的问题陈述，并通过严格的后验证确保提取质量。
本文的核心创新在于『对象依赖图 + P2P 测试保护』的代码提取机制。与现有方法的本质区别在于：SWE-bench 依赖 PR 中的代码差异，SWE-Flow 仅使用 F2P 测试合成任务但忽略了 P2P 测试，SWE-Smith 使用启发式规则修改代码。FeatureBench 则同时利用 F2P 和 P2P 测试来精确定位功能边界——F2P 测试标识了需要实现的功能入口点，P2P 测试标识了需要保护的其他功能。通过以 F2P 测试的顶层导入对象为起点进行 BFS 遍历，将遍历过程中遇到 P2P 执行路径的节点标记为『保留』，其余标记为『提取』。这种机制确保了提取操作只移除目标功能的代码，而不会影响其他功能的正常运行，这是之前方法所不具备的。
方法步骤详情
FeatureBench 的构建流程包含以下详细步骤：（1）环境配置：手动指定仓库的安装命令（约3分钟），自动化脚本配置环境并打包为 Docker 镜像。（2）测试筛选：使用 pytest 的 collection 机制收集所有测试文件，执行并验证，将失败的测试文件标记为 F2P，随机采样 m 个通过的文件作为 P2P。（3）依赖图构建：执行 F2P 和 P2P 测试，利用 Python 内置 tracing 捕获函数调用事件，构建对象依赖图，每个节点包含唯一标识符、源码位置、依赖函数列表和是否在 P2P 中触发的标志。（4）LLM 分类：使用 LLM 分析 F2P 测试文件，区分与目标功能相关的导入函数和辅助工具函数，分类结果经验证后精度达 81.03%、召回率 89.24%。（5）图遍历与节点分类：以分类出的顶层对象为入口点执行 BFS，P2P 路径中的节点标记为 remained，其余标记为 extracted。（6）代码提取与后验证：移除 extracted 节点对应的代码，验证修改后的代码库通过所有 P2P 测试且失败所有 F2P 测试，重新应用补丁后所有测试通过。（7）问题陈述生成：从代码片段推导接口签名（输入输出变量类型），利用 LLM 生成缺失的文档字符串，组装最终的任务描述。
技术新颖性
FeatureBench 的技术新颖性体现在多个层面。首先，在基准构建范式上，它实现了从『PR 驱动』到『测试驱动』的范式转换，不再依赖人工编写的 PR 历史，而是从单元测试反向提取功能任务，使得任何具有测试套件的 Python 仓库都成为潜在的数据源。其次，在功能边界识别上，它创新性地结合了 F2P 和 P2P 测试——F2P 测试定义了功能的『正面边界』（需要实现什么），P2P 测试定义了功能的『负面边界』（不能破坏什么），两者共同构成了功能的完整边界描述。第三，在任务难度分级上，它定义了 L1（增量开发，保留部分代码库）和 L2（从零实现，完全移除代码库）两个难度级别，真实反映了软件开发中的两种典型场景。第四，在评估设计上，它要求智能体输出『直接可调用的模块』，接口签名和调用路径在问题陈述中明确指定，消除了需求歧义，使得基于执行的自动化评估成为可能。
实验结果
本文在 FeatureBench 上评估了 7 个前沿模型+框架组合，揭示了当前智能体编程的巨大挑战。在 Full 集（200个任务）上，最强的两个配置——Claude Code + Claude Opus 4.5 和 Codex + GPT-5.1-Codex（中等推理）——分别仅达到 11.0% 和 12.5% 的解决率。在 Lite 集（30个任务）上，这两个配置分别达到 20.0% 的解决率。其他模型表现更差：OpenHands + DeepSeek-V3.2 为 5.5%，OpenHands + Gemini-3-Pro-Preview 为 4.5%，OpenHands + Qwen3-Coder-480B-A35B-Instruct 为 3.5%。值得注意的是，通过率（Passed Rate）普遍远高于解决率，例如 Claude Opus 4.5 在 Full 集上的通过率为 43.29%，但解决率仅为 11.0%，这表明当前智能体经常生成看似合理但距离真正解决问题还有很大差距的方案。在 token 消耗方面，所有模型的输入 token 都超过 100 万，Claude Opus 4.5 的输入 token 高达 750-900 万，反映了现有智能体在处理真实开发任务时的极低效率。与 SWE-bench 的对比更为震撼：Claude Opus 4.5 在 SWE-bench 上达到 74.4% 的解决率，但在 FeatureBench 共享仓库子集上仅达到 5.2%，差距超过 14 倍。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| FeatureBench Full Set（200个任务） | Resolved Rate | 12.5%（GPT-5.1-Codex） | 11.0%（Claude Opus 4.5） | 最强模型仅12.5%，揭示巨大挑战空间 |
| FeatureBench vs SWE-bench（共享仓库子集） | Resolved Rate | 5.2%（Claude Opus 4.5 on FeatureBench） | 74.4%（Claude Opus 4.5 on SWE-bench） | FeatureBench 比 SWE-bench 难 14 倍以上 |
| L1（增量开发）vs L2（从零实现） | Resolved Rate | L1: 13.9%（GPT-5.1-Codex） | L2: 5.9%（GPT-5.1-Codex） | 从零实现比增量开发难约2.4倍 |
| 可见单元测试 vs 不可见单元测试 | Resolved Rate | 63.3%（GPT-5.1-Codex with visible tests） | 16.7%（GPT-5.1-Codex without tests） | 可见测试提升46.6个百分点 |
| 提供接口 vs 不提供接口 | Resolved Rate | 10.0%（Gemini-3-Pro with interface） | 3.3%（Gemini-3-Pro without interface） | 接口定义提升6.7个百分点 |
局限与改进
本文的局限性可以从多个角度分析。从作者承认的角度看：（1）FeatureBench 当前仅覆盖 Python 仓库，未扩展到其他编程语言；（2）环境配置仍需约 3 分钟的人工干预，虽然整体人工成本很低（24 个仓库总计不到 1 小时），但仍未实现完全自动化；（3）Lite 集仅包含 30 个实例，可能无法完全代表 Full 集的分布，尽管实验显示排名一致性很高。从我自己的观察来看：（1）任务的时间分布（2022年5月至2025年9月）可能导致某些较早的任务已经被模型在训练数据中见过，尽管作者强调支持持续更新以缓解此问题；（2）评估依赖 pytest 测试套件的质量，如果原始仓库的测试覆盖不完整，可能导致评估偏差；（3）LLM 分类器虽然准确率达 81%，但仍有约 19% 的误分类可能影响提取质量；（4）L2 任务要求完全从零实现，这在实际开发中相对少见，可能降低了该难度级别的实践意义。
独立分析的弱点
基于独立分析，FeatureBench 存在以下弱点及改进方向：（1）语言覆盖局限——当前仅支持 Python，而真实软件开发涉及多种语言。改进方向是扩展工具包以支持 Java、JavaScript、Go 等主流语言的依赖分析和测试框架。（2）任务类型单一——聚焦于『实现新功能』，未覆盖功能重构、性能优化、API 迁移等常见开发任务。可以通过修改提取策略来生成这些类型的任务。（3）评估粒度粗——二元的『解决/未解决』指标无法反映智能体的部分成功。虽然已有 Passed Rate 作为软指标，但可以进一步细分为功能正确性、代码质量、实现效率等维度。（4）静态接口约束——问题陈述中明确给出接口签名，降低了需求理解的难度。可以设计更模糊的需求描述来评估智能体的需求分析能力。（5）单轮交互模式——当前评估是单次输入-输出，未考虑真实的多轮开发-调试循环。可以引入迭代评估机制。
未来方向
作者提出的未来方向包括：利用基准的可验证环境进行智能体训练（强化学习），以及持续更新基准以缓解数据泄露。基于本文成果可以延伸的方向有：（1）构建跨语言的功能级基准，统一不同编程语言的评估标准；（2）开发更智能的测试生成技术，为缺乏测试的仓库自动生成高质量测试用例；（3）利用 FeatureBench 的任务格式进行智能体微调，特别是利用通过率作为奖励信号；（4）研究『人机协作』开发模式下的评估方法，将人类反馈纳入评估循环；（5）探索多智能体协作开发的评估框架，评估团队级的开发能力；（6）将评估扩展到整个软件生命周期，包括需求分析、架构设计、代码审查等环节。
复现评估
本文的可重现性评估非常积极。在开源情况方面，代码已在 GitHub 开源（github.com/LiberCoders/FeatureBench），数据集公开可访问。在数据方面，200 个评估任务和 3825 个可执行环境均来自 24 个公开的 GitHub 仓库，数据来源透明可查。每个实例包含完整的 Docker 镜像、问题陈述、代码补丁和测试套件，确保了评估环境的完整重建。在算力方面，评估的主要成本在于 API 调用——每个任务平均消耗数百万输入 token，Full 集评估一次的成本较高，但 Lite 集（30 个任务）提供了一个经济的替代方案。在复现难度方面，自动化工具包大大降低了基准构建的门槛，仅需为每个新仓库指定安装命令即可自动完成后续流程。总体而言，这是近期智能体编程基准中可重现性最好的工作之一。
论文图表
