編碼代理實際需要什麼上下文才能行動？
一項新研究顯示，編碼代理在編輯程式碼時真正需要的上下文極少：訊號只存在於被編輯的程式碼本身，自然語言摘要幾乎無法替代原始碼回答行為問題，周圍上下文（如UML骨架）與刪除它效果無異，而壓縮上下文（如類別簽名）能以三分之一token達到完整檔案的效果。此外，溫度-0 API推理在相同輸入下約有9%的結果翻轉，構成了SWE-bench上所有小效果檢測的噪聲底線。研究團隊釋出了包含驗證環境、確定性補丁和預註冊假設的工具。
現代編碼代理能夠將整個程式碼倉庫放入上下文視窗，但大部分閱讀都是浪費的。一項由Brian Sam-Bodden提交至arXiv的新研究（論文編號2607.09691）探討了代理在編輯程式碼時實際需要多少上下文。研究人員將“定位”和“行動”分開，透過固定在定位部分（使用oracle），僅改變程式碼的表示方式，在SWE-bench Verified上測試上下文對問題解決的影響。
結果令人驚訝地簡單：真正有用的訊號存在於被編輯的程式碼本身。自然語言摘要幾乎無法回答原始碼能夠回答的行為問題（4/45 vs 27/45，使用獨立裁判），而且這一差距來自表示方式本身，而非摘要模型——前沿模型和3B模型的摘要表現一樣差。周圍上下文也幾乎沒有影響：在所有多檔案例項中，將檔案其餘部分渲染為UML骨架和簽名，與完全刪除這些部分相比，解決問題數量沒有顯著差異（N=70，精確McNemar p=0.75）。這一預先註冊的假設被拒絕。
與此同時，壓縮上下文（如類別簽名和介面）能以三分之一的token達到與完整檔案相同的效果：每個已解決問題平均消耗19K上下文token，而非94K。研究還發現，溫度-0 API推理在相同輸入下會翻轉約9%的結果，這為SWE-bench上報告的所有小效果設定了一個噪聲底線，包括本研究自身的發現。
研究人員釋出了他們的工具，包括經過驗證的環境、每個例項中參考編輯可從任何上下文表達的證明、確定性補丁構建，以及預註冊的假設及釋出的零假設。這些成果將有助於更準確地評估編碼代理的能力，並最佳化上下文使用，降低推理成本。