SWE-Pruner：面向编程智能体的自适应上下文剪枝方法

基于目标感知的行级轻量剪枝框架，为编程Agent压缩代码上下文

前置知识

LLM编程Agent

以大语言模型为核心的自主编程智能体，能够通过工具调用（如文件读取、代码执行、编辑修改）与代码仓库进行多轮交互来完成软件工程任务。典型代表包括Claude Code、Gemini CLI等，它们将终端、编辑器、文件搜索等工具链集成到LLM中，实现对复杂代码库的多步推理。在SWE-Bench等基准测试中，Agent需要根据Issue描述定位问题、阅读代码、运行测试并生成补丁。

本文的研究对象正是这类Agent在交互过程中积累的长上下文问题，理解Agent的工作机制是理解本文动机和方法的前提。

上下文窗口与Token消耗

LLM的上下文窗口（Context Window）限制了单次推理能处理的最大Token数。在编程Agent场景中，每一轮交互都会将文件内容、工具输出等信息塞入上下文，导致Token消耗快速累积。Read类操作（如cat、grep）往往输出大量代码文本，是Token消耗的主要来源。当前主流模型支持128K甚至更长的上下文窗口，但盲目塞入大量代码会导致注意力稀释（attention dilution）和幻觉问题。

Token消耗直接决定了API调用成本和推理延迟，这是本文要解决的核心效率问题。理解上下文窗口的限制有助于理解为什么需要压缩。

提示压缩（Prompt Compression）

通过减少输入给LLM的Token数量来降低推理成本的技术。已有方法包括：基于困惑度（PPL）的Token级剪枝（如LLMLingua）、基于自信息的选择性上下文（Selective-Context）、基于嵌入相似度的RAG检索、以及基于程序结构的LongCodeZip等。这些方法各有优劣，但普遍存在破坏代码语法结构、无法适应任务动态变化等问题。

本文的SWE-Pruner正是在这些已有方法的基础上提出改进，理解已有压缩技术的工作原理和局限性有助于理解本文的创新点。

CRF（条件随机场）

一种判别式概率图模型，常用于序列标注任务。CRF通过建模相邻标签之间的转移概率来捕捉序列中的依赖关系。在本文中，CRF被用于建模相邻行之间的保留/剪枝决策的转移概率，使得模型能够学习到行级的保留模式而非独立地对每一行做二分类决策。CRF的负对数似然损失（CRF-NLL）是本文训练目标的核心组成部分。

本文使用CRF-NLL而非简单的二元交叉熵作为训练损失，这一设计选择直接关系到剪枝模型能否捕捉代码行之间的结构依赖。

重排序（Reranking）

在信息检索中，重排序是在初步检索结果的基础上，利用更精细的模型对候选文档进行重新排序的技术。本文将上下文剪枝问题形式化为重排序问题：给定Agent的当前目标作为查询，对代码上下文中的每一行计算相关性分数，然后根据分数阈值决定保留哪些行。选用Qwen3-Reranker-0.6B作为骨干网络，利用其预训练的代码结构理解能力。

将剪枝视为重排序是本文的核心视角转换，使得方法可以利用已有的重排序模型的预训练知识，而非从零训练一个剪枝模型。

研究动机

编程Agent在处理真实世界的代码仓库时面临严重的上下文膨胀问题。论文通过实证分析Mini SWE Agent在SWE-Bench Verified上的轨迹发现，Read类操作（包括cat、grep、head等文件读取命令）消耗了总Token数的76.1%（约4.38M Token），远超Execute操作（12.1%，约0.69M）和Edit操作（11.8%，约0.68M）。这意味着Agent在多轮交互中将大量Token花在了反复探索代码库上，而且早期轮次检索的代码会在上下文中持续累积，进一步加剧了问题。现有的上下文压缩方法在编程场景中存在根本性缺陷：Token级剪枝方法（如LLMLingua-2）会破坏代码的语法结构完整性；基于困惑度等静态指标的压缩方法无法适应Agent任务的动态变化；粗粒度的检索方法（如RAG）可能遗漏关键的实现细节。这些问题导致压缩后代码的可用性大幅下降，甚至产生负面效果。

