新智元報道

編輯：LRST

【新智元導(dǎo)讀】AI編程模型在SWE-bench上表現(xiàn)優(yōu)異，但僅能處理單倉庫小修小補(bǔ)。BeyondSWE提出全新評測標(biāo)準(zhǔn)，考驗AI跨倉庫檢索、領(lǐng)域知識理解、依賴升級和從零構(gòu)建系統(tǒng)的能力，結(jié)果發(fā)現(xiàn)頂尖模型通過率暴跌至45%以下，暴露其缺乏真實工程思維。

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

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

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

這意味著什么？

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

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

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

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

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

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

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

項目主頁：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條）

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

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

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

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

讓一個后端工程師去修量子計算庫的Bug，但他從沒學(xué)過量子力學(xué)——這就是當(dāng)前Code Agent在領(lǐng)域?qū)I(yè)任務(wù)上面臨的窘境。

該任務(wù)與來自11個學(xué)科方向的領(lǐng)域?qū)＜液献鳂?gòu)建，覆蓋量子物理（QuTiP）、生物信息學(xué)（Biotite）、凸優(yōu)化（cvxpy）、天文學(xué)（astroplan）、等離子體物理（PlasmaPy）等高門檻領(lǐng)域。

每道題經(jīng)過三位領(lǐng)域?qū)＜要毩徍?，只有同時滿足環(huán)境正確性、領(lǐng)域知識必要性和解法非平凡性的樣例才能入選。Bug的正確修復(fù)不僅需要讀懂代碼，更需要理解背后的物理公式、數(shù)學(xué)概念或生物學(xué)原理——寫對了語法，算錯了物理，照樣零分。

DepMigrate：整個倉庫的系統(tǒng)性改造（178條）

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

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

Doc2Repo：從白紙到系統(tǒng)（50條）

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

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

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

數(shù)據(jù)質(zhì)量：多輪校驗保底線

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

在數(shù)據(jù)構(gòu)建上，每條樣例經(jīng)過三個階段的嚴(yán)格篩選：候選爬取、基于Agent的自動化Docker環(huán)境構(gòu)建、以及嚴(yán)格的環(huán)境一致性驗證（每條樣例5次獨立運行，P2P和F2P測試結(jié)果必須完全一致）。

此外，3位領(lǐng)域?qū)＜摇?位資深軟件工程師和5位專注Code Agent研究的博士生參與了全流程的人工校驗。

實驗結(jié)果

近乎腰斬

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

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

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

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

DomainFix是最硬的骨頭：幾乎沒有模型突破36%。領(lǐng)域?qū)I(yè)知識不是靠多訓(xùn)練幾輪代碼數(shù)據(jù)就能補(bǔ)上的，它構(gòu)成了一道真實的認(rèn)知壁壘。

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

SearchSWE：聯(lián)網(wǎng)搜索是銀彈嗎？

一個自然的追問：既然Agent內(nèi)部知識不夠用，給它聯(lián)網(wǎng)搜索能力，情況會好多少？

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

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

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

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

實驗給出了一個微妙而真實的答案——既不是「聯(lián)網(wǎng)萬能」，也不是「搜索無用」。

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

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

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

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

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

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

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

核心啟示

Deep Research for Coding

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

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

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

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

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

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

參考資料：

http://arxiv.org/abs/2603.03194