不止修bug：Agentic Coding評測走向復雜feature交付新階段

在 Princeton 發布 SWE-Bench 之后，用真實世界代碼倉庫+可執行測試評測大模型軟件工程能力，幾乎已成為學術界與工業界的共識。圍繞 SWE issue 的評測范式迅速發展，也催生了一系列 SWE 系列 benchmark，在刻畫模型 bug 修復能力方面發揮了重要作用。

但真實的軟件工程實踐并不止于修 bug。大量關鍵工作發生在feature 級別的 End-to-End 開發中：它往往意味著更長的代碼路徑、更復雜的跨文件依賴，以及對長期上下文與整體系統行為的理解。也就是說，能修 bug 并不意味著能交付一個完整的 feature。

為填補這一空白，中國科學院自動化研究所聯合華為聚焦Test-Driven的評測范式，提出了FeatureBench（Benchmarking Agentic Coding in End-to-End Development of Complex Features），并構建了一整套覆蓋數據構建、推理與評測的端到端基礎設施。數據、管線代碼與執行鏡像均已完整開源，旨在為評估與推動更強、更全面的 agentic coding 模型提供新的基準。

• 論文標題：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

「高精準度」

動態追蹤驅動的精準 feature 級代碼抽取

FeatureBench 的任務構造以真實代碼倉庫中的單元測試作為切入點。在成熟的軟件工程中，單元測試往往覆蓋完整的功能路徑或其關鍵組成部分，并隱式刻畫了 feature 的行為邊界與實現假設，因此天然適合作為定位 feature 行為范圍的自然入口。

不同于僅將單元測試作為結果評估手段的既有評測方式，FeatureBench 在任務構造階段便引入單元測試，用其反向定位并抽取與目標 feature 強相關的實現代碼，從而形成要求 Code Agent 補全 feature 本身的評測任務。具體而言，系統會首先在真實代碼倉庫中自動發現并篩選可執行的單元測試，將這些單元測試所測內容視為任務的目標 feature，作為后續的Fail-to-Pass（F2P）；與此同時，引入Pass-to-Pass（P2P）測試，用于約束任務構造過程中對非目標功能的潛在破壞。

在測試執行過程中，FeatureBench 利用動態追蹤技術，從 F2P 單元測試出發，捕獲執行測試路徑上的函數調用與對象依賴關系，并在對象粒度上對相關實現進行標注與分類。隨后，系統僅會抽取并移除既與 F2P 測試強相關、又不會影響 P2P 測試持續通過的實現代碼，其余部分保持不變。而被移除的代碼的接口，簽名等信息則通過規則自動從原聲代碼抽取，并在后續作為任務描述的一部分提供給模型。

這里需要強調的是，研究團隊在構造評測任務之初，便考慮到了 featrue 級實現任務接口模糊可能導致的任務不可解的問題——對于feature開發問題，若給 Agent 的任務描述本身是模糊的自然語言，則極有可能出現 Agent實現了邏輯等價的功能，但因為接口不匹配的問題而無法通過已經固定的單元測試的情況。

因此在每條任務中，FeatureBench 都提供了原生codebase的接口描述。所有接口簽名均通過規則自動抽取自原生 codebase。對于那些原生codebase缺少接口描述的任務，例如某些案例中的接口簽名下缺少詳細的docstring，FeatureBench 構建了一套自動化的工作流，讓大模型根據設定好的必要信息去合成詳細的接口描述。所有合成的接口描述均在后續進行了人工檢驗。

通過這一過程，FeatureBench 構造得到的是一類更接近真實開發場景的評測任務：模型需要在保持所有 P2P 通過的前提下，僅依據給定的接口描述與倉庫上下文信息，補全缺失的 feature 實現。

從單元測試出發，結合動態追蹤定位 feature 相關對象，抽取并移除實現，生成缺失版本代碼庫與 gold patch，并在沙盒環境中執行評測。

「強可執行性」

基于錯誤歷史回溯的任務構造機制

然而，在真實代碼庫中直接移除實現代碼，往往會引入非常多困難且復雜的工程問題。復雜系統中存在大量隱式依賴、初始化邏輯與運行時假設，一旦相關代碼被刪除，程序甚至可能在單元測試執行之前就已無法啟動，導致構造出的任務失去可執行性。

