编码代理实际上需要在什么背景下采取行动？

arXiv:2607.09691v1 公告类型：新 摘要：现代编码代理可以在其上下文窗口中保存整个存储库。它的大部分阅读都被浪费了——有趣的问题不是代理可以使用多少上下文，而是它实际上\emph{需要}什么。我们目前研究这个最重要的问题：代理何时必须\emph{编辑}代码。将 \emph{finding} 工作站点与 \emph{acting} 分开，我们用预言机固定本地化，仅改变代码的表示方式，并根据 SWE-bench Verified 上的实际问题解决方案对上下文进行评分。答案是微不足道的。信号存在于正在编辑的代码本身中：它的自然语言摘要几乎没有回答源回答的任何行为问题（$4/45$ vs.\ $27/45$，保留存储库，独立法官），并且差距属于表示，而不是摘要器 - 前沿模型的摘要得分与 3B 模型的摘要得分一样差。周围的上下文也不重要：在 Verified 中的每个多文件实例中，在任何数据之前冻结的协议下，将文件的剩余部分呈现为 UML 骨架和签名，与直接删除剩余部分（$N{=}70$，确切的 McNemar $p{=}0.75$）相比，解决的问题并不多。这是我们注册的假设，但它失败了。与此同时，压缩上下文在三分之一的令牌处匹配整个文件：解决问题需要花费 $19$K 上下文令牌，而不是 $94$K。该仪器还得出了该领域应该保留的发现：温度-0 API 推断在字节相同的运行之间翻转 ${\sim}9\%$ 的每个实例结果。这是该基准测试中报告的每一个小影响下的本底噪声，包括我们的基准测试。我们发布了该工具——经过黄金验证的环境、每个实例的证明（每个参考编辑都可以从每个手臂的上下文中表达）、确定性补丁构建以及我们发布其零值的预先注册假设。