大模型的上下文窗口已经长到百万 token，压缩却没有因此过时。窗口越长，系统越容易把全部历史、工具返回、检索文档和代码文件一股脑塞进去。请求能发出去，只说明容量够，不能说明这批内容都值得模型再读一遍。
我把论文和几家平台文档对了一遍，原先以为上下文压缩主要是在省输入账单。文档给出的方向更宽。它同时在处理四件事，容量、延迟、注意力分配和长期任务的状态延续。钱只是最容易看见的一项。
压缩早已不只是做一份摘要
最直观的办法是滚动摘要。系统保留最近几轮原文，把更早的对话改写成短摘要。它适合聊天和长任务，因为人类也会这样交接工作。弱点同样明显。摘要一旦漏掉变量名、否决过的方案或一个小小的限制，后续模型通常不会知道自己漏了什么。
第二类办法先选择，再拼上下文。RAG 的 top-k 检索、按查询重排、只保留相关代码片段都属于这一类。它没有改写原文，精确事实更容易保住。代价是选择器可能在入口处就把正确材料排除。压缩发生在模型调用之前，漏掉的证据不会自己回来。
第三类办法直接裁 token。Microsoft Research 的 LLMLingua 用较小的语言模型估计哪些 token 信息较少，再按预算删减。原始论文报告过最高 20 倍压缩和约 1.5 个百分点的性能下降。这个数字很吸引人，也最容易被误用。它来自特定数据集和实验配置，不能直接写进生产预算。LLMLingua-2 又把问题改成 token 分类，用数据蒸馏学习哪些内容应当留下，目标是提高任务无关性和速度。
还有一类在 Agent 系统里更常见。系统清掉过期的工具结果，只留下由这些结果形成的决定。一次网页搜索可能返回上万 token，模型看完并提取结论以后，原始页面没有必要在后面二十轮里反复计费。Anthropic 的 Context editing 已经把工具结果清理、思考块清理和 compaction 分成独立能力。这个拆分很重要，因为删除、选择和重写造成的风险不同。
MemGPT 给出了更完整的系统视角。它把有限的主上下文和外部记忆分层管理，需要时再把相关内容调进来。沿着这条路看，上下文压缩只是记忆管理的一部分。近期原文、任务状态、长期记忆、工具证据和可重新检索的材料，应当进入不同层级，使用不同保真要求。
少传一半 token，账单未必少一半
输入费用可以先写成一个简单关系。
`单次成本 = 新输入 token 费用 + 缓存输入费用 + 输出 token 费用 + 压缩计算费用 + 存储费用`
压缩直接减少的是第一项，有时也会减少输出。LLMLingua 论文观察到压缩提示会带来更短的生成文本，但生产系统不能预设每个任务都会如此。摘要器或压缩小模型还要运行一次，它的 token、GPU、延迟和工程维护都要算进去。
缓存又改变了这笔账。Google 的 Gemini 定价页面把普通输入、缓存输入和缓存存储分开列出，缓存输入单价明显低于普通输入，同时可能收取按时长计算的存储费用。一个长系统提示和固定文档会被重复调用时，缓存常比压缩更稳，因为内容没有被改写。内容只用一两次，显式缓存的存储和管理成本可能抵消收益。
真正该看的是整条调用链。假设一段十万 token 的历史被压到两万，原始输入费理论上下降八成。若压缩器读完整历史再生成摘要，这一步也要花钱。若压缩破坏了关键细节，主模型重试一次，前面的节省可能全部吐回去。再加上缓存命中率下降、用户纠错和人工复核，最终收益会离纸面压缩率很远。
这也是为什么稳定前缀应该优先缓存，过期工具结果应该优先删除，长文档应该先检索，真正需要连续叙事的历史再做摘要。token 级裁剪适合放在后面补足预算，不能默认对所有内容一视同仁。
最大成本常常来自丢错信息
压缩错误很少像接口报错那样醒目。模型仍会给出流畅答案，只是忘了某个约束，重新采用已经否决的方案，或者把旧状态当成当前状态。代码 Agent 尤其敏感。函数名、文件路径、测试失败原因和用户明确要求保留的行为，字面上很短，权重却很高。
因此，评估不能只看 Rouge、语义相似度或 token 减少比例。更有用的指标包括任务成功率、事实召回、约束保留率、重试次数、人工纠正率、首 token 延迟和整次任务成本。还要留下压缩边界，知道哪一轮发生了摘要，哪些工具结果被清除，系统为何重新取回一段旧材料。
服务端 compaction 正在降低接入门槛。Anthropic 的文档允许按输入 token 阈值触发压缩，也允许为摘要指定保留重点，并明确推荐服务端方案处理长对话和 Agent 工作流。平台能更准确地知道实际 token 使用量，也能少写一套客户端摘要代码。应用仍然要决定什么最重要。平台不知道一个业务字段为何必须逐字保留，也不知道哪份旧工具输出以后可能成为审计证据。
未来会出现上下文控制面
我的判断是，单独卖一个“压缩算法”会越来越难，压缩能力会进入模型 API、Agent SDK 和 AI Gateway。网关已经掌握模型路由、价格、缓存、限流和观测数据，再加上上下文策略，就能针对每次请求决定哪些内容直传，哪些命中缓存，哪些重新检索，哪些摘要，哪些必须固定保存。
长窗口仍会继续增长，它解决的是一次能放多少。上下文控制解决的是该放什么、以什么精度放、花多少钱放。两条路线会一起发展。窗口变大以后，粗暴截断会减少，分层记忆和按需调入会增加，压缩触发也会从固定 token 阈值转向任务状态、信息类型和风险等级。
模型还会参与管理自己的上下文。它可以在阶段结束时生成结构化交接，标出必须逐字保存的约束，把可再获取的工具结果降级到外部存储。这个方向有用，也带来新的循环问题。负责压缩的模型可能误判，后续模型又只能根据被误判后的材料工作。因此系统需要可追溯的原文引用、可逆的重新取回和独立评测，不能只相信一段读起来很顺的摘要。
眼下更实用的做法很朴素。先统计输入由什么组成，找出反复出现的稳定前缀和膨胀最快的工具结果。给必须逐字保留的信息单独标记。先上缓存、检索和过期结果清理，再考虑摘要和 token 级压缩。每次改策略，都用真实任务比较总成本与任务成功率。
上下文压缩的前景很好，极限压缩率的故事会慢慢降温。最后留下来的能力，会更像数据库的查询规划和操作系统的内存管理。用户很少关心它用了哪种算法，只会在任务跑得更久、答案没有忘事、账单也没有失控时感到它存在。
参考资料
