這項(xiàng)由KR Labs機(jī)構(gòu)開展的研究以預(yù)印本形式發(fā)布于2026年4月4日，arXiv編號(hào)為2604.04979，收錄于計(jì)算機(jī)科學(xué)·軟件工程（cs.SE）分類。有興趣深入了解的讀者可以通過該編號(hào)在arXiv平臺(tái)檢索完整論文。

**程序員的"智能助手"有個(gè)藏了很久的小毛病**

假設(shè)你雇了一個(gè)助理，每次你問他"剛才那條報(bào)錯(cuò)信息是什么？"，他都會(huì)把整本日志從頭到尾念給你聽，哪怕你要的答案只藏在第183行那短短兩句話里。這不只是浪費(fèi)時(shí)間，每念一遍都要花真金白銀——因?yàn)榻裉斓腁I助手按"讀了多少字"來收費(fèi)。

這正是當(dāng)下所有"編程智能體"（Coding Agent，可以理解為能自動(dòng)寫代碼、找bug、修問題的AI程序）都面臨的真實(shí)困境。這類系統(tǒng)每完成一步操作，都要去讀文件、跑命令、看輸出——文件掃描結(jié)果、報(bào)錯(cuò)日志、測(cè)試報(bào)告、版本歷史……每一份輸出動(dòng)輒幾百行，但真正有用的往往就那么幾行。AI助手卻不得不把每份輸出從頭讀到尾，浪費(fèi)大量算力，也拖慢了整個(gè)工作流程。

KR Labs的研究者把這個(gè)問題叫做"工具輸出修剪"（Tool-Output Pruning）——核心思路是：在AI助手讀取工具輸出之前，先用另一個(gè)小模型把沒用的內(nèi)容剪掉，只把真正有價(jià)值的那幾行傳給AI。他們把這套系統(tǒng)起名叫**Squeez**（擠壓、精簡(jiǎn)之意），并圍繞它做了一套完整的測(cè)評(píng)基準(zhǔn)、數(shù)據(jù)集和模型。

研究結(jié)果相當(dāng)出人意料：一個(gè)只有20億參數(shù)的小模型（Qwen 3.5 2B），經(jīng)過針對(duì)性訓(xùn)練后，不僅能在刪掉92%無關(guān)內(nèi)容的同時(shí)保住86%的關(guān)鍵信息，還把一個(gè)比它大18倍的模型（Qwen 3.5 35B）遠(yuǎn)遠(yuǎn)甩在了身后。

一、為什么"智能助手讀太多"是個(gè)大問題？

回到那個(gè)助理的比喻?，F(xiàn)實(shí)中的編程智能體在解決一個(gè)軟件問題時(shí)，會(huì)經(jīng)歷一連串操作：打開某個(gè)文件看看里面的代碼，用搜索命令找某個(gè)關(guān)鍵詞，跑一遍測(cè)試看看哪里失敗了，查一下版本歷史看誰(shuí)動(dòng)過這行代碼……每一步操作都會(huì)產(chǎn)生"工具輸出"——也就是命令執(zhí)行完之后屏幕上吐出來的那些文字。

問題在于，這些輸出往往非常冗長(zhǎng)。一次文件讀取可能返回上千行代碼；一次測(cè)試運(yùn)行可能產(chǎn)生幾百行日志；一次版本歷史查詢可能列出幾十條提交記錄。而AI智能體在決定下一步怎么做之前，需要把這些內(nèi)容全部"讀"進(jìn)去。在大型語(yǔ)言模型的世界里，"讀"是要花錢的——讀的字越多，消耗的算力越多，速度越慢，成本越高。

麻煩的是，相關(guān)內(nèi)容往往只占整個(gè)輸出的很小一部分。一條ImportError的原因可能就藏在500行文件里的某個(gè)函數(shù)定義里；一次構(gòu)建失敗的根因可能是110行構(gòu)建日志中的那一行Dockerfile語(yǔ)法錯(cuò)誤。其余的內(nèi)容對(duì)于當(dāng)前這個(gè)決策步驟毫無價(jià)值，卻必須全部占用AI的"閱讀"資源。

