AI取代程序員還遠！新基準BeyondSWE：頂尖模型通過率暴跌至45%

新智元報道

編輯：LRST

【新智元導讀】AI編程模型在SWE-bench上表現優異，但僅能處理單倉庫小修小補。BeyondSWE提出全新評測標準，考驗AI跨倉庫檢索、領域知識理解、依賴升級和從零構建系統的能力，結果發現頂尖模型通過率暴跌至45%以下，暴露其缺乏真實工程思維。

過去兩年，SWE-bench幾乎是衡量Code Agent能力的唯一標尺。

從最初不到30%的解決率，到如今Gemini 3 Pro、GPT-5.2等前沿模型突破80%，社區似乎已經形成了一個共識：AI正在快速逼近人類程序員的水平。

但如果回頭審視這張「考卷」本身，一些數字令人不安：SWE-bench Verified僅覆蓋12個倉庫，每道題平均只需修改1.3個文件、11.6行代碼，全部答案都能在倉庫內部找到。即便是后續的SWE-bench Pro和SWE-bench Live，雖然擴展了倉庫數量和修改規模，但在「知識來源」這個維度上仍然沒有走出單一倉庫的邊界。

這意味著什么？

現有benchmark對Code Agent的考察，相當于讓一個學生在開卷考試中做填空題——答案就在手邊，只需定位和填寫。而真實軟件工程的全貌遠不止于此。

近日，OpenAI也宣布放棄將SWE-bench Verified作為內部評測標準，直言其已難以區分前沿模型的能力差異。當出卷者都不再信任自己的試卷時，是時候換一張了。

衡量一個Code Agent是否「真的會寫代碼」，可以從兩個維度來看：

解決范圍（Resolution Scope）：需要改動多大的代碼范圍？是改一個函數，還是改造整個倉庫？

知識來源（Knowledge Scope）：需要從哪里獲取信息？倉庫內部就夠了，還是需要外部知識？

將這兩把尺子擺在現有benchmark面前，差距一目了然——所有SWE-bench變體都集中在同一個象限：局部函數級別的解決范圍，倉庫內部的知識來源。真實軟件工程中最常見、最棘手的那些場景，恰恰是評測的空白地帶。

中國人民大學高瓴人工智能學院提出BeyondSWE，首次在這兩個維度上同時突破，通過四類任務系統性地覆蓋了真實軟件工程的多個象限。

項目主頁：https://aweai-team.github.io/BeyondSWE/

論文鏈接：http://arxiv.org/abs/2603.03194

代碼鏈接：https://github.com/AweAI-Team/BeyondSWE

Scaffold鏈接：https://github.com/AweAI-Team/AweAgent

Leadboarder鏈接：https://aweai-team.github.io/BeyondSWE_leaderboard/

CrossRepo：答案不在這個倉庫里（200條）

實際開發中，大量Bug的根因或修復思路并不在當前倉庫內——開發者經常需要去翻閱上游倉庫的issue、Stack Overflow的討論帖、甚至去讀另一個項目的源碼才能定位問題。

BeyondSWE從3000個包含外部鏈接的GitHub PR中層層篩選，最終得到來自67個倉庫、平均包含1.3個外部鏈接的200條高質量樣例。

Agent仍然只在單一倉庫中修改代碼，但修復所需的關鍵信息存在于外部。這考察的不是「多倉庫協同開發」的能力，而是對開源生態的廣泛認知——這種認知既可以來自模型自身對生態的深度理解，也可以通過搜索外部資源來獲取。

DomainFix：代碼之外的知識壁壘（72條）

讓一個后端工程師去修量子計算庫的Bug，但他從沒學過量子力學——這就是當前Code Agent在領域專業任務上面臨的窘境。

該任務與來自11個學科方向的領域專家合作構建，覆蓋量子物理（QuTiP）、生物信息學（Biotite）、凸優化（cvxpy）、天文學（astroplan）、等離子體物理（PlasmaPy）等高門檻領域。

