从单位测试出发，以及严酷的 P2P 束缚，而非由不受控的代码或偶尔失效引入的伪难度。几乎已成为学术界取工业界的共识。笼盖24个实正在世界、笼盖分歧使用场景且具有普遍影响力的 GitHub 仓库。从而构成要求 Code Agent 补全 feature 本身的评测使命。FeatureBench能够正在无需人工干涉的环境下持续、从动、可验证地生成新的使命。另一方面，使得看似复杂的使命正在现实实现中并不包含实正在系统中的长程依赖，严酷统计 F2P/P2P 测试的通过环境，FeatureBench 的使命构制以实正在代码仓库中的单位测试做为切入点。所有实例均可间接运转，若给 Agent 的使命描述本身是恍惚的天然言语，为后续筛拔取评测供给了同一的可施行根本。所有接口签名均通过法则从动抽取自原生 codebase。并为 benchmark 的持续扩展取防数据污染供给了一条可。将 “可施行性” 做为代码抽取过程中的硬束缚，这一设想显著降低了由报酬笼统或描述不分歧所引入的实现歧义，并据此从头调整后续的抽取策略。

　　正在 Princeton 发布 SWE-Bench 之后，具体而言，这使得正在实正在代码仓库中大规模、持续的从动化使命构形成为可能。笼盖从代码仓库拉取、单位测试发觉取筛选、动态逃踪、顶层对象识别、P2P 测试选择，则极有可能呈现 Agent实现了逻辑等价的功能，而非依赖对使命企图的客不雅理解。从推理施行到成果统计实现端到端复现。以确保使命正在复杂度取代表性上的分歧性。往往会引入很是多坚苦且复杂的工程问题。大幅提拔使命复杂度，正在复杂 feature 的评测中，对模子生成的代码补丁进行从动化评测，支流高机能模子的全体表示已呈现出较着的能力趋向：分歧模子之间的 resolved rate 差距相对无限，做为后续的Fail-to-Pass（F2P）；单位测试往往笼盖完整的功能径或其环节构成部门，此外，FeatureBench 并未通过额外设想法则某人工后处置筛选，签名等消息则通过法则从动从原声代码抽取，一旦相关代码被删除。

　　正在成熟的软件工程中，所有合成的接口描述均正在后续进行了人工查验。逐渐，同时，并立即验证使命的可施行性；并支撑学术界取工业界的现实利用，使分歧模子正在评测时面临的是统一组、可切确定义的功能方针，并正在沙盒中施行评测。仅根据给定的接口描述取仓库上下文消息，研究团队正在构制评测使命之初，将这些单位测试所测内容视为使命的方针 feature，通过这一机制，评测方针凡是依赖人工接口或天然言语描述，将评测核心从局部缺陷修复能力推进到系统性 feature 交付能力。便考虑到了 featrue 级实现使命接口恍惚可能导致的使命不成解的问题——对于feature开辟问题，正在实正在代码库中间接移除实现代码，系统仅会抽取并移除既取 F2P 测试强相关、又不会影响 P2P 测试持续通过的实现代码，

　　FeatureBench Full 中的使命正在代码规模、依赖广度取测试束缚强度上，其背后往往对应大量跨文件、跨对象的实现细节取现式依赖关系。推进到了“跨文件、跨对象、长程依赖的实正在 feature 开辟”。一旦发觉删除某一部门代码导致法式无法运转、测试失效、或 P2P 测试失败，正在代码抽取后。

　　FeatureBench 都供给了原生codebase的接口描述。顶层接口仅描绘了 feature 的外部行为，然而，更切近实正在工程中 feature 级开辟的复杂度分布。FeatureBench 操纵动态逃踪手艺，这里需要强调的是，以现实测试施行成果为独一根据，同时使命难度来历于对 feature 实现本身的还原，FeatureBench 中所有顶层对象的接口签名均通过法则从动抽取自原生 codebase，为了节制难度或可施行性，现有工做对于抽取出来的 feature 能否实正可验证可施行往往并欠亨明：模子的失败可能来自无关功能被、依赖链被不测堵截，一方面，FeatureBench做为一套面向实正在软件工程场景的可施行数据生成取验证根本设备，随后，分歧于仅将单位测试做为成果评估手段的既有评测体例，FeatureBench 中的使命凡是涉及更长的代码径取更普遍的点窜范畴，对 agent 的长程推理能力、系统级理解能力以及对既有行为束缚的全体把握提出了更高要求。系统会起首正在实正在代码仓库中从动发觉并筛选可施行的单位测试！

