100K 上下文就够了：压缩记忆，而不是买一个更大的窗口

窗口大小不是问题

每隔几个月，就有实验室发布一款上下文窗口更大的模型，然后讨论重新洗牌：二十万 token，然后一百万，然后两百万。言下之意是，记忆是个硬件问题，总会有人把它做得更大。

billion-context 是 ranxianglei 的 TypeScript 项目，从九月下旬开始一路往上爬，它的宣传语站到了反面：100K 上下文就够了。不是"目前够用"，是够了——前提是你别再把对话当成一份只能追加的日志。

它是一个代理，夹在你的编码 agent 和模型 API 之间。请求经过它，被压缩，再转发出去。响应在回来的路上被改写。模型本身一点没变。它想说的是：贵的那部分从来不是窗口大小，而是我们一直往里塞的东西。

压缩是怎么做的

代理按 Anthropic 或 OpenAI 的格式解析每个请求，对整段对话跑一遍它的压缩内核，然后注入四个模型可以自己调用的工具：把一段消息压缩成摘要，在需要确切细节时把某一段解压回来，按关键词搜索压缩后的摘要和可见消息，以及查看上下文占用。

关键的设计选择是：什么时候压缩由模型自己决定，而不是一道硬阈值。宿主自带的摘要器通常在窗口填满时触发，把切点之前的一切换成一个无法撤销的摘要。billion-context 按小段压缩，保持可逆，并且不破坏前缀缓存。

最后这点才是值得在意的工程细节。前缀缓存是长 agent 会话负担得起的原因；如果每次压缩都改写对话开头，缓存就失效，你得为整段历史再付一次全价。项目声称健康会话的前缀缓存命中率能保持在 95-97%，压缩本身的开销不超过 2%。这些是它自己给出的数字，同时它提供了命令，可以把命中率下降归因到具体原因，通常是上游缓存 TTL 过期，或者切了模型。

让这个说法可信的那个数字

厂商天天都在宣称省 token。这里不寻常的是随代码一起发布的一项纵向研究：四个半月，三个宿主，174,327 次模型调用，单个宿主累计输入 18.76B token，所有宿主加起来约 24.7B。报告说最长的会话跑了 8,584 到 12,049 次调用，在 204,800 token 的模型上零次上下文窗口违规。

零窗口违规才是关键的那句话。它意味着没有任何一个会话是因为对话长过了模型而死掉的。研究里其他的一切，都在这句话的下游。

它也重新定义了"长会话"是什么意思。大多数人对上下文上限的体验是缓慢的退化：agent 越来越含糊，忘掉两小时前的一个约束，开始重读已经读过的文件。等到窗口真的满了，这个会话通常已经糟糕了一阵子。持续运行的压缩处理的是退化，而不只是那个硬性中断。

至于它在你的工作负载上是否真如宣传所说，是另一个问题。这些说法是自报的，基准就是作者自己的使用情况，而"token 少 5 倍"完全取决于你的会话有多重复。一个读了四十个文件、改了三处的会话会被压得很漂亮。一个读了一个巨大的文件、然后逐行推理的会话，可折叠的冗余就少得多。

它改变了日常循环里的什么

实际的差别出现在一个长任务无聊的中段。一个正在做重构的 agent 有三种记忆：它决定了什么，它读了什么，它试过又放弃了什么。原始记录把这三者放在同一个分辨率上，这就是为什么一次四十个文件的重构，会用早就不重要的堆栈跟踪把窗口填满。

压缩让 agent 把决策保持在全保真度，把证据折进摘要，只在需要时回去取确切的那几行。这大致就是人干活的方式：你记得你把校验挪进了中间件，你不记得之前失败的六次尝试。

失败模式也一样人性化。如果摘要漏掉了唯一重要的那个约束——"这个接口必须保持向后兼容"——agent 会在四十分钟后兴高采烈地把它破坏掉，而压缩层替你省了钱，同时送你一个 bug。可逆性让这件事还能承受：你可以解压，看看摘要当时到底说了什么。

为什么这现在成了一个品类

至少有三种不同的路线在争同一个问题。一种是实验室的答案：造一个更大的窗口。另一种是框架的答案：检索，而不是记忆，上下文里只留一个工作集。第三种，也就是 billion-context 代表的：保留对话，就地压缩，可逆。

权衡是真实的。更大的窗口最简单，也最不可控；你每次调用都要为它付钱，不管那段历史相不相关。检索最便宜，但失去连续性，因为 agent 不知道自己忘了什么。就地压缩想同时保住连续性和低成本，代价是坐在你的请求路径里。

最后这个代价才是要想清楚的。一个夹在中间的代理，看得到每一个提示和每一次补全。对独立开发者来说没问题。对有数据处理规定的公司来说，这是一场合规对话，而"我们读过源码，没问题"和一次审计不是一回事。

还有许可证这件小事。技术论文是 MIT 的，放在仓库里。仓库本身的许可证据报是"Other"，而不是一个标准的 OSI 许可证。如果你要在公司内部部署，这个区别早晚会冒出来。

那个让人不舒服的推论

如果压缩做得足够好，100K 就够了，那么大量关于上下文窗口的营销，瞄准的是一个用软件就能更便宜解决的问题。这不代表更大的窗口没用——一份 400 页的文档总得有地方放——但它确实意味着"我们有一百万 token"这个卖点，比听起来要弱。这就像宣传油箱更大，而不是油耗更低。

它也改变你应该怎么写一个 agent。如果记忆是可压缩的，就该鼓励 agent 用结构化的形式把学到的东西写下来，因为结构化的笔记比原始日志好压缩得多。一句"认证中间件从 header 里读租户，不是从 cookie"，抵得上一千行堆栈跟踪。压缩层奖励良好的记账习惯，对一个工具来说，这是个不错的属性。

这个项目有一千多颗星，npm 月下载量大约 400,000，还有二十多个客户端的徽章。这不是业余规模的装机量。它说明这个痛点是真实的，而且大家都疼，也说明人们伸手去够的答案，不是在窗口大小后面再加一个零。

这就是那个有用的结论，不管你最后用哪个工具。上下文是预算，不是容器。这样看待它的团队，每一块钱会做成更多事；等着更大窗口的那些，会继续为"不用决定什么重要"这件事买单。