锯齿折叠

首先，让我们来谈谈什么是“锯齿折叠”。
锯齿折叠英文是 “Sawtooth Collapsing” ，消息折叠，对话折叠都对，目前尚无官方定义。

锯齿折叠实际上并不是官方翻译，这只是字面翻译。

经过长时间的对话，AI 接近上下文极限时，系统会压缩上下文，这会让上下文的某些关键信息丢失，这是不可避免的局限性。

更别提，如果上下文本身就产生了污染，那么压缩后的内容也会包含污染内容，唯一的选择就只有开启新对话。

锯齿折叠就是折叠 AI 的历史上下文，把无关或多轮对话之前的旧内容折叠起来（这发生在压缩上下文之前）。
锯齿折叠需要保证甜点区（200K 上下文）还需要确保折叠时机，它会在超过阈值（例如 180K）并满足时机条件时，在用户还没有发消息之前就把上下文折叠。

只留下一个被折叠过后的“块”，这会留下一个“截断预览”。
如果 AI 需要知道这个“块”的内容，那么就采取“无感召回”的方案。
当用户发送新消息时，系统会先做一个探针检测，发现你的新问题命中了以前折叠的“存根”关键词，系统自动就把历史解压了，并塞进本次请求里发给 AI。

这套机制的做法就是在 AI 对话动态的过程中慢慢隐去之前已经过时的上下文，仍能保留原文的信息，不会丢失。

这和压缩上下文有很大不同。
标准压缩是“总结上下文”，锯齿折叠更像是一个“按需加载”。

解决基本不能用的 1M

说到什么时候模型开始贵起来，这得从 1M 成为了各家的“标配”开始说起。
今年 3 月份，Anthropic 宣布 Claude 4.6 起将 1M 上下文正式发布，Claude Code 从此标配 1M。

Claude 4.7 名义上是 1M，可是上下文一旦超出甜点区（120K 左右）就会出现注意力不集中，一旦超过 400K 基本就无法使用了。超出甜点区后就产生更多的幻觉，一般称作“上下文腐烂”。
这就导致上下文窗口越长注意力越差，而且读取和创建缓存都会产生显著的开销。过去，只能通过压缩上下文或是开新对话解决，成为长任务的瓶颈。

省钱

这可能是出人意料的一点。我们稍后会详细讨论这一点。
根据 yesmem 作者测试，每天省 $47，主要省在缓存读取上 —— 上下文越小，每次请求要读的缓存就越少。

省钱只是一个额外的好处；最重要的是，它还能提高答案的质量。

AI 模型能长对话，并理解上下文的关键就在于上下文全量发送，你的上下文无论是五十轮之前的对话，还是上一轮的对话，都需要全量发送给 AI 进行计算。

关键在于减少上下文噪声。那个三小时前已经解决的 Bug、十轮前你已经否决的方案 —— 这些内容留在上下文里只会分散模型的注意力，更难获得有用信息。
折叠就是在新一轮对话发出之前，把这些历史上下文压成一行，有需要再展开读取它
这样一来模型不会忘记近期发生过的关键事情，也不会受到上下文干扰的影响。

缓存破坏

提示词缓存就是 AI 省钱最关键的部分。
它把 AI 的上下文对话缓存到一个存储容器里，可能是显存可能是内存。在下次请求的时候立刻从缓存部分读取内容，再丢到机器里面进行 AI 计算。

缓存的目的是提升速度并降低成本。
问题是每次创建缓存得花钱，而且缓存有时效性，Claude 的缓存默认是 5 分钟；一旦过期，就需要重建。

缓存的原理是“前缀必须一字不差”。

一开始不敢做折叠，是怕一旦折叠，缓存就失效，重建缓存还得花钱。
锯齿折叠确实会破坏一次缓存，但它剔除的可是上下文的垃圾信息。
在长对话中，省下这些无用 Token 带来的收益，远超缓存未命中的成本；这就是为什么能省钱
此外，yesmem 的锯齿折叠，会主动去计算缓存过期时间，发现缓存过期后，发起一波大折叠，把损失降到最低。

下次你再发消息时，发过去的内容已经是折叠后的精简版，新创建的缓存量很小，干扰也少了，还不会破坏缓存（因为它本来就过期了）。

开发进度

这是一个还没被广泛认识的技术。
我唯一能找到的实现就是 yesmem

yesmem 项目发布在 GitHub。目前的缺点也很明显，社区没有人关注，Windows 上不能原生使用。

预期

如果做好了，你应该完全察觉不到任何折叠发生，对话该多长多长，该多便宜多便宜，模型该多聪明多聪明。yesmem 已经非常接近这一理想状态。剩下的问题，是大厂是否愿意投入同样的工程心思来做到这一点。

---

版权声明：本文采用 [CC BY-SA 4.0（署名-相同方式共享）] 许可协议。转载请注明作者及原文链接。