粗读得吓人

各位，你们知道吗？

大家都应该了解 LLM 自主管理上下文的技术，MemGPT 所提出的方法就是典型代表。通过工具调用（Tool Calling）提取分块信息，利用滑动窗口归档旧信息，或者让 LLM 直接对对话进行总结压缩。那些帮助生成长对话摘要的工具，思路全部源于此。

但我产生了这样的想法：

GIF

“如果模型用特殊 Token 标记出不重要的 Token，然后推理引擎检测到并将其悄悄剔除，这样不是很好吗？”

因为 LLM 足够聪明，甚至能察觉到自己的推理错误。我待会儿会给出依据。

但最让人无语的是，这个领域其实已经在被积极研究了。我还是晚了一步。不过，在了解之前，有一点必须先知道。

毫无意义的第一个 Token 绝对不能死

对于 LLM 来说，第一个 Token 并没有什么特别的意义。大部分情况下它是输入 Token，通常是系统提示词（System Prompt）的第一个字。虽然有些模型明确包含 Start Token，但现在的趋势似乎是直接输入 Token，也可以通过微调进行修改。

然而，这个家伙会吸收惊人的注意力（Attention）。研究人员称之为 Attention Sink（注意力汇聚点）。

GIF

据说在初始阶段，当 Softmax 必须强制产生 1，但没有出现显著发散的值，或者 Top-k 候选都差不多时，模型会将权重全部倾注到第一个 Token 上。挺神奇的吧？

但重点在于，在长对话中，如果把这个 Sink Token 挤掉，模型的输出就会乱成一团。这是 StreamingLLM 揭示的事实。因此，推理引擎绝对不会丢弃这个看起来毫无用处的 Token，因为丢了就全完了。

原理得另外找时间细说，深入研究后发现挺有意思的。

简单来说，最愚蠢的 Token 反而活得最久。

GIF

只保留重要 Token 并进行删减的研究已在如火如荼地进行

H2O：只保留注意力权重高的少数 Heavy Hitters，直接丢弃其余 KV Cache。
SnapKV：预先扫一遍提示词，只压缩关键部分。

顺便提一下，在这些淘汰（Eviction）研究中，保留 Sink Token 作为例外已经成了惯例。

DeepSeek 干脆只选看“关键 Token”

从 DeepSeek-V3.2-Exp 开始加入的 DSA 就是这个。一个名为 Lightning Indexer 的小模块在每次查询时会选出“只需要看这些 Token”，然后推理引擎跳过对未选中 Token 的注意力计算。最令人震惊的是，它只看 Top-2048 个。如果想得浅显一点，这就像看书时只挑书里最重要的 2048 个词来总结整本书？你可能会觉得这怎么可能实现，但那个负责挑选 2048 个词的索引器是通过极高强度的学习训练出来的。这就是机器学习的魅力所在。

GIF

这其实就是“丢弃不必要 Token”最接近的实体化，准确来说不是剔除，而是“不去看”。这是一个显著降低长上下文成本的技巧。这比我之前的设想更加高级。

所以我也试了试

只谈模型层面的东西感觉像在画饼，所以我想介绍两个我为了解决同样问题而制作的开源项目。

inline-agent：滑动窗口的升级版

Agent 在每一步都会重新读取全部对话记录。研究显示，Claude 4 Sonnet 每天 1000 亿个 Token 中，99% 的计算量不是生成，而是重读 (Xiao et al., FSE 2026)。这听起来是不是很理所当然？SWE-bench 平均 48.4K Token 中，63% 是工具调用结果，其中大部分在下一步操作中是毫无意义的。比如已经通过的测试日志、ls 的结果等。

但 Agent 无法主动清除上下文。即使 AgentDiet 提供了擦除工具，Claude 4 Sonnet 也只会专注于原来的任务。因此 inline-agent 在其他层面进行整理，让 Agent 无需操心。

保留最近的 N 轮原始记录，旧轮次则用“指令-结果对”（删除了大部分文本）替换。
错误、失败、diff 绝对保留，已通过的测试、目录列表删除（标准虽模糊，但通过关键词搜索实现）。
LLM 调用次数为 0 -- 有论文证明基于规则的掩码（Masking）在效果上不亚于 LLM 总结 (NeurIPS WS 2025)。

pi-recap - 换成摘要，需要时再找回

我更想狠一点地删除工具调用的结果。因此 pi-recap 把总结任务交给了 LLM。但是！！这里有一个关键概念。在主 Agent 工作的同时，有一个与主 Agent 共享相同模型、相同上下文的“影子分身”，为每个工具结果写下 1~3 行摘要。几轮过后，悄悄把原始结果换成摘要。如果需要，可以通过 recap_recover 恢复原件。

重点是分身使用了与主 Agent 完全相同的前缀（Prefix）。因为命中了 Provider 的前缀缓存（Prefix Cache），摘要输入仅按缓存费用计算。更重要的是，如果一个什么都不知道的 LLM 去做总结，意义会大量流失；但如果是模型亲自压缩，它清楚该留下什么信息，什么信息是不需要的。

在实际编程会话中，主上下文的工具结果 Token 从 75.5K 降至 7.0K，减少了 90.7%。分析 226 个长会话的摘要后发现，原件恢复调用在 127 次中仅为 0 次。

不过这里会产生一个合理的质疑：如果摘要写得烂，或者把关键信息切掉了怎么办？

观察 Agent 的推理日志，从未出现过关于“交换（Swap）”的不满。这正常吗？我的判断如下：如果确实不足，早就表现出来了。

Agent 的结构是根据观察（工具结果）来决定下一步行动的 (ReAct)。如果观察与预期不符，重新确认、重新尝试等行为变化会立即显现。
模型很清楚自己不知道什么。Language Models (Mostly) Know What They Know (Kadavath 2022)。上下文里没有答案就不胡编乱造，这种能力从 SQuAD 2.0 开始就是基准测试项目。这是强有力的证据吧？
如果信息不足，表现出的性能比言语更早暴露问题。Lost in the Middle 表明，长上下文的信息丢失会直接导致准确率下降。像 CoACT 这类压缩研究之所以无条件保留“与后续行动直接相关的信息”，就是因为一旦删掉，性能立马掉给你看。

诚实地补充一点，有研究表明模型并不总是说实话 (Reasoning Models Don't Always Say What They Think, 2025)。所以我不是看“言语”，而是看“行动信号”。比如恢复调用、重新探索、再次询问同样的问题。在 127 次 Swap 中从未出现过该信号，意味着没有观测到信息不足的案例。

而且我连 Swap 的事都没告诉 Agent，它居然毫不知情地运行得很好。这难道不能说我已经实现了“悄悄剔除”吗……？