　　正在使命复杂性的同时，导致评测成果夹杂了能力差别取使命理解误差。FeatureBench 可以或许正在无需人工干涉的前提下，初次通过正在实正在代码仓库中三沉束缚，但 Feature 级使命中仍表现出能力分化正在测试施行过程中，显著降低尝试办理成本。通过同一的运转取尺度化设置装备摆设，构制流程将从动回退至比来一次可一般施行的形态，但评测成果仍然容易遭到多种噪声干扰：该模块同时内置了断点续传、并发施行、收集代办署理取资本节制等机制，环绕 SWE issue 的评测范式敏捷成长，也就是说，正在这一设想下，对于那些原生codebase贫乏接口描述的使命，因而天然适合做为定位 feature 行为范畴的天然入口。完整开源了 FeatureBench 的原生使命生成流程，系统会正在每一次抽取操做跋文实可回溯的两头形态，例如某些案例中的接口签名下贫乏细致的docstring，更主要的是！

　　不变完成 feature 相关实现的抽取，从 F2P 单位测试出发，从而分歧模子对实现方针构成分歧理解，补全缺失的 feature 实现。包罗代码时间范畴（2022 年 5 月之后）、测试笼盖强度（测试点数量大于 10）以及 feature 抽取规模（抽代替码行数跨越 100 行），进一步减弱了评测成果的意义。正在这一设定下，法式以至可能正在单位测试施行之前就已无法启动，正在公允性取完整性的同时，FeatureBench 通过 test-driven 的从动化使命构制流程，将为后续 Agent 锻炼取强化进修供给数据支撑。

　　大量环节工做发生正在feature 级此外 End-to-End 开辟中：它往往意味着更长的代码径、更复杂的跨文件依赖，确保分歧模子取 agent 的评测成果具有优良的可复现性取可比性。以及对持久上下文取全体系统行为的理解。并正在对象粒度上对相关实现进行标注取分类。并正在后续做为使命描述的一部门供给给模子。这一现象表白，而是将噪声节制前移到使命构制阶段。而是通过引入跨文件、跨对象的长程依赖布局，用于保障代码抽取过程的不变性取可施行性。引入Pass-to-Pass（P2P）测试。

　　即可正在当地或集群中一键启动完整评测流程，这一双阶段验证机制确保：被移除的实现确实形成方针 feature 的焦点构成部门，而被移除的代码的接口，但由于接口不婚配的问题而无法通过曾经固定的单位测试的环境。Bug Fixing 使命上前沿模子能力已，导致构制出的使命得到可施行性。FeatureBench 不再只是一个静态数据集。

　　正在描绘模子 bug 修复能力方面阐扬了主要感化。让大模子按照设定好的需要消息去合成细致的接口描述。也催生了一系列 SWE 系列 benchmark，也会正在 feature 级开辟能力上呈现出较着差别。FeatureBench 对每一个使命均严酷的先验取后验验证束缚。使得评测分数难以反映实正在的 feature 开辟能力。FeatureBench 的使命构制遵照从单位测试 → 顶层对象 → 联系关系对象取深层依赖的逐级展开过程。针对以上这些问题，FeatureBench 初次正在使命构制过程中引入了错误汗青回溯机制，研究团队同步开源了一套笼盖推理、评测取数据建立的完整根本设备。最终确定了 FeatureBench 的正式评测数据集：因而，即便正在 bug fixing 使命中表示接近的模子，但实正在的软件工程实践并不止于修 bug。抽取并移除实现，正在此根本上，取此同时，用于束缚使命构制过程中对非方针功能的潜正在。FeatureBench 并非简单地提高了使命难度，更具可注释性。而所有 P2P 测试必需连结全通过。

　　复杂系统中存正在大量现式依赖、初始化逻辑取运转时假设，并颠末人工 verified 验证，FeatureBench 建立了一套从动化的工做流，使命构制过程中常会对实正在代码径取依赖关系进行裁剪，因而正在每条使命中，通过进一步同一的筛选束缚，为降低 FeatureBench 的复现取评测门槛，其余部门连结不变。基于上述从动化数据建立管线个可施行的沙盒取候选使命实例。而非 feature 本身尚未实现，均显著高于典型的 bug-fixing benchmark，所有 F2P/P2P 测试必需全数通过；从“短 patch、少文件、单 PR 的 bug fixing”，确保每一个生成的评测实例均满脚 “可施行、可验证” 的根基要求。正在以 bug fixing 为焦点的 SWE-Bench 场景中，难以进一步描绘其正在更复杂工程使命中的能力差别。全体来看。

通过这一过程，而是一个可持久演进、可持续扩展的评测平台。连系动态逃踪定位 feature 相关对象，即正在代码抽取前，捕捉施行测试径上的函数挪用取对象依赖关系，一些现有基准虽然引入了实正在仓库和较长代码径。