新智元報道

編輯：LRST

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

在自動化軟件工程（Automated Software Engineering）領域，以SWE-bench為代表的評測基準已成為衡量大語言模型代碼能力的事實標準，SWE-bench、SWE-bench Pro、Multi-SWE-bench、SWE-PolyBench等代碼庫級評測推動了代碼智能體快速進步。

然而，這類評測仍以最終修復成功率為核心，主要關注端到端成功率（End-to-End Success Rate），即Agent是否能夠生成通過測試用例的補丁。

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

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

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

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

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

項目主頁：https://contextbench.github.io/

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

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

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

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

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

很多最強大模型傾向「多撈少漏」，導致噪聲偏多；

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

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

「黃金上下文」由人類專家認證

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

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

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

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

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

評測對象

頂尖模型與主流Agent

研究團隊使用CONTEXTBENCH評測了當前最強的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

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

代碼Agent的「苦澀教訓」

實驗結(jié)果揭示了當前LLM和Agent在代碼檢索上的三大痛點：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

ContextBench的發(fā)布，標志著代碼Agent的評測進入了「過程可解釋」的新階段。

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

參考資料：

https://arxiv.org/abs/2602.05892