為解決這一問題，FeatureBench 首次在任務構造過程中引入了錯誤歷史回溯機制，將 “可執行性” 作為代碼抽取過程中的硬約束，用于保障代碼抽取過程的穩定性與可執行性。系統會在每一次抽取操作后記錄可回溯的中間狀態，并即時驗證任務的可執行性；一旦發現刪除某一部分代碼導致程序無法運行、測試環境失效、或 P2P 測試失敗，構造流程將自動回退至最近一次可正常執行的狀態，并據此重新調整后續的抽取策略。

通過這一機制，FeatureBench 能夠在無需人工干預的前提下，逐步收斂，穩定完成 feature 相關實現的抽取，確保每一個生成的評測實例均滿足 “可執行、可驗證” 的基本要求。這使得在真實代碼倉庫中大規模、持續的自動化任務構造成為可能。

「強驗證機制」

由目標對齊、驗證閉環與長鏈路復雜性構成的評測約束

在復雜 feature 的評測中，“更難” 往往并不意味著 “更可靠”。一些現有基準雖然引入了真實倉庫和較長代碼路徑，但評測結果仍然容易受到多種噪聲干擾：

一方面，評測目標通常依賴人工接口或自然語言描述，從而不同模型對實現目標形成不同理解，導致評測結果混合了能力差異與任務理解偏差。

另一方面，現有工作對于抽取出來的 feature 是否真正可驗證可執行往往并不透明：模型的失敗可能來自無關功能被破壞、依賴鏈被意外切斷，而非 feature 本身尚未實現，使得評測分數難以反映真實的 feature 開發能力。

此外，為了控制難度或保證可執行性，任務構造過程中常會對真實代碼路徑與依賴關系進行裁剪，使得看似復雜的任務在實際實現中并不包含真實系統中的長程依賴，進一步削弱了評測結果的指示意義。

針對以上這些問題，FeatureBench 并未通過額外設計規則或人工后處理篩選，而是將噪聲控制前移到任務構造階段。首次通過在真實代碼倉庫中施加三重約束，在保證任務復雜性的同時，使評測結果更穩定、可對齊，更具可解釋性。

1) 目標對齊（評測的公平性）：

FeatureBench 中所有頂層對象的接口簽名均通過規則自動抽取自原生 codebase，而非人工編寫或模型生成。由于接口定義直接來源于真實實現，這一設計顯著降低了由人為抽象或描述不一致所引入的實現歧義，使不同模型在評測時面對的是同一組、可精確定義的功能目標，而非依賴對任務意圖的主觀理解。

2) 驗證閉環（評測的完備性）：

FeatureBench 對每一個任務均施加嚴格的先驗與后驗驗證約束。即在代碼抽取前，所有 F2P/P2P 測試必須全部通過；在代碼抽取后，F2P 測試的通過率需低于預設閾值，而所有 P2P 測試必須保持全通過。這一雙階段驗證機制確保：被移除的實現確實構成目標 feature 的核心組成部分，同時任務難度來源于對 feature 實現本身的還原，而非由不受控的代碼破壞或偶然失效引入的偽難度。

3) 長鏈路復雜性（評測的長程性）：

FeatureBench 的任務構造遵循從單元測試 → 頂層對象 → 關聯對象與深層依賴的逐級展開過程。頂層接口僅刻畫了 feature 的外部行為，其背后往往對應大量跨文件、跨對象的實現細節與隱式依賴關系。

因此，FeatureBench 中的任務通常涉及更長的代碼路徑與更廣泛的修改范圍，對 agent 的長程推理能力、系統級理解能力以及對既有行為約束的整體把握提出了更高要求。

「高復雜度」

面向真實 feature 的大規模可執行評測實例

基于上述自動化數據構建管線，研究團隊在3天之內，系統性構建了3825個可執行的沙盒環境與候選任務實例。覆蓋24個真實世界、覆蓋不同應用場景且具有廣泛影響力的 GitHub 倉庫。所有實例均可直接運行，為后續篩選與評測提供了統一的可執行基礎。

在此基礎上，通過進一步施加統一的篩選約束，包括代碼時間范圍（2022 年 5 月之后）、測試覆蓋強度（測試點數量大于 10）以及 feature 抽取規模（抽取代碼行數超過 100 行），以確保任務在復雜度與代表性上的一致性。并經過人工 verified 驗證，最終確定了 FeatureBench 的正式評測數據集：

• FeatureBench Full：包含200條評測任務。單任務最多抽取4495行代碼，單任務最多涉及76份不同代碼文件。
• FeatureBench Lite：從 Full 集中進一步篩選30條任務，作為低成本評測子集，便于社區進行快速對比實驗與方法迭代。

