代碼Agent的苦澀教訓(xùn)！首次拆解上下文檢索，直指自動(dòng)化軟件瓶頸

新智元報(bào)道

編輯：LRST

【新智元導(dǎo)讀】ContextBench首次從「過程」評(píng)測(cè)代碼智能體，不再只看是否修好代碼，而是追蹤它是否精準(zhǔn)找到并真正使用了關(guān)鍵代碼片段，揭示了當(dāng)前模型多讀少用、被關(guān)鍵詞誤導(dǎo)、復(fù)雜架構(gòu)無效等深層問題，推動(dòng)AI助手向更可靠、可解釋的方向進(jìn)化。

在自動(dòng)化軟件工程（Automated Software Engineering）領(lǐng)域，以SWE-bench為代表的評(píng)測(cè)基準(zhǔn)已成為衡量大語言模型代碼能力的事實(shí)標(biāo)準(zhǔn)，SWE-bench、SWE-bench Pro、Multi-SWE-bench、SWE-PolyBench等代碼庫級(jí)評(píng)測(cè)推動(dòng)了代碼智能體快速進(jìn)步。

然而，這類評(píng)測(cè)仍以最終修復(fù)成功率為核心，主要關(guān)注端到端成功率（End-to-End Success Rate），即Agent是否能夠生成通過測(cè)試用例的補(bǔ)丁。

這一評(píng)價(jià)方式隱含著一個(gè)關(guān)鍵缺陷：它僅觀察最終結(jié)果，卻無法刻畫模型的中間推理過程，難以量化「過程中是否檢索到解決問題必需的上下文、是否真正把它用進(jìn)補(bǔ)丁」

換言之，我們無法判斷Agent是真正理解了代碼庫的語義結(jié)構(gòu)，還是通過試探式修改或偶然匹配測(cè)試條件而得到正確結(jié)果。

因此，現(xiàn)有評(píng)測(cè)更接近于「結(jié)果可驗(yàn)證」，而非「過程可解釋」。

為了填補(bǔ)這一空白，來自南京大學(xué)、倫敦大學(xué)學(xué)院（UCL）等機(jī)構(gòu)的研究團(tuán)隊(duì)推出了首個(gè)面向過程的代碼上下文檢索評(píng)測(cè)基準(zhǔn)ContextBench，基于1,136個(gè)真實(shí)問題修復(fù)任務(wù)（66個(gè)代碼庫、8種語言），由專家在文件/代碼塊/行號(hào)三個(gè)粒度標(biāo)注「關(guān)鍵上下文」，并自動(dòng)追蹤智能體的檢索與閱讀軌跡進(jìn)行結(jié)構(gòu)化對(duì)齊，用召回率、準(zhǔn)確率、F1、效率與「使用衰減」等指標(biāo)，把「找上下文」和「用上下文」拆開評(píng)估。

論文鏈接：https://arxiv.org/abs/2602.05892

項(xiàng)目主頁：https://contextbench.github.io/

代碼倉庫：https://github.com/EuniAI/ContextBench

數(shù)據(jù)集：https://huggingface.co/datasets/Contextbench/ContextBench

ContextBench并非直接構(gòu)造新的編程任務(wù)，而是從真實(shí)開源倉庫的 Issue 與補(bǔ)丁出發(fā)，逆向追蹤問題修復(fù)過程中實(shí)際依賴的代碼片段，并將其組織為評(píng)測(cè)用的「黃金上下文」。評(píng)測(cè)的核心由「是否修復(fù)成功」轉(zhuǎn)變?yōu)椤甘欠穸ㄎ坏秸_代碼」

ContextBench不再只問「修好了嗎？」，而是追問：「在解決問題時(shí)，Agent究竟檢索并使用了哪些代碼上下文？」

研究人員觀察到幾條典型現(xiàn)象：復(fù)雜的智能體腳手架不一定帶來更好的上下文檢索質(zhì)量，反而像一種「苦澀的教訓(xùn)」(The Bitter Lesson)式的過度工程化；