這就是Squeez要解決的問題：在AI助手讀輸出之前，先做一道"精準(zhǔn)篩選"，只保留當(dāng)前任務(wù)真正需要的那部分內(nèi)容。

二、Squeez的工作方式：一個(gè)"專職過濾器"的誕生

Squeez的基本邏輯可以用一個(gè)圖書館助理的場(chǎng)景來理解。你去圖書館查資料，不是直接把整本書搬回家，而是先告訴助理："我要找關(guān)于1920年代上海租界的經(jīng)濟(jì)數(shù)據(jù)，在那本500頁(yè)的歷史書里。"助理熟悉書的結(jié)構(gòu)，直接翻到相關(guān)章節(jié)，把那幾頁(yè)復(fù)印給你。Squeez扮演的就是這個(gè)"熟悉書本結(jié)構(gòu)"的圖書館助理角色。

具體來說，Squeez接受兩樣?xùn)|西作為輸入：一個(gè)簡(jiǎn)短、具體的"提取查詢"（Extraction Query），以及一份原始的工具輸出文本。提取查詢是對(duì)當(dāng)前任務(wù)需求的精確描述，比如"找到解釋ImportError的調(diào)用棧"或者"找出影響xr.polyval維度順序變化的那條提交記錄"。工具輸出則是命令執(zhí)行后原封不動(dòng)的輸出內(nèi)容。

Squeez的輸出是原始文本中的一段或幾段連續(xù)行——不是改寫，不是總結(jié)，而是原文的直接摘取。研究者把這稱為"逐字證據(jù)塊"（Verbatim Evidence Block）。這一點(diǎn)很關(guān)鍵：AI助手讀到的依然是原汁原味的代碼、日志或命令輸出，只是去掉了無關(guān)的部分，不存在任何信息被曲解或改寫的風(fēng)險(xiǎn)。

在系統(tǒng)架構(gòu)上，Squeez被設(shè)計(jì)成一個(gè)輕量級(jí)的"預(yù)處理步驟"，插在工具執(zhí)行和AI助手讀取之間。工具跑完、輸出出來，先經(jīng)過Squeez過濾，再傳給AI助手。這意味著不需要改動(dòng)AI助手本身的任何邏輯，只需在它"眼睛"前面加一個(gè)過濾鏡。研究團(tuán)隊(duì)已經(jīng)把它做成了可以接收管道輸入的命令行工具（CLI），也可以通過vLLM這個(gè)高效推理框架來部署，接入現(xiàn)有的編程智能體系統(tǒng)（比如Codex或Claude Code）幾乎不需要額外的工程改造。

三、造一把"尺子"：11477個(gè)例子構(gòu)成的測(cè)評(píng)基準(zhǔn)

要知道Squeez做得好不好，首先得有一把靠譜的"尺子"。研究團(tuán)隊(duì)為此專門構(gòu)建了一個(gè)包含11477個(gè)樣本的測(cè)評(píng)基準(zhǔn)，這本身就是這項(xiàng)研究的重要貢獻(xiàn)之一。

數(shù)據(jù)來自兩個(gè)不同的源頭，這兩個(gè)源頭的結(jié)合非常有意思。第一個(gè)源頭是SWE-bench——這是學(xué)術(shù)界廣泛使用的一個(gè)軟件工程基準(zhǔn)，包含了大量真實(shí)的GitHub代碼倉(cāng)庫(kù)和對(duì)應(yīng)的問題。研究團(tuán)隊(duì)克隆了這些倉(cāng)庫(kù)的快照，然后在上面實(shí)際運(yùn)行了14種不同類型的工具：讀取文件、grep搜索、Git提交歷史、Git代碼歸屬查詢、測(cè)試運(yùn)行器、代碼風(fēng)格檢查、類型檢查器、pip包安裝、curl網(wǎng)絡(luò)請(qǐng)求等等，總共收集了10713條原始工具輸出。這些都是編程智能體在真實(shí)工作中會(huì)遇到的東西。

