编码代理实际需要什么上下文才能行动？
一项新研究显示，编码代理在编辑代码时真正需要的上下文极少：信号只存在于被编辑的代码本身，自然语言摘要几乎无法替代源代码回答行为问题，周围上下文（如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上报告的所有小效果设定了一个噪声底线，包括本研究自身的发现。
研究人员发布了他们的工具，包括经过验证的环境、每个实例中参考编辑可从任何上下文表达的证明、确定性补丁构建，以及预注册的假设及发布的零假设。这些成果将有助于更准确地评估编码代理的能力，并优化上下文使用，降低推理成本。