编码智能体究竟需要多少上下文？新研究揭示答案“出乎意料的少”
核心发现：上下文并非越多越好
现代编码 AI 智能体（coding agent）可以轻松将整个代码仓库塞进上下文窗口，但一篇最新 arXiv 预印本研究指出：绝大多数阅读是浪费的。真正关键的问题不是“智能体能处理多少上下文”，而是“它实际需要多少”。
该研究将智能体的工作拆解为两个阶段：定位（finding） 和 执行（acting）。研究者通过“oracle”固定定位环节，仅改变代码的表示方式，并在 SWE-bench Verified 基准上评估真实问题修复效果。结果令人惊讶：智能体真正需要的上下文非常有限。
核心实验与数据
1. 自然语言摘要几乎无用
当把待编辑代码替换为自然语言摘要时，智能体的表现从源文件的 27/45 骤降至 4/45（独立评估，保留仓库）。这说明摘要无法回答源代码中包含的行为性问题。更关键的是，这一差距源于表示形式本身，而非摘要质量：前沿模型生成的摘要与 3B 小模型的摘要得分几乎一样差。
2. 周围上下文几乎不影响结果
在多文件实例中，将文件剩余部分渲染为 UML 骨架和签名，与直接删除剩余部分相比，解决问题的数量没有显著差异（N=70，精确 McNemar 检验 p=0.75）。研究者原本假设上下文压缩会有效，但这一注册假设（registered hypothesis）被证伪。
3. 压缩上下文可大幅降低 token 消耗
好消息是，使用压缩上下文表示（如方法签名和关键结构）可以在 1/3 token 量 下达到与完整文件相同的效果：每个已解决问题平均消耗 19K 上下文 token，而非完整文件的 94K。
不可忽视的噪声：温度 0 也不稳定
研究还发现一个对整个领域有警示意义的结论：即使在 temperature=0 的 API 推理中，约 9% 的实例结果会在字节相同的两次运行之间翻转。这意味着所有在 SWE-bench 上报告的小效应都面临一个噪声基底，本研究的结果也不例外。
研究工具与开源
研究者发布了完整的实验工具，包括金标准验证环境、每个实例的参考编辑可表达性证明、确定性补丁构建方法，以及预注册假设及其零假设。这为后续研究提供了可复现的基础。
对 AI 编码实践的启示
- 不要盲目堆上下文：给智能体完整代码库可能不如给精准的局部代码有效，且 token 成本高昂。
- 优先代码结构而非自然语言：方法签名、类型定义等结构化信息比文字描述更有用。
- 关注噪声问题：temperature=0 并非绝对确定，小样本实验结果需谨慎解读。
该研究挑战了“上下文越大越好”的直觉，为设计更高效、更经济的编码智能体提供了重要参考。