187 亿 token 一个会话：当上下文压缩让 AI 记住一切
一个 AI 编程助手跟你工作了 4 个半月。你们一起写了 174,327 次代码——从项目架构到 bug 修复，从重构到新功能。累计输入 187 亿 token。它记得你 3 个月前说的"数据库迁移用 schema 版本号而非时间戳"，所以今天你问"这个迁移怎么写"时，它不会犯 3 个月前你已经纠正过的错误。
目录
一个 AI 编程助手跟你工作了 4 个半月。你们一起写了 174,327 次代码——从项目架构到 bug 修复，从重构到新功能。累计输入 187 亿 token。它记得你 3 个月前说的"数据库迁移用 schema 版本号而非时间戳"，所以今天你问"这个迁移怎么写"时，它不会犯 3 个月前你已经纠正过的错误。
这不是 GPT-5 的百万 token 上下文窗口，也不是 Claude 的 200K 上下文。这是一个叫 billion-context 的开源插件做到的事——在 100K 的上下文窗口里，跑完了 187 亿 token 的会话。
核心问题：上下文窗口是 AI 的"短期记忆"
大语言模型有一个硬限制：上下文窗口。Claude 200K，GPT-4o 128K，Gemini 1M——不管多大，终究有上限。超过上限，最早的内容就被"遗忘"了。这就像一个人的短期记忆只有 30 秒，30 秒前说过的话全部消失。
对聊天机器人来说这不是问题——你不会跟 ChatGPT 聊 4 个月。但对 AI 编程助手来说，这是致命的。一个项目可能开发几个月，AI 需要记住架构决策、代码约定、历史 bug、API 设计。一旦上下文窗口满了，这些"记忆"就丢了，AI 开始重复你已经纠正过的错误。
现有的解决方案各有缺陷：
- 硬截断：丢掉最早的内容。简单粗暴，丢失关键上下文。
- RAG（检索增强生成）：把历史存到向量数据库，按需检索。问题是检索可能漏掉关键信息，而且打断生成流程。
- 模型自带摘要：让模型自己总结历史。问题是摘要不可逆——一旦压缩，细节就回不来了。
billion-context 的方案：模型自己决定压缩什么
billion-context 的核心思路是：不硬截断，不外部检索，让模型自己管理自己的上下文。
它作为一个代理（proxy）跑在 AI 助手和模型 API 之间，拦截所有通信。它给模型注入 4 个工具：
1. compress：把一段对话折叠成高保真摘要
2. decompress：需要细节时把摘要展开回原始内容
3. search_context：在压缩后的摘要和可见消息里关键词搜索
4. acp_status：查看当前上下文使用情况，哪些段落还可以压缩
关键在于：模型自己决定什么时候压缩、压缩什么。不是外部规则强制"超过 50K 就截断"，而是模型在对话过程中判断"这段讨论已经结束了，可以压缩成摘要"。
这就像人类的记忆——你不是把所有对话逐字记住，而是自动把不太重要的部分压缩成"大概讨论了什么"，重要的细节保持清晰。需要回忆时，你能从摘要展开到细节。
为什么这比"模型自带摘要"好
很多 AI 助手（如 Claude Code）已经有内置的上下文摘要功能。billion-context 的区别在于三点：
增量压缩：不是一次性把整个历史摘要，而是分段落、分范围地压缩。每次只压缩一小段，保持其他部分原样。这就像整理书架——你不会把所有书都倒出来重新排，而是一本一本调整位置。
可逆压缩：decompress 工具可以把摘要展开回原始内容。这意味着压缩不是信息毁灭，而是"折叠"。需要细节时随时展开。模型自带摘要通常是不可逆的——一旦总结，原始对话就丢了。
前缀缓存友好：这是最技术性但最重要的点。大模型推理有"前缀缓存"机制——如果请求的前缀和之前一样，可以直接复用计算结果，大幅加速。传统的摘要会改变整个上下文，导致缓存失效。billion-context 的增量压缩保持缓存前缀不变，实测前缀缓存命中率 95-97%，压缩本身只占 ≤2% 的开销。
4.5 个月、187 亿 token 的生产实验
billion-context 不是玩具项目。它的作者在论文里报告了一个4.5 个月的生产规模纵向研究：
- 3 台主机同时运行
- 174,327 次模型调用
- 187.6 亿累计输入 token（所有主机合计约 247 亿）
- 204,800-token 上下文窗口的模型，零次窗口溢出
- 最长会话达到 8,584–12,049 次调用
第三方基准测试
独立测试者用 1,500 道题的跨基准评测（LongMemEval-S、ContextBench、MemoryAgentBench）对比 billion-context 和三种 RAG 方案（BM25、embedding、embedding-rerank）：
- ContextBench：billion-context 第一名，F1=0.3097，成本比全上下文低 58.3%
- LongMemEval-S：比最佳 RAG 高 16.6%（79.20% vs 62.60%），独立会话成本低 71.1%
- MemoryAgentBench：100% 存活率，在 148 万 token 的 TTL 测试中，全上下文方案 199/199 全部失败
代理架构：一个"中间人"的优雅
billion-context 的架构很优雅——它不是某个 AI 助手的插件，而是一个通用代理，跑在任何 AI 助手和模型 API 之间。它重写 Anthropic/OpenAI 的流式响应，在模型和助手之间插入压缩层。
这意味着它支持几乎所有主流 AI 编程工具：
- Claude Code
- OpenAI Codex
- OpenCode
- Gemini CLI
- Kimi Code
- Qwen Code
- GitHub Copilot CLI
- TRAE
"模型驱动"的深层含义
billion-context 的论文标题是"Model-Driven Incremental Hierarchical Compression"。关键词是 Model-Driven——模型驱动。
传统的上下文管理是规则驱动的——"超过 N token 就截断"、"每 K 轮摘要一次"。这些规则是开发者预设的，不管对话内容是什么都一刀切。
模型驱动意味着让模型自己管理自己的记忆。模型知道哪些内容重要（当前正在讨论的代码）、哪些可以压缩（已经解决的 bug 讨论）、哪些可以完全丢弃（寒暄和闲聊）。这比任何外部规则都更准确，因为模型理解语义，而规则只看 token 数。
这和人类记忆的机制惊人地相似。人脑不是按时间截断记忆，而是按重要性压缩。你记得上周的代码决策，但不记得上周二中午吃了什么。你的大脑自动做了这件事，billion-context 让 AI 也能这样做。
一个开放的问题
billion-context 的数据很漂亮，但有一个问题值得追问：压缩后的摘要质量如何保证？
模型自己决定压缩什么，但模型可能犯错——它可能把重要细节压缩掉了，或者摘要不够准确。decompress 工具可以展开原始内容，但前提是模型意识到自己需要展开。如果模型没意识到摘要里丢了关键信息，它就不会调用 decompress。
这就像人类的"虚假记忆"——你记得某个决定，但记错了细节，而且你不知道自己记错了。billion-context 的 95-97% 缓存命中率说明压缩本身高效，但命中率不等于准确率。基准测试里的 79.20% LongMemEval-S 得分已经很高，但仍有 20% 的信息丢失。
不过，这是所有上下文管理方案的共同问题——硬截断丢得更多，RAG 检索也可能漏掉关键信息。billion-context 的优势在于它把"丢什么"的决定权交给了最懂上下文的实体——模型自己。
项目链接：ranxianglei/billion-context 语言：TypeScript | 协议：MIT | 今日新增：374 颗星