編碼代理實際需要什麼上下文才能行動？
一項新研究顯示，編碼代理在編輯代碼時真正需要的上下文極少：信號只存在於被編輯的代碼本身，自然語言摘要幾乎無法替代源代碼回答行為問題，周圍上下文（如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上報告的所有小效果設定了一個噪聲底線，包括本研究自身的發現。
研究人員發佈了他們的工具，包括經過驗證的環境、每個實例中參考編輯可從任何上下文表達的證明、確定性補丁構建，以及預註冊的假設及發佈的零假設。這些成果將有助於更準確地評估編碼代理的能力，並優化上下文使用，降低推理成本。