在现代编码代理中，代理可以在其上下文窗口中持有整个代码库。然而，大多数的读取是浪费的。关键问题并非代理能够使用多少上下文，而是它实际上需要多少上下文。本文在代理必须编辑代码的关键时刻研究了这一问题。
我们将工作地点的定位与实际操作分开，固定定位条件，变化代码的表示方式，并根据在SWE-bench Verified上的真实问题解决情况对上下文进行评分。结果表明，所需上下文显著最小。信号主要存在于被编辑的代码本身：自然语言摘要几乎无法回答源代码所能解答的行为问题（$4/45$ vs. $27/45$，持出库，独立评审），而差距来源于表示方式，而非摘要生成器——前沿模型的摘要效果与3B模型一样糟糕。
此外，周围的上下文也几乎无关紧要：在Verified的每个多文件实例中，使用UML骨架和签名来渲染文件的其余部分，解决的问题数量与直接删除该部分无异（$N=70$，精确的McNemar $p=0.75$）。这正是我们注册的假设，但结果却未能如预期。
压缩上下文的表现与完整文件相当，仅需三分之一的标记：解决一个问题的上下文成本为$19$K标记，而非$94$K。我们的研究工具也发现了一个值得注意的结论：温度为0的API推理在每个实例的结果中翻转了约$9\text{perthousand}$的结果，这成为了该基准下每个小效应的噪声底线，包括我们的研究。我们发布了该工具——黄金验证的环境、每个实例的证明，所有参考编辑均可从每个臂的上下文中表达，确定性补丁构建，以及我们发布的零假设的预注册假设。
博主点评： 本文通过实证研究揭示了编码代理在编辑代码时所需的上下文远低于预期，强调了代码本身的信号远比上下文更为重要。这一发现为未来的编码工具开发提供了重要的指导，可能会改变我们对上下文处理的传统理解。