上海交大与字节合作：智能剪枝框架让Token消耗骤降54%！

Yerba投稿

智猩猩AI整理

当所有人都在追逐“百万上下文”的大模型时, 一个残酷的事实被忽略了：

• 在真实软件工程任务中，76.1%的Token开销来自cat/grep等文件读取操作；

• 模型“吃”进整份代码，却因注意力稀释而频繁幻觉、反复试错;

• 现有压缩方法（如LLMLingua）一剪就断AST结构，RAG检索又依赖完美命名——面对“屎山代码”，全军覆没。

这不是模型能力问题，而是上下文管理的系统性失效。

针对上述挑战，上海交通大学LLMSE Lab联合字节跳动、中山大学提出SWE-Pruner ——首个面向编码智能体的任务感知自适应剪枝框架。它不靠增大上下文窗口，而是教会AI像人类一样“有目的地略读”，在SWE-Bench等基准上实现最高54%的Token节省，且任务成功率几乎零下降甚至上升。

• 论文标题：SWE-Pruner: Self-Adaptive Context Pruning for Coding Agents

• 论文链接：https://arxiv.org/pdf/2601.16746

• 开源地址：https://github.com/Ayanami1314/swe-pruner

• 模型下载：https://huggingface.co/ayanami-kitasan/code-pruner

01 方法

研究团队提出的SWE-Pruner不是简单压缩，而是一套针对代码特性的动态过滤流水线：

优势

传统方案痛点

SWE-Pruner解法

代码特化

Token级剪枝破坏语法树（AST断裂）

行级抽取式剪枝，保留原始代码结构，确保逻辑可执行

任务感知

静态压缩无视当前目标（Debug时还留着无关注释）

引入 context_focus_question（如“聚焦错误日志打印”），动态调整剪枝策略

轻量即插即用

大模型 summarizer 增加延迟

0.6B轻量神经略读器，推理延迟

图3：SWE-Pruner 概览。左侧：交互工作流展示了 SWE-Pruner 作为编程智能体（Coding Agent）与环境之间的中间件运行。它拦截来自文件操作的原始上下文（Raw Context），并向智能体提供经过剪枝的上下文（Pruned Context）。右侧：剪枝流水线详细说明了其内部机制。根据编码智能体提供的特定目标提示（goal hint），神经速读模块（neural skimmer）对原始上下文进行逐行评分和自适应选择，从而生成并传递剪枝后的上下文。

SWE-Pruner关键设计：Agent在调用grep file.py pattern时，只需增加一个参数：grep(file.py, pattern, context_focus_question="如何定位数据库连接超时异常？")——SWE-Pruner便能据此精准裁剪出相关代码片段，剔除90%噪声。

SWE-Pruner的核心是一个双头轻量模型（基于Qwen3-Reranker-0.6B）：

CRF剪枝头：将行级保留/删除建模为序列标注问题，确保剪枝结果在语法上连贯（例如：不会把if和{拆开）；

Reranking序头：同步输出文档级相关性分数；

训练数据：61K条由Qwen3-Coder-30B生成的高质量 (任务提问, 代码, 行级掩码) 三元组;

覆盖9类真实开发场景：Debug、Refactor、Feature Add、Code Locate…

它不是“删代码”，而是“帮AI划重点”——就像老手程序员快速扫一眼就能定位到关键函数。

02 评估

在SWE-Bench Verified（500个真实GitHub Issue修复任务）上，集成SWE-Pruner的Mini-SWE-Agent表现如下：

在SWE-QA（评测模型对整个代码仓库级别的理解能力）上，集成SWE-Pruner的模型效果同样喜人。

更惊人在单轮长代码任务（Long Code Completion和Long Code QA）中：

SWE-Pruner在更高的压缩率下相关指标也显著优于baseline方法——证明剪枝后上下文质量更高、更聚焦。