每道題經過三位領域專家獨立審核，只有同時滿足環境正確性、領域知識必要性和解法非平凡性的樣例才能入選。Bug的正確修復不僅需要讀懂代碼，更需要理解背后的物理公式、數學概念或生物學原理——寫對了語法，算錯了物理，照樣零分。

DepMigrate：整個倉庫的系統性改造（178條）

NumPy 1.x升級到2.0、Pydantic v1到v2、Django 4.x到5.0——現代軟件生態中，破壞性的依賴升級不是小概率事件，而是每個項目維護者都會反復面對的日常。這類任務的改動量和思維復雜度遠超普通Bug修復，需要Agent精確掌握新舊API的差異，并在可能橫跨數十個文件的代碼庫中完成一致、正確的全局遷移。

BeyondSWE識別了23個包含重大版本更新的核心依賴包，從7000個候選項中篩選出178條樣例，覆蓋120個倉庫。每個樣例的Docker環境已配置為依賴更新后的版本，而倉庫代碼仍停留在升級前——Agent面對的正是一個"依賴已升級、代碼未適配"的真實困境。

Doc2Repo：從白紙到系統（50條）

真實的軟件工程往往不是從Bug開始，而是從一份設計文檔或PRD開始。Agent面對的不再是「修什么」，而是「造什么」——架構怎么設計？模塊怎么拆分？接口怎么實現？這是一種與Bug修復截然不同的工程能力。

50條樣例全部收集自2025年新建的高質量倉庫（持續活躍、至少3位貢獻者、Star超過20），代碼量從1000行到超過16000行不等，近四成樣例超過4000行。

為防止Agent「背出」已有倉庫的代碼，評測中刻意隱去了倉庫名稱和目錄結構——Agent只拿到一份純文字的功能說明文檔和一個空目錄，一切從零開始。

數據質量：多輪校驗保底線

BeyondSWE總計涵蓋246個真實GitHub倉庫、500條樣例，平均每題涉及5.6個文件、209.9行代碼。

在數據構建上，每條樣例經過三個階段的嚴格篩選：候選爬取、基于Agent的自動化Docker環境構建、以及嚴格的環境一致性驗證（每條樣例5次獨立運行，P2P和F2P測試結果必須完全一致）。

此外，3位領域專家、5位資深軟件工程師和5位專注Code Agent研究的博士生參與了全流程的人工校驗。

實驗結果

近乎腰斬

基于OpenHands框架，BeyondSWE對Gemini 3 Pro、GPT-5.2、DeepSeek-V3.2、GLM-4.7、Kimi-K2、Seed-Coder等一批前沿模型進行了全面測試。核心發現干脆利落：

沒有任何模型的整體表現突破45%。從SWE-bench的80%到BeyondSWE的45%，差距不是小幅波動，而是近乎腰斬。

深入各任務來看，失敗模式各不相同：

沒有全能選手：Seed-Coder領跑CrossRepo（44.72%），DeepSeek-V3.2拿下Doc2Repo最高通過率（54.99%），Gemini 3 Pro在DepMigrate最強（41.81%）。沒有一個模型能在所有維度上同時稱王，四類任務考察的確實是不同的能力。

DomainFix是最硬的骨頭：幾乎沒有模型突破36%。領域專業知識不是靠多訓練幾輪代碼數據就能補上的，它構成了一道真實的認知壁壘。

Doc2Repo藏著「虛高陷阱」：通過率看似有45-55%，但能讓所有測試100%通過的完整倉庫寥寥無幾。Agent善于實現零散的功能模塊，卻難以架構出一個連貫自洽的完整系統——兩者之間有本質鴻溝。

SearchSWE：聯網搜索是銀彈嗎？

一個自然的追問：既然Agent內部知識不夠用，給它聯網搜索能力，情況會好多少？

