跳转至

FeatureBench: Benchmarking Agentic Coding for Complex Feature Development

会议: ICLR 2026
arXiv: 2602.10975
代码: https://github.com/LiberCoders/FeatureBench
领域: Agent
关键词: agentic coding, software development, feature development, benchmark, code agent

一句话总结

提出 FeatureBench——面向特征级软件开发的 Agent 编程基准，200 个任务/24 个开源仓库，平均需实现 790 行代码跨 15.7 个文件。即便是 Claude Opus 4.5（SWE-bench 74.4%）也仅解决 11.0%，揭示了当前 Agent 在真实特征开发场景中的巨大能力缺口。

研究背景与动机

  1. 领域现状：LLM 驱动的 coding agent（Claude Code、Qwen Code 等）正从辅助工具转变为自主开发者。SWE-bench 是最广泛使用的评估基准，但解决率已从<10% 快速提升到>70%，评估区分度不足。

  2. 现有痛点：(a) SWE-bench 以单 PR bug 修复为主（78-82% 的任务），平均仅 32.8 行代码/1.7 文件，远不能代表真实特征开发的复杂度；(b) 特征开发通常跨越多个 PR 散布在时间线上，基于 PR 的收集方法无法完整捕获；(c) 很多基准依赖人工标注或无法自动扩展更新。

  3. 核心矛盾：Agent 在 bug 修复上接近饱和，但真实软件开发的核心是特征实现——需要理解全局架构、管理跨文件依赖、实现大量代码。这一能力完全未被现有基准评估。

  4. 本文要解决什么？ (a) 构建面向特征级开发的基准；(b) 提供自动化、可扩展的任务收集工具；(c) 确保执行式评估（非 LLM judge）。

  5. 切入角度：以单元测试为起点反向追踪——通过运行 F2P 测试并动态追踪依赖图，自动定位特征相关代码，将其从代码库中提取出来作为待实现部分。

  6. 核心 idea 一句话：测试驱动的功能提取——从单元测试出发追踪运行时依赖图，自动从仓库中分离出完整的特征实现作为 Agent 待完成的任务。

方法详解

整体框架

四阶段自动化流水线：(1) 环境配置——Docker 化仓库，人工仅需指定安装命令（~3 分钟/仓库）；(2) 测试构建——验证并选择 F2P 和 P2P 测试；(3) 依赖图追踪——动态追踪构建对象依赖图，BFS 遍历分类节点；(4) 代码提取+问题生成——从代码库中提取特征实现，自动生成问题描述+接口定义。

关键设计

  1. 测试驱动的代码补丁提取:
  2. 做什么：从完整仓库中自动分离出特征相关代码
  3. 核心思路：执行 F2P 测试和 P2P 测试，利用 Python trace 捕获函数调用事件和依赖关系，构建对象依赖图。LLM 分析 F2P 测试导入的函数，区分目标特征函数和辅助测试函数。从特征入口开始 BFS 遍历：P2P 测试中出现的节点标记为 "remained"（其他功能依赖，不能移除），未出现的标记为 "extracted"（待实现的特征代码）

  4. 设计动机：P2P 测试的引入确保提取特征代码后不会破坏现有功能——这是关键的工程约束

  5. 问题描述自动生成:

  6. 做什么：生成明确的接口定义和功能描述
  7. 核心思路：从提取的代码片段中提取函数签名、输入输出类型、导入路径。有 docstring 则直接使用，无则用 LLM 从代码生成。明确指定"解决方案必须可直接调用"

  8. 设计动机：消除实现歧义——明确的接口定义确保正确实现能通过所有测试，实现自动化执行式评估

  9. 两难度级别设计:

  10. L1（增量开发）：在现有代码库基础上扩展实现新功能
  11. L2（从零开发）：完全从零实现相同功能

  12. 设计动机：反映真实开发中的两种场景

  13. 后验证流程:

  14. 修改后的代码库必须通过所有 P2P 测试（现有功能完好）+ 失败所有 F2P 测试（目标功能已移除）
  15. 恢复补丁后所有测试必须通过
  16. 确保所有 F2P 测试所需的工具函数在修改后的代码库中仍可访问

