Squeez：面向编码智能体的任务条件工具输出剪枝 Squeez: Task-Conditioned Tool-Output Pruning for Coding Agents
Squeez用2B小模型对编码智能体的工具输出做任务条件剪枝，召回86%时压缩92%输入。
前置知识
LoRA（Low-Rank Adaptation）
LoRA 是参数高效微调方法。它冻结预训练模型主体权重，仅在每层注入两个低秩矩阵 $A$、$B$，通过学习 $\Delta W = BA$ 适配下游任务。训练参数少、显存低，推理时可与原模型合并而不增加延迟。
Squeez-2B 的整个训练流程建立在 LoRA 之上（lr $2 \times 10^{-4}$、3 epoch），理解低秩适配与全参数微调的区别，是读懂论文为何能用单卡 A100 80GB 完成 2B 模型微调的关键。
SWE-bench 基准
SWE-bench 是评估 LLM 在真实 GitHub issue 上软件工程能力的基准，收集 12 个开源 Python 仓库的 issue-PR 对，要求模型生成能通过单元测试的代码补丁。本文用它构造 14 类工具的真实工作流。
Squeez 基准 11477 条样本中 9205 条来自 SWE-bench 真实工作流，是论文能区别于'合成玩具数据'并保证观察真实性的根基；理解 SWE-bench 才能把握 benchmark 数据为何覆盖丰富。
提取式问答（Extractive QA）
提取式问答要求模型直接从给定上下文中定位并抽取答案片段，而非自由生成，SQuAD 是经典代表。它标注答案在原文中的字符或句子跨度，强调答案可溯源以避免幻觉，是本文任务'从工具输出中抽取证据块'的方法学根基。
Squeez 的输出形式 $Y = \{(s_1, e_1), \ldots, (s_k, e_k)\}$——行级连续跨度集合——本质上是 Extractive QA 在工具观察上的实例；理解这种范式才能把握为何 Squeez 要'逐字保留'而非'摘要改写'。
RAG 上下文剪枝
RAG 通过检索外部文档增强 LLM 回答质量，但检索段落常含大量无关内容。上下文剪枝旨在压缩保留相关信息以提升效率与准确性，代表方法如 EXIT、Provence、Zilliz Semantic Highlight 等。
Squeez 与 EXIT/Provence 同属'查询条件下的内容过滤'问题族，但处理对象从'检索段落'换成'编码智能体循环中的工具观察'；对比 RAG 剪枝的差异是理解 Squeez 切入口的必要参照。
编码智能体（Coding Agent）
编码智能体是自主完成软件工程任务的 LLM 系统，代表如 SWE-Agent、OpenHands、Claude Code、Codex 等。它在循环中调用读文件、grep、git log、测试等工具观察输出后推理下一步动作。工具观察常含大量代码与日志。
Squeez 解决的问题正源于此：read file 平均 1677 token、type check 平均 3418 token 的工具观察中，真正相关的行往往只占极小部分；理解编码智能体循环是把握'Squeez 作为可插拔剪枝器'这一部署形态的前提。
研究动机
现代编码智能体（如 SWE-Agent、Codex、Claude Code）在解决 GitHub issue 时，会反复调用文件读取、grep、git log、测试运行器、构建工具等多种工具，每次返回的观察通常包含数百到数千行内容。论文统计显示 read file 类观察平均 1677 输入 token，type check 类高达 3418 token。然而下一步决策真正需要的信息往往只占观察总量的极小一部分，智能体却必须重读整个输出来定位关键证据。这种'低信息密度-高 token 消耗'矛盾使剪枝成为核心效率瓶颈。当前的解决路径存在三类不足：一是 LLMLingua、LongLLMLingua 等提示压缩方法面向自然语言提示而非混合格式工具观察；二是 EXIT、Provence 等 RAG 上下文剪枝器假设输入是检索段落，无法处理代码、日志、shell 跟踪、结构化输出交错的情况；三是 SWE-Pruner、FocusAgent 等针对编码智能体的剪枝器要么聚焦仓库级代码而非单一工具观察，要么仅适用于网页智能体。三者都未把'工具观察剪枝'作为独立的有监督基准任务对待。
本文的目标是本文的核心目标是将工具观察的剪枝问题重新定义为一项独立的、有监督的基准任务。具体而言，给定一个聚焦的查询 $q$（描述智能体下一步需要的信息）和一个原始工具观察 $o$（可能包含代码、日志、堆栈、shell 输出等），要求模型返回最小化的、逐字保留的证据块 $\{(s_1, e_1), \ldots, (s_k, e_k)\}$——即 $o$ 中若干连续行号区间，使得智能体在下一推理步中能据此推进。该任务被刻意收窄：不要求解决 bug、不要求生成补丁，只要求保留相关证据、丢弃其余。更重要的是，作者希望证明：(1) 这是一项可学习的、有明确监督信号的窄任务；(2) 小模型经过 LoRA 微调后可以显著优于远大于它的零样本生成模型（2B vs 35B）；(3) 该任务在编码智能体栈（Codex、Claude Code 等）中可以以 vLLM 服务或 CLI 过滤器的形式低成本集成，不改动核心规划逻辑。
与已有工作不同的是，本文最独特的切入角度是提出'任务条件的工具输出剪枝'作为一项独立基准任务，并首次构建了配套的数据集、评估协议和模型，与已有方法形成明确区隔。区别于 LLMLingua 等提示压缩方法，本文处理的是混合格式（代码 + 日志 + 元数据）的单一工具观察；区别于 EXIT、Provence 等 RAG 剪枝器，本文输入不是检索段落而是智能体循环中的工具观察；区别于 SWE-Pruner（聚焦仓库级代码上下文）和 FocusAgent（针对网页智能体），本文的剪枝对象是单条工具观察中真正相关的那一两个连续行块。在数据层面，作者既使用 SWE-bench 真实工作流，又用 gpt-oss-120b 合成了跨生态系统的工具观察（TypeScript、Go、Rust、Java、Docker、Terraform、Kubernetes），覆盖 27 种工具类型，并专门构造 575 条显式负例让模型学会'该返回空时就返回空'。在评估层面，提出基于行的 recall、严格 F1、模糊 F1、压缩率四维指标，把这一领域从经验性技巧转化为可量化的基准研究。
核心方法
作者的方法体系由三部分组成：基准构建、教师标注、模型训练与部署。直觉上，编码智能体在每一步都像在'读一份大文档找一句话'，与其让 LLM 用整篇文档推理，不如训练一个专门的、廉价的'高亮器'：给定查询，它指出哪些行相关。技术上，基准来源包括两个——SWE-bench 仓库快照上执行 14 类工具产生的 10713 条真实观察，以及 gpt-oss-120b 生成的 2039 条跨生态系统合成观察。两条路径都经过统一的两阶段教师标注流水线：教师模型先基于背景任务和原始观察生成聚焦的、工具感知的提取查询（不是完整 issue 描述），然后在编号化的观察中挑选能回答该查询的最小连续行块或多块。教师看到带行号的渲染版，但释放的标签映射回原始文本的逐字行块——保证每个目标都是源观察的字面子集。最后丢弃查询无法被观察支持的正例；用 `` XML 包裹的提取文本作为生成训练目标，在 Qwen 3.5 2B 上做 3 epoch LoRA 微调；推理时合并 LoRA 适配器，通过 vLLM 服务或 CLI 过滤器部署到智能体循环。
本文的核心创新是'重新定义问题边界'——把工具观察剪枝从隐式的提示工程操作，转变为一项有明确输入（查询+观察）、明确输出（行级连续跨度集合）和明确评估指标（recall、严格 F1、模糊 F1、压缩率）的有监督基准任务。这一重构带来三方面本质区别。第一，目标形式不同：传统方法要么做抽象摘要（不可溯源），要么做文档级相关度排序（粒度太粗），本文要求输出严格的'行号区间集合'——既能精确评估，又保证证据逐字可溯源。第二，监督信号不同：传统方法缺乏针对工具观察的标注数据，本文通过两阶段教师流水线构造了 11477 条带跨度标签的样本（含 575 显式负例）。第三，工程形态不同：Squeez-2B 不是又一个被调用的 LLM，而是可插拔的'剪枝器'——既可作 vLLM 服务，也可作消费管道输入的 CLI 过滤器，能以 92% 压缩率插入 Codex/Claude Code 等现有智能体栈而不改变核心规划逻辑。这把'大模型生成'问题转化为'小模型提取'问题——经验上 2B 微调模型比 35B 零样本模型在该任务上 recall 高 11 个百分点。
方法步骤详情
方法分四步。**步骤一·数据采集**：(a) SWE-bench 来源——克隆 12 个仓库快照运行 14 类工具，收集 10713 条真实观察；(b) 合成来源——gpt-oss-120b 为 TS/Go/Rust/Java/Docker/Terraform/K8s 生成 2039 条观察；(c) 显式负例——不匹配查询与观察配对 575 条。**步骤二·教师标注**（两阶段）：教师先写聚焦的、工具感知的提取查询，再选最小连续行块或多块；标签映射回原始文本保证逐字可溯源；丢弃查询无法被观察支持的正例。**步骤三·划分**：按仓库/工具族划分得 10508 训练、240 验证、618 测试；测试集从 729 候选中人工剔除 111 条。**步骤四·训练与部署**：Qwen 3.5 2B 上 LoRA 微调，3 epoch、max seq 20000、batch size 8、grad accum 4、lr $2 \times 10^{-4}$、warmup 0.05、weight decay 0.01；单卡 A100 80GB；推理合并 LoRA 适配器，通过 vLLM 部署。
技术新颖性
技术新颖性体现在三个层面。**问题形式化层面**：首次将工具观察剪枝形式化为 $(q, o) \to Y = \{(s_1, e_1), \ldots, (s_k, e_k)\}$ 的行级跨度预测任务，与 prompt compression、document-level RAG pruning、abstractive summarization 有本质不同——输出粒度细、严格可溯源、有精确评估指标。**数据构造层面**：两阶段教师流水线配合原始观察的逐字映射，避免了教师自由改写引入的偏差；显式负例（575 条）让模型学会'不该提取时不要硬提'——在 59 条负例测试集上 Squeez-2B 80% 正确返回空，而 Qwen 35B 仅 7%。**训练范式层面**：用 2B 小模型 LoRA 微调替代 35B 零样本推理——92% 压缩目标下小模型 LoRA 比大模型零样本 recall 高 11 个点、压缩率相同，说明该任务对生成能力需求有限、对任务特定的提取模式学习需求强烈。可插拔的部署形态（vLLM + CLI 管道）让 Squeez 能以'剪枝器'角色嵌入现有智能体栈。
实验结果
论文报告四大类核心发现。**主要结果**（Table 4）：Squeez-2B 在 618 条人工评审测试集上达到 Precision 0.80、Recall 0.86、Strict F1 0.79、模糊 F1 0.80、压缩率 92%，同时取得最高 precision 和 recall。比 18 倍大的 Qwen 3.5 35B A3B 零样本高 11 个 recall 点（0.86 vs 0.75），比未微调的 Qwen 3.5 2B 基座高 33 个 recall 点。**压缩-召回权衡**（Figure 2）：Squeez-2B 在 Pareto 前沿右上角明显领先——同等压缩下 recall 更高。**零样本基线失败各异**：Qwen 35B 在重复日志或 git 历史中常选语义相邻但错误的块；Kimi K2 是最激进的压缩器（0.94 压缩）但 recall 仅 0.61；未微调 2B 基座压缩不足（0.82）且提取更噪。**启发式基线崩盘**：BM25 recall 仅 0.22；First-N/Last-N/Random (10%) recall 0.05–0.14。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 工具输出剪枝（人工评审 618 例测试集） | Recall（行级） | 0.86 | Qwen 3.5 35B A3B 零样本 0.75；Qwen 3.5 2B 零样本 0.53；Kimi K2 0.61；BM25 0.22 | 比 18× 大的 Qwen 35B 高 +0.11；比同尺寸未微调基座高 +0.33；比最强启发式 BM25 高 +0.64 |
| 工具输出剪枝 | Precision（行级） | 0.80 | Qwen 35B 0.74；Kimi K2 0.61；Qwen 2B 0.42；BM25 0.07 | 比 Qwen 35B 高 +0.06，且为所有基线中最高 precision |
| 工具输出剪枝 | F1（模糊子串阈值 0.5） | 0.80 | Qwen 35B 0.73；Kimi K2 0.68；Qwen 2B 0.55；BM25 0.23 | 比 Qwen 35B 高 +0.07，比基座高 +0.25 |
| 工具输出剪枝 | Strict F1（精确文本匹配） | 0.79 | Qwen 35B 0.70；Kimi K2 0.53；Qwen 2B 0.41；BM25 0.13 | 比 Qwen 35B 高 +0.09，比基座高 +0.38 |
| 工具输出剪枝 | Compression（输入被移除比例） | 0.92 | Qwen 35B 0.92；Kimi K2 0.94；Qwen 2B 0.82；启发式 0.90-0.91 | 压缩率与最强零样本基线持平，但 precision/recall 全面领先 |
| 真负例识别（59 条负例） | 正确返回空输出率 | 80% | Qwen 35B 7%；Qwen 2B 基座接近 0% | 比 Qwen 35B 高 +73 个百分点，体现显式负例训练的关键价值 |
局限与改进
作者明确承认了论文的三大局限。**第一**，基准评估的对象是单条工具观察而非完整智能体轨迹——这意味着它直接衡量证据保留质量，但不直接衡量端到端任务完成度。一个可能的情况是：剪枝后保留了正确的证据块，但智能体因为其他原因（如规划错误）仍无法解决 issue；论文没有给出端到端的 SWE-bench 任务成功率对比。**第二**，'有用性'用行集与金标的重叠来近似，但无法穷举所有合法的剪枝决策——可能存在多块同样合法的证据选择。**第三**，部分工具族（尤其是 grep、lint）的观察噪声较大，模型在这些族上 recall 显著低于 read file 之类结构化输出。从我自己的观察看，还有几个未明说的弱点：(a) 训练数据严重依赖 gpt-oss-120b 教师标注，存在教师偏差传染给 Squeez-2B 的风险；(b) 评估仅在 618 条测试集上完成，模型可能在合成分布上 overfit；(c) 92% 压缩率看起来高，但智能体在多步循环中错过的关键行可能级联放大成最终决策错误。
独立分析的弱点
独立分析本文存在以下弱点和改进方向。**弱点一·评估与真实场景脱节**：单观察剪枝质量不能直接外推到完整智能体循环——智能体在多步决策中会交叉验证、容错，剪枝失误的代价可能小于单步评估显示的；改进方向是在 SWE-bench 完整轨迹上做端到端 A/B，对比'接入 Squeez 剪枝的 Codex'与'无剪枝的 Codex'在解决率、平均 token、平均步数上的差异。**弱点二·教师偏差传染**：所有金标来自 gpt-oss-120b，模型学到的是'模仿 gpt-oss-120b 的行选偏好'——若教师系统性偏好某种行块形态，Squeez-2B 会放大这种偏差；改进方向是引入多教师集成或人工二次修订关键子集。**弱点三·行级粒度的局限**：部分工具（JSON 响应、base64 日志）的'行'语义并不对应'证据单元'；改进方向是引入字符级或语义块级评估。**弱点四·对查询质量的依赖**：当查询写得不够'局部'时，剪枝器会保留更多上下文，压缩率下降；改进方向是联合训练查询改写器与剪枝器。
未来方向
作者在结论与局限部分点出了一些未来方向，我结合成果可延伸性补充如下。**作者提出的方向**：(1) 评估从单观察扩展到完整智能体轨迹，量化剪枝对端到端任务完成度的影响；(2) 探索多模态工具观察（图像、PDF 表格）的剪枝。**可延伸方向**：(a) **多步累积上下文剪枝**：智能体在长循环中累积多个工具观察，Squeez 应能处理'上下文窗口'级别的剪枝而非单条观察；(b) **跨观察依赖建模**：当一条观察中的行在另一条观察中被引用时，行块提取应联合考虑；(c) **主动学习与在线适应**：根据下游决策成功/失败信号持续微调；(d) **教师-学生蒸馏扩展**：用更大的 Claude 或 GPT-4 做教师蒸馏出 Squeez-2B，比 gpt-oss-120b 教师有更高上限；(e) **检索增强的剪枝器**：先用 BM25 加语义检索预筛候选行块，再让 Squeez-2B 精排，进一步降低单次推理成本；(f) **针对特定工具族的专家模型**：分别训练 read file、test output、log 类工具的专门子模型。
复现评估
复现性方面本文做得相当充分。**代码与模型开源**：模型、评估代码、CLI 工具均公开在 GitHub（github.com/KRLabsOrg/squeez），数据集与训练后模型公开在 Hugging Face，许可证为 Apache 2.0。**数据规模可控**：基准 11477 条样本，教师标注用 gpt-oss-120b 完成；Squeez-2B 训练在单卡 A100 80GB 上 3 epoch 完成，按报告超参数（lr $2 \times 10^{-4}$、batch size 8、grad accum 4、max seq 20000、warmup 0.05、weight decay 0.01）能稳定复现。**评估脚本可重跑**：618 条测试集人工评审，评估指标（recall、strict F1、tolerant F1、compression）实现细节在论文中给出（含 fuzzy substring 阈值 0.5）。**复现难度**：中等偏低——主要门槛在于 gpt-oss-120b API 访问；教师 prompt、负例规则与评审准则未在论文中公开，是潜在复现性缺口。
论文图表
工具族计数表，列出 27 种工具类型在释放基准中的行数：read file 3768、grep 1330、git log 720、python 698、test output 546、curl 493、pip install 441、type check 317、tsc 229、ls 347、git blame 291、build output 168、make cmake 133、npm build 230、docker build 151、cargo build 122、kubectl 123、mvn build 114、gradle 120、lint output 184、mypy 95、pyright 78、eslint 198、docker logs 78、git terraform diff 103、coverage 53 等。
该表说明基准覆盖广度——从 Python 生态（read file、grep、pytest、mypy）扩展到 TypeScript/Go/Rust/Java/Docker/K8s/Terraform——这是论文'多生态系统'与'真实编码智能体多样性'承诺的量化证据。