本文的目标是本文的目标是设计一个面向编程Agent的自适应上下文压缩框架，能够在保持代码语法和逻辑结构完整性的同时，显著减少Token消耗和API成本。具体而言，框架需要满足三个关键需求：（1）任务感知——能够根据Agent当前的推理目标动态调整压缩策略，而非使用固定的压缩规则；（2）结构保持——在行级粒度进行压缩，避免破坏代码的语法结构；（3）轻量高效——压缩模型本身不能引入显著的额外延迟，否则得不偿失。最终目标是在不降低甚至提升任务成功率的前提下，实现20-50%的Token减少。

与已有工作不同的是，本文的独特切入角度来源于对程序员行为的观察：人类程序员在阅读大量代码时并非逐行阅读，而是采用选择性略读策略——根据当前目标快速定位相关代码段。例如，当需要修复一个错误处理相关的Bug时，程序员会聚焦于错误处理相关的代码，而跳过无关部分。本文将这一洞察转化为技术方案：让Agent先生成一个明确的目标提示（Goal Hint），然后训练一个轻量级神经网络模拟选择性略读的过程，根据目标提示从原始上下文中筛选相关行。这种目标驱动的行级剪枝方式与已有方法的本质区别在于：它不是静态的、与任务无关的压缩，而是动态的、与Agent当前推理步骤紧密耦合的压缩。此外，本文将剪枝框架实现为Agent与环境之间的中间件，无需对Agent架构进行大幅修改即可无缝集成。

核心方法

SWE-Pruner的整体思路是将上下文剪枝问题建模为一个目标驱动的重排序问题，并以中间件的形式嵌入Agent工作流。直觉上，当Agent发出文件读取命令（如grep、cat）时，原始检索结果往往包含大量与当前任务无关的内容。SWE-Pruner在原始输出返回给Agent之前进行拦截和过滤。技术路线上，框架由三个核心组件构成：（1）目标提示生成——Agent在每轮交互中生成一个自然语言描述其当前信息需求的Goal Hint；（2）轻量神经网络剪枝器——一个基于Qwen3-Reranker-0.6B的神经网络，根据Goal Hint对上下文中的每一行计算相关性分数；（3）自适应选择——根据分数阈值决定保留哪些行，将剪枝后的上下文返回给Agent。整个过程对Agent是透明的，Agent只需在调用工具时额外提供一个可选的目标提示参数。

本文的核心创新在于三个层面的突破。第一，目标驱动的自适应压缩：不同于已有方法使用固定指标（如困惑度）进行无差别压缩，SWE-Pruner让Agent明确表达当前的信息需求，压缩行为随着Agent推理阶段的变化而动态调整。第二，行级粒度的结构保持：相比Token级剪枝容易破坏代码语法结构，行级剪枝天然保持了代码的语法完整性，每一行要么完整保留要么完全删除，避免了语法碎片。第三，极轻量的剪枝模型：采用仅0.6B参数的编码器模型作为剪枝器，其推理延迟始终低于100ms（即使在8K Token长度下），远低于使用大语言模型进行摘要的方式。这三个设计选择共同解决了已有方法在编程场景中的核心痛点：任务无关性、结构破坏性和额外延迟。

方法步骤详情

SWE-Pruner的方法包含以下具体步骤。第一步，目标提示生成（Section 3.2）：Agent在调用文件操作工具时，生成一个Goal Hint作为可选参数context_focus_question传入。Goal Hint是一个自包含的自然语言问题，如Focus on the MRO resolution logic。标准工具接口被扩展为grep_with_pruner(file_path, pattern, context_focus_question=None)的形式，当未提供Goal Hint时直接返回原始输出，保持向后兼容。第二步，行级分数计算（Section 3.3）：给定Agent上下文 $C = \{x_1, x_2, ..., x_n\}$ 和查询 $q$，模型通过神经评分函数 $F$ 计算每个Token的相关性分数 $s_i = F(q, x_i | C; \theta)$。然后将Token级分数聚合到行级：$\bar{s}_j = \frac{1}{|T_j|} \sum_{t \in T_j} s_t$，其中 $T_j$ 是第 $j$ 行包含的Token集合。这种平均聚合确保行级评估基于整体相关性而非少数高分Token主导。第三步，自适应选择：使用阈值 $\tau$ 进行二元决策，保留分数超过阈值的行。模型对检索的代码块并行处理以减少延迟。第四步，训练数据构建：从GitHub采样代码片段，使用教师LLM（Qwen3-Coder-30B-A3B-Instruct）合成面向任务的查询，构建训练四元组 $(q, C, M, S)$，其中 $M$ 是行级二值掩码，$S$ 是文档级相关性分数。基于9种Agent任务类型（代码调试、功能添加、代码重构等）的分类体系设计查询，最终通过LLM-as-a-Judge过滤获得61,184个高质量训练样本。

