锯齿折叠

先聊聊什么是锯齿折叠吧，锯齿折叠英文是 “Sawtooth Collapsing” ，消息折叠，对话折叠都对，目前还没有官方定义。

锯齿折叠实际上并不是官方翻译，只是直译过来，意为“把对话锯掉，然后折起来”。

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

更别提，如果上下文本身就产生了污染，那么压缩过后还会带上污染的内容，唯一的选择就只有输入 /clear 开启新对话。

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

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

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

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

解决基本不能用的 1M

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

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

省钱

这可能是最反直觉的部分。后面会专门讲，先抛结论：根据开发者实测每天省 $47，主要省在 cache read 上 —— 上下文越小，每次请求要读的缓存就越少。

省钱只是顺带的，更重要的是它顺手把回答质量提升了。那么它是如何提升质量的？

AI 模型能思考，能知道上下文核心就在于上下文全量发送，你的上下文无论是五十轮之前的还是上一轮的对话都需要全量发送给 AI 进行计算。

关键就在于减少上下文污染（降噪）。三小时前那个已经解决的 Bug、五十轮前你已经否决的方案 —— 这些东西留在上下文里只会让模型产生干扰，更难获得有效信息。
折叠就是在新一轮对话发出之前，把这些历史上下文压成一行，有需要再展开读取它
这样模型不会忘记近期发生过的关键事情，也不会被上下文干扰带偏。

缓存破坏

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

提示词缓存的作用就是速度提升了，价格下来了。
问题是每次创建缓存得花钱，而且缓存有时效性，Claude 的缓存默认是 5 分钟，超过就过期，一旦过期就需要重建。

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

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

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

开发进度

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

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

期待

如果做好了，你应该完全察觉不到任何折叠发生，对话该多长多长，该多便宜多便宜，模型该多聪明多聪明。yesmem 已经无限接近这个状态了。剩下的问题，是大厂愿不愿意花同样的工程心思把它做对 —— 而不是简单地用一次 LLM 摘要糊过去。

---

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