整體來看，FeatureBench Full 中的任務在代碼規模、依賴廣度與測試約束強度上，均顯著高于典型的 bug-fixing benchmark，更貼近真實工程環境中 feature 級開發的復雜度分布。

FeatureBench 的復雜度顯著高于典型 bug-fixing benchmark，覆蓋跨文件、跨對象、長程依賴的真實 feature 實現。

「高區分度」

Feature 級任務評測重新拉開模型能力差距

研究團隊在 FeatureBench 上對多種主流 agent 框架（包括 OpenHands、Codex、Gemini-CLI、Claude Code 等）與多種模型配置（Opus 4.5、GPT-5.1-Codex、Gemini-3-Pro、Qwen-3-Coder-480B-A35B-Instruct、DeepSeek-V3.2 等）進行了系統評測。

評測結果顯示，在以 bug fixing 為核心的 SWE-Bench 場景中，主流高性能模型的整體表現已呈現出明顯的能力收斂趨勢：不同模型之間的 resolved rate 差距相對有限，難以進一步刻畫其在更復雜工程任務中的能力差異。

相比之下，當評測任務推進到 feature 級端到端開發時，模型與 agent 之間的差距被顯著放大。以 Claude Opus 為例，其在 SWE-Bench Verified 上的 resolved rate 已達到74.4%，而在 FeatureBench Full 上的解決率為11%；與此同時，其他模型在 FeatureBench 上的表現分化更為明顯，呈現出遠高于 SWE-Bench 場景的區分度。

這一現象表明，FeatureBench 并非簡單地提高了任務難度，而是通過引入跨文件、跨對象的長程依賴結構，以及嚴格的 P2P 約束，將評測焦點從局部缺陷修復能力推進到系統性 feature 交付能力。在這一設定下，即便在 bug fixing 任務中表現接近的模型，也會在 feature 級開發能力上呈現出明顯差異。

Bug Fixing 任務上前沿模型能力已收斂，但 Feature 級任務中仍體現出能力分化

Lite 數據集上的模型表現

「高易用性」

一行命令啟動 FeatureBench 的完整評測流程

為降低 FeatureBench 的復現與評測門檻，并支持學術界與工業界的實際使用，研究團隊同步開源了一套覆蓋推理、評測與數據構建的完整基礎設施。通過統一的運行環境與標準化配置，用戶無需繁瑣的環境搭建或手動拼裝流程，即可在本地或集群中一鍵啟動完整評測流程，從推理執行到結果統計實現端到端復現。在這一設計下，FeatureBench 不再只是一個靜態數據集，而是一個可長期演進、可持續擴展的評測平臺。

推理模塊（Inference）：多 Agent 框架的統一入口

FeatureBench 提供了統一的 agent 抽象接口，對主流代碼 agent 框架進行了標準化適配，包括 Claude Code、Codex、Gemini-CLI、OpenHands 以及 Mini-SWE-Agent 等。用戶只需進行最小化配置，即可將自定義 agent 接入現有管線，并在統一環境中完成大規模推理實驗。

該模塊同時內置了斷點續傳、并發執行、網絡代理與資源控制等機制，使長時間、多配置的推理任務能夠通過單一命令穩定運行，顯著降低實驗管理成本。

評測模塊（Evaluation）：執行即評測

以實際測試執行結果為唯一依據，對模型生成的代碼補丁進行自動化評測，嚴格統計 F2P/P2P 測試的通過情況，確保不同模型與 agent 的評測結果具有良好的可復現性與可比性。

數據構建管線（Data Pipeline）：任務可自動生成、持續擴展

完整開源了 FeatureBench 的原生任務生成流程，覆蓋從代碼倉庫拉取、單元測試發現與篩選、動態追蹤、頂層對象識別、P2P 測試選擇，到對象級代碼抽取與后驗驗證的全鏈路步驟。借助該管線，FeatureBench可以在無需人工干預的情況下持續、自動、可驗證地生成新的任務。

結語

FeatureBench 是 Code Agent 評測領域的一次關鍵突破：FeatureBench 系統性地將 agentic coding 的評測范式，從“短 patch、少文件、單 PR 的 bug fixing”，推進到了“跨文件、跨對象、長程依賴的真實 feature 開發”。更重要的是，FeatureBench 通過 test-driven 的自動化任務構造流程，在保證公平性與完備性的同時，大幅提升任務復雜度，并為 benchmark 的持續擴展與防數據污染提供了一條可行路徑。

同時，FeatureBench作為一套面向真實軟件工程場景的可執行數據生成與驗證基礎設施，將為后續 Agent 訓練與強化學習提供數據支持。