FeatureBench
搜索文档
不止修bug:Agentic Coding评测走向复杂feature交付新阶段
机器之心· 2026-03-04 11:58
行业研究:AI代码代理(Code Agent)评测基准演进 - 当前行业共识是使用真实世界代码仓库和可执行测试来评估大模型的软件工程能力,例如SWE-Bench系列基准,主要聚焦于bug修复能力[1] - 然而,真实的软件工程实践远不止修复bug,大量关键工作发生在功能级别的端到端开发中,这涉及更长的代码路径、更复杂的跨文件依赖以及对长期上下文和整体系统行为的理解[1][4] - 为填补功能级别开发评测的空白,中国科学院自动化研究所与华为联合提出了FeatureBench基准,旨在评估和推动更强大、更全面的AI代码代理[2] FeatureBench基准的核心创新与设计 - **高精准度:动态追踪驱动的精准功能级代码抽取** - 任务构造以真实代码仓库中的单元测试为切入点,利用其反向定位并抽取与目标功能强相关的实现代码[7] - 在测试执行过程中,利用动态追踪技术捕获执行路径上的函数调用与对象依赖关系,并在对象粒度上对相关实现进行标注与分类[8] - 为克服任务接口模糊问题,所有接口签名均通过规则自动从原生代码库抽取,对于缺少描述的情况,使用大模型合成并经人工检验,确保任务可解[9] - **强可执行性:基于错误历史回溯的任务构造机制** - 在真实代码库中直接移除代码会引入复杂的工程问题,可能导致程序无法启动[14] - FeatureBench首次在任务构造中引入错误历史回溯机制,将“可执行性”作为硬约束,通过即时验证和自动回退确保生成的每个评测实例均可执行、可验证[14] - **强验证机制:由目标对齐、验证闭环与长链路复杂性构成的三重约束** - **目标对齐**:所有顶层对象的接口签名均通过规则自动抽取自原生代码库,确保评测公平性,降低实现歧义[17] - **验证闭环**:对每个任务施加严格的双阶段验证约束,确保任务难度来源于对功能实现本身的还原,而非代码破坏[19] - **长链路复杂性**:任务构造遵循从单元测试到顶层对象再到深层依赖的逐级展开过程,涉及更长的代码路径和更广泛的修改范围,对代理的长期推理和系统理解能力要求更高[20] FeatureBench数据集规模与复杂度 - 研究团队在3天内系统性构建了3825个可执行的沙盒环境与候选任务实例,覆盖24个真实世界的GitHub仓库[22] - 经过统一筛选和人工验证,最终确定了正式评测数据集,其任务在代码规模、依赖广度与测试约束强度上均显著高于典型的bug修复基准[22] - 与SWE-bench相比,FeatureBench的任务描述长度(4818词 vs 195.1词)、黄金解决方案的代码行数(790.2行 vs 32.8行)、涉及文件数(15.7个 vs 1.7个)、涉及函数数(29.2个 vs 3个)以及失败测试点数量(62.7个 vs 9.1个)都高出数个量级,表明其复杂度显著更高[23][25] 评测结果揭示的模型能力分化 - 在以bug修复为核心的SWE-Bench场景中,主流高性能模型的整体表现已呈现明显的能力收敛趋势,模型间的解决率差距有限[29] - 在FeatureBench的功能级端到端开发评测中,模型与代理之间的能力差距被显著放大[29] - 例如,Claude Opus在SWE-Bench Verified上的解决率为74.4%,而在FeatureBench Full上的解决率仅为11%[29] - 其他模型在FeatureBench上的表现分化更为明显,呈现出远高于SWE-Bench场景的区分度[29] - 评测排行榜显示,在FeatureBench Full数据集上,表现最佳的GPT-5.1-Codex解决率为12.5%,Claude Opus为11.0%,而其他模型如DeepSeek V3.2、Gemini-3-Pro、Qwen3-Coder等的解决率在1%至5.5%之间,差距明显[30] 平台化与开源:推动行业应用与迭代 - **高易用性**:研究团队开源了覆盖推理、评测与数据构建的完整基础设施,用户可通过一行命令一键启动完整评测流程,大幅降低复现与使用门槛[33] - **推理模块**:提供了统一的多代理框架入口,对主流代码代理框架进行标准化适配,并内置了断点续传、并发执行等机制,便于大规模实验[34][35] - **评测模块**:以实际测试执行结果为唯一依据进行自动化评测,确保结果的可复现性与可比性[36] - **数据构建管线**:完整开源了原生任务生成全链路流程,使FeatureBench能在无需人工干预的情况下持续、自动、可验证地生成新任务,成为一个可长期演进的评测平台[37] 行业意义与未来展望 - FeatureBench是代码代理评测领域的一次关键突破,将评测范式从“短补丁、少文件、单PR的bug修复”推进到了“跨文件、跨对象、长程依赖的真实功能开发”[38] - 该基准通过测试驱动的自动化任务构造流程,在保证公平性与完备性的同时,大幅提升了任务复杂度,并为基准的持续扩展与防数据污染提供了可行路径[38] - FeatureBench作为一套面向真实软件工程场景的可执行数据生成与验证基础设施,将为后续代理训练与强化学习提供数据支持[39]