从 100K 到十亿级单会话:billion-context 上线的第 71 天,社区在聊什么【免费下载链接】billion-contextA context-compression plugin for small context windows (a 100K context is enough), token savings (5x fewer tokens), and month-long single sessions (billions of tokens).上下文压缩插件兼顾小窗口(100k上下文足矣)省token(省5倍token)和超长会话(数月级别几十亿token单会话)。billion-context is all you need项目地址: https://gitcode.com/gh_mirrors/bil/billion-context一个夹在编码 Agent 和模型 API 之间的本地代理,把上下文不够用拆成了一道可审计的工程问题:不扩窗口、不加显存、不堆向量库,而是让模型自己决定把已消费的对话折叠成可逆摘要。billion-context 于 2026-08-06 开源,今天是它上线的第 71 天。这个时间点的观察价值在于:它已经跑出了真实的用户反馈回路——GitHub 的 issue/PR 编号推进到 3200,npm 版本号从 0.1.34 走到了 0.1.197,仓库里沉淀了 800 多个测试文件和一篇 MIT 许可的预印本论文。本文基于仓库源码、CHANGELOG、论文与最近的社区文章,回答三个问题:71 天的增长轨迹是什么形状;100K 上下文撑几十亿 token 单会话的量级跨度是否可信;以及接下来值得盯的里程碑在哪里。一、71 天的增长轨迹:一周一个功能面,一天一个补丁先看节奏。仓库里的版本证据链很密:8 月 8 日(上线第 3 天),reference/release.md中的发布分支示例已是2026-08-08_release-v0.1.17;到8 月 11 日,CHANGELOG 记录已推进到0.1.34——头一周就密集修掉了 thinking 模式reasoning_content回传 400、round-2 流式缓冲、compress 死循环这类第一天就会遇到的问题;8 月 24 日前后,CHANGELOG 已记录到0.1.49,devlog 目录(devlog/)在 8 月 13 日至 9 月 27 日间沉淀了 36 个迭代记录,每条都带实施前写好的REQ.md和实施中写好的WORKLOG.md;当前package.json中的版本是0.1.197。71 天,160 多个 npm 发布,平均不到一天一个版本。活动量上,tests/目录最大的回归测试编号已到issue3250,最近一次合并的 PR 是#3234,71 天内 issue/PR 编号推进到 3200,意味着平均每天 40 多个社区事件(提交、讨论、回归)。测试规模同样可观:tests/下 700 多个测试文件,kernel/tests/96 个,pi-subagents/tests/16 个,tests/e2e/17 个套件——其中 E2E 直接驱动真实的codexCLI 穿过代理与 Responses 兼容上游,断言 warmup → 负载增长 → ACP 压缩 → 原生 compact 拦截的完整生命周期。社区讨论的密度也能佐证。10 月 14 日,CSDN 上出现了一篇专门讲如何为 billion-context 贡献代码的开发者指南,通篇是 500 测试体系、原生插件协议(x-bili-plugin头 GET /__bili/plugin/manifestPOST /__bili/plugin/tool)与统一存储架构的拆解——当一个 71 天的项目开始有第三方写贡献指南,说明它的社区叙事已经从怎么用切换到了怎么共建。客户端覆盖面也在持续扩张。README.md的 Which do I need? 表格里现在列了 20 多个宿主:pi、opencode、omp、dsh、kimi、hermes、zcode、claude、codex、gemini、iflow、qwen、antigravity、mcode、aider、copilot、amp、crush、zed、goose、codebuddy、qoder、trae、jcode——有插件接缝的走bili plugin install client原生模式,没有的走bili client启动器(cert-MITM 或/bili/baseURL 改写),兜底方案是把 baseURL 前缀换成http://localhost:8787/bili/。还有一个容易被忽略的信号:10 月上旬的发布注记(release-notes/package.json,由 CI 从本仓库发布到独立 npm 包)在 10 月 1 日至 12 日间出了 5 个版本,其中 3 个是critical级——0.1.186(修 codex 启动器与 claude code 账号场景)、0.1.192/0.1.193(修 dsh/codex 切模型导致会话 fork、压缩状态失效、缓存重付)。critical 级发布集中出现在上线第 56–67 天,恰好是真实用户把 dsh 桌面版、codex 订阅登录这类长尾场景用出来的阶段:这 71 天里,项目经历了跑通 → 跑顺 → 长尾场景挨个打补丁的完整过程,而它的自动更新 critical 分级注记 advisories/强制更新通道(独立 npm 包,当前 advisory 列表为空,即从未触发过)构成了完整的线上修复闭环。二、社区焦点一:量级跨度到底可不可信100K 上下文够用、单会话几十亿 token——这是 README 第一行的承诺,也是社区质疑最多的一点。可信的关键在于分清仓库里三个不同口径的数字,它们都来自随代码开源的论文(paper/目录下,MIT 许可的活文档,v0.2 版,2026-09-07):口径一:实测多会话总量。主宿主机上 4.5 个月(2026-04-23 → 2026-09-07)的生产日志:4,843 个会话、174,327 次模型调用、18.76B 累计输入 token(其中 1.75B 是新鲜输入,17.01B 是缓存读取),三台宿主合计约 24.7B。注意这是累计输入口径、跨会话的,且缓存读取占绝对大头(读:新 ≈ 9.7:1)——billion 首先是这个名字的由来,而不是单次请求的大小。口径二:实测单会话马拉松。真正对应十亿级单会话的数字:OpenCode 宿主上最长的会话跑了12,049 次调用、1.52B 累计输入 token,峰值上下文 374,946(1M 级窗口);Pi 宿主上最长的会话8,584 次调用、1.01B token,峰值 257,721。这两个数字是逐次调用从 API usage 里实测的,不是推演。口径三:仿真外推上限。论文 §7 给出的1M 窗口单会话可支撑28.6B token / 106 天是闭式推导 离散事件仿真的结果,论文明确标注为[A: simulation],且承认这是对最大实测会话约 19 倍的纯外推,tier-3 蒸馏率甚至是设计值(未观测到)。附录 B 的 Claims register 把每个声明逐条标了[V](有日志证据)/[A](分析模拟)/[P](计划实验)——把哪些是实测、哪些是模型写进论文正文,这本身就是回应量级可信度质疑的方式。支撑这套数字的工程事实有三条,都在源码里有对应物:零窗口违规。204,800 窗口模型上 42,986 次调用零溢出(峰值 198,628);第三台宿主(ework,自主 agent 服务)12.2 天 32,733 次调用对 262,144 窗口同样零违规,峰值 229,355(87.5%)。Pi 宿主更干净的逐次计费显示平均 88K / 中位 72K / p99 218K——典型的锯齿震荡在窗口带内,而不是爬升。折叠只压缩已消费的增量。生产数据:229M token 被压缩,但 62% 集中在 1.3% 的超大会话里(≥1000 条消息)——论文称之为马拉松现象:短会话基准根本观测不到压缩真正起作用的地带。单次压缩的产出中位只有185 token、97.5% 不超 2K;每次折叠中位吃掉 2.6K 增量。重负载会话(历史中位 ~530K)最终只留 ~13K 常驻摘要,宏观折叠比约70×。前缀缓存不被压缩破坏。这是省 5 倍 token的经济学核心:历史 append-only、压缩只把后缀区段置为摘要,已建立的 KV 前缀永不失效。实测缓存读取占比 90.7%(主宿主混合值),按调用间隔分层后,间隔 2 分钟(占 89% 流量)的请求缓存读取占比达94.2%,miss 归因里只有 16% 来自新追加的后缀,其余是 provider 侧 TTL 过期——与布局无关。README 的健康判据也写得很直白:健康会话保持95–97%前缀缓存命中,压缩本身的成本 ≤2%。受控实验给了另一组佐证:在 Session Marathon 试点里,压缩组相对保留基线计费 token 降 31–54%、重复取数(re-fetch)调用降 63%(2.7×),而记忆探针得分持平;阶段结构化负载上默认配置在质量、成本、方差三个维度全部最优。论文也诚实地记录了反面:128K 窗口的静默对照组(不执行任何压缩、只保留 doctrine 文本和消息标签)独自复现了几乎全部的 re-fetch 降幅(−62% vs −63%),说明收益大部分来自判断内容 标签布局这个组合,而不是压缩动作本身。三、社区焦点二:实现路径——一个 fold,而不是更大的窗口2026 年的Agent 上下文工程已经是条热闹赛道:火山引擎的 OpenViking 把 Agent 记忆做成可自进化的上下文数据库,headroom 主打上下文压缩层、最高省 95% token,Context Mode 用 SQLite FTS5 BM25 把大输出转进本地沙箱(21K stars),Lindy 走共享记忆服务路线——同一时间窗里,掘金、CSDN 上关于上下文数据库上下文节流轻量级上下文模式的解读一篇接一篇。billion-context 的差异化答案很明确:不动模型(免训练)、不动窗口(200K 够)、不搬数据(蒸馏物留在会话内),在代理层做增量分层折叠。拆开源码看,实现路径是四个部件:1. 折叠布局(the fold)。模型窗口 金字塔分级摘要块 逐字最近区。tier-1 块总结一段消息区间;tier-1 积累到一定体量后被折成 tier-2,tier-2 再折成 tier-3——论文的原话是an LSM tree over prose。关键不变量是每段内容一生只被折叠一次,然后以摘要块形式常驻不再变:所以早期内容的保留率恒在 ~1/8(工具主导的块中位 24×),不会像阈值触发式一次性 compaction 那样按 ρ^k 几何衰减(四轮只剩 3–13%)。块携带directBlockIds/effectiveMessageIds血统链,任意块可decompress还原,还有 decompress-to-file 模式把全文写到文件系统而不是上下文,还原时不扰动缓存前缀。2. 模型驱动的压缩决策。代理注入四个工具——compress/decompress/search_context/acp_status——由模型自己调用。触发是需求侧的:增长门(growth-gate)默认每50K token 增量注入一次 nudge(kernel 契约里 growthFloor/growthCap 都是平的 50000,故意不做窗口百分比缩放,见AGENTS.md关键设计决策第 8 条),nudge 只带候选区段 真实大小的推荐清单,从不告诉模型窗口占用百分比,且模型有权拒绝。生产日志显示这不只是纸面设计:五天窗口内 23/103 次有效压缩发生在引擎刻意不注入 nudge 的回合上(22%),模型会自发发起压缩;内核还会把无法恢复的 drop 直接抛错而不是静默降级。3. 会话身份。代理以客户端自己提供的 conversation id逐字作为压缩状态键(src/session-id.ts),不做哈希、不掺协议/上游/API-key 维度——因为那些会中途变化,历史上正是它们在用户还在说话时把状态孤儿化。无头客户端(如裸 pi)走src/prefix-affinity.ts的匿名前缀亲和:历史从位置 0 起字节级复现才重新附着到已有会话,否则铸造独立的pfa-…会话。子会话在出生时上报parentConversationId,获得只读的derivedFrom链,decompress/search_context可以沿父链回查(循环保护 深度上限 8)。4. 可机检的不变量。这是仓库里最非典型的部分:proof/spec/下用 SMT-LIB 对出站请求体的组装写了字节级模型,在 Z3 上证明了两条定理——T1(增长稳定性:追加一条消息后,新旧请求体共享长度 ≥D 的字节前缀,除声明过的 carrier 位置外逐字节相等)、T2(ref id 永不复用:单调游标下已发号不会重发),每条定理配一个变异孪生(注入已知缺陷,solver 必须在时间预算内给出反例,否则证明视为无效),再配 grounding 测试把每条公理钉回真实代码(kernel/src/rebuild.ts、kernel/src/refs.ts等)。proof/README.md甚至单列了一节Trust boundary,明说定理证明的是满足公理的组装函数,代码↔公理的同步由 grounding 测试 计费套件双机制兜底。对前缀缓存这种错一个字节就重付整个前缀的系统,用求解器锁字节前缀,是社区在讨论实现路径时反复被引用的一点。此外,压缩有 proxy / plugin 两种模式、摘要载体不同(proxy 模式用acp_summary消息,plugin 模式用工具调用本身),内核源码就 vendored 在kernel/(npm 名acp-kernel,550 独立测试,构建时内联进dist/index.js),统一存储走 SQLite(src/storage/,node:sqlite内置优先),当前默认shadow模式双写对账——这些细节构成了第三方写贡献指南时的全部骨架。四、社区焦点三:工程治理与贡献门槛71 天里最容易被低估的部分,是这个项目把怎么修 bug写成了规范。AGENTS.md(仓库自述的最高优先级开发规范)里能看到一套完整的治理机器:自动合并 8 条门槛:单模块、有复现原 bug 的回归测试、rebase 最新 master 全绿、不碰配置 schema/持久化格式/wire 形状/kernel、纯fix:、diff 干净、引用 issue、不碰承重基建——历史数据里约 7% 的 PR 需要二轮返工,主因是过期 base和只修症状路径;kernel 变更人类门槛:触碰kernel/**的 PR 必须在正文声明kernel-change: reason,先经 owner 批准,内核版本 bump 由 CI 强制,永不自动合并;版本纪律:版本号只在*_release-v*发布分支变更,lock-syncCI 校验package-lock.json同步——绝不在内容分支碰version;发布通道:CI 全自动发布到 npm tag Release;billion-context-release-notes(分层、模型撰写的发布注记)与billion-context-advisories(critical 缺陷强制更新,可指定回滚目标版本)作为独立 npm 包,代理每 3 分钟轮询,失败时指数退避(5 分钟起、上限 6 小时)且不阻塞模型流量;许可证:MIT 一条附加条款——任何终端用户可见/可交互且使用了本软件的产品,须在首页或文档中注明使用了 billion-context 并附仓库链接(LICENSE末尾)。这条MIT1在社区讨论里也是话题,它划清了谁算下游的边界。可观测性则直接面向终端用户:客户端内/acp面板(会话、块、可压缩区段、用量)、/acp-cache缓存归因报告( GRAND LEDGER / FOLD ECONOMICS / LINE ITEMS / MODEL SWITCHES 四个区块,把 miss 分解成新增内容、压缩重付、TTL 过期、密钥轮换),以及 Web 控制台(会话列表、逐会话明细、命中率折线图、配置编辑、上游连通性测试)。健康判据就一行:命中率低于 95–97% 时,报告按上游 TTL → 模型切换 → bili bug → 其他的顺序告诉你嫌疑对象。五、下一步值得盯的里程碑从CHANGELOG.md的 Unreleased 段、论文[P](planned)标记和最近的 devlog,可以列出一个有明确仓库证据的观察清单:增量回合(#3248)——客户端停止重发全量历史。原生宿主现在可以在普通模型请求上打x-bili-plugin-turn: 1,首回合 seed 规范态、后续回合只发 delta(含上一条 assistant 回复),代理端组装完整 body 重入管线,严格x-bili-applied-seq回执,409 强制 resync。对数十亿 token 单会话而言,这砍掉的是每轮重发完整历史的 O(full) 管线开销,是当前 roadmap 上杠杆最大的一条。R3 内存平面(#3050)——把最长会话的常驻内存降下来。空闲会话的元数据、块内容、raw tail 在保存后折叠成懒加载壳(实测最肥的 dogfood 会话分别省 ~19.6 / ~27 / ~47 MB),启动预热集默认关闭(空闲 RSS −151 MB),新增GET /__bili/memory诊断端点。超长会话的另一个瓶颈从来不只是 token,还有代理自身的内存。统一存储 Phase 3。SQLite 索引已是 shadow 默认真相源(storage.unified当前默认shadow),下一步是storage.jsonWriter: off——JSON 信封彻底退役,SQLite 成为唯一持久副本;fork 检查点已随本阶段落地。持久化格式变更是这个项目自己划的承重区,值得盯它怎么过回滚契约。论文 [P] 项落地。RQ1 的 7 臂全量评估(含 oracle 全上下文臂与忠实的 LCM 无损递归实现,OOLONG 与 SWE-ContextBench 基准)、RQ4 的脱敏语料公开(目前 4,843 会话的原始存储尚未公开,论文写明sanitized corpus planned)。多个月、多宿主、24.7B token 的压缩语料一旦放出,会直接改变这条赛道谁有生产数据的格局。doctrine → weights,以及 ~50K 极端压缩区间。论文 §9 把压缩 doctrine 定位成可版本化的判断规格,两条延伸:把日志里的压缩决策做成 SFT 课程蒸馏进权重(模型不再需要脚手架提示),以及针对 ~50K 总上下文的极端压缩配置(受速率限制的 nudge 是缺的安全阀)。前者如果走通,免训练这个项目的立身之本会进化成先免训练、后蒸馏。28.6B 仿真外推会被实测追上多少。当前最长实测会话(1.52B)只触及模型上限的 5.3%,论文自己标注这是 ~19× 外推、tier-3 蒸馏率尚属设计值。未来几个月马拉松会话继续跑,实测与仿真的差距本身就是最好的进度条;顺带留意 tier-3 蒸馏在生产中是否开始被观测到(当前 1,711 块中 tier-2 只有 60 个)。71 天,billion-context 交出的不只是一个省 token 的代理,而是一整套可审计的证据链:实测数字标[V]、仿真数字标[A]、计划实验标[P],前缀稳定性有求解器背书,修复通道有 critical 分级与强制更新兜底。社区讨论的重心从它能不能做到转向怎么贡献代码和下一个里程碑是什么——对一个上线第七周的项目来说,这已经是相当少见的社区状态。【免费下载链接】billion-contextA context-compression plugin for small context windows (a 100K context is enough), token savings (5x fewer tokens), and month-long single sessions (billions of tokens).上下文压缩插件兼顾小窗口(100k上下文足矣)省token(省5倍token)和超长会话(数月级别几十亿token单会话)。billion-context is all you need项目地址: https://gitcode.com/gh_mirrors/bil/billion-context创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 从 100K 到十亿级单会话:billion-context 上线的第 71 天,社区在聊什么
从 100K 到十亿级单会话:billion-context 上线的第 71 天,社区在聊什么【免费下载链接】billion-contextA context-compression plugin for small context windows (a 100K context is enough), token savings (5x fewer tokens), and month-long single sessions (billions of tokens).上下文压缩插件兼顾小窗口(100k上下文足矣)省token(省5倍token)和超长会话(数月级别几十亿token单会话)。billion-context is all you need项目地址: https://gitcode.com/gh_mirrors/bil/billion-context一个夹在编码 Agent 和模型 API 之间的本地代理,把上下文不够用拆成了一道可审计的工程问题:不扩窗口、不加显存、不堆向量库,而是让模型自己决定把已消费的对话折叠成可逆摘要。billion-context 于 2026-08-06 开源,今天是它上线的第 71 天。这个时间点的观察价值在于:它已经跑出了真实的用户反馈回路——GitHub 的 issue/PR 编号推进到 3200,npm 版本号从 0.1.34 走到了 0.1.197,仓库里沉淀了 800 多个测试文件和一篇 MIT 许可的预印本论文。本文基于仓库源码、CHANGELOG、论文与最近的社区文章,回答三个问题:71 天的增长轨迹是什么形状;100K 上下文撑几十亿 token 单会话的量级跨度是否可信;以及接下来值得盯的里程碑在哪里。一、71 天的增长轨迹:一周一个功能面,一天一个补丁先看节奏。仓库里的版本证据链很密:8 月 8 日(上线第 3 天),reference/release.md中的发布分支示例已是2026-08-08_release-v0.1.17;到8 月 11 日,CHANGELOG 记录已推进到0.1.34——头一周就密集修掉了 thinking 模式reasoning_content回传 400、round-2 流式缓冲、compress 死循环这类第一天就会遇到的问题;8 月 24 日前后,CHANGELOG 已记录到0.1.49,devlog 目录(devlog/)在 8 月 13 日至 9 月 27 日间沉淀了 36 个迭代记录,每条都带实施前写好的REQ.md和实施中写好的WORKLOG.md;当前package.json中的版本是0.1.197。71 天,160 多个 npm 发布,平均不到一天一个版本。活动量上,tests/目录最大的回归测试编号已到issue3250,最近一次合并的 PR 是#3234,71 天内 issue/PR 编号推进到 3200,意味着平均每天 40 多个社区事件(提交、讨论、回归)。测试规模同样可观:tests/下 700 多个测试文件,kernel/tests/96 个,pi-subagents/tests/16 个,tests/e2e/17 个套件——其中 E2E 直接驱动真实的codexCLI 穿过代理与 Responses 兼容上游,断言 warmup → 负载增长 → ACP 压缩 → 原生 compact 拦截的完整生命周期。社区讨论的密度也能佐证。10 月 14 日,CSDN 上出现了一篇专门讲如何为 billion-context 贡献代码的开发者指南,通篇是 500 测试体系、原生插件协议(x-bili-plugin头 GET /__bili/plugin/manifestPOST /__bili/plugin/tool)与统一存储架构的拆解——当一个 71 天的项目开始有第三方写贡献指南,说明它的社区叙事已经从怎么用切换到了怎么共建。客户端覆盖面也在持续扩张。README.md的 Which do I need? 表格里现在列了 20 多个宿主:pi、opencode、omp、dsh、kimi、hermes、zcode、claude、codex、gemini、iflow、qwen、antigravity、mcode、aider、copilot、amp、crush、zed、goose、codebuddy、qoder、trae、jcode——有插件接缝的走bili plugin install client原生模式,没有的走bili client启动器(cert-MITM 或/bili/baseURL 改写),兜底方案是把 baseURL 前缀换成http://localhost:8787/bili/。还有一个容易被忽略的信号:10 月上旬的发布注记(release-notes/package.json,由 CI 从本仓库发布到独立 npm 包)在 10 月 1 日至 12 日间出了 5 个版本,其中 3 个是critical级——0.1.186(修 codex 启动器与 claude code 账号场景)、0.1.192/0.1.193(修 dsh/codex 切模型导致会话 fork、压缩状态失效、缓存重付)。critical 级发布集中出现在上线第 56–67 天,恰好是真实用户把 dsh 桌面版、codex 订阅登录这类长尾场景用出来的阶段:这 71 天里,项目经历了跑通 → 跑顺 → 长尾场景挨个打补丁的完整过程,而它的自动更新 critical 分级注记 advisories/强制更新通道(独立 npm 包,当前 advisory 列表为空,即从未触发过)构成了完整的线上修复闭环。二、社区焦点一:量级跨度到底可不可信100K 上下文够用、单会话几十亿 token——这是 README 第一行的承诺,也是社区质疑最多的一点。可信的关键在于分清仓库里三个不同口径的数字,它们都来自随代码开源的论文(paper/目录下,MIT 许可的活文档,v0.2 版,2026-09-07):口径一:实测多会话总量。主宿主机上 4.5 个月(2026-04-23 → 2026-09-07)的生产日志:4,843 个会话、174,327 次模型调用、18.76B 累计输入 token(其中 1.75B 是新鲜输入,17.01B 是缓存读取),三台宿主合计约 24.7B。注意这是累计输入口径、跨会话的,且缓存读取占绝对大头(读:新 ≈ 9.7:1)——billion 首先是这个名字的由来,而不是单次请求的大小。口径二:实测单会话马拉松。真正对应十亿级单会话的数字:OpenCode 宿主上最长的会话跑了12,049 次调用、1.52B 累计输入 token,峰值上下文 374,946(1M 级窗口);Pi 宿主上最长的会话8,584 次调用、1.01B token,峰值 257,721。这两个数字是逐次调用从 API usage 里实测的,不是推演。口径三:仿真外推上限。论文 §7 给出的1M 窗口单会话可支撑28.6B token / 106 天是闭式推导 离散事件仿真的结果,论文明确标注为[A: simulation],且承认这是对最大实测会话约 19 倍的纯外推,tier-3 蒸馏率甚至是设计值(未观测到)。附录 B 的 Claims register 把每个声明逐条标了[V](有日志证据)/[A](分析模拟)/[P](计划实验)——把哪些是实测、哪些是模型写进论文正文,这本身就是回应量级可信度质疑的方式。支撑这套数字的工程事实有三条,都在源码里有对应物:零窗口违规。204,800 窗口模型上 42,986 次调用零溢出(峰值 198,628);第三台宿主(ework,自主 agent 服务)12.2 天 32,733 次调用对 262,144 窗口同样零违规,峰值 229,355(87.5%)。Pi 宿主更干净的逐次计费显示平均 88K / 中位 72K / p99 218K——典型的锯齿震荡在窗口带内,而不是爬升。折叠只压缩已消费的增量。生产数据:229M token 被压缩,但 62% 集中在 1.3% 的超大会话里(≥1000 条消息)——论文称之为马拉松现象:短会话基准根本观测不到压缩真正起作用的地带。单次压缩的产出中位只有185 token、97.5% 不超 2K;每次折叠中位吃掉 2.6K 增量。重负载会话(历史中位 ~530K)最终只留 ~13K 常驻摘要,宏观折叠比约70×。前缀缓存不被压缩破坏。这是省 5 倍 token的经济学核心:历史 append-only、压缩只把后缀区段置为摘要,已建立的 KV 前缀永不失效。实测缓存读取占比 90.7%(主宿主混合值),按调用间隔分层后,间隔 2 分钟(占 89% 流量)的请求缓存读取占比达94.2%,miss 归因里只有 16% 来自新追加的后缀,其余是 provider 侧 TTL 过期——与布局无关。README 的健康判据也写得很直白:健康会话保持95–97%前缀缓存命中,压缩本身的成本 ≤2%。受控实验给了另一组佐证:在 Session Marathon 试点里,压缩组相对保留基线计费 token 降 31–54%、重复取数(re-fetch)调用降 63%(2.7×),而记忆探针得分持平;阶段结构化负载上默认配置在质量、成本、方差三个维度全部最优。论文也诚实地记录了反面:128K 窗口的静默对照组(不执行任何压缩、只保留 doctrine 文本和消息标签)独自复现了几乎全部的 re-fetch 降幅(−62% vs −63%),说明收益大部分来自判断内容 标签布局这个组合,而不是压缩动作本身。三、社区焦点二:实现路径——一个 fold,而不是更大的窗口2026 年的Agent 上下文工程已经是条热闹赛道:火山引擎的 OpenViking 把 Agent 记忆做成可自进化的上下文数据库,headroom 主打上下文压缩层、最高省 95% token,Context Mode 用 SQLite FTS5 BM25 把大输出转进本地沙箱(21K stars),Lindy 走共享记忆服务路线——同一时间窗里,掘金、CSDN 上关于上下文数据库上下文节流轻量级上下文模式的解读一篇接一篇。billion-context 的差异化答案很明确:不动模型(免训练)、不动窗口(200K 够)、不搬数据(蒸馏物留在会话内),在代理层做增量分层折叠。拆开源码看,实现路径是四个部件:1. 折叠布局(the fold)。模型窗口 金字塔分级摘要块 逐字最近区。tier-1 块总结一段消息区间;tier-1 积累到一定体量后被折成 tier-2,tier-2 再折成 tier-3——论文的原话是an LSM tree over prose。关键不变量是每段内容一生只被折叠一次,然后以摘要块形式常驻不再变:所以早期内容的保留率恒在 ~1/8(工具主导的块中位 24×),不会像阈值触发式一次性 compaction 那样按 ρ^k 几何衰减(四轮只剩 3–13%)。块携带directBlockIds/effectiveMessageIds血统链,任意块可decompress还原,还有 decompress-to-file 模式把全文写到文件系统而不是上下文,还原时不扰动缓存前缀。2. 模型驱动的压缩决策。代理注入四个工具——compress/decompress/search_context/acp_status——由模型自己调用。触发是需求侧的:增长门(growth-gate)默认每50K token 增量注入一次 nudge(kernel 契约里 growthFloor/growthCap 都是平的 50000,故意不做窗口百分比缩放,见AGENTS.md关键设计决策第 8 条),nudge 只带候选区段 真实大小的推荐清单,从不告诉模型窗口占用百分比,且模型有权拒绝。生产日志显示这不只是纸面设计:五天窗口内 23/103 次有效压缩发生在引擎刻意不注入 nudge 的回合上(22%),模型会自发发起压缩;内核还会把无法恢复的 drop 直接抛错而不是静默降级。3. 会话身份。代理以客户端自己提供的 conversation id逐字作为压缩状态键(src/session-id.ts),不做哈希、不掺协议/上游/API-key 维度——因为那些会中途变化,历史上正是它们在用户还在说话时把状态孤儿化。无头客户端(如裸 pi)走src/prefix-affinity.ts的匿名前缀亲和:历史从位置 0 起字节级复现才重新附着到已有会话,否则铸造独立的pfa-…会话。子会话在出生时上报parentConversationId,获得只读的derivedFrom链,decompress/search_context可以沿父链回查(循环保护 深度上限 8)。4. 可机检的不变量。这是仓库里最非典型的部分:proof/spec/下用 SMT-LIB 对出站请求体的组装写了字节级模型,在 Z3 上证明了两条定理——T1(增长稳定性:追加一条消息后,新旧请求体共享长度 ≥D 的字节前缀,除声明过的 carrier 位置外逐字节相等)、T2(ref id 永不复用:单调游标下已发号不会重发),每条定理配一个变异孪生(注入已知缺陷,solver 必须在时间预算内给出反例,否则证明视为无效),再配 grounding 测试把每条公理钉回真实代码(kernel/src/rebuild.ts、kernel/src/refs.ts等)。proof/README.md甚至单列了一节Trust boundary,明说定理证明的是满足公理的组装函数,代码↔公理的同步由 grounding 测试 计费套件双机制兜底。对前缀缓存这种错一个字节就重付整个前缀的系统,用求解器锁字节前缀,是社区在讨论实现路径时反复被引用的一点。此外,压缩有 proxy / plugin 两种模式、摘要载体不同(proxy 模式用acp_summary消息,plugin 模式用工具调用本身),内核源码就 vendored 在kernel/(npm 名acp-kernel,550 独立测试,构建时内联进dist/index.js),统一存储走 SQLite(src/storage/,node:sqlite内置优先),当前默认shadow模式双写对账——这些细节构成了第三方写贡献指南时的全部骨架。四、社区焦点三:工程治理与贡献门槛71 天里最容易被低估的部分,是这个项目把怎么修 bug写成了规范。AGENTS.md(仓库自述的最高优先级开发规范)里能看到一套完整的治理机器:自动合并 8 条门槛:单模块、有复现原 bug 的回归测试、rebase 最新 master 全绿、不碰配置 schema/持久化格式/wire 形状/kernel、纯fix:、diff 干净、引用 issue、不碰承重基建——历史数据里约 7% 的 PR 需要二轮返工,主因是过期 base和只修症状路径;kernel 变更人类门槛:触碰kernel/**的 PR 必须在正文声明kernel-change: reason,先经 owner 批准,内核版本 bump 由 CI 强制,永不自动合并;版本纪律:版本号只在*_release-v*发布分支变更,lock-syncCI 校验package-lock.json同步——绝不在内容分支碰version;发布通道:CI 全自动发布到 npm tag Release;billion-context-release-notes(分层、模型撰写的发布注记)与billion-context-advisories(critical 缺陷强制更新,可指定回滚目标版本)作为独立 npm 包,代理每 3 分钟轮询,失败时指数退避(5 分钟起、上限 6 小时)且不阻塞模型流量;许可证:MIT 一条附加条款——任何终端用户可见/可交互且使用了本软件的产品,须在首页或文档中注明使用了 billion-context 并附仓库链接(LICENSE末尾)。这条MIT1在社区讨论里也是话题,它划清了谁算下游的边界。可观测性则直接面向终端用户:客户端内/acp面板(会话、块、可压缩区段、用量)、/acp-cache缓存归因报告( GRAND LEDGER / FOLD ECONOMICS / LINE ITEMS / MODEL SWITCHES 四个区块,把 miss 分解成新增内容、压缩重付、TTL 过期、密钥轮换),以及 Web 控制台(会话列表、逐会话明细、命中率折线图、配置编辑、上游连通性测试)。健康判据就一行:命中率低于 95–97% 时,报告按上游 TTL → 模型切换 → bili bug → 其他的顺序告诉你嫌疑对象。五、下一步值得盯的里程碑从CHANGELOG.md的 Unreleased 段、论文[P](planned)标记和最近的 devlog,可以列出一个有明确仓库证据的观察清单:增量回合(#3248)——客户端停止重发全量历史。原生宿主现在可以在普通模型请求上打x-bili-plugin-turn: 1,首回合 seed 规范态、后续回合只发 delta(含上一条 assistant 回复),代理端组装完整 body 重入管线,严格x-bili-applied-seq回执,409 强制 resync。对数十亿 token 单会话而言,这砍掉的是每轮重发完整历史的 O(full) 管线开销,是当前 roadmap 上杠杆最大的一条。R3 内存平面(#3050)——把最长会话的常驻内存降下来。空闲会话的元数据、块内容、raw tail 在保存后折叠成懒加载壳(实测最肥的 dogfood 会话分别省 ~19.6 / ~27 / ~47 MB),启动预热集默认关闭(空闲 RSS −151 MB),新增GET /__bili/memory诊断端点。超长会话的另一个瓶颈从来不只是 token,还有代理自身的内存。统一存储 Phase 3。SQLite 索引已是 shadow 默认真相源(storage.unified当前默认shadow),下一步是storage.jsonWriter: off——JSON 信封彻底退役,SQLite 成为唯一持久副本;fork 检查点已随本阶段落地。持久化格式变更是这个项目自己划的承重区,值得盯它怎么过回滚契约。论文 [P] 项落地。RQ1 的 7 臂全量评估(含 oracle 全上下文臂与忠实的 LCM 无损递归实现,OOLONG 与 SWE-ContextBench 基准)、RQ4 的脱敏语料公开(目前 4,843 会话的原始存储尚未公开,论文写明sanitized corpus planned)。多个月、多宿主、24.7B token 的压缩语料一旦放出,会直接改变这条赛道谁有生产数据的格局。doctrine → weights,以及 ~50K 极端压缩区间。论文 §9 把压缩 doctrine 定位成可版本化的判断规格,两条延伸:把日志里的压缩决策做成 SFT 课程蒸馏进权重(模型不再需要脚手架提示),以及针对 ~50K 总上下文的极端压缩配置(受速率限制的 nudge 是缺的安全阀)。前者如果走通,免训练这个项目的立身之本会进化成先免训练、后蒸馏。28.6B 仿真外推会被实测追上多少。当前最长实测会话(1.52B)只触及模型上限的 5.3%,论文自己标注这是 ~19× 外推、tier-3 蒸馏率尚属设计值。未来几个月马拉松会话继续跑,实测与仿真的差距本身就是最好的进度条;顺带留意 tier-3 蒸馏在生产中是否开始被观测到(当前 1,711 块中 tier-2 只有 60 个)。71 天,billion-context 交出的不只是一个省 token 的代理,而是一整套可审计的证据链:实测数字标[V]、仿真数字标[A]、计划实验标[P],前缀稳定性有求解器背书,修复通道有 critical 分级与强制更新兜底。社区讨论的重心从它能不能做到转向怎么贡献代码和下一个里程碑是什么——对一个上线第七周的项目来说,这已经是相当少见的社区状态。【免费下载链接】billion-contextA context-compression plugin for small context windows (a 100K context is enough), token savings (5x fewer tokens), and month-long single sessions (billions of tokens).上下文压缩插件兼顾小窗口(100k上下文足矣)省token(省5倍token)和超长会话(数月级别几十亿token单会话)。billion-context is all you need项目地址: https://gitcode.com/gh_mirrors/bil/billion-context创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考