损失函数 / 训练策略

FeatureBench 是评估基准而非训练方法。评估指标： - Resolved Rate：任务完全解决的比例 - Passed Rate：F2P 测试平均通过比例（软指标） - Token I/O：输入输出 token 消耗（效率指标）

实验关键数据

主实验

Scaffold + Model Lite Resolved Full Resolved Token I/O
OpenHands + Qwen3-Coder-480B 6.7% 3.5% 2.0M/14k
OpenHands + DeepSeek-V3.2 6.7% 5.5% 3.1M/23k
Gemini-CLI + Gemini-3-Pro 10.0% 5.0% 2.5M/12k
Claude Code + Claude Opus 4.5 20.0% 11.0% 7.5M/34k
Codex + GPT-5.1-Codex 20.0% 12.5% 6.3M/39k
OpenHands + Claude Opus 4.5 20.0% 10.5% 8.1M/29k

与 SWE-bench 对比

维度 SWE-bench FeatureBench
问题描述长度 195 words 4818 words
Gold Solution 行数 32.8 790.2
Gold Solution 文件数 1.7 15.7
函数数 3 29.2
测试点 6.3 62.7

关键发现

  • Claude Opus 4.5 在 SWE-bench 上 74.4% → FeatureBench 上仅 11.0%，特征级开发比 bug 修复难一个数量级
  • Passed Rate 远高于 Resolved Rate（如 Claude 45.53% vs 11.0%），说明 Agent 能产生"看起来合理"但实际不完整的代码，需要大量调试
  • Token 消耗巨大：所有 LLM 输入超过 100 万 token，但解决率很低——效率是关键瓶颈
  • 常见失败模式：NameError（跨文件依赖未正确导入）、AttributeError（缺失原型方法）——都是跨文件理解不足的表现
  • L2（从零开发）远难于 L1（增量开发），暗示 Agent 严重依赖已有代码的上下文提示

亮点与洞察

  • 测试驱动的功能提取：从测试出发反向追踪依赖图来分离特征代码，这是一种优雅的工程方法——既能自动化又能确保提取后代码库的完整性
  • 可持续更新：基于自动化工具包，FeatureBench 可以持续从新仓库生成任务，避免数据泄露
  • 揭示 Agent 的真实能力边界：SWE-bench 饱和不代表 Agent 接近人类水平——特征开发才是真正的试金石
  • 3825 可执行环境可用于训练：不仅是评估基准，也是 Agent RL 训练的高质量数据源

局限性 / 可改进方向

  • 仅限 Python 仓库，其他语言的软件开发场景未覆盖
  • 200 个任务的规模虽然比手工基准大，但相比 SWE-bench 的 500 个仍偏少
  • L2 从零开发的评估可能过于严格——真实场景中很少完全从零实现
  • 未评估 Agent 的迭代调试能力——只看最终结果，不看中间过程

相关工作与启发

  • vs SWE-bench: SWE-bench 以 bug 修复为主（78-82%），平均 32 行；FeatureBench 专注特征开发，平均 790 行，难度高一个数量级
  • vs PaperBench/MLE-bench: 这些专注 ML 领域，人工策划，不可自动扩展；FeatureBench 覆盖通用 Python 开发且全自动
  • vs SWE-Smith/SWE-Flow: 合成任务但不保证特征级别或现有功能完整性；FeatureBench 的 P2P 测试约束确保了真实开发场景的保真度

评分

  • 新颖性: ⭐⭐⭐⭐⭐ 填补特征级编程基准空白，测试驱动的功能提取方法新颖实用
  • 实验充分度: ⭐⭐⭐⭐ 7 种 scaffold+模型配置，24 个真实仓库，与 SWE-bench 深度对比
  • 写作质量: ⭐⭐⭐⭐ 方法描述清晰，图表直观
  • 价值: ⭐⭐⭐⭐⭐ 揭示了 Agent 编程的真实差距，为社区提供了更有区分度的评估工具