你让 AI 连续干一个月的活，就像让同一个人参加一场不散会的会议。桌上的记录越堆越高，终有一天放不下；如果只保留会议纪要，早先的数字、出处和约束又可能被概括掉。billion-context 想解决的，正是长时间运行的 Agent 如何既不“失忆”，又不让历史记录拖高成本。
这里的 Agent，是能调用工具、连续执行任务的 AI 程序。模型每次能直接看到的文本范围叫上下文窗口，通常用 Token 计量。Token 是模型处理文字的基本片段，不等同于一个汉字或一个单词。会话超过窗口后，旧内容只能删除、压缩或移到外部存储。
项目方宣称，billion-context 能用约 100K 的小窗口支撑持续一个月、累计处理十亿级 Token 的单次会话，并把 Token 用量降到约五分之一。不过，全部效果数据都来自项目仓库及其中的论文，属于同一个信源；“5× fewer tokens”等说法也没有独立评测佐证。
它不是扩大窗口，而是整理旧账
billion-context 位于 Agent 与模型 API 之间，像一名替双方整理记录的秘书。它接收 Anthropic 或 OpenAI 格式的请求，用 acp-kernel 压缩会话，再把请求转发给真正的模型，并改写流式响应。
它采用“模型驱动的增量分层压缩”。说白了，不是等记录碰到固定上限就从头硬删，而是让模型判断何时整理、哪些内容可以折叠。已经用过的对话会被分成小段，写成较详细的摘要；摘要以后还能继续被压缩，形成多层记录。
代理同时给模型加入四件工具：compress 把一段消息折叠成摘要；decompress 在需要原始细节时恢复该段；search_context 用关键词搜索摘要和仍可见的消息；acp_status 查看窗口用量及哪些区间还能压缩。
这套思路的关键不是“把十亿 Token 塞进 100K 窗口”。十亿级数字统计的是历次调用的累计输入量。模型在任何一次推理中看到的仍只是有限窗口，旧内容则靠摘要、搜索和按需解压重新进入视野。
为什么要一小段一小段地压
长会话还有一个容易忽略的成本：前缀缓存。它让推理服务复用多次请求中相同的开头，避免反复计算。若系统每次压缩都重写大段历史，缓存就容易失效。
项目称自己的压缩方式是 incremental、reversible、prefix-cache friendly，也就是逐步进行、可以逆转，并尽量保持前缀稳定。按项目自报，健康会话的前缀缓存命中率为 95%—97%，压缩本身的成本不超过 2%。但这不是普遍保证；仓库也说明，缓存有效期、模型切换和实现缺陷都会拉低命中率。
数字很大，证据该怎么看
项目报告了一项持续 4.5 个月的纵向研究，覆盖三台主机和 174,327 次模型调用。在 204,800-token 模型上，项目方称没有发生窗口超限；最长会话包含 8,584—12,049 次调用。
累计输入量的口径却不够清楚。论文一处写 18.76B tokens，另一处又称全部主机合计约 24.7B。项目名称也来自这种累计规模：若干“马拉松”会话各自累计约 10 亿至 15 亿 Token，但这依旧不是模型同时容纳的上下文长度。
更值得警惕的是论文留下的一项对照：项目原本把“减少重复翻找旧资料”归功于压缩，但一个根本不执行压缩、只给模型加入行为准则和消息标签的静默对照组，也让重复获取下降 62%，几乎追上宣传中的 63%。这说明，至少在这个指标上，教模型如何整理工作台，可能与真正压缩历史同样重要。
局限与未知
- 摘要即使能够解压，也可能先丢掉关键约束、出处或细节；材料没有给出独立的压缩质量指标、误差范围或基线比较。
- “减少 5× tokens”和“100K is enough”均为项目方自报，具体计算口径未披露；压缩、检索和解压还可能增加模型调用、延迟、费用及隐私风险。
- 论文以 MIT License 放在仓库的
paper/目录，并被称为可接受修改的 living document。开放修订值得肯定，但材料不能证明它经过独立同行评审。
所以，这个项目真正值得看的，不是“把上下文窗口扩大到十亿 Token”，而是把长期记忆改造成一套可折叠、可搜索、可恢复的工作记录。它展示了一条实用路线，也把最难的问题留在桌面上：当 AI 用摘要记住一个月的工作时，我们怎样确认它忘掉的恰好都是不重要的东西。