编程代理究竟需要什么上下文来执行操作？

# 编程智能体真正需要什么上下文才能执行操作？ 来源：https://arxiv.org/html/2607.09691 Brian Sam-Bodden Integrallis Software [email protected] ###### 摘要 现代编程智能体可以将整个代码仓库放入其上下文窗口。但它读取的大部分内容都是浪费的——有趣的问题不是智能体能用多少上下文，而是它实际*需要*多少。我们研究这个问题的时候，正是它最重要的时刻：当智能体必须*编辑*代码时。将*查找*工作位置与*执行*操作分开，我们使用一个神谕（oracle）固定局部化，仅改变代码的表示方式，并根据SWE-bench Verified上的实际问题解决情况对上下文评分。答案非常简洁。信号存在于正在编辑的代码本身：其自然语言摘要几乎没有回答源码能回答的行为问题（4/45对比27/45，保留仓库，独立评判员），这个差距属于表示方式而非摘要器——一个前沿模型的摘要与一个3B模型的摘要得分一样差。周围的上下文也几乎不重要：在Verified的所有多文件实例中，在一个在数据收集前冻结的协议下，将文件的其余部分渲染为UML骨架和签名所解决的问题数量并不比直接删除该其余部分多（N=70，精确麦克尼马尔检验，p=0.75）。这是我们预先注册的假设，但它失败了。与此同时，压缩上下文以三分之一的token匹配整个文件：解决一个问题需要19K上下文token，而不是94K。该工具还发现了一个该领域应牢记的结果：温度0的API推理在字节相同的运行之间翻转了约9%的每个实例结果。这是该基准上报告的每个小效应（包括我们的）下的噪声底限。我们发布该工具——经过金验证的环境、每个实例的证明（每个参考编辑都能从每个分支的上下文中表达出来）、确定性的补丁构建以及预先注册的假设（我们发布其零假设）。

参见图1：查找/执行边界。行为探针准确率按上下文表示划分（n=45：从seaborn/pylint/pytest中抽取15个保留类×每个类的*测试文件*铸造3个探针；相同的模型——Claude Sonnet 4.6——在每个分支中读取上下文并回答问题，因此只有表示方式变化；答案由独立家族的评判员评分，与第二位评判员的κ=0.84）。前沿/3B标签指示编写表示的*摘要器*，而非回答者。源码回答60%；自然语言摘要回答约9%——前沿摘要器和3B摘要器相同——且没有摘要成功于源码失败之处（麦克尼马尔检验23比0，p<10^-4）。每个条形下方表示平均表示大小（以100k_base token计）。

## 1 引言

