代码Agent的"元认知"：SWE-Pruner Pro 发现模型自己知道该剪什么

你正在调试一个棘手的 bug。你的 AI 编程助手帮你跑了一轮 grep，屏幕上刷出 500 行搜索结果。你扫了一眼——大部分是噪音，只有第 47 行附近那段是你真正需要的。

你跳过了其余 499 行。

问题是：AI 助手自己能做这个判断吗？

上海交通大学和上海人工智能实验室的团队在 SWE-Pruner Pro 论文中给出了一个让人意外的答案：能，而且模型本来就知道。

论文地址：https://arxiv.org/abs/2607.18213 代码仓库：https://github.com/Ayanami1314/swe-pruner-pro

---

一、上下文爆炸：代码Agent的隐形税

先说问题。当编程 Agent 在代码仓库里执行任务时，它需要反复调用工具——cat 看文件、grep 搜关键词、ls 列目录、python 跑测试。每一轮交互都产生大量工具输出，这些输出累积在上下文窗口里。

实际测量发现，一次任务轨迹中绝大部分的 token 预算都花在了工具输出上，其中很多是重复的、再也不会被引用的内容。这些冗余内容不仅推高成本，还会触发一个被反复验证的现象：长上下文退化。模型在超长上下文中会"迷失"，忘记该关注什么，准确率随上下文长度下降。

所以，剪枝（pruning）长上下文成了代码 Agent 的刚需技术。

二、两条旧路线

之前的方案分两派：

第一派：通用压缩。 用困惑度（perplexity）或语法结构等固定指标给 token 打分，按分数裁剪。问题是它不知道 Agent 当前关注什么——你在找函数定义，它在帮你保留注释块。

第二派：任务感知剪枝。 以 SWE-Pruner 为代表，用一个额外的打分模型，根据 Agent 每轮写的"目标提示"（goal-hint）来决定保留什么。效果更好，但代价是：多了一个外部模型，而且 Agent 每轮都得写一次目标提示——既慢又尴尬。

三、关键发现：模型内部早就有了答案

研究团队做了一个简单而精巧的实验。他们冻结了 Qwen3-Coder-Next 模型，对每行工具输出取最后一层隐藏状态（hidden states）的均值池化，然后用逻辑回归（logistic regression）测试一个简单问题：模型能否从内部表征中区分"该保留"和"该剪掉"的代码行？

答案是：能，而且 AUC 达到 0.83。

这意味着什么？当 Agent 在读一段 grep 输出时，它的隐藏状态里已经编码了"这行重要/这行不重要"的信号。模型在读代码的时候，内部已经"知道"哪些行跟当前任务相关——只是这个知识从未被显式提取出来。

这就像你读一篇论文时，大脑会自动高亮关键段落——你不需要另一个"阅读理解助手"来告诉你哪里重要。模型也一样。

四、SWE-Pruner Pro：让模型自己剪自己

基于这个发现，团队提出了 SWE-Pruner Pro。核心设计：

1. 不引入外部打分模型。 剪枝信号直接来自 Agent 自身的内部表征。 2. 一个小型剪枝头（pruning head）。 它读取 Agent 的隐藏状态，加上一个"长度感知嵌入"（length-aware embedding，编码工具输出的行数信息），为每一行输出一个"保留/剪掉"的标签。 3. 冻结主干，只训练头。 Agent 本体不动，只训练这个小型头，推理开销极小。

整个流程像是在 Agent 的"阅读过程"上接了一根探针——读取它正在想什么，然后帮它把不相关的部分划掉。

五、实验结果：省 token 还涨点

在两个开源主干（Qwen3-Coder-Next 和 MiMo-V2-Flash）和四个多轮基准测试上：

• 省 token：最多节省 39% 的 prompt + completion token。在 Qwen3-Coder-Next 上，三个基准分别节省 34.7%、39.4%、13.9%。
• 不伤质量：在 SWE-QA/Pro 上，其他剪枝方法（SWE-Pruner、Self-Prune）都会降低评判分数 0.14–0.65，而 SWE-Pruner Pro 保持质量（+0.02、+0.24、-1.4pp）。
• 甚至涨点：在 MiMo-V2-Flash 上，SWE-Pruner Pro 把 SWE-Bench Verified 的解决率提高了 +3.8%，长上下文 Oolong 准确率提高 +2.2 点。

六、为什么这件事有意思

1. "模型已经知道"是一个反复出现的模式。

这让人想起 BERT 时代的探针实验：你训练一个分类器去探测模型的隐藏状态，发现它内部已经编码了词性、句法树、语义角色——这些都不是被显式训练的，而是预训练的副产品。SWE-Pruner Pro 把这个思路搬到了代码 Agent 场景：模型在阅读工具输出时，内部表征已经包含了"相关性"信号。

2. 从"外部监督"到"内部读取"的范式转变。

之前的 SWE-Pruner 需要一个外部模型来告诉你"这行重不重要"。SWE-Pruner Pro 说：不用，模型自己知道，我们只需要把这个信号读出来。这和 mechanistic interpretability 的思路一脉相承——与其从外部强加一个解释，不如从内部提取已有的表征。

3. 工程上的简洁性。

冻结主干 + 训练一个小头，这意味着：

• 不需要重新训练 Agent
• 推理开销可控
• 可以即插即用地加到不同模型上

七、局限与诚实评价

论文也坦承了局限：

• 训练数据依赖 Claude Sonnet 4.6 做行级标注，标注质量本身是一个瓶颈
• 只在两个开源主干上验证，闭源模型（GPT、Claude）能否复现未知
• "模型知道该剪什么"这个结论目前只在代码场景成立——迁移到其他领域（比如对话、推理）是否成立，是开放问题

八、更大的图景

SWE-Pruner Pro 做的事，本质上是给 Agent 装了一个"元认知"接口——读取它自己的内部状态来做决策。这和人类阅读时的"扫读-精读"切换很像：你的眼睛在扫过一页文字时，大脑已经在无意识地标记重要段落，然后你有意识地回头精读。

未来的 Agent 可能会有更多这样的"内部信号读取"模块：读取"我是否困惑"、"我是否在重复"、"我是否接近答案"——这些都是隐藏状态里已经存在但未被利用的信号。

模型知道的东西比它说出来的多。SWE-Pruner Pro 只是把这个差距缩小了一点。

---

论文：SWE-Pruner Pro: The Coder LLM Already Knows What to Prune 作者：Yuhang Wang, Yuling Shi, Shaoqiu Zhang 等（上海交通大学） arXiv：https://arxiv.org/abs/2607.18213 代码：https://github.com/Ayanami1314/swe-pruner-pro