技术新颖性

SWE-Pruner的技术新颖性体现在多个方面。首先，在训练目标设计上，采用CRF负对数似然损失（CRF-NLL）而非简单的二元交叉熵。CRF显式建模了相邻行之间保留/剪枝状态的转移概率，使得模型能够学习到行级的保留模式，捕捉代码行之间的序列依赖关系。损失函数为 $\mathcal{L}_{compress} = \frac{1}{B} \sum_{i=1}^{B} \frac{1}{L_i} \mathcal{L}_{CRF-NLL}(x_i, y_i)$，其中 $L_i$ 是序列长度归一化项，防止长上下文中出现偏向激进剪枝的偏差。其次，采用双头架构：保留Qwen Reranker原有的重排序头用于文档级相关性评分，同时添加CRF压缩头用于行级剪枝决策。最终目标函数为 $\mathcal{L}_{total} = (1-\lambda) \cdot \mathcal{L}_{compress} + \lambda \cdot \mathcal{L}_{rerank}$，兼顾行级压缩和文档级相关性。第三，在数据构建上，采用教师-学生范式，利用30B参数的教师模型合成训练数据，训练0.6B参数的学生剪枝器，实现了知识蒸馏的效果。同时通过任务分类体系（9种Agent任务类型）和LLM-as-a-Judge质量过滤机制确保训练数据的多样性和质量。

实验结果

本文在多个基准测试和模型上验证了SWE-Pruner的有效性。在SWE-Bench Verified上，SWE-Pruner与Mini SWE Agent集成后，使用Claude Sonnet 4.5作为骨干模型时，Token消耗从0.911M降至0.701M（减少23.1%），成功率从70.6%提升至72.0%（+1.4个百分点），交互轮次从51.0降至41.7（减少18.2%）。使用GLM-4.6时效果更为显著，Token消耗从0.791M降至0.488M（减少38.3%），成功率从55.4%提升至56.6%（+1.2个百分点），轮次从49.3降至36.6（减少25.8%）。在SWE-QA上，SWE-Pruner在三个仓库（Streamlink、Reflex、Conan）上实现了29-54%的Token减少，同时任务性能保持稳定或略有提升。在单轮任务Long Code QA上，SWE-Pruner在8x压缩约束下实现了14.84倍的有效压缩率，准确率达58.71%，远超其他基线方法。与不同上下文管理策略的对比（在50个SWE-Bench样本上）显示，SWE-Pruner以64%的成功率优于原生Agent（62%）和LLMLingua2（54%）、RAG（50%）、LLM Summarize（56%）、LongCodeZip（54%）。此外，SWE-Pruner的剪枝器延迟始终低于100ms，在8K Token长度下也远优于Qwen3-32B（超过1200ms）等大模型。

**Table 4**: Long Code Completion和Long Code QA评估结果

查看结构化数据

任务	指标	本文	基线	提升
SWE-Bench Verified (Claude Sonnet 4.5)	Success Rate / Token Consumption	72.0% / 0.701M Tokens	Mini SWE Agent: 70.6% / 0.911M Tokens	成功率+1.4%，Token减少23.1%，轮次减少18.2%
SWE-Bench Verified (GLM-4.6)	Success Rate / Token Consumption	56.6% / 0.488M Tokens	Mini SWE Agent: 55.4% / 0.791M Tokens	成功率+1.2%，Token减少38.3%，轮次减少25.8%
SWE-QA Streamlink (Claude Sonnet 4.5)	Avg Score / Token Consumption	8.59 / 557.1K Tokens	Claude Sonnet 4.5: 8.36 / 611.2K Tokens	分数+0.23，Token减少8.9%
SWE-QA Streamlink (GLM-4.6)	Avg Score / Token Consumption	8.56 / 145.1K Tokens	GLM-4.6: 8.56 / 318.2K Tokens	分数持平，Token减少54.4%
Long Code QA (8x constraint)	Compression Ratio / Accuracy	14.84x / 58.71%	RAG: 5.87x / 55.86%	压缩率提升153%，准确率+2.85%
Long Code Completion (8x constraint)	Compression Ratio / Edit Similarity	10.92x / 57.58 ES	RAG: 6.60x / 55.82 ES	压缩率提升65.5%，ES+1.76
SWE-Bench Verified (50样本对比)	Success Rate / Token Consumption	64.0% / 0.670M Tokens	LLMLingua2: 54% / 0.856M, RAG: 50% / 0.771M	成功率最高（64% vs 54%/50%），Token最少