第二個(gè)源頭是為了彌補(bǔ)SWE-bench的局限性。SWE-bench主要是Python項(xiàng)目，但現(xiàn)實(shí)中的工程師還要面對(duì)TypeScript、Go、Rust、Java、Docker容器、Terraform基礎(chǔ)設(shè)施代碼、Kubernetes集群管理等各種技術(shù)棧。于是研究團(tuán)隊(duì)用一個(gè)大型語(yǔ)言模型（openai/gpt-oss-120b）生成了2039條涵蓋這些技術(shù)生態(tài)的合成工具輸出，讓測(cè)評(píng)基準(zhǔn)的覆蓋范圍更加全面。此外，他們還專門構(gòu)造了575個(gè)"陷阱樣本"——查詢和工具輸出故意不匹配，正確答案是"什么都不提取"，用來測(cè)試模型是否能識(shí)別出"這里根本沒有你要的東西"的情況。

最終發(fā)布的基準(zhǔn)包含9205條SWE衍生樣本、1697條合成正例和575條合成負(fù)例，橫跨27種工具類型。其中數(shù)量最多的是文件讀?。?768條）、grep搜索（1330條）、Git提交日志（720條）、Python異常（698條）、curl輸出（493條）、pip安裝（441條）等。

每個(gè)樣本的構(gòu)建遵循一套統(tǒng)一的"教師標(biāo)注流水線"：給定原始工具輸出和背景任務(wù)，用大模型先寫一個(gè)聚焦的提取查詢——注意是局部的信息需求，不是完整的問題描述——然后再選出能回答這個(gè)查詢的最小連續(xù)文本段。模型看到的是帶行號(hào)的工具輸出，以便精確定位，但最終存儲(chǔ)在數(shù)據(jù)集里的標(biāo)注是映射回原始文本的坐標(biāo)，確保每個(gè)答案都是原文的逐字摘取。

測(cè)試集的把關(guān)尤為嚴(yán)格。從729個(gè)候選測(cè)試樣本中，有111個(gè)（占比15.2%）被人工審核后剔除，理由包括：與其他樣本過于相似、輸出內(nèi)容太短（只有一兩行）沒有測(cè)試價(jià)值、標(biāo)注的范圍過于寬泛、或者標(biāo)注本身有誤。最終的618個(gè)測(cè)試樣本全部經(jīng)過人工復(fù)核，質(zhì)量有保障。

四、訓(xùn)練一個(gè)"專才"而不是"通才"

Squeez的核心模型是Qwen 3.5 2B——一個(gè)來自阿里云Qwen系列的20億參數(shù)語(yǔ)言模型。選擇這個(gè)模型有明確的工程考量：研究者的目標(biāo)不是找一個(gè)能憑空推理出問題答案的"大腦"，而是訓(xùn)練一個(gè)能在現(xiàn)有智能體系統(tǒng)里高效運(yùn)行的"專職過濾器"。20億參數(shù)的模型足夠輕量，可以以很低的成本運(yùn)行，而Qwen 3.5系列本身在代碼理解和推理方面有不錯(cuò)的基礎(chǔ)能力，正好適合這個(gè)任務(wù)。

訓(xùn)練方式采用了LoRA（低秩自適應(yīng)，一種只調(diào)整模型中少量參數(shù)的高效微調(diào)技術(shù)）?？梢园阉斫鉃椋翰恍枰匦屡嘤?xùn)一個(gè)員工的所有技能，只需要給他加一堂專項(xiàng)技能課。訓(xùn)練在一張NVIDIA A100 80GB顯卡上進(jìn)行，跑了三輪（epoch），序列最大長(zhǎng)度設(shè)置為20000個(gè)token（大約夠處理一份很長(zhǎng)的工具輸出），學(xué)習(xí)率2×10??，加上梯度累積、預(yù)熱策略和權(quán)重衰減等常規(guī)訓(xùn)練技巧。

模型的輸入格式很直接：提取查詢和工具輸出按照固定格式組合成一個(gè)提示，模型被訓(xùn)練輸出用``標(biāo)簽包裹的逐字提取文本。訓(xùn)練完成后，LoRA適配器被合并進(jìn)基礎(chǔ)模型，通過vLLM高效推理框架部署使用。

