这项由上海交通大学LLM4SE实验室联合字节跳动抖音集团共同完成的研究以预印本形式发布于2026年7月20日论文编号为arXiv:2607.18213v1有兴趣深入了解的读者可通过该编号查询完整论文。**当AI助手开始刷屏时麻烦来了**假设你雇了一位非常聪明的编程助手每次你问他问题他都会翻遍整个代码仓库然后把所有看过的页面一张不落地放在桌子上。时间一长桌子堆满了纸其中95%的内容你们早就不需要再看了但它们就这么占着地方。这位助手不得不在这堆纸里找来找去效率越来越低回答也越来越离谱——他在找不到重点的困境中越陷越深。这不是一个比喻故事而是当今几乎所有AI编程代理coding agent可以理解为能自动帮你写代码、修bug的AI助手面临的真实困境。每次AI调用查看文件搜索代码运行测试等工具时工具返回的原始输出——有时长达数百行——就会被原封不动地追加进AI的记忆里。随着对话轮次增加这些记忆越堆越厚大量重复的、再也不会被引用的内容挤占着有限的空间不仅让API调用成本飙升还会导致AI在超长上下文中迷失方向答非所问。研究团队在SWE-Bench Verified这个标准测试集上统计发现一个典型的AI编程代理在解决代码问题时光是读文件这一类工具调用产生的输出就占据了整个对话70%以上的token可以理解为AI处理文字的基本单位越多越费钱、越难处理。这个数字触目惊心也正是这项新研究希望解决的核心痛点。研究团队将他们的方案命名为**SWE-Pruner Pro**。这个名字中的Pruner意为修剪者整个系统的核心思路是在AI助手把工具输出记入记忆之前先帮它把那些没用的行删掉只留下真正有价值的内容。但真正让这项研究与众不同的是他们为AI修剪内容的方式——他们不依赖任何外部评判而是让AI助手用自己的内心感受来决定什么该留、什么该删。---**一、那堆记忆残片里AI其实已经知道该扔掉什么**在解释SWE-Pruner Pro到底做了什么之前有必要先理解它背后最关键的一个发现——而这个发现才是整篇论文真正令人拍案叫绝的地方。当AI助手读取一段工具输出时它的内部会发生一件复杂的事情它会通过数以百亿计的神经网络参数把每一个词、每一行代码都转化成一种叫做隐层表示hidden representation的东西——可以把它理解成AI大脑对这段内容的内心感受一个多维度的数字向量编码了这段内容在当前任务背景下的种种意义。研究团队提出了一个问题当AI读完一段工具输出后它的内心感受里有没有隐含着这行重要或这行没用的判断为了验证这个猜想他们收集了大约2260次多轮工具对话记录涉及约15.5万行代码和文本让Claude Sonnet 4.6一个强大的AI模型为每一行打上保留或删除的标签。然后他们冻结了另一个AI模型Qwen3-Coder-Next的参数让这个模型读取这些工具输出提取每行内容对应的最后一层隐层表示再用一个极其简单的线性分类器逻辑回归就是大学统计课上最基础的那种分类方法来尝试区分该保留的行和该删除的行。结果非常清晰两类行在AI的内心感受空间里确实有着可以被线性区分的差异。沿着最能区分两类的方向投影保留行和删除行的分布有明显的中心偏移。这个简单的线性分类器在测试集上达到了AUC 0.83、最优F1值0.63——对于一个从未专门训练过判断重要性任务的冻结模型来说这是非常强的信号远远超过了纯粹猜测的上限如果只猜删除F1上限约为0.46。换句话说AI在被动阅读工具输出的过程中已经在潜移默化地形成了哪行重要的内部判断。这些判断没有被显式地表达出来但它们真实地编码在了隐层表示里。就像一个心不在焉翻阅报纸的人即便没有刻意标注他的眼睛其实已经知道哪段新闻值得细读、哪段可以略过——只是他没有把这种直觉写下来。然而线性分类器存在一个明显的瓶颈在中间地带既不明显重要也不明显无用的行上两类行的分布高度重叠简单的线性边界无法有效区分。此外一段代码该保留多少行还跟这段代码本身有多长密切相关——一个5行的小函数删掉2行是灾难一个300行的类定义删掉50行可能无关痛痒。这两个局限性共同催生了SWE-Pruner Pro的具体设计。---**二、轻量级翻译头把内心感受变成删除决定**SWE-Pruner Pro的整体运作方式可以用一个图书馆管理员的比喻来理解。每次AI助手从工具那里收到一份返回结果比如cat命令读取了某个文件的全部内容管理员会悄悄地站在AI身边观察AI在读这份材料时脸上的表情变化——哪段让AI眼睛一亮哪段让AI面无表情地快速翻过。管理员把这些表情信息记录下来转化成一份删除清单然后在AI把这份材料归档进记忆之前悄悄地按照清单撕掉那些无用的页面只留下真正有价值的部分。具体来说当AI助手在第t轮对话中发出工具调用、收到原始返回结果之后按照正常流程AI的主体模型冻结的大型语言模型骨干会对这段新内容做一次预填充prefill——可以理解为大脑快速扫描并处理新信息的过程。在这个扫描过程中每个token都会被转化为一个隐层表示向量。SWE-Pruner Pro就在这个时刻介入它蹭着这次本就要发生的扫描顺手读取每个token的最后一层隐层表示然后把这些表示送进一个轻量级的判断头pruning head。这个判断头由两个核心部件组成共同决定每行内容的命运。第一个部件叫**长度感知嵌入**length-aware embedding。它的作用是让判断头知道当前这段工具输出总共有多少行。研究团队把行数按照对数尺度划分成8个区间比如0-2行、3-5行、6-10行……超过200行每个区间对应一个可学习的向量。这个向量会被叠加到所有token的隐层表示上相当于给整段内容打上一个这是短文本/中等文本/长文本的标签让判断头在做决定时把内容长度纳入考量。这种设计的直觉非常自然对于一个只有5行的函数每一行都可能是关键的判断头应该更加谨慎对于一个500行的文件缺失几行往往无关大局判断头可以更果断地清理。第二个部件是**逐token前馈分类器**per-token feed-forward classifier。它的结构并不复杂一层LayerNorm归一化让数值更稳定两个线性变换→GELU激活→Dropout的堆叠块Dropout是一种防止过拟合的技巧相当于训练时随机忽略一些连接让模型更健壮最后一个线性层输出一个单一的分数再经过Sigmoid函数压缩到0到1之间代表这个token属于应保留内容的概率。这个分类器会对工具输出中的每个token都输出一个概率分数。然后按照每行中超过一半的token被判为保留则这行保留否则删除的多数投票规则得出每行的最终去留决定。被判为删除的行会从工具输出中移除替换为已过滤N行的占位标记然后这个精简后的版本才被追加进AI的对话历史作为下一轮的输入。关键点在于AI助手在第t轮自己的生成过程中仍然看到的是完整的原始输出因为判断和修剪发生在这轮生成之后只有在第t1轮及以后AI才会看到经过修剪的压缩版本。这样设计是为了确保当前轮次的AI决策不受影响而长期累积的记忆负担则被有效控制。整个判断头大约有1800万个参数相比于动辄数百亿参数的主体AI模型这是个微不足道的小零件。而且因为它蹭的是本就要发生的预填充过程不需要额外调用一次模型额外的计算开销被控制在非常小的范围内。---**三、教会判断头什么是重要的训练数据与损失函数的精心设计**一个判断头再精巧也需要经过训练才能发挥作用。研究团队为此构建了一个包含22609条样本的训练数据集每条样本都是一次真实的多轮工具对话记录包含对话历史、工具调用、工具输出以及AI在看到这个输出后的下一步行动。训练数据来自五个公开的HuggingFace数据集覆盖了SWE风格的代码修改任务以及涉及象棋、机器学习、密码学、数据库操作、Shell调度等多种命令行任务的记录。这种多样性是刻意为之的——研究团队希望判断头能处理各种类型的工具输出而不是只认识Python代码。每条样本的每一行都由Claude Sonnet 4.6打上了保留或删除的标签标注时参考了完整的对话历史和AI的下一步行动——也就是说标注的标准是AI在做完这步操作之后哪些内容对它接下来的行动是有用的。这是一个相当细致的标注过程最终经过预处理、多样性采样和人工复核形成了这个训练集。从数据分布来看一段工具输出平均76行中位数56行Claude标注的保留率平均约32%、中位数约23%——也就是说典型情况下大约七成的内容是可以删掉的。这和AI实际行为中的大量冗余完全吻合。训练时使用的损失函数可以理解为衡量模型表现好坏的尺子是这项研究的另一个创新点。通常的做法是用交叉熵损失cross-entropy loss简单来说就是你猜错的次数越多、惩罚越重。但这种做法有个问题由于绝大多数token都属于删除类别保留率只有约30%模型可能会偷懒地学会几乎什么都删在数量上减少错误但实际上错误地删掉了最关键的内容。标准的Focal Loss聚焦损失通过加大对难以区分的样本的惩罚来改进这个问题但它对整个数据集统一处理没有考虑单个样本的保留/删除比例差异。研究团队设计了一种逐样本平衡Focal损失per-sample balanced focal loss对于每个工具输出样本先分别计算所有应保留token上的平均损失和所有应删除token上的平均损失然后各取一半加权合并。这样做的效果是无论一个样本中保留行只有3行还是90行保留和删除两类信息对这个样本的学习贡献都是对等的。这种设计背后有一个非常直观的洞察当一段100行的输出里只有3行被标记为保留时那3行一定极度重要因为AI在浏览完整段输出后判断只有这3行值得记住当一段100行的输出里90行都被标记为保留时那10行被标记为删除的内容也一定是极度冗余的比如纯粹的版权声明或者完全无关的调试输出。两种极端情况下少数派的信息才是最有价值的学习信号——而逐样本平衡机制正是为了保护这些少数派的信号不被淹没。在消融实验中研究团队对比了BCE标准交叉熵、Focal标准聚焦损失、Dice损失、Tversky损失以及他们自己设计的逐样本平衡Focal损失在100个样本的保留测试集上同时用F1分数和LLM评判分数由GPT-5.4-mini在1-10分的量表上打分评估裁剪后的内容是否足够让AI完成任务衡量效果。结果显示逐样本平衡Focal损失在两项指标上均表现最佳——F1为0.635LLM评判分为7.08——相比标准BCEF1提升了0.16LLM评判分提升了1.13。一个有趣的细节是Dice损失和Tversky损失的F1值与逐样本平衡Focal损失相近均为0.591但LLM评判分却分别只有5.30和3.03远低于对方。这揭示了F1分数的局限性一个模型可能只保留了少数高置信度的行在集合匹配上表现不错但保留下来的内容缺乏上下文AI根本无法据此完成工作。LLM评判分更能反映保留内容的实际可用性而不仅仅是保留集合与标注集合的重叠程度。研究团队用两个具体案例对这种差异做了详细的质性分析一个案例中BCE方法在pdm库的解析器代码上只保留了4行函数签名没有函数体、没有导入AI看了无从下手LLM评判仅2分而逐样本平衡Focal方法保留了30行涵盖导入、类型检查块、函数体LLM评判8分——尽管F1反而是前者更高。---**四、长度感知嵌入和额外计算开销两个工程细节的实测效果**长度感知嵌入带来了多大的提升消融实验给出了清晰的答案加入长度嵌入后LLM评判分从6.86提升到7.08而F1几乎没有变化0.636 vs 0.635。这个结果很耐人寻味。长度嵌入并没有改变总体的行级别分类准确率F1不变但它改变了错误的分布位置它让判断头在短输出上更保守不敢乱删在长输出上更激进放心地大量删除把错误集中到了危害更小的地方。这正是设计的初衷——LLM评判分的提升意味着裁剪后的内容更加可用即便总错误数没有减少错误发生的位置从致命伤变成了皮外伤。研究团队还专门测量了SWE-Pruner Pro在实际部署时引入的额外计算开销。他们用16个轨迹的MiMo-V2-Flash回放实验来量化这一点开启判断头之后裁剪调用的累计耗时占到AI总生成时间的15.0%第50百分位数约14.7%第95百分位数约34.8%。这个15%的额外开销乍一听似乎不小但有几个因素让它变得可以接受。第一裁剪开销只在每轮AI生成之后发生一次而它带来的token节省却会惠及之后所有轮次的生成——随着轮次增加节省的总量远大于增加的代价。第二这个15%是相对于AI的生成时间而言的而不是总体挂钟时间在实际部署中AI的解码生成过程本身已经经历了多年的工程优化是极度高效的所以15%并不意味着用户会感知到明显的等待时间增加。第三研究团队指出如果把判断头的参数量化压缩精度、或者使用更高效的序列化方式这个开销还有相当大的压缩空间。在工程实现上研究团队选择了SGLang一个主流的大模型推理框架作为服务器开启了其内置的返回隐层状态功能并为此修复了三个原本存在于隐层状态传输路径上的正确性漏洞混合批次中的对齐问题、分块预填充下的截断问题以及前缀缓存命中时的遗漏问题。他们还将隐层状态的序列化格式从嵌套JSON浮点列表一个16000 token的隐层张量用这种格式传输会膨胀至1-3GB的文本改为base64二进制封装float16精度同样的张量压缩至85MB实现了约20倍的传输体积缩减。---**五、四个测试集上的全面评测省钱又不降质偶尔还能涨分**研究团队在四个基准测试集上评估了SWE-Pruner Pro的实际效果并与六种现有的裁剪/压缩方法进行了对比使用了两种不同的开源AI模型骨干。四个测试集的性质各不相同覆盖了从简单问答到复杂代码修改的多种场景。SWE-QA包含144个需要多轮工具调用才能回答的代码仓库理解问题SWE-QA-Pro包含260个类似但更难的问题且运行在真实可执行的环境中Oolong本来是一个单轮长上下文理解基准研究团队将其改造成了多轮工具调用场景AI通过grep、awk等命令工具在沙箱文件里查找和汇总信息SWE-Bench Verified包含500个真实的GitHub代码仓库修复任务是衡量AI编程代理能力最权威的基准之一。两种AI骨干分别是MiMo-V2-Flash小米开发的309B参数混合专家模型每次只激活15B参数和Qwen3-Coder-Next阿里开发的80B参数混合专家模型每次只激活3B参数两者都是专门为长上下文编程任务优化的模型。在SWE-QA、SWE-QA-Pro和Oolong三个问答类测试集上SWE-Pruner Pro是七种方法中唯一一个在所有测试格子两种骨干×三个测试集6个格子中都能同时减少token消耗、且保持任务质量不明显下滑的方法。最高节省达39%Qwen3-Coder-Next在SWE-QA-Pro上长上下文场景的最高节省达30%MiMo-V2-Flash在Oolong上。对比来看其他方法的表现都有明显的短板。LLMLingua2在Oolong上用MiMo-V2-Flash骨干时token消耗不降反升189.8%——原因是它的压缩逻辑需要额外的处理步骤反而带来了更多的token开销。Selective Context和RAG基于检索的方法在某些格子上也出现了token膨胀的情况。Self-Prune让AI骨干自己重新回答哪些行该保留的方法在质量上有明显损失在token上的节省也有限。LongCodeZip基于函数级别困惑度排名的代码压缩方法效果参差不齐。SWE-Pruner这项研究的前作需要在每轮对话中让AI生成一个目标提示然后交给独立的评分模型判断哪些行重要效果相对不错但它有两个额外成本每轮都要AI多生成一段文字以及调用一次额外的评分模型总开销并不小。在质量指标上Qwen3-Coder-Next骨干下SWE-Pruner Pro是唯一一个在SWE-QA和SWE-QA-Pro两个测试集上分数高于或持平基线不裁剪时的分数的裁剪方法分别为0.02和0.24。在MiMo-V2-Flash骨干下SWE-Pruner Pro在Oolong上的准确率从92.4%提升到94.6%提升了2.2个百分点——裁剪反而让AI答得更准了。这个反直觉的结果可以用去噪来理解当冗余信息被清除后AI在有限的注意力资源下能更清晰地聚焦于真正有用的内容避免了在噪音中迷路的问题。在SWE-Bench Verified这个代码修复任务上情况略有不同。MiMo-V2-Flash骨干下所有裁剪方法都提升了解决率SWE-Pruner的提升最大4.2%从326/500到347/500SWE-Pruner Pro紧随其后3.8%达到345/500但SWE-Pruner Pro的token增量只有7.4%而SWE-Pruner的token增量高达14.9%——也就是说SWE-Pruner Pro用大约一半的额外token开销换取了相近的质量提升。在Qwen3-Coder-Next骨干下所有裁剪方法都造成了解决率下降SWE-Pruner Pro的下降幅度最小-1.2%仅损失6道题同时实现了所有方法中最大的token节省-13.5%。这表明裁剪对这个模型的伤害相对最小是最不坏的选择。研究团队还注意到一个有趣的现象在SWE-Bench Verified上API调用次数和token消耗量有时会朝相反方向变化。SWE-Pruner Pro在MiMo-V2-Flash上的API调用次数是所有方法中最多的111.8次 vs. 基线的94.8次但token消耗却是最少的之一。原因在于裁剪改变了AI在后续轮次中看到的历史内容这会影响AI的决策路径有时会导致AI需要更多轮次才能完成任务但每轮的上下文更短、更聚焦。这两个指标在不同骨干上的表现方向甚至相反因此研究团队选择分别报告而不是合并成单一效率数字。---**六、对比和局限这项研究能做什么不能做什么**SWE-Pruner Pro与现有方法的本质区别在于信息来源。通用型压缩方法如LLMLingua2使用固定的替代指标如困惑度、自信息等来判断token的重要性这些指标与AI当前任务的关联很弱——不管AI在处理什么问题压缩逻辑都是一样的对AI的实际信息需求视而不见。基于检索的方法如RAG把工具输出拆成片段用向量相似度检索最相关的片段但相似度不等于有用性而且检索本身也有额外开销。代码结构感知的压缩方法如LongCodeZip尊重了代码的语法边界但依然使用固定策略不随任务变化。SWE-Pruner前作是最接近SWE-Pruner Pro的方法它明确考虑了AI的当前任务但需要每轮让AI额外生成一段目标提示goal-hint query然后把这个提示交给一个独立的评分模型来判断哪些行重要。这个流程意味着每轮两次额外的model call一次生成目标提示一次评分以及大量的token消耗。SWE-Pruner Pro彻底绕开了这两个额外步骤不需要AI生成目标提示不需要独立评分模型直接读取AI骨干在预填充时产生的内部状态。信息本来就在那里不过之前没有人意识到可以直接使用它。当然这项研究也有两个明确的局限。第一它目前只能用于开放权重open-weight模型——也就是可以访问内部参数和隐层状态的模型对于闭源模型如GPT-4、Claude等无法读取隐层状态这套方案需要重新设计。第二每换一种骨干模型判断头就需要重新训练因为不同模型的隐层表示维度和语义都不同。不过训练成本相对较低研究中提到在8块H200 GPU上训练10个epoch只需约15分钟这个局限在实践中并不算严重的障碍。在应用范围上尽管训练数据以Python代码为主约39.5%这套方法在Oolong这个自然语言聚合任务上同样取得了良好效果表明隐层状态中的重要性信号并不局限于代码场景而是一种更通用的能力。---说到底这项研究揭示了一个被长期忽视的事实AI在被动地读完一段内容之后它的内部世界已经悄悄地形成了什么重要、什么不重要的判断只不过这些判断一直深埋在数字向量里没有被利用起来。SWE-Pruner Pro做的不过是在AI旁边放了一个小小的翻译器把这些内心判断变成了实际的删除动作。这对普通用户意味着什么最直接的影响是成本AI编程助手处理一个任务所消耗的token减少了云服务的账单就会变小。其次是质量上下文更干净、更聚焦的AI助手在某些情况下反而表现得更好因为它不再被大量无关信息分散注意力。从更宏观的视角看这项研究还指向了一个更深的问题我们已经在大量使用AI模型的内部表示来理解它的输出但还有多少信号被隐藏在这些表示里等待被发掘利用判断信息重要性只是其中一种可能。有兴趣深入了解技术细节的读者可以通过arXiv:2607.18213v1查阅完整论文代码也已在论文主页开源供感兴趣的工程师直接使用和改进。---**QA**Q1SWE-Pruner Pro和普通的AI上下文压缩方法有什么根本区别A普通压缩方法比如LLMLingua2用困惑度等固定指标来判断哪些词重要不管AI在做什么任务都用同一套标准和AI的实际需求脱节。SWE-Pruner Pro则直接读取AI模型自己在处理工具输出时产生的内部表示隐层状态这些状态已经隐含了AI对哪行内容和当前任务相关的判断不需要额外的评分模型或让AI重新描述自己的目标。Q2SWE-Pruner Pro会不会因为删掉内容导致AI产生错误答案A研究实验显示在大多数测试场景中SWE-Pruner Pro裁剪后的任务质量与不裁剪相差极小甚至在部分场景如Oolong测试集和SWE-Bench Verified的MiMo-V2-Flash骨干出现了质量提升因为去掉冗余内容后AI反而更容易聚焦。但研究也明确指出在特定骨干模型Qwen3-Coder-Next的代码修复任务上会损失约1.2%的解决率所以在实际部署前需要针对具体场景验证。Q3SWE-Pruner Pro能用在ChatGPT或Claude这类闭源AI上吗A目前不能。SWE-Pruner Pro需要访问AI模型的内部隐层状态相当于模型处理文字时的内心感受数值而闭源模型的这些内部数据对外不开放。现阶段该方法只适用于开源或开放权重的大模型比如论文中使用的MiMo-V2-Flash和Qwen3-Coder-Next。如果应用于新的开源模型还需要重新训练一个对应的轻量级判断头。