开源神器Billion Context：为AI编程Agent解锁无限上下文

长任务编程Agent总在上下文窗口爆满时崩溃？每轮对话重发历史记录，token账单高企？GitHub上有个叫Billion Context的项目，宣称能让单次会话持续一个月、在100k窗口内吞吐数十亿token，还把token消耗降到五分之一。不到三个月拿下约3700 star、300 fork。它到底做了什么，又藏着哪些坑？

它解决的是什么问题

AI编程Agent处理长任务时，对话历史会不断膨胀。上下文窗口被占满后，Agent要么把内容硬压成笼统摘要，要么直接中断；而且每轮请求都要重发全部历史，重复token的费用白白烧掉。

Billion Context的思路是在Agent和模型API之间加一层轻量代理。你只需把Agent的base URL指向它，请求就会先经过它。它读取对话内容，压缩已完成的部分，再转发给真实模型。兼容Anthropic和OpenAI两种API格式，理论上任何Agent都能接。

压缩机制：增量、可逆、不毁缓存

它不是到上限就粗暴截断，而是给模型四个新工具：

compress：把一段消息折叠成详细摘要
decompress：将指定片段调回，需要细节时查看原文
search context：对全部压缩内容做关键词检索
状态查询：显示上下文占用率以及还有哪些内容可压缩

模型自行决定何时压缩、压缩什么。与Agent自带的总结功能相比，它的压缩是增量式的——只对小范围内容做摘要，而非一次性概括全文，且过程完全可逆。

增量压缩与内置总结的差异

更关键的是缓存。官方称正常会话的提示词缓存命中率稳定在95%到97%，压缩本身的开销仅占2%甚至更低。缓存token极为便宜，保住缓存意味着省钱又不掉速。

提示词缓存（Prompt Caching） 是主流模型 API 提供的一项降本机制：服务端会把请求中重复出现的前缀部分（系统提示、历史对话等）缓存下来，后续请求若前缀完全相同，这部分 token 便以远低于常规输入的价格计费，并能跳过重复的预填充计算，从而降低延迟。Anthropic、OpenAI 均按缓存命中/未命中分档计价，缓存读取费用通常只有常规输入价的十分之一左右。

对长会话 Agent 而言，缓存的关键约束是「前缀必须稳定」：一旦中间某段历史被改写或截断，后面的缓存全部失效，下一轮就要按全价重算。这也是暴力摘要方案往往「省了 token 却更贵」的原因。Billion Context 之所以强调增量压缩与高命中率，正是为了在改动历史的同时尽量只影响局部前缀，保住绝大部分缓存收益。

基准测试：省钱且略有胜出，但别指望逐字召回

作者在仓库附了一篇论文，覆盖长达四个半月的实际使用、17.4万次模型调用、187.6亿输入token，上下文窗口零溢出，且全部在200k模型上完成。

第三方基准测试跑在DeepSeek^广告 V4.1 Flash上：

Context Bench（编程Agent探索真实代码库）：Billion Context 的F1分数0.31，超过全上下文的0.29；成本4.61美元，对比全上下文的11.05美元，降低58%
Long Memo Val：得分79.2%，全上下文为83.2%，远高于最佳RAG方案的62.6%，成本降低71%
148万token测试：全上下文199次测试全部失败，Billion Context凭约30倍压缩比每次过关

代价也很明确。大海捞针式精确检索某句原话时，准确率从69%降至27%。摘要保留核心语义，不是逐字原文。对编程Agent而言通常是划算的权衡，但你得心里有数。

精确召回率明显下降

F1 分数 是分类/检索类任务的常用综合指标，取精确率（Precision，检出的内容里有多少是对的）与召回率（Recall，该检出的内容有多少被检出）的调和平均，取值范围 0 到 1。F1 为 0.31 与 0.29 这类数值看似很低，是因为此类基准的判定通常较严格（要求定位到正确的文件、函数或代码片段），绝对值不具直观意义，重点在于两者之间的相对高低。

大海捞针（Needle in a Haystack） 则是一种长上下文压力测试：在超长文本的随机位置埋入一条特定信息，再要求模型准确复述。它考察的是逐字级检索能力，与语义理解是两条不同的能力维度。压缩方案会改写原文，因此在这类测试上天然吃亏——文章提到的 69% 降至 27% 正是这一差异的体现。

上手：三种接入方式，搭配低价开源模型

安装运行 npm install -g billion-context，用prefix参数指定本地目录后即可使用billy命令。三种用法：

运行 billy plugin install 加客户端名，作为原生插件支持OpenCode、KimiCode等
直接 billy 加客户端名启动客户端并通过代理，无需改配置
先启动billy，再把代理地址加在base URL前面，适合其他客户端

搭配Claude Pass（注：素材音译为Client Pass/Clumpass）尤其划算。这是每月9.99美元的订阅，提供DeepSeek V4.1 Flash、Kimi K3.1 Pro、GLM 5.3、Qwen 3.8 Max、MiniMax M3.1 Flash等开源编程模型，调用速率上限是常规的2-5倍，还能通过兼容OpenAI标准的API独立使用。

在Claude（素材音译为Client）中选OpenAI兼容服务商，base URL填入本地代理地址加上API地址，模型填 claude-pass/deepseek-v4.1-flash。每个请求都会先经Billion Context压缩，再转发至Claude Pass。仓库已将其列为官方认证客户端。

配置OpenAI兼容服务商

桌面端同样适用，适合并行多个会话、设置任务排期、导入Claude Code或Codex历史继续执行。同一套餐额度因为历史被精简，能撑得更久。

启动后在浏览器打开本地仪表盘，可看会话列表、实时日志和配置编辑器。在支持的客户端输入 slash 命令可生成报告，包含缓存命中率、每次压缩节省的token数，以及命中率下降时是什么导致缓存失效。

压缩节省的token明细

如何融入多Agent编排

视频作者常用PandaCode做图形化编排：一个架构师统筹全局，把具体任务分发给独立worker，Claude是内置运行框架之一。架构师是生命周期最长的会话，上下文膨胀最厉害，也是压缩最能派上用场的地方。既然worker可以跑在OpenCode或自带原生billy插件的KimiCode上，整条工作流就能保持轻量。

必须知道的局限

迭代极快，目前仅0.1.21版本，默认自动更新主分支，随时可能出Bug，务必从npm安装正式发布版
带host参数运行时完全没有身份验证，只在受信任的网络中使用
桌面端的Code标签页会绕过代理，那部分不会被压缩
精确召回率下降，调取久远逐字原文需先解压
官方文档篇幅很长、技术性强，配置需要花时间研读

主分支自动更新 在快速迭代的开源项目中是双刃剑。默认跟踪主分支意味着每次拉取都会拿到最新提交，可能包含未充分测试的改动、破坏性接口变更甚至半成品功能，随时可能让原本可用的工作流突然失败。稳妥做法是通过 npm 安装带版本号的正式发布版，并锁定版本号，等确认新版本稳定后再手动升级；生产或多 Agent 编排场景尤其应避免直接跟随主分支。

谁适合用

如果Agent长任务总中途挂掉，或者token成本高得离谱，这个代理层值得一试：让模型压缩自己的历史、用工具分段且可还原、同时不破坏原有缓存。在DeepSeek V4.1 Flash上的基准显示，它比全量上下文更省钱，代码任务上甚至略胜。搭配低价订阅套餐与桌面客户端，是当前长会话编程Agent场景里一个务实的解法。