評(píng)估指標(biāo)的選擇體現(xiàn)了這個(gè)任務(wù)的特殊性。研究者選定了四個(gè)主要指標(biāo)：召回率（Recall，衡量金標(biāo)準(zhǔn)內(nèi)容被覆蓋了多少）、F1分?jǐn)?shù)（綜合考慮精確率和召回率的平衡指標(biāo)）、嚴(yán)格精確文本匹配F1，以及壓縮率（Compression，輸入中被刪除的比例）。評(píng)估的基本單位是"行"——預(yù)測(cè)結(jié)果和標(biāo)準(zhǔn)答案都表示為行集合，逐行比較。F1的計(jì)算采用了一種"容忍模糊匹配"的方式，只要預(yù)測(cè)行和金標(biāo)準(zhǔn)行的文本相似度超過0.5就算匹配，這是為了應(yīng)對(duì)生成式模型輸出中可能存在的微小格式差異。整個(gè)評(píng)估框架把召回率放在比精確率更重要的位置，因?yàn)樵谶@個(gè)任務(wù)里，漏掉關(guān)鍵信息（召回率低）通常比多保留了一點(diǎn)無關(guān)內(nèi)容（精確率低）危害更大。

五、比賽結(jié)果：小個(gè)子打敗大力士

實(shí)驗(yàn)對(duì)比的陣容很有代表性。除了Squeez（Qwen 3.5 2B微調(diào)版），研究者還測(cè)試了三個(gè)零樣本生成模型——也就是沒有經(jīng)過任何針對(duì)性訓(xùn)練、直接按照任務(wù)要求回答的模型：比Squeez大約18倍的Qwen 3.5 35B A3B、Kimi K2，以及沒有經(jīng)過微調(diào)的Qwen 3.5 2B基礎(chǔ)版。另外還有四個(gè)啟發(fā)式基線：BM25（一種基于關(guān)鍵詞匹配的經(jīng)典信息檢索算法）、First-N（直接取前10%的行）、Last-N（直接取后10%的行）、Random（隨機(jī)取10%的行）。后四種基線都保留約10%的內(nèi)容，與金標(biāo)準(zhǔn)的壓縮比例相當(dāng)，保證比較的公平性。

結(jié)果非常清晰。Squeez在保持92%壓縮率的同時(shí)，召回率達(dá)到0.86，F(xiàn)1分?jǐn)?shù)達(dá)到0.80，精確率0.79——在所有被測(cè)系統(tǒng)中全面領(lǐng)先。Qwen 3.5 35B A3B盡管參數(shù)量是Squeez的18倍，召回率只有0.75，比Squeez低了11個(gè)百分點(diǎn)。Kimi K2的壓縮做得最激進(jìn)（94%），但付出的代價(jià)是召回率只有0.53，漏掉了太多關(guān)鍵內(nèi)容。未經(jīng)微調(diào)的Qwen 3.5 2B基礎(chǔ)版召回率同樣是0.53，但過度保留了內(nèi)容，壓縮率只有82%，并且提取結(jié)果質(zhì)量更嘈雜。

四個(gè)啟發(fā)式基線的表現(xiàn)則慘不忍睹。BM25的召回率僅有0.22，F(xiàn)irst-N是0.14，Random是0.10，Last-N墊底只有0.05。這組數(shù)據(jù)直接說明了一個(gè)關(guān)鍵事實(shí)：工具輸出里的關(guān)鍵信息可能出現(xiàn)在任何位置，頭部、中間、尾部都有可能，而且是否有用取決于具體的查詢需求，而非內(nèi)容的字面關(guān)鍵詞。單純靠位置或詞頻來做篩選，在這個(gè)任務(wù)上根本行不通。

從"召回率-壓縮率權(quán)衡圖"（論文中的Figure 2）來看，Squeez占據(jù)了左上角的最優(yōu)位置——高召回率加高壓縮率，而其他系統(tǒng)要么在兩個(gè)維度上都不如它，要么存在明顯的取舍問題。

