开源社区正在为 Agent 重建“上下文基建“，billion-context 站到了哪一环

开源社区正在为 Agent 重建上下文基建billion-context 站到了哪一环【免费下载链接】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一个跑了三天的 coding agent 会话上下文窗口是如何死去的工具输出逐轮堆积harness 在窗口边缘触发一次阈值式 compaction把全部历史压成一个不可逆的摘要 blob——从这一刻起agent 永远丢失了为什么当时这么修的过程性记忆而 token 账单并没有因为历史被总结过而变便宜。把最近一年社区里与上下文相关的开源情报摊开看能清晰地分辨出三条路线卷模型窗口、把上下文搬出去、教会 agent 自己管理上下文。billion-context 恰好卡在第三条路线的入口而且是目前少数拿得出多个月生产级纵向数据的项目。本文结合仓库源码拆解它到底站到了哪一环、护城河是什么、以及它身上已经出现的标准化苗头。一、三次开源浪潮从放大窗口到自己管理上下文第一浪把窗口做大。2023 年微软 LongNet 把 Transformer 上下文实验做到 10 亿 token2025 年起 MiniMax-01/M11M/4M 上下文、QwenLong-L1 等开源长上下文模型密集出现。这条路线的代价是显存与成本线性上涨且注意力在长上下文尾部的退化是结构性的——论文的综述部分把这称为扩窗路线它解决的是装得下不解决记得住。第二浪把上下文搬出去。2026 年上半年外部记忆与上下文数据库成为显学字节火山引擎开源的 OpenViking 用虚拟文件系统统一管理 agent 记忆、RAG 与技能Lindy 以 Go 实现跨会话共享记忆服务Context Mode 靠 SQLite FTS5 BM25 把 agent 的大输出转进本地沙箱检索拿到 21K starsheadroom 这类上下文压缩层宣称最高省 95% token。这条路线的共同问题是事实抽取fact extraction能回答说过什么但丢掉了 traceback、约束条件等过程性上下文——一旦内容离开窗口就不可恢复。第三浪让 agent 在会话内自己管理上下文。学术界的研究主线AgentFold、Context-ReAct、ACM不约而同收敛到训练路线每个 agent 框架配一个定制 checkpoint策略在训练时冻结。与此同时有研究量化了生产级/compact式一次性摘要的保真坍塌五轮之后安全规则存活率只剩 10%。第三浪里真正空出来的生态位是免训练training-free、模型自主决策压缩时机与内容、多代可逆、并且有生产数据。billion-context 的仓库里把这三点分别落成了 kernel、doctrine压缩教义和一块开源的论文。二、定位不是另一个框架而是 Agent 与模型 API 之间的上下文数据面billion-context 的形态在 README.md 开头就说清了它站在任意agent 与其模型 API 之间是一个代理proxy用 acp-kernel 对 Anthropic / OpenAI 的流式请求做压缩改写agent 只需要把 base URL 指过来零适配代码。三种接入姿势覆盖了不同的宿主能力原生插件bili plugin install pi / opencode / dsh / kimi / hermes / zcode——代理活在客户端进程内launcherbili claude/bili codex/bili gemini…——一条命令拉起代理加客户端证书 MITM 或/bili/URL 重写不碰任何真实配置文件URL 改写最通用——baseURL 前缀拼上http://localhost:8787/bili/完整上游URL。代理向会话注入四个上下文管理工具compress把一段消息区间折叠为摘要块、decompress按需还原、search_context跨摘要块与可见消息的关键字检索、acp_status上下文占用总览。关键设计是模型驱动什么时候压、压哪段、压多狠由模型基于任务状态自行决定拒绝压缩是被允许的拒绝是质量阀门不是失败增长门控的 nudge 只负责保底。内核 kernel/README.md 自称host-agnostic, model-driven约一万行 TypeScript、零宿主依赖心智模型类似 zip 库processTurn({ messages, state }) → { messages, state, nudge? } applyCompression({ call, state }) → { state, result }它实现的是一种3 层 LSM-tree 式摘要分层tier-1 块摘要消息区间tier-2 折叠 tier-1 块tier-3 再折叠 tier-2每代块保留到源消息的引用链effectiveMessageIds传递覆盖任何块都可以单独decompress还原甚至走 decompress-to-file 模式把原文写盘而不污染 KV 前缀。论文把这个布局命名为the fold护城河首先是数据。仓库里的 paper/MIT 许可、可 PR 的 living document报告了 4.5 个月、三台宿主机的生产纵向研究174,327 次模型调用、18.76B 累计输入 token三宿主合计约 24.7Bbillion-context名字由此而来在 204,800 token 窗口的模型上零窗口违例marathon 会话达到 8,584–12,049 次调用重度会话历史均值 ~900K token 最终只留下 ~13K 摘要约 70× 常驻折叠单次压缩输出中位数仅 185 token。仿真给出 1M 窗口下单会话可持续 ~28.6B token / 106 天的上限。作者自称这是首个多月跨宿主部署的会话内压缩纵向研究——对长会话这类马拉松现象短会话 benchmark 根本观测不到。护城河的第二层是缓存经济学。因为历史是 append-only、压缩只停用折叠掉的区间KV 前缀缓存永不被压缩动作失效活跃节奏下 cache-read share 实测 94.2%README 给出的健康基线是 95–97% 前缀缓存命中率、压缩本身开销 ≤2%并用/acp-cache面板做逐段归因TTL 过期 / 模型切换 / key 轮换 / 缺陷。对比重写式compaction 每次全窗口重付这是真金白银的差异。第三层是工程纵深。tests/目录下有 690 个.test.ts文件README 口径500 passing实际已远超更有意思的是 proof/ 目录——用 Z3 对出站请求体组装的字节级模型做了机器检验T1 证明追加消息后新旧请求体共享的字节前缀下界增长稳定性T2 证明 ref 编号永不复用单调游标且每条定理都有mutation twin——注入已知缺陷必须能产出反例否则证明视为无效。把缓存稳定性写成可证伪的定理这在同类项目里是独一份。三、标准化的苗头合作式插件协议与统一存储架构如果说数据是护城河那么仓库里正在沉淀的两份协议资产就是标准化的苗头。其一Cooperative Plugin Protocolv2。PLUGIN.md 把内外分工画成了一张责任表工具注册、agent 自身的 tool loop、会话身份由**插件宿主侧负责压缩引擎、状态、折叠/引用/ nudge 由代理外部**负责工具 schema 与压缩教义 prompt 一律由运行中的代理下发——插件是一根刻意做薄的管子proxy 与 plugin 永远不会漂移。协议核心端点只有几个GET /__bili/plugin/manifest启动时拉取能力声明、POST /__bili/plugin/tool执行compress等工具带expectedRevision乐观并发控制过期返 409、GET /__bili/plugin/status面板级上下文读数、POST /__bili/plugin/compact宿主原生压缩的边界通知以及 fork 协议 2 的snapshot/fork端点——子会话按有序前缀分叉revision 守卫保证并发安全幂等键保证重试语义。这套协议不绑定任何具体 agent本质上是给上下文压缩引擎的宿主接入方式写的一份 RFC 草案。其二统一存储架构。src/storage/schema.ts 注释里的原话值得引用The compression ledger (blocks) is the crown jewel: every state change to it is one transaction。schema 已迭代到 v5核心纪律是三条messages/content/blocks 是append-only 事实UPDATE 即 bug视图永不落盘为内容标量列只是从逐字事实payload_json等派生的投影由 verifier 断言两者一致防止静默漂移。实现上是一个 SQLiteindex.dbWAL 内容寻址 blobWAL journal 上限 8 MiB 以约束长命进程src/storage/driver.ts 的引擎解析链是node:sqlite→ 宿主自带better-sqlite3→ 运行时自下载的 N-API 预编译件任何一环失败都降级回 legacy JSON 持久化——引擎获取永远不依赖宿主的 build-script 审批这个设计直接决定了它能否被塞进各种 host 的插件体系里。配套还有两份正式设计文档SESSION-IDENTITY.md 规定匿名请求的会话归属只靠重放历史的逐字节前缀匹配内容是唯一不可变的锚点系统提示、工具定义、模型名一律不进哈希MESSAGE-IDENTITY.md 处理消息粒度的同类问题。协议 版本化存储 schema 形式化设计记录这三件套正是基础设施项目开始被依赖前的标准动作。四、对上层 Agent 框架的传导效应传导效应最直观的体现是 README.md 里那张客户端矩阵pi、opencode1.x/2.x、omp、dsh、kimi、hermes、zcode、claude、codex、gemini、iflow、qwen、antigravity、mcode、aider、copilot、amp、crush、zed、goose、jcode、codebuddy、trae、qoder——二十多个宿主每个都有明确的接入档位native plugin / launcher / MITM / 纯 URL 前缀和已归档的限制 issue 编号。对上层框架而言这意味着三件事compaction 不再是每个 harness 的私活。窗口管理从各框架自研一次性摘要器变成可插拔的一层opencode 装 bili 插件时顺带关掉原生 auto-compaction 避免双重压缩claude 侧由 managed settings block 接管宿主只保留何时上报身份这一个义务。引擎可以脱离这个仓库单独复用。acp-kernel 是独立 npm 包MIT独立重实现与 AGPL 的灵感来源零源码共享pi-subagents/ 等衍生包共用同一内核任何想自建压缩能力的 agent 框架可以只拿内核不拿代理。运维面开始按基础设施配置。关键缺陷强制更新通道advisories/独立 npm 包3 分钟轮询、fail-open、分层 release notesroutine/recommended/critical 三级静默发布为默认、真实模型回归门禁npm run gate:local——这些在 reference/release.md 与 reference/git-pr.md 中成文是框架型项目向可被生产系统依赖演进的标志。回到标题的问题billion-context 站到了哪一环第一浪属于模型厂商第二浪属于记忆服务与数据库而它占据的是会话内上下文生命周期这一层——在 Agent 与模型 API 之间做有状态的压缩平面模型写摘要引擎管账本存储保血缘协议定接入。三次浪潮短期不会合并但方向清晰窗口会继续变大、记忆服务会更丰富而如何不让上下文在会话内腐烂这一层正从各家 harness 的隐藏功能收敛成一层有协议、有存储格式、有生产数据背书的公共基建。谁先把这层的接口做稳谁就握住了上层 agent 框架事实上的上下文标准。【免费下载链接】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），仅供参考