局限与改进

论文承认了几个主要局限性。第一，当前实现主要针对Python仓库进行评估，虽然方法本身不依赖Python特有特性，但多语言支持（如Java、C++、JavaScript等）仍需进一步验证和扩展。第二，数据泄漏问题：虽然作者选择了在训练数据收集时间之后发布的SWE-QA仓库来缓解此问题，但持续在新发布的仓库上进行评估仍然重要。第三，虽然轻量级神经剪枝器显著减少了Token消耗，但它引入了边际延迟开销（尽管低于100ms），这一开销可以通过知识蒸馏或早退（early-exit）机制进一步优化。从独立观察来看，本文的实验规模有限——SWE-Bench的完整评估仅在500个样本上进行，而与其他压缩策略的对比仅在50个样本的子集上完成，这可能影响结论的统计显著性。此外，Goal Hint的生成质量依赖于Agent自身的能力，如果Agent无法准确描述其当前信息需求，剪枝效果可能下降，但论文未对此进行深入分析。

独立分析的弱点

SWE-Pruner存在几个值得关注的弱点。首先，Goal Hint的质量瓶颈：框架假设Agent能够生成准确描述当前信息需求的目标提示，但Agent本身可能无法准确判断自己需要什么信息，特别是在探索阶段。如果Goal Hint质量不高，剪枝器可能会错误地过滤掉关键代码行。改进方向可以是设计自动Goal Hint生成机制，根据Agent的推理轨迹自动推断当前阶段的信息需求。其次，单一阈值策略的局限性：当前使用固定的阈值 $\tau$ 进行保留/剪枝决策，但不同任务和代码结构可能需要不同的压缩率。自适应阈值机制（根据上下文长度和任务类型动态调整）可能进一步提升效果。第三，仅在Python上验证：尽管方法设计不依赖Python特性，但不同编程语言的代码结构差异（如Java的类层次结构、C的宏定义）可能影响行级剪枝的效果。改进方向是在更多语言上进行系统性评估和适配。

未来方向

基于本文的成果，未来研究可以向多个方向延伸。第一，多语言扩展：将SWE-Pruner扩展到Java、JavaScript、Go等主流编程语言，评估行级剪枝在不同语言语法结构下的泛化能力。第二，与Agent历史压缩方法的结合：本文的框架聚焦于压缩环境观察（文件内容），而SUPO、FoldGRPO、AgentFold等方法聚焦于压缩Agent的交互历史。将两者结合可能实现更全面的上下文管理。第三，更强的剪枝模型：虽然0.6B参数的模型已经表现良好，但探索更大规模的剪枝器（如3B-7B）与更精细的训练策略可能进一步提升压缩质量。第四，动态压缩率控制：根据任务难度和Agent推理阶段自动调整压缩率，在探索阶段保留更多信息，在聚焦阶段进行更激进的压缩。第五，扩展到更多Agent框架：当前仅在Mini SWE Agent和OpenHands上验证，将框架集成到Claude Code、Cursor等更广泛使用的Agent工具中具有重要的实用价值。

复现评估

从复现性角度来看，SWE-Pruner具有较好的可复现条件。代码已在GitHub开源（https://github.com/Ayanami1314/swe-pruner），提供了完整的训练和评估代码。训练数据构建方法描述详细：从GitHub采样代码片段、使用Qwen3-Coder-30B-A3B-Instruct作为教师模型合成查询、通过LLM-as-a-Judge（Qwen3-Next-80B-A3B-Thinking）过滤质量，最终获得61,184个训练样本。骨干模型Qwen3-Reranker-0.6B是公开可用的预训练模型。在算力需求方面，由于剪枝模型仅0.6B参数，训练和推理的计算成本相对较低。但完整复现仍面临一些挑战：教师模型（30B参数）的数据合成需要显著的计算资源；SWE-Bench Verified的评估需要调用Claude Sonnet 4.5和GLM-4.6等商业或大型模型，涉及API成本；部分实验仅在50个样本的子集上进行，完整评估可能需要更多资源。总体而言，核心方法的复现门槛适中，但完整基准评估的成本较高。

SWE-Pruner：面向编程智能体的自适应上下文剪枝方法 SWE-Pruner: Self-Adaptive Context Pruning for Coding Agents