六、它在哪些情況下表現(xiàn)最好，又在哪里會(huì)出錯(cuò)？

定性分析揭示了Squeez成功和失敗的規(guī)律，讀起來頗為有趣。

在結(jié)構(gòu)化輸出中精準(zhǔn)命中方面，以Git提交日志為例：21行的日志里，查詢要求找到與xr.polyval維度順序變化相關(guān)的提交。Squeez直接找到了那唯一正確的一條。相比之下，Qwen 35B選了一條"看起來也跟轉(zhuǎn)置操作有關(guān)"但其實(shí)是錯(cuò)的提交，未微調(diào)的2B基礎(chǔ)版則把幾條polyval相關(guān)的提交全選了進(jìn)去。

在噪聲環(huán)境中提取故障塊方面，以176行的服務(wù)日志為例：查詢要求找到影響健康檢查請(qǐng)求的TLS握手失敗信息。Squeez返回了正確的5行健康檢查失敗塊。Qwen 35B選了日志里稍后出現(xiàn)的一次支付請(qǐng)求TLS失敗（語(yǔ)義相近但不是問的那個(gè)），Kimi K2只保留了正確塊的一部分。

在識(shí)別"查無此物"方面，當(dāng)查詢問的是日志里是否存在numpy版本沖突，而日志里根本沒有這個(gè)問題時(shí)，Squeez正確地返回了空輸出。在測(cè)試集的59個(gè)負(fù)例樣本中，Squeez有80%的時(shí)候都能給出空輸出，而Qwen 35B只有7%的時(shí)候能做到這一點(diǎn)——多數(shù)情況下它會(huì)生成一段解釋性文字，比如"未發(fā)現(xiàn)相關(guān)行……"，這顯然不是過濾器應(yīng)該輸出的格式。

Squeez的主要失誤模式是"相鄰過度選取"：找到了正確的內(nèi)容，但順手把旁邊的相關(guān)內(nèi)容也帶進(jìn)來了。以110行構(gòu)建輸出為例，查詢要求找第12行的Dockerfile語(yǔ)法錯(cuò)誤，Squeez找到了，但同時(shí)把附近一個(gè)Python SyntaxError也選了進(jìn)去。這類錯(cuò)誤通常是"多了一點(diǎn)"而不是"找錯(cuò)了地方"，危害相對(duì)有限。

Figure 3給出了一個(gè)更直觀的例子：250行的kubectl輸出，查詢要求找出analytics-worker容器的OOMKilled原因和退出碼。金標(biāo)準(zhǔn)答案是兩行："26: Reason: OOMKilled"和"27: Exit Code: 137"。在整個(gè)250行的輸出中，Squeez準(zhǔn)確地鎖定了這兩行。

七、這項(xiàng)研究的邊界在哪里？

研究者在論文中坦誠(chéng)地指出了幾個(gè)局限性，這些局限性也劃定了Squeez當(dāng)前的適用范圍。

Squeez評(píng)估的是單次工具輸出的修剪質(zhì)量，而不是整個(gè)智能體任務(wù)流程的最終完成效果。換句話說，它能告訴你"相關(guān)證據(jù)有沒有被保留下來"，但不能直接回答"用了Squeez之后，AI助手解決bug的成功率提高了多少"。后者需要在完整的端到端系統(tǒng)中做實(shí)驗(yàn)，這是未來工作的自然延伸。

另一個(gè)局限是評(píng)估指標(biāo)本身。用文本行的重疊程度來衡量修剪質(zhì)量，無法捕捉所有合理的修剪決策——有時(shí)候換一種方式截取內(nèi)容，效果可能同樣好甚至更好，但在行重疊指標(biāo)下會(huì)被認(rèn)為是錯(cuò)誤。這是所有基于標(biāo)注的評(píng)估體系都會(huì)面臨的根本性挑戰(zhàn)。

在數(shù)據(jù)質(zhì)量方面，某些工具類型的樣本質(zhì)量仍然參差不齊，尤其是grep輸出和代碼風(fēng)格檢查（lint）輸出，這兩類工具的輸出格式變化較多，標(biāo)注難度也更大。