当软件工程师修复一个bug时，她不会重新阅读整个仓库。她找到少数几个重要的函数，仔细阅读，并让代码库的其余部分成为一个模糊的地图，知道什么在哪里。编程智能体构建的方式却相反：上下文窗口现在能容纳整个仓库，而自然的倾向是填满它们。这种倾向是有代价的——token、延迟、金钱——而且背后的证据却惊人地薄弱。前沿智能体已经解决了SWE-bench Verified的很大一部分[5 (https://arxiv.org/html/2607.09691#bib.bib5)]，然而ContextBench[7 (https://arxiv.org/html/2607.09691#bib.bib7)]发现复杂的检索脚手架往往仅勉强超过简单基线，且*探索的*上下文与*使用的*上下文之间存在巨大差距。因此，值得问的问题不是我们能否容纳代码，而是：对于给定的代码任务，智能体实际需要的最小上下文是什么——以及以何种表示方式？

我们分离两个经常混淆的子问题：
- • **查找**——定位工作发生的位置；
- • **执行**——给定位置，知道足够信息以正确编辑。

为了测量*执行*上下文的成本而不奖励“包含更多内容”，我们使用一个*神谕*（每个分支的相同黄金文件）固定局部化，并*仅*改变表示方式（§3 (https://arxiv.org/html/2607.09691#S3)）。这产生一个我们可以通过或失败的预先指定的预测：*如果程序结构是智能体执行操作所需的内容，那么结构化表示层级（UML骨架/仅方法）应该在相同局部化情况下比平面二进制保留/丢弃解决更多问题*[3 (https://arxiv.org/html/2607.09691#bib.bib3)]。第5节 (https://arxiv.org/html/2607.09691#S5) 在SWE-bench Verified的每个多文件实例上测试该预测，协议在数据收集前冻结并提交。预测失败，我们报告零假设。

#### 贡献
(1) 一个经过审计的 resolve@cost 工具：神谕局部化的表示分支，带有每个实例的*可表达性*验证（每个黄金编辑都能从每个分支的上下文中证明可表达），每个实例的黄金补丁环境验证，确定性补丁构建以及预先注册的假设——每个数字都可追溯到原始工件。
(2) 一个有力的零假设：结构化表示层级在神谕局部化、单次运行中不携带超过二进制保留/丢弃的解决信号（N=70，p=0.75），而压缩上下文以33–3.7倍的更少token匹配整个文件。
(3) 一个去循环的查找/执行边界：使用测试铸造的探针、保留仓库和独立评判员，源码携带约7倍于自然语言摘要的可操作信号，且前沿摘要器无法缩小差距（摘要器质量控制的首次运行）。
(4) 一个在过程中测量的方法论警示：T=0时的运行间非确定性翻转了约9%的SWE-bench每个实例结果在字节相同的运行之间——限制了所有小的分支差距（包括我们和其他人的）的解释。

#### 严谨性与范围
本文中的每个数字都可追溯到原始工件。协议、假设和实例样本在数据收集前冻结并提交；每个实例的环境在模型调用前用其参考补丁验证；每个参考编辑都验证可从每个分支的上下文中表达；图形从原始结果文件重新生成。resolve@cost 和探针实验在SWE-bench Verified和保留的开源仓库上运行；被替代或探索性的测量被隔离在附录D (https://arxiv.org/html/2607.09691#A4) 中，不做出声明。我们标记每个n，报告每个比例的Wilson 95%置信区间，并对每个负结果说明其偏差方向。

## 2 相关工作

**基于充分性的代码上下文**。SWEzze[3 (https://arxiv.org/html/2607.09691#bib.bib3)]将问题上下文缩减为最小充分子序列（代码段落的二进制保留/丢弃），经过解决验证；Joren等[6 (https://arxiv.org/html/2607.09691#bib.bib6)]形式化了用于RAG的“充分上下文”。我们在此基础上构建；我们*执行*视角的探针询问*哪种替代渲染*足够，而我们的resolve@cost实验回答*层级*是否胜过它们的*保留/丢弃*（它们没有，N=70，§5 (https://arxiv.org/html/2607.09691#S5)）。

**上下文修剪/压缩**。SWE-Pruner[12 (https://arxiv.org/html/2607.09691#bib.bib12)]、LLMLingua[4 (https://arxiv.org/html/2607.09691#bib.bib4)]以及相关系统修剪token或行；我们选择*程序结构表示*并测量*解决*，而非相关性。

**局部化与检索**。Agentless[13 (https://arxiv.org/html/2607.09691#bib.bib13)]、LocAgent[1 (https://arxiv.org/html/2607.09691#bib.bib1)]、RepoGraph[9 (https://arxiv.org/html/2607.09691#bib.bib9)]和LingmaAgent[8 (https://arxiv.org/html/2607.09691#bib.bib8)]处理*查找*；我们通过神谕*排除*局部化以隔离表示。

**分层检索**。RAPTOR[11 (https://arxiv.org/html/2607.09691#bib.bib11)]和GraphRAG[2 (https://arxiv.org/html/2607.09691#bib.bib2)]构建摘要层次结构；我们的探针结果限制了摘要节点能为*执行*携带的内容，并且在探索性测试中，基于架构的层次下降并未胜过平面检索（附录D (https://arxiv.org/html/2607.09691#A4)）。

**代码上下文的苦涩教训**。ContextBench[7 (https://arxiv.org/html/2607.09691#bib.bib7)]报告复杂的脚手架仅勉强超过简单基线，且大量探索的上下文未被利用；我们的结果从一个独立构建、经过审计的工具佐证了这一点。CodeCompass[10 (https://arxiv.org/html/2607.09691#bib.bib10)]在*导航*方面持相反观点——当词汇重叠较低时，结构遍历胜过检索——这与我们的范围一致：我们的零假设涉及*执行*上下文的渲染，而非导航。

## 3 方法

### 3.1 实验设置

表1：设置。本文中的每个声明除非另有说明，都继承这些条件。

| 项目 | 细节 |
|------|------|
| 解决数据集 | SWE-bench Verified[5 (https://arxiv.org/html/2607.09691#bib.bib5)]：所有71个多文件实例（≥2个黄金文件）；70个经过黄金验证排除后（astropy-8707，其黄金补丁在自身环境中失败）。 |
| 探针数据 | 来自seaborn/pylint/pytest的15个保留类，固定提交，每个带有专用测试文件（探针从测试中铸造，从未从被评分的文本）。 |
| 智能体（解决） | Claude Sonnet 4.6，单次，温度0，max_tokens=8000，≤2次应用失败重试轮次；在编辑块之前允许推理。 |
| 探针评判员 | GPT-4o-mini（独立家族），Claude作为第二评判员（报告κ）。 |
| 补丁 | 确定性SEARCH/REPLACE→difflib统一diff；不明确或不匹配的编辑被反馈进行≤2次重试；空的SEARCH创建新文件。 |
| 解决 | SWE-bench 4.1.0 Docker harness（FAIL_TO_PASS ∧ PASS_TO_PASS）。 |
| 黄金补丁验证 | 每个实例都经过验证（70/71通过）。 |
| 可表达性门控 | 每个分支×实例，每个黄金块的删除行（或插入锚点）在渲染的上下文中逐字验证存在，在任何智能体调用之前：所有分支中70/70。 |
| 成本 | cl100k_base_token代理，加上Anthropic count_tokens在每次会话的精确*初始*提示上（重试提示记录在度量中但不计入token）。 |
| 统计 | 每个比例的Wilson 95%置信区间；成对解决上的精确双尾麦克尼马尔检验。 |
| 结构树 | 确定性AST提取产生子系统→组件→文件→类→函数。 |
| 表示层级 | 完整主体·仅方法·UML类骨架·签名+文档·名称·排除（全部确定性；无LLM）。 |

### 3.2 resolve@cost 实验装置

参见图2：装置，端到端。黄金更改的文件（神谕局部化）在三个表示方式不同的分支下渲染；智能体发出SEARCH/REPLACE块；确定性构建器构造diff；官方Docker harness报告解决情况。

**神谕局部化**将表示与检索隔离：分支共享黄金更改的文件。分支也是*覆盖公平*的：压缩分支逐字渲染模块级代码、类属性区域、装饰器以及非Python黄金文件，因此每个黄金编辑都能从每个分支的上下文中表达（每个实例验证；表1 (https://arxiv.org/html/2607.09691#S3.T1)）。我们披露不对称性：压缩分支是从黄金编辑的单元构建的（它们以完整细节编码了*在哪里*编辑）；oracle_full接收没有高亮的整个文件。所有分支都是神谕*上限*，而非可部署策略；层级与保留/丢弃的比较——共享相同的黄金单元——是清晰的比较。

**确定性补丁**消除了LLM编写diff的主要混淆因素：在开发测试中，模型编写的统一diff在9次尝试中有7次未能应用；SEARCH→difflib构建器干净地应用，git apply --check已验证，带有唯一性检查、新文件创建和≤2次重试轮次，每次编辑失败都有反馈。

**resolve@cost**被报告为对（解决率，平均上下文token）并总结为*token per resolve* = 总上下文token / 已解决实例。我们不将解决除以平均token：该比率奖励一个分支在它从未解决的实例上缩减上下文。

## 4 查找/执行边界

源代码的压缩替代品——摘要、签名——能否携带智能体*执行*所需的内容？我们通过行为探针测量这一点：来自seaborn/pylint/pytest的15个保留类，固定提交，每个带有专用测试文件；每个类三个探针*从测试*铸造（独立行为真实值——回答者永远看不到它们；允许“UNKNOWN”）；单个前沿模型（Claude Sonnet 4.6）读取表示并在每个分支中回答每个探针；答案由*独立家族*评判员（GPT-4o-mini）评分，并行运行同家族评判员仅报告一致性（κ=0.84，94%原始一致）。全程温度0。摘要器质量控制使用相同的180-token预算和一个小模型（Qwen2.5-Coder-3B）以及一个前沿模型（Claude Sonnet 4.6）运行相同的提示，因此“摘要失败”不能是弱摘要器的产物。

表2：查找/执行边界（n=45=15个保留类×3个测试铸造探针；独立评判员；严格T=0）。与源码的精确麦克尼马尔检验：两个摘要分支均为23对0不一致，签名分支为21对0不一致（所有p<10^-4）。

三个观察结果。首先，**源码并非完美**（0.600）：测试铸造的行为探针很难，有时需要单个类之外的上下文——这正是公平协议重要的原因：从被评分文本本身铸造的探针集报告了漂亮的1.00（附录D (https://arxiv.org/html/2607.09691#A4)）。其次，**边界宽度约为7倍**：源码回答了60%的问题，摘要仅回答约9%，且没有摘要曾在源码失败时成功。第三——赋予结果力量的控制——**前沿编写的摘要得分与3B摘要相同**：差距是*表示类别*的属性，而非摘要器质量。更好的散文在此预算下并不会转化为可操作的信息。签名，在类似成本下，略优于散文摘要（6/45对比4/45）——在这些计数中，这不过是暗示幸存于压缩的是结构而非叙述的线索。这表明**摘要不能*执行***；它**不**表明摘要有助于*导航*——在我们的探索性导航测试（附录D (https://arxiv.org/html/2607.09691#A4)）中，基于摘要键的分层下降也未胜过平面检索。

## 5 Resolve@cost：每个多文件Verified实例，预先注册

**协议**（在数据收集前冻结并提交）。所有黄金补丁涉及≥2个文件的71个实例；神谕局部化；仅改变表示方式；单次智能体（表1 (https://arxiv.org/html/2607.09691#S3.T1)）。每个实例的黄金补丁首先通过harness运行（70/71环境通过；排除的失败被记录），且每个黄金编辑在每个分支中验证可表达，在任何智能体调用之前。

**注册假设H2**：oracle_tier解决的实例多于oracle_keep_drop。

参见图3：样本来源。500个Verified实例→71个多文件（注册标准）→70个经过一次黄金验证排除后。整个池运行；没有抽样。

参见图4：有力结果（N=70）。*左*：每个分支的解决率与Wilson 95%置信区间——注册的层级对比保留/丢弃比较为零（精确麦克尼马尔检验p=0.754）。*右*：每个解决实例的上下文token：压缩上下文以19–26K token获得一个解决；整个文件支付94K token。

表3：解决与上下文成本（N=70；每个分支在每个实例上覆盖每个黄金块，因此差异来自表示方式，而非可表达性）。

表4：成对检验（精确麦克尼马尔检验，双尾）。