該工作同期提出SearchSWE框架來系統研究這個問題。

SearchSWE在OpenHands基礎上為Agent引入兩個工具：SearchTool（搜索引擎查詢）和BrowserTool（網頁內容瀏覽與理解）。Agent可以在編碼過程中自主決定何時跳出本地環境，去查閱文檔、翻閱論壇或檢索領域知識——就像真實開發者隨手打開瀏覽器一樣。

為防止Agent直接搜到目標倉庫的現成答案，SearchSWE設計了雙重攔截機制：在搜索結果側過濾所有指向目標倉庫的URL，在執行命令側攔截任何直接訪問目標倉庫的操作。Docker環境中也已清除目標commit之后的全部git歷史。Agent別無捷徑，只能靠真正的推理來解題。

搜索有用，但融合是真正的難點

實驗給出了一個微妙而真實的答案——既不是「聯網萬能」，也不是「搜索無用」。

9個模型中，6個加入搜索后整體提升，3個反而下降。搜索對知識密集型任務幫助最為直接：Gemini 3 Pro在DomainFix提升+7.5%，外部文檔確實彌補了內部知識的不足。但最反直覺的發現在于搜索頻率與效果的關系：

Gemini 3 Pro平均每任務只調用搜索0.8-1.1次，卻拿下了最好的整體增益（+2.0%）；DeepSeek-V3.2平均搜索4.2-5.4次，整體反而微降0.2%。搜索的價值不在于頻率，而在于「知道什么時候該搜，搜到了怎么用」的精準判斷。

三類失敗模式：為什么搜索+編碼這么難融合

對Agent搜索行為的深入追蹤，揭示了三類根本性的障礙：

信息景觀的鴻溝。搜索引擎經過幾十年優化，擅長檢索人類可讀的高層文檔。但代碼任務所需的關鍵知識，往往深埋在源文件、commit diff和issue評論的只言片語中——搜索引擎對這類「技術原始制品」的索引能力天然不足。Agent拿到的是"概念上正確"的文檔摘要，但它真正需要的是"邏輯上精確"的源碼細節。

版本時間錯位。搜索引擎天然偏向展示最新版本的文檔，而SWE任務的本地環境往往鎖定在某個歷史版本。更麻煩的是，LLM自身的參數知識也傾向于最新的代碼模式。兩者疊加，Agent可能會「幻想」出一個不存在的新版本環境，然后用最新的API寫法去改老代碼——搜索不僅沒有糾錯，反而加速了錯誤的落地。

語義漂移與噪聲污染。技術術語存在大量歧義。當Agent搜索一個小眾庫的專有概念時，搜索引擎往往返回來自完全不同領域的高權重結果。Agent缺乏有效的噪聲過濾能力，會將"看起來合理"但完全不相關的信息納入推理鏈路，導致修復方案偏離正軌。

核心啟示

Deep Research for Coding

這些實驗共同指向一個清醒的判斷：search能力和coding能力各自已經相當成熟，但兩者的有效融合不會自動涌現。

過去幾年，Deep Research（信息檢索與知識整合）和Code Agent（代碼生成與倉庫級推理）各自取得了長足進步，但它們幾乎沿著兩條平行軌道獨立發展。

當真實的軟件工程天然要求兩種能力的深度融合時——API會更新、依賴會變化、領域知識永遠學不完——這種「各自為戰」的發展路徑就暴露了其根本局限。

Deep Research for Coding——讓Code Agent真正具備在編碼過程中流暢穿插搜索與推理的能力——是下一階段進化的關鍵方向。

BeyondSWE提供了一個在「解決范圍」和「知識來源」兩個維度上都更全面的評測框架，SearchSWE則為系統研究搜索與編程的融合提供了實驗基礎。

兩者共同的目標，是推動Code Agent從單一倉庫的刷題者，真正走向能在開放世界中獨當一面的工程智能體。

參考資料：

http://arxiv.org/abs/2603.03194