說到底，Squeez做的事情看起來簡(jiǎn)單——把一大堆輸出剪成一小塊——但背后的道理很深刻?？筷P(guān)鍵詞匹配做不到，靠截頭去尾做不到，靠大模型直接零樣本也做不到。真正有效的方法，是針對(duì)這個(gè)具體任務(wù)收集專門的訓(xùn)練數(shù)據(jù)，然后讓一個(gè)小模型"死磕"這一件事。用一個(gè)專門訓(xùn)練的20億參數(shù)小模型，打敗了不經(jīng)過訓(xùn)練的360億參數(shù)大模型，這件事本身就值得所有在AI工程領(lǐng)域摸爬滾打的人思考一下：什么時(shí)候該用"通才"，什么時(shí)候該培養(yǎng)"專才"？

對(duì)于普通用戶來說，Squeez可能暫時(shí)還不會(huì)直接出現(xiàn)在你的日常工具里。但它所代表的思路——讓AI助手的每一步操作都更專注、更高效、更不浪費(fèi)——將會(huì)悄悄影響未來所有編程智能體產(chǎn)品的工程決策。當(dāng)你下一次用某個(gè)AI工具幫你找代碼里的bug，它反應(yīng)更快、更準(zhǔn)、費(fèi)用更低，背后可能就有類似Squeez這樣的"幕后過濾器"在默默工作。

對(duì)于對(duì)這個(gè)方向感興趣的讀者，可以通過arXiv編號(hào)2604.04979查閱完整論文，模型權(quán)重、數(shù)據(jù)集和評(píng)估代碼也已在GitHub（KRLabsOrg/squeez）和Hugging Face平臺(tái)以Apache 2.0協(xié)議開源，完全可以自行部署和復(fù)現(xiàn)。

Q&A

Q1：Squeez是什么，它和普通的AI壓縮工具有什么區(qū)別？

A：Squeez是KR Labs開發(fā)的一個(gè)針對(duì)編程智能體工具輸出的修剪系統(tǒng)。與LLMLingua等通用提示壓縮工具不同，Squeez專門處理混合格式的工具輸出（代碼、日志、命令結(jié)果等），并且是"任務(wù)條件化"的——必須同時(shí)給出一個(gè)具體的提取查詢，它才會(huì)根據(jù)當(dāng)前任務(wù)需求來決定保留哪些內(nèi)容，而不是無差別壓縮。輸出的是原文的逐字摘取，不改寫內(nèi)容。

Q2：Squeez的20億參數(shù)小模型為什么能打敗360億參數(shù)的大模型？

A：關(guān)鍵在于"專項(xiàng)訓(xùn)練"。Squeez用了11477個(gè)專門針對(duì)工具輸出修剪任務(wù)的標(biāo)注樣本做微調(diào)，讓模型學(xué)會(huì)了工具輸出的特定規(guī)律，比如日志里故障塊的位置模式、Git提交記錄的結(jié)構(gòu)特征等。而大模型是零樣本使用的，沒有接受過這類專項(xiàng)訓(xùn)練，面對(duì)重復(fù)性日志或格式化輸出時(shí)容易選錯(cuò)相鄰的內(nèi)容塊。這說明在高度具體的任務(wù)上，針對(duì)性訓(xùn)練比模型規(guī)模更重要。

Q3：Squeez數(shù)據(jù)集里的11477個(gè)樣本是怎么來的？

A：樣本來自兩個(gè)來源。一部分是在SWE-bench的真實(shí)代碼倉(cāng)庫(kù)上實(shí)際運(yùn)行14種工具（文件讀取、grep、Git日志、測(cè)試運(yùn)行等）收集的真實(shí)輸出，共9205條。另一部分是用大模型生成的合成工具輸出，覆蓋TypeScript、Go、Rust、Java、Docker等Python以外的技術(shù)生態(tài)，共1697條正例和575條專門設(shè)計(jì)的"查無此物"負(fù)例。所有樣本都經(jīng)過統(tǒng)一的大模型標(biāo)注流水線處理，測(cè)試集中618個(gè)樣本全部經(jīng)過人工復(fù)核。