很多最強(qiáng)大模型傾向「多撈少漏」，導(dǎo)致噪聲偏多；

「檢索到」不等于「用到了」，看過關(guān)鍵代碼也可能沒體現(xiàn)在最終補(bǔ)丁里；更均衡的檢索策略往往在成功率與成本之間更劃算。

ContextBench希望為代碼智能體提供可觀測(cè)、可度量、可優(yōu)化的過程評(píng)測(cè)視角，幫助社區(qū)更精準(zhǔn)地改進(jìn)檢索與推理鏈路。

「黃金上下文」由人類專家認(rèn)證

為了構(gòu)建這一基準(zhǔn)，研究團(tuán)隊(duì)并沒有依賴自動(dòng)化生成，而是采用了一套嚴(yán)謹(jǐn)?shù)摹溉藱C(jī)回環(huán)」（Human-in-the-loop）標(biāo)注流程。

大規(guī)模覆蓋：包含來自66個(gè)真實(shí)代碼倉庫的 1,136個(gè) 問題解決任務(wù)，覆蓋 Python、Java、C++、Go、Rust、JavaScript、TypeScript、C 等 8種主流編程語言。

專家級(jí)標(biāo)注：每一條數(shù)據(jù)都配有由專家開發(fā)者標(biāo)注的「黃金上下文」（Gold Contexts）。這些上下文并非「相關(guān)代碼」的簡(jiǎn)單集合，而是問題修復(fù)過程中不可或缺的最小代碼依賴集。研究者通過分析真實(shí)補(bǔ)丁，沿函數(shù)調(diào)用、類引用與變量依賴關(guān)系逐步回溯，最終確定必須閱讀的代碼片段。

一個(gè)真實(shí)倉庫中的依賴鏈條：若未閱讀箭頭所連接的函數(shù)與類，即使模型生成補(bǔ)丁，也難以保證語義正確

細(xì)粒度追蹤：評(píng)測(cè)框架能夠記錄Agent的每一步操作軌跡，并在文件（File）、代碼塊（Block）、行（Line）三個(gè)層級(jí)上計(jì)算檢索的精確率（Precision）和召回率（Recall）。這意味著模型的行為可以被量化為「定位能力」：不僅判斷是否訪問了關(guān)鍵文件，還能判斷是否精確定位到關(guān)鍵函數(shù)乃至關(guān)鍵語句。

評(píng)測(cè)對(duì)象

頂尖模型與主流Agent

研究團(tuán)隊(duì)使用CONTEXTBENCH評(píng)測(cè)了當(dāng)前最強(qiáng)的4款LLM和5種主流代碼Agent框架：

• LLM：GPT-5, Claude 4.5 Sonnet, Gemini 2.5 Pro, Devstral 2

• Agent框架：SWE-agent, OpenHands, Agentless, Prometheus, mini-SWE-agent

各個(gè)LLM的表現(xiàn)情況如圖所示，該排行榜將在主頁上持續(xù)更新

代碼Agent的「苦澀教訓(xùn)」

實(shí)驗(yàn)結(jié)果揭示了當(dāng)前LLM和Agent在代碼檢索上的三大痛點(diǎn)：

1. 架構(gòu)越復(fù)雜，效果越好？未必！

通過分析排行榜數(shù)據(jù)可以發(fā)現(xiàn)，復(fù)雜的 Agent 架構(gòu)在上下文檢索性能上帶來的增益微乎其微。

實(shí)驗(yàn)顯示，復(fù)雜的檢索腳手架——比如基于圖的檢索或復(fù)雜的向量庫——在檢索成功率上，甚至有時(shí)還不如簡(jiǎn)單的基準(zhǔn)方案（如 mini-SWE-agent）。這再次印證了 AI 領(lǐng)域的「苦澀教訓(xùn)」：復(fù)雜的工程堆砌，往往不如底層模型能力的提升。

不同Agent框架在檢索F1分?jǐn)?shù)上的差異遠(yuǎn)小于預(yù)期，復(fù)雜檢索結(jié)構(gòu)并未帶來顯著收益

