ContextSniper：AntTrail的令牌高效代码记忆模块用于仓库级程序修复

# ContextSniper：面向仓库级程序修复的令牌高效代码存储

来源：https://arxiv.org/html/2607.01916

Chiwang Luk¹,†　Matin Mohammad Najafi¹　Zhifeng Jia¹　Wei Yang¹　Xiuchang Li¹　Jinwei Zhu¹　Yang Ren¹　Lei Chen²　Gao Cong³,†

¹华为 ²香港科技大学（广州） ³南洋理工大学

###### 摘要

大语言模型代理可以修复真实的仓库问题，但它们经常在整文件读取、广泛搜索和长终端输出上花费大量上下文预算，而这些输出中有用的证据与无关代码和日志混杂在一起。本文提出了ContextSniper，一种令牌高效的代码存储层，位于宿主编码代理和仓库之间。ContextSniper检索候选代码和运行时证据，通过混合检索信号对其进行排序，通过意图感知的上下文门控过滤长输出，并返回紧凑的证据包，同时将可恢复的源上下文保留在提示词之外。我们在SWE-bench Lite上使用OpenClaw和Claude Code评估ContextSniper，每个宿主代理条件运行50个任务。ContextSniper将OpenClaw的总令牌使用量减少51.5%，日志记录成本降低36.4%；将Claude Code的总令牌使用量减少38.9%，估计成本降低27.3%。提交解决率略有下降，OpenClaw从26.0%降至24.0%，Claude Code从32.0%降至30.0%。ContextSniper已在github.com/Calluking/ContextSniper (https://github.com/Calluking/ContextSniper) 开源。

††通讯作者。

> 关键词：仓库级程序修复、编码代理、代码存储、代理记忆、检索增强软件工程、令牌效率

## 1 引言

### 1.1 动机

大语言模型代码代理越来越多地被评估和部署于仓库级软件工程任务。仓库级修复基准和代理系统使这一转变具体化，要求模型检查代码库、执行工具并生成源代码补丁，而不仅仅完成孤立代码片段[1 (https://arxiv.org/html/2607.01916#bib.bib1),2 (https://arxiv.org/html/2607.01916#bib.bib2),3 (https://arxiv.org/html/2607.01916#bib.bib3),4 (https://arxiv.org/html/2607.01916#bib.bib4)]。像Claude Code这样的系统越来越多地用于仓库级开发、调试和修复，代理必须检查现有文件、理解程序结构、运行命令并生成源代码补丁[5 (https://arxiv.org/html/2607.01916#bib.bib5)]。在这些工作流中，上下文不仅仅是辅助文本：它是代理对仓库状态的工作记录。丢失一个文件路径、失败的测试跟踪、API前置条件或符号关系，都可能破坏定位，导致一个看似合理的补丁瞄准错误的代码。这呼应了最近长时程代理工作的动机，该工作认为代理上下文必须保留精确的动作、观察和演变状态，而不仅仅是最大化长度[6 (https://arxiv.org/html/2607.01916#bib.bib6)]。

困难在于，主流代理通过原始仓库访问获取这些证据。如图1 (https://arxiv.org/html/2607.01916#S1.F1)A所示，任务提示与整文件读取、广泛搜索结果和长终端日志混合在一起。随着交互累积，活动上下文既包含有用证据，也包含过时的探索残留。这种增长给仓库修复带来了两个耦合的瓶颈。首先，它提高了推理成本和延迟，因为后面的每个推理步骤都必须携带更多令牌。其次，它降低了决策质量，因为解释失败的那几行被无关助手、重复的堆栈跟踪、构建噪声和早期失败尝试稀释了。当代理未能修复问题时，它可能重新读取类似的文件或日志，产生一个“读取-尝试-失败-重新读取”的循环，消耗更多令牌而不一定增加有用证据的数量[2 (https://arxiv.org/html/2607.01916#bib.bib2),7 (https://arxiv.org/html/2607.01916#bib.bib7)]。长上下文研究表明，当相关信息被埋藏在长输入中时，模型可能无法可靠地使用它[8 (https://arxiv.org/html/2607.01916#bib.bib8)]；仓库修复使这个问题具体化，因为补丁所需的证据往往被无关代码和运行时输出包围。

简单的上下文缩减是不够的。简单的截断可能删除唯一解释bug的测试断言或导入边界，而通用摘要可能模糊来源、行号和可编辑性。编码代理的有效上下文管理必须积极缩减，同时保留异质的修复信号：问题意图、代码结构、符号定义、失败观察、命令结果以及编辑后的更新状态。检索增强生成和仓库存储系统推动了知识存储与提示构建之间的分离[9 (https://arxiv.org/html/2607.01916#bib.bib9),7 (https://arxiv.org/html/2607.01916#bib.bib7),10 (https://arxiv.org/html/2607.01916#bib.bib10)]，但仓库修复还需要控制哪些读取和命令输出允许首先进入活动上下文。

ContextSniper正是围绕这一路径构建的：上下文作为证据，而不是压舱物。图1 (https://arxiv.org/html/2607.01916#S1.F1)B展示了由此产生的工作流。ContextSniper不直接将原始仓库和运行时输出传递给LLM，而是首先将其视为候选证据。我们将证据捕获过程描述为“狙击”：系统锁定与任务相关的代码和运行时信号，切掉周围低价值区域，并将幸存材料组装成紧凑的证据包供代理使用。ContextSniper将上下文优化的动机应用于仓库级编码代理，不仅控制检索哪些代码，还控制哪些读取和命令输出允许进入活动上下文，同时将可恢复的源证据保留在提示词之外。

有用证据
中性上下文
噪声

（A）主流代码代理

用户任务
问题 + 提示
原生仓库工具
Grep
Read
Bash
未过滤上下文
低信噪比
path.py:1--110
上下文窗口
200k / 200k（全满）
宿主代理：推理→编辑→测试
失败时：重新读取类似文件；
重复上下文持续增长

（B）ContextSniper

用户任务
问题 + 提示
ContextSniper插入层
抑制噪声输出
search_code
Read
Bash
紧凑证据包
高信噪比
path.py:42--58
上下文窗口
80k / 200k
宿主代理：推理→编辑→测试
提交补丁；
无冗余重读

（C）有用证据工作点

工作点
上下文成本（令牌）
对修复的有用性
ContextSniper
原始访问（grep/ls）

每任务平均令牌数

越低越好

Claude
OpenClaw
0
1M
1.45M
0.79M
1.36M
0.66M
-38.9%
-51.5%
基线
ContextSniper

图1：ContextSniper将噪声仓库上下文变为紧凑修复证据。（A）和（B）共享相同的宿主代理工作流；只有上下文获取模块不同。（A）原生Grep、Read和Bash输出累积成未过滤的提示上下文，失败尝试重新读取类似文件。（B）ContextSniper插入层用search_code摘录替代广泛发现，并在同一宿主代理组装紧凑提示之前门控长Read/Bash输出。（C）上下文获取经过四个阶段：指令、检索与编辑、足够证据、上下文溢出。ContextSniper提前到达工作点并停止；原始grep/ls访问通过冗余读取继续消耗令牌，只有在上下文溢出时才失去准确性。柱状图给出了每任务的平均令牌使用量（表2 (https://arxiv.org/html/2607.01916#S4.T2)）。

预期的工作点如图1 (https://arxiv.org/html/2607.01916#S1.F1)C所示。当上下文添加缺失的证据时有帮助，但在代理获得足够信息后，额外的文件和日志主要增加成本和干扰。因此，ContextSniper不试图最大化上下文大小或统一压缩所有内容。它试图将代理保持在有用证据区域附近：足够的代码和运行时证据以定位和修复问题，但足够少的周围噪声以减少令牌、轮次和混乱。ContextSniper不替换宿主编码代理，而是针对代理与仓库之间的上下文访问层。它维护本地代码存储，检索紧凑的任务相关代码，抑制噪声读取和命令输出，并将存储与仓库编辑同步，从而使提示携带当前证据包而非整个探索历史。

### 1.2 问题陈述

仓库级程序修复要求代理将问题描述与代码库的相关实现、测试、接口和执行行为连接起来[1 (https://arxiv.org/html/2607.01916#bib.bib1)]。这很困难，因为必要的证据很少孤立于一个函数中。它可能分布在多个文件、导入的依赖项、类层次结构、配置逻辑和失败的测试中。在代理能够生成正确的补丁之前，它必须首先定位重要的代码，这也是定位和仓库图方法所针对的瓶颈[4 (https://arxiv.org/html/2607.01916#bib.bib4),11 (https://arxiv.org/html/2607.01916#bib.bib11),12 (https://arxiv.org/html/2607.01916#bib.bib12)]。

现有代理通常通过原始仓库工具获取此上下文。它们直接读取文件，运行搜索命令，检查命令输出，然后决定下一步读取什么[2 (https://arxiv.org/html/2607.01916#bib.bib2),3 (https://arxiv.org/html/2607.01916#bib.bib3)]。这种工作流是通用的，但它将上下文积累作为获取证据的默认路径。它在重复探索步骤之间提供的记忆很少，对进入上下文窗口的无关输出量的控制很少，并且对使检索到的上下文与修复过程中更改的文件保持一致的支持有限。最近的代码库存储和基于图的系统通过向代理提供结构化仓库访问来解决部分问题，但上下文选择和运行时输出控制仍然是重要的实际问题[10 (https://arxiv.org/html/2607.01916#bib.bib10),7 (https://arxiv.org/html/2607.01916#bib.bib7)]。

本文研究以下问题：如何使现有的仓库级代码代理将原始仓库和运行时上下文转换为紧凑的修复证据，同时保持代理的核心推理和编辑循环不变？这个问题有两个耦合的目标。第一个是减少浪费：更少的无关令牌、更少的重复探索轮次、更低的成本和更短的延迟。第二个是减少混乱：更清晰的证据包，改善代码定位、补丁推理和验证行为。

### 1.3 相关工作

ContextSniper与从不同角度针对同一瓶颈的三条先前工作线相关联：代理工具、提示与检索压缩、以及代理工具的输出侧过滤。

第一条工作线研究仓库级软件工程的代理工具和代理-计算机接口。SWE-agent表明，LLM与计算机之间的接口，包括文件导航、编辑、搜索和测试执行工具，强烈塑造代理行为[2 (https://arxiv.org/html/2607.01916#bib.bib2)]。AutoCodeRover构建了更具软件工程导向的自主修复工作流，包含结构化代码搜索和测试感知的故障定位[3 (https://arxiv.org/html/2607.01916#bib.bib3)]，而Agentless将仓库修复分解为定位、修复和验证，无需完全自主的工具循环[4 (https://arxiv.org/html/2607.01916#bib.bib4)]。这些系统改进了代理的规划、导航和编辑仓库的方式，但活动上下文在很大程度上仍然与代理的探索性读取、搜索结果和命令输出耦合。ContextSniper保持宿主代理的推理、编辑和验证循环不变，而是改变向该循环提供证据的上下文访问层。

第二条工作线优化提示和检索压缩。LLMLingua和LongLLMLingua通过小型LM丢弃低信息令牌，实现高达20倍压缩，质量损失小，并明确缓解“迷失在中间”的失败模式[13 (https://arxiv.org/html/2607.01916#bib.bib13),14 (https://arxiv.org/html/2607.01916#bib.bib14)]。RECOMP在检索和LM之间插入一个学习到的压缩器，为检索增强生成（RAG）设置提供抽取式和抽象式两种变体[15 (https://arxiv.org/html/2607.01916#bib.bib15)]。COMPACT使压缩率依赖于查询，对每个检索到的文档决定如何积极缩短[16 (https://arxiv.org/html/2607.01916#bib.bib16)]。Selective Context通过自信息过滤令牌[17 (https://arxiv.org/html/2607.01916#bib.bib17)]，而AutoCompressor训练模型发出摘要向量，将早期上下文压缩到KV缓存中[18 (https://arxiv.org/html/2607.01916#bib.bib18)]。该层次的开源工程工具包括ctxbudgeter，它在模型调用之前编译、审计、治理和可视化上下文包，具有令牌预算、策略检查、来源和缓存规划[19 (https://arxiv.org/html/2607.01916#bib.bib19)]，以及Token Reducer，一个面向Claude Code的本地管道，结合BM25和向量检索、抽象语法树（AST）分块、重排序和TextRank风格的代码库上下文压缩[20 (https://arxiv.org/html/2607.01916#bib.bib20)]。这些方法对已经选定用于提示的文本或检索到的块进行操作；ContextSniper在更早的层次上为仓库修复操作，决定哪些工具输出和代码摘录允许进入该文本。

第三条工作线在工具输出进入模型上下文之前进行过滤。RTK通过Rust CLI代理重写shell命令，通过过滤、分组、截断和去重，报告常见开发命令可节省60-90%的令牌[21 (https://arxiv.org/html/2607.01916#bib.bib21)]。Headroom将此思想从shell命令推广到工具输出、日志、文件、RAG块和对话历史，通过库、代理和MCP服务器实现，报告实际代理工作负载可节省60-95%的令牌，同时保持本地优先操作和可逆检索原始内容[22 (https://arxiv.org/html/2607.01916#bib.bib22)]。Bearing在工作流层面解决上下文增长：它将规划与执行分离，在新代理进程中运行任务，并传递任务摘要和相关文件提示，而不是整个累积的对话[23 (https://arxiv.org/html/2607.01916#bib.bib23)]。ContextSniper与此家族最接近，但将输出门控专门用于仓库级修复：它将工具输出过滤与同步本地代码存储相结合，使宿主代理获得紧凑的、任务相关的修复证据，而无需更改其外部工作流。现有的代理工具、提示压缩器和输出过滤器各自改进了证据链的一个环节；据我们所知，没有哪个在保持同步代码存储的同时，为修复门控原始仓库和运行时输出。ContextSniper将这些思想合并到一个单一的上下文访问层中，并在仓库级修复基准[1 (https://arxiv.org/html/2607.01916#bib.bib1)]上针对主流的原始访问工作流进行评估，而不是针对合成长上下文任务上的抽象压缩比。

### 1.4 贡献

本文提出了ContextSniper，一个用于令牌高效的存储器。