这项由KR Labs机构开展的研究以预印本形式发布于2026年4月4日，arXiv编号为2604.04979，收录于计算机科学·软件工程（cs.SE）分类。有兴趣深入了解的读者可以通过该编号在arXiv平台检索完整论文。
**程序员的"智能助手"有个藏了很久的小毛病**
假设你雇了一个助理，每次你问他"刚才那条报错信息是什么？"，他都会把整本日志从头到尾念给你听，哪怕你要的答案只藏在第183行那短短两句话里。这不只是浪费时间，每念一遍都要花真金白银——因为今天的AI助手按"读了多少字"来收费。
这正是当下所有"编程智能体"（Coding Agent，可以理解为能自动写代码、找bug、修问题的AI程序）都面临的真实困境。这类系统每完成一步操作，都要去读文件、跑命令、看输出——文件扫描结果、报错日志、测试报告、版本历史……每一份输出动辄几百行，但真正有用的往往就那么几行。AI助手却不得不把每份输出从头读到尾，浪费大量算力，也拖慢了整个工作流程。
KR Labs的研究者把这个问题叫做"工具输出修剪"（Tool-Output Pruning）——核心思路是：在AI助手读取工具输出之前，先用另一个小模型把没用的内容剪掉，只把真正有价值的那几行传给AI。他们把这套系统起名叫**Squeez**（挤压、精简之意），并围绕它做了一套完整的测评基准、数据集和模型。
研究结果相当出人意料：一个只有20亿参数的小模型（Qwen 3.5 2B），经过针对性训练后，不仅能在删掉92%无关内容的同时保住86%的关键信息，还把一个比它大18倍的模型（Qwen 3.5 35B）远远甩在了身后。
一、为什么"智能助手读太多"是个大问题？
回到那个助理的比喻。现实中的编程智能体在解决一个软件问题时，会经历一连串操作：打开某个文件看看里面的代码，用搜索命令找某个关键词，跑一遍测试看看哪里失败了，查一下版本历史看谁动过这行代码……每一步操作都会产生"工具输出"——也就是命令执行完之后屏幕上吐出来的那些文字。
问题在于，这些输出往往非常冗长。一次文件读取可能返回上千行代码；一次测试运行可能产生几百行日志；一次版本历史查询可能列出几十条提交记录。而AI智能体在决定下一步怎么做之前，需要把这些内容全部"读"进去。在大型语言模型的世界里，"读"是要花钱的——读的字越多，消耗的算力越多，速度越慢，成本越高。
麻烦的是，相关内容往往只占整个输出的很小一部分。一条ImportError的原因可能就藏在500行文件里的某个函数定义里；一次构建失败的根因可能是110行构建日志中的那一行Dockerfile语法错误。其余的内容对于当前这个决策步骤毫无价值，却必须全部占用AI的"阅读"资源。
这就是Squeez要解决的问题：在AI助手读输出之前，先做一道"精准筛选"，只保留当前任务真正需要的那部分内容。
二、Squeez的工作方式：一个"专职过滤器"的诞生
Squeez的基本逻辑可以用一个图书馆助理的场景来理解。你去图书馆查资料，不是直接把整本书搬回家，而是先告诉助理："我要找关于1920年代上海租界的经济数据，在那本500页的历史书里。"助理熟悉书的结构，直接翻到相关章节，把那几页复印给你。Squeez扮演的就是这个"熟悉书本结构"的图书馆助理角色。
具体来说，Squeez接受两样东西作为输入：一个简短、具体的"提取查询"（Extraction Query），以及一份原始的工具输出文本。提取查询是对当前任务需求的精确描述，比如"找到解释ImportError的调用栈"或者"找出影响xr.polyval维度顺序变化的那条提交记录"。工具输出则是命令执行后原封不动的输出内容。
Squeez的输出是原始文本中的一段或几段连续行——不是改写，不是总结，而是原文的直接摘取。研究者把这称为"逐字证据块"（Verbatim Evidence Block）。这一点很关键：AI助手读到的依然是原汁原味的代码、日志或命令输出，只是去掉了无关的部分，不存在任何信息被曲解或改写的风险。
在系统架构上，Squeez被设计成一个轻量级的"预处理步骤"，插在工具执行和AI助手读取之间。工具跑完、输出出来，先经过Squeez过滤，再传给AI助手。这意味着不需要改动AI助手本身的任何逻辑，只需在它"眼睛"前面加一个过滤镜。研究团队已经把它做成了可以接收管道输入的命令行工具（CLI），也可以通过vLLM这个高效推理框架来部署，接入现有的编程智能体系统（比如Codex或Claude Code）几乎不需要额外的工程改造。
三、造一把"尺子"：11477个例子构成的测评基准
要知道Squeez做得好不好，首先得有一把靠谱的"尺子"。研究团队为此专门构建了一个包含11477个样本的测评基准，这本身就是这项研究的重要贡献之一。
数据来自两个不同的源头，这两个源头的结合非常有意思。第一个源头是SWE-bench——这是学术界广泛使用的一个软件工程基准，包含了大量真实的GitHub代码仓库和对应的问题。研究团队克隆了这些仓库的快照，然后在上面实际运行了14种不同类型的工具：读取文件、grep搜索、Git提交历史、Git代码归属查询、测试运行器、代码风格检查、类型检查器、pip包安装、curl网络请求等等，总共收集了10713条原始工具输出。这些都是编程智能体在真实工作中会遇到的东西。
第二个源头是为了弥补SWE-bench的局限性。SWE-bench主要是Python项目，但现实中的工程师还要面对TypeScript、Go、Rust、Java、Docker容器、Terraform基础设施代码、Kubernetes集群管理等各种技术栈。于是研究团队用一个大型语言模型（openai/gpt-oss-120b）生成了2039条涵盖这些技术生态的合成工具输出，让测评基准的覆盖范围更加全面。此外，他们还专门构造了575个"陷阱样本"——查询和工具输出故意不匹配，正确答案是"什么都不提取"，用来测试模型是否能识别出"这里根本没有你要的东西"的情况。
最终发布的基准包含9205条SWE衍生样本、1697条合成正例和575条合成负例，横跨27种工具类型。其中数量最多的是文件读取（3768条）、grep搜索（1330条）、Git提交日志（720条）、Python异常（698条）、curl输出（493条）、pip安装（441条）等。
每个样本的构建遵循一套统一的"教师标注流水线"：给定原始工具输出和背景任务，用大模型先写一个聚焦的提取查询——注意是局部的信息需求，不是完整的问题描述——然后再选出能回答这个查询的最小连续文本段。模型看到的是带行号的工具输出，以便精确定位，但最终存储在数据集里的标注是映射回原始文本的坐标，确保每个答案都是原文的逐字摘取。
测试集的把关尤为严格。从729个候选测试样本中，有111个（占比15.2%）被人工审核后剔除，理由包括：与其他样本过于相似、输出内容太短（只有一两行）没有测试价值、标注的范围过于宽泛、或者标注本身有误。最终的618个测试样本全部经过人工复核，质量有保障。
四、训练一个"专才"而不是"通才"
Squeez的核心模型是Qwen 3.5 2B——一个来自阿里云Qwen系列的20亿参数语言模型。选择这个模型有明确的工程考量：研究者的目标不是找一个能凭空推理出问题答案的"大脑"，而是训练一个能在现有智能体系统里高效运行的"专职过滤器"。20亿参数的模型足够轻量，可以以很低的成本运行，而Qwen 3.5系列本身在代码理解和推理方面有不错的基础能力，正好适合这个任务。
训练方式采用了LoRA（低秩自适应，一种只调整模型中少量参数的高效微调技术）。可以把它理解为：不需要重新培训一个员工的所有技能，只需要给他加一堂专项技能课。训练在一张NVIDIA A100 80GB显卡上进行，跑了三轮（epoch），序列最大长度设置为20000个token（大约够处理一份很长的工具输出），学习率2×10??，加上梯度累积、预热策略和权重衰减等常规训练技巧。
模型的输入格式很直接：提取查询和工具输出按照固定格式组合成一个提示，模型被训练输出用``标签包裹的逐字提取文本。训练完成后，LoRA适配器被合并进基础模型，通过vLLM高效推理框架部署使用。
评估指标的选择体现了这个任务的特殊性。研究者选定了四个主要指标：召回率（Recall，衡量金标准内容被覆盖了多少）、F1分数（综合考虑精确率和召回率的平衡指标）、严格精确文本匹配F1，以及压缩率（Compression，输入中被删除的比例）。评估的基本单位是"行"——预测结果和标准答案都表示为行集合，逐行比较。F1的计算采用了一种"容忍模糊匹配"的方式，只要预测行和金标准行的文本相似度超过0.5就算匹配，这是为了应对生成式模型输出中可能存在的微小格式差异。整个评估框架把召回率放在比精确率更重要的位置，因为在这个任务里，漏掉关键信息（召回率低）通常比多保留了一点无关内容（精确率低）危害更大。
五、比赛结果：小个子打败大力士
实验对比的阵容很有代表性。除了Squeez（Qwen 3.5 2B微调版），研究者还测试了三个零样本生成模型——也就是没有经过任何针对性训练、直接按照任务要求回答的模型：比Squeez大约18倍的Qwen 3.5 35B A3B、Kimi K2，以及没有经过微调的Qwen 3.5 2B基础版。另外还有四个启发式基线：BM25（一种基于关键词匹配的经典信息检索算法）、First-N（直接取前10%的行）、Last-N（直接取后10%的行）、Random（随机取10%的行）。后四种基线都保留约10%的内容，与金标准的压缩比例相当，保证比较的公平性。
结果非常清晰。Squeez在保持92%压缩率的同时，召回率达到0.86，F1分数达到0.80，精确率0.79——在所有被测系统中全面领先。Qwen 3.5 35B A3B尽管参数量是Squeez的18倍，召回率只有0.75，比Squeez低了11个百分点。Kimi K2的压缩做得最激进（94%），但付出的代价是召回率只有0.53，漏掉了太多关键内容。未经微调的Qwen 3.5 2B基础版召回率同样是0.53，但过度保留了内容，压缩率只有82%，并且提取结果质量更嘈杂。
四个启发式基线的表现则惨不忍睹。BM25的召回率仅有0.22，First-N是0.14，Random是0.10，Last-N垫底只有0.05。这组数据直接说明了一个关键事实：工具输出里的关键信息可能出现在任何位置，头部、中间、尾部都有可能，而且是否有用取决于具体的查询需求，而非内容的字面关键词。单纯靠位置或词频来做筛选，在这个任务上根本行不通。
从"召回率-压缩率权衡图"（论文中的Figure 2）来看，Squeez占据了左上角的最优位置——高召回率加高压缩率，而其他系统要么在两个维度上都不如它，要么存在明显的取舍问题。
六、它在哪些情况下表现最好，又在哪里会出错？
定性分析揭示了Squeez成功和失败的规律，读起来颇为有趣。
在结构化输出中精准命中方面，以Git提交日志为例：21行的日志里，查询要求找到与xr.polyval维度顺序变化相关的提交。Squeez直接找到了那唯一正确的一条。相比之下，Qwen 35B选了一条"看起来也跟转置操作有关"但其实是错的提交，未微调的2B基础版则把几条polyval相关的提交全选了进去。
在噪声环境中提取故障块方面，以176行的服务日志为例：查询要求找到影响健康检查请求的TLS握手失败信息。Squeez返回了正确的5行健康检查失败块。Qwen 35B选了日志里稍后出现的一次支付请求TLS失败（语义相近但不是问的那个），Kimi K2只保留了正确块的一部分。
在识别"查无此物"方面，当查询问的是日志里是否存在numpy版本冲突，而日志里根本没有这个问题时，Squeez正确地返回了空输出。在测试集的59个负例样本中，Squeez有80%的时候都能给出空输出，而Qwen 35B只有7%的时候能做到这一点——多数情况下它会生成一段解释性文字，比如"未发现相关行……"，这显然不是过滤器应该输出的格式。
Squeez的主要失误模式是"相邻过度选取"：找到了正确的内容，但顺手把旁边的相关内容也带进来了。以110行构建输出为例，查询要求找第12行的Dockerfile语法错误，Squeez找到了，但同时把附近一个Python SyntaxError也选了进去。这类错误通常是"多了一点"而不是"找错了地方"，危害相对有限。
Figure 3给出了一个更直观的例子：250行的kubectl输出，查询要求找出analytics-worker容器的OOMKilled原因和退出码。金标准答案是两行："26: Reason: OOMKilled"和"27: Exit Code: 137"。在整个250行的输出中，Squeez准确地锁定了这两行。
七、这项研究的边界在哪里？
研究者在论文中坦诚地指出了几个局限性，这些局限性也划定了Squeez当前的适用范围。
Squeez评估的是单次工具输出的修剪质量，而不是整个智能体任务流程的最终完成效果。换句话说，它能告诉你"相关证据有没有被保留下来"，但不能直接回答"用了Squeez之后，AI助手解决bug的成功率提高了多少"。后者需要在完整的端到端系统中做实验，这是未来工作的自然延伸。
另一个局限是评估指标本身。用文本行的重叠程度来衡量修剪质量，无法捕捉所有合理的修剪决策——有时候换一种方式截取内容，效果可能同样好甚至更好，但在行重叠指标下会被认为是错误。这是所有基于标注的评估体系都会面临的根本性挑战。
在数据质量方面，某些工具类型的样本质量仍然参差不齐，尤其是grep输出和代码风格检查（lint）输出，这两类工具的输出格式变化较多，标注难度也更大。
说到底，Squeez做的事情看起来简单——把一大堆输出剪成一小块——但背后的道理很深刻。靠关键词匹配做不到，靠截头去尾做不到，靠大模型直接零样本也做不到。真正有效的方法，是针对这个具体任务收集专门的训练数据，然后让一个小模型"死磕"这一件事。用一个专门训练的20亿参数小模型，打败了不经过训练的360亿参数大模型，这件事本身就值得所有在AI工程领域摸爬滚打的人思考一下：什么时候该用"通才"，什么时候该培养"专才"？
对于普通用户来说，Squeez可能暂时还不会直接出现在你的日常工具里。但它所代表的思路——让AI助手的每一步操作都更专注、更高效、更不浪费——将会悄悄影响未来所有编程智能体产品的工程决策。当你下一次用某个AI工具帮你找代码里的bug，它反应更快、更准、费用更低，背后可能就有类似Squeez这样的"幕后过滤器"在默默工作。
对于对这个方向感兴趣的读者，可以通过arXiv编号2604.04979查阅完整论文，模型权重、数据集和评估代码也已在GitHub（KRLabsOrg/squeez）和Hugging Face平台以Apache 2.0协议开源，完全可以自行部署和复现。
Q&A
Q1：Squeez是什么，它和普通的AI压缩工具有什么区别？
A：Squeez是KR Labs开发的一个针对编程智能体工具输出的修剪系统。与LLMLingua等通用提示压缩工具不同，Squeez专门处理混合格式的工具输出（代码、日志、命令结果等），并且是"任务条件化"的——必须同时给出一个具体的提取查询，它才会根据当前任务需求来决定保留哪些内容，而不是无差别压缩。输出的是原文的逐字摘取，不改写内容。
Q2：Squeez的20亿参数小模型为什么能打败360亿参数的大模型？
A：关键在于"专项训练"。Squeez用了11477个专门针对工具输出修剪任务的标注样本做微调，让模型学会了工具输出的特定规律，比如日志里故障块的位置模式、Git提交记录的结构特征等。而大模型是零样本使用的，没有接受过这类专项训练，面对重复性日志或格式化输出时容易选错相邻的内容块。这说明在高度具体的任务上，针对性训练比模型规模更重要。
Q3：Squeez数据集里的11477个样本是怎么来的？
A：样本来自两个来源。一部分是在SWE-bench的真实代码仓库上实际运行14种工具（文件读取、grep、Git日志、测试运行等）收集的真实输出，共9205条。另一部分是用大模型生成的合成工具输出，覆盖TypeScript、Go、Rust、Java、Docker等Python以外的技术生态，共1697条正例和575条专门设计的"查无此物"负例。所有样本都经过统一的大模型标注流水线处理，测试集中618个样本全部经过人工复核。
AI助手
资讯
常用工具
网站模板