對(duì)比不同Agent架構(gòu)在不同層級(jí)檢索上的成功率，數(shù)據(jù)表明復(fù)雜架構(gòu)并未拉開顯著差距

2. 寧濫勿缺：模型偏愛高召回率

所有的LLM在檢索策略上都表現(xiàn)出驚人的一致性：重召回，輕精確。模型傾向于閱讀大量的代碼以確保覆蓋相關(guān)信息，但這引入了大量的噪音。例如，GPT-5雖然召回率很高，但引入的無關(guān)代碼嚴(yán)重拖累了精確率。這也解釋了為什么更高昂的Token消耗并沒有線性轉(zhuǎn)化為解決率的提升。

從精確率與召回率的對(duì)比可以看到，多數(shù)模型傾向于擴(kuò)大檢索范圍以避免遺漏，但代價(jià)是大量無關(guān)上下文被引入，從而干擾后續(xù)推理

數(shù)據(jù)展示了各模型Recall極高、Precision極低的「偏科」現(xiàn)狀，精確率普遍偏低

3. 策略分化：GPT-5「大口吞」 vs Devstral 2「小步跑」

不同模型在檢索策略上展現(xiàn)出了截然不同的性格 。

• GPT-5 傾向于「少次多量」，平均只需 5.87 輪檢索，但每一步會(huì)閱讀高達(dá) 119 行代碼，試圖一次性獲取大量信息 。

• Devstral 2 則采取「多次少量」的策略，平均需要進(jìn)行 22 輪檢索，但每一步僅讀取約 12 行代碼 。

• 這種高頻交互導(dǎo)致 Devstral 2 的Token消耗激增，成為成本最高的模型

4. 致命的「關(guān)鍵詞陷阱」：Agent 容易陷入局部視野

通過對(duì)失敗案例的分析，研究者發(fā)現(xiàn)Agent極易被表面關(guān)鍵詞誤導(dǎo)，從而陷入「隧道視野」（Tunnel Vision）。

案例：在修復(fù)一個(gè)涉及Django多數(shù)據(jù)庫（MySQL/SQLite）的 Bug 時(shí)，OpenHands因?yàn)樗阉鹘Y(jié)果中大量出現(xiàn)MySQL相關(guān)關(guān)鍵詞，就固執(zhí)地將排查范圍鎖定在 MySQL 模塊 。

后果：盡管Agent擁有查看整個(gè)代碼庫的權(quán)限，但關(guān)鍵詞的干擾使其完全忽略了真正出問題的SQLite模塊，導(dǎo)致結(jié)構(gòu)性的檢索失敗 。

5. 「讀了」不等于「用了」

這是一個(gè)更為致命的問題：檢索與利用之間存在巨大鴻溝。軌跡分析顯示，Agent經(jīng)常在中間步驟成功檢索到了「黃金上下文」，但在最終生成補(bǔ)丁時(shí)，卻未能有效利用這些信息，導(dǎo)致修復(fù)失敗。

這種「過目即忘」的現(xiàn)象（Information Consolidation Bottleneck）是當(dāng)前Agent推理能力的一大短板。軌跡分析進(jìn)一步表明，模型在中間步驟能夠訪問到黃金上下文，但在最終生成補(bǔ)丁時(shí)未能有效利用這些信息，即「檢索成功但推理失敗」。

總結(jié)

ContextBench的發(fā)布，標(biāo)志著代碼Agent的評(píng)測(cè)進(jìn)入了「過程可解釋」的新階段。

該工作表明，端到端成功率不足以刻畫代碼Agent的真實(shí)能力。未來的代碼Agent不僅需要具備代碼生成能力，更需要具備穩(wěn)定且精確的代碼定位能力。只有當(dāng)Agent能夠精準(zhǔn)地定位、檢索并有效利用代碼上下文時(shí)，它們才能真正成為開發(fā)者值得信賴的助手。

參考資料：

https://arxiv.org/abs/2602.05892