跑一个月级长会话：billion-context 配置到验证全流程

跑一个月级长会话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 的死法很典型工具输出、诊断日志、决策记录以每轮几千 token 的速度堆积直到撞上上下文窗口——要么被截断丢掉记忆要么被一次性 summarize 成一团不可逆的摘要之后再想翻出三天前那条报错就无望了。billion-context 要解决的就是这个问题它自称100K 上下文足矣靠模型自主决策的增量分层压缩acp-kernel把单会话推到数十亿乃至上十亿 token 的月级尺度同时省约 5 倍 token。这个项目在仓库里随附了一篇 4.5 个月的真实生产纵向研究paper/2026 年 10 月中旬开始CSDN 上也陆续出现开发者指南类文章拆解它的 500 自动化测试体系、原生插件协议与统一存储架构——社区热度之外更重要的是它敢把生产日志摊开来给数字。本文按安装接入 → 长会话配置拆解 → 跨天稳定性验证 → 压缩比与质量的实测数据这条完整链路走一遍所有配置项和数字都能在仓库源码与论文里对到出处。一、先看清楚它压的是什么fold 布局billion-context 是一个架在 agent 与模型 API 之间的 HTTP 代理解析 Anthropic/OpenAI 形态的请求对会话运行 acp-kernel 压缩注入compress/decompress/search_context/acp_status四个上下文管理工具再转发到真实模型 API 并重写流式响应。与到阈值就把全历史压成一块的传统 auto-compact 不同它的布局叫the fold蒸馏出的摘要块tier-1/2/3 塔式分层常驻窗口头部最近工作区约 50K token保持原文每条消息带稳定 ref idmNNNNN。压缩时只折叠上一次压缩以来任务已消费掉的增量每个块随时可单独decompress还原。这个布局的直接后果是历史 append-only压缩只停用被折叠的区段KV-cache 前缀永不被压缩失效——这是后面 94% 缓存命中率数字的结构性前提。二、安装与接入三种方式选一种npm install -g billion-context --prefix~/.localbili命令落在~/.local/bin大多数发行版已在 PATH 中Windows 用户%APPDATA%\npm默认可写直接npm install -g billion-context即可。README 给出三种接入姿势长会话场景下任选其一原生插件bili plugin install client支持 pi / omp / opencode / dsh / kimi / hermes / zcode代理直接嵌在客户端里Launcherbili client一条命令同时拉起代理和客户端证书 MITM 或/bili/改写不碰客户端任何真实配置URL 改写bili启动代理后把客户端 baseURL 改成http://localhost:8787/bili/https://真实上游。端口规则#1660值得记一下手动bili start独占8787所有 lane 自管的代理由18787起独立分区冲突时 1 漂移并各自记住——多客户端并发跑长会话时不会互相抢端口。三、长会话场景的配置项拆解配置文件是单个 JSON~/.config/billion-context/billion-context.jsonXDG 路径BILI_CONFIG_FILE可指任意文件首次运行会播种空模板。优先级CLI flag env 配置文件 内置默认。完整参数表见 CONFIGURATION.md长会话真正需要关心的是compress块——它支持global → provider → model 三级合并逐级覆盖。3.1 决定什么时候压的三层机制CONFIGURATION.md 里对 acp-kernel 的判定逻辑做了源码级核对CONFIGURATION.md Soft target with elastic headroom 一节Growth 层日常主驱动绝对 token自上次锚点会话启动 / 上次 nudge / 压缩后重置以来的累积增长达到nudge.growthFloor默认50k窗口无关的平值且可压缩质量足够时注入 nudgegrowth gate 为max(20k, 0.45 × 50k) ≈ 22.5kT1 路径另需 ≥ 50k 可压缩质量。Pressure 层窗口百分比usage ≥ maxContextLimit默认 75%→ 每轮注入 nudge 直到降回线以下usage ≥ emergencyThresholdPercent默认 95%→ 强制 nudge 紧急截断。Qualification 层内核默认 45%不暴露只管冷启动票和 T2/T3 升级的块数下限。长会话配置里最常调的几项均出自 CONFIGURATION.md 参数表配置项默认作用compress.modelContextLimit模型原生窗口有效窗口上限用量分母 preflight 硬墙优先级最高的窗口源compress.maxContextLimit75%强制压缩 nudge 阈值非硬顶compress.emergencyThresholdPercent95%超大工具输出紧急截断线compress.nudgeGrowthTokens50000增长门步长决定压缩节奏compress.preserveRecentMessages/preserveRecentTokens3/ ≈5000最近消息软保护区compress.tierstrueT1→T3 分层蒸馏摊平折叠成本compress.protectedTools/protectedLatestTools无硬排除 / 仅保护最新实例如 todo 类快照工具compress.neverPreserveRecentTools[decompress,search_context,read,bash]排除出近区保护、立即可压的工具compress.promptPackdefaultlean用单行工具描述瘦身系统面3.2 一个长会话可用的配置示例// ~/.config/billion-context/billion-context.json { providers: { https://api.anthropic.com: { models: { claude-sonnet-4-5: { context: 200000, output: 8192 } } } }, compress: { maxContextLimit: 75%, emergencyThresholdPercent: 95%, nudgeGrowthTokens: 50000, preserveRecentMessages: 5, tiers: true, promptPack: default }, network: { upstreamTimeoutMs: 900000 }, persist: { zstd: true }, sessions: { gc: { enabled: true, maxAgeDays: 14 } } }几个针对长会话的细节models.name.context声明高于 models.dev 注册表和内置表解析顺序请求级协商 每模型声明 注册表 内置表。走 relay/私有部署时务必钉住真实窗口路由未命中任何 provider 键时所有 per-provider 覆盖会被静默忽略——#2317 起会打[route]警告和routemiss标记。persist.zstd: true月级会话的状态文件持续膨胀zstd 落盘省磁盘persist.tailTokens默认 16384保留近端原文尾部供导出。sessions.gc默认关闭——会话文件是用户数据不会静默删。开启后按超龄默认 7 天且从未压缩且 ≤1M token双条件清理压缩过的会话永不删。Windows 用户把%USERPROFILE%\.local\share\billion-context\加进 Defender 排除项。长会话每轮重写状态文件实时杀软/索引器/OneDrive 锁目录会导致EPERM写失败#362。3.3 为什么第一次压缩等到 200k 才来这是长会话调优最常见的困惑CONFIGURATION.md 有专节Why the first compaction waits until 200k压缩不按绝对窗口位置触发而按增长间隔——第一次软压缩在boot 内容 50k处发生。boot 30–50k 的客户端大约 80–100k 首次压缩boot 100k 或增长步长调高到 100k首次压缩就可能等到 ~200k。想让首次压缩更早按序做三件事精简 system prompt、禁用不用的工具、修剪 skills——boot 体积直接决定首次压缩的绝对位置把nudgeGrowthTokens降回 ~50k开 lean 模式promptPack: lean。调参前先用/acp或 web UI 实测 boot 用量别拍脑袋。四、跨天持续会话的稳定性验证配置完之后验证链路从代理活着到压缩在干活再到跨天不漂移分三步。第一步健康与统计探针。# 代理存活 转发去向 curl -s http://localhost:8787/__bili/health # → {ok:true,upstream:https://api.anthropic.com} # 真实请求过一遍之后的会话统计 curl -s http://localhost:8787/__bili/stats第二步日志确认压缩活动。日志统一落到~/.local/state/billion-context/bili.log同时 tee 到 stderr10MB 自动轮转。发一条消息后应看到每请求一行processTurn会话增长后出现[acp-usage] round N inputX cachedY (cache hit Z%)外加compress事件行。bili --debug或debug: true会再展开 nudge 决策growth/usage/pendingT1/shouldInject、客户端头与 SSE 重写细节。第三步面板级验证。原生插件客户端里/acp直接渲染当前会话的 ACP 状态面板session、blocks、可压缩区段、用量/acp-cache [full]打印缓存归因报告对应 web UI 的 sessions 详情页——下图是一个跨 3 天的真实会话509 次请求、28.8M input tokens、96.0% 缓存命中、压缩累计省 63.3M token上下文锯齿在 41K/869K 窗口内振荡FOLD BREAKDOWN表逐次折叠列出压缩量、摘要量与折叠后命中率README 给了一条明确的经验线健康会话的 prefix-cache 命中率应在 95–97%压缩本身的代价 ≤2%持续低于这个值按/acp-cache的归因顺序查上游缓存 TTL 过期 → 模型切换整个稳定前缀重新计费→ bili bug → 其他。跨天/跨周不漂移的工程保障自更新与安全闸代理启动后每 3 分钟查 npm--auto-restart-on-update默认关开启后在零在途请求时验证新安装、drain、同端口重生10 分钟冷却标记防止版本抖动导致循环重启。插件模式下重启 bili重启宿主宿主一直开着会静默留在旧代码上#1603web UI 横幅和/__bili/status的stale字段会暴露运行版本与磁盘版本之差。关键缺陷通告独立于 auto-update代理轮询billion-context-advisories伴生包CI 从 advisories/ 目录发布命中affected区间时强制安装指定target甚至可以是回滚版本走完整的备份验证回滚链源不可达时 fail-open绝不阻塞模型流量。bili doctorsrc/doctor.ts 的runDoctor审计全部安装 lane 的版本、owner、advisory 状态与运行中进程--json可脚本化。多 lane 环境pi 原生 opencode launcher 并存建议每天跑一次它也是排查到底哪个代理在跑的入口。会话状态本身压缩状态按客户端自带的会话 id 原文 key 化src/session-id.ts无 id 的客户端走字节级前缀亲和src/prefix-affinity.ts——恢复的对话即使代理重启过也重新挂回原会话新任务不会误继承别的会话的压缩块。跨天续会话时这是记忆没丢的机制保证。五、效果评估压缩比与质量保持的实测数据下面全部来自仓库内论文的 production telemetry观察窗口 2026-04-23 → 2026-09-07约 4.5 个月三个宿主标注 [V] 为日志可验证与受控实验[V: pilot logs]。5.1 规模与有界性指标数值主宿主模型调用174,327 次累计输入 token18.76B1.75B fresh 17.01B cache reads三宿主合计 ≈24.7B204,800 窗口GLM-5.142,986 次调用零窗口违规峰值 198,628cache-read : fresh≈ 9.7 : 1Pi 宿主逐调用上下文均值 88,218 / 中位 72,113 / p99 217,742马拉松会话最长 12,049 次调用 / 1.52B tokenPi 侧 8,584 次 / 1.01B峰值 257,721值得单独拎出的一个数字第三宿主7×24 自主 agent 服务vLLM 本地 Qwen3.8-27B262,144 窗口12.2 天 629 会话 / 32,733 次调用零违规含一个跨6.2 天、364 次调用的马拉松会话——同一内核、同一 doctrine、默认配置原样跑。5.2 压缩比摘要到底压成了什么摘要块输出大小中位185 token97.5% ≤2Kdoctrine 的长度规则压出来的每次压缩替换一段历史被压 token 中位2.6Kp90 40K块级压缩比整体中位7.9×工具输出主导的块n7,241中位24×p7545×最大超 3,000×——折叠的红利集中在工具输出这个大头宏观视角重载会话100K 压缩量n242历史均值 ~910K常驻摘要块中位仅 13 个~13K token常备宏观折叠比约70×——摘要质量不随历史长度线性增长因为 tier-2 再蒸馏会封顶前缀质量1,711 块中仅 60 个被 tier-2 触及3.5%。5.3 质量保持探针平、重读降、成本降受控实验qwen3.8-27btemp 065,536 窗口18 个串行任务 ×6 遍的 Session Marathon 负载相对保留基线计费 token 降31–54%默认 −31.5%激进调参 −53.7%重读重新拉取已压缩内容调用降63%2.7×recall 探针分数持平——默认调参下无可测回忆损失分段式负载6 步迁移计划只陈述一次后续只说继续BC-default 计费 4.67M ± 0.12M比滑动窗口省 50%所有臂中方差最小探针81.6%为全场最高损失集中在压缩掉的小事上而 KEEP 类内容计划、决策、路径在所有配置下幸存——损失是有结构的不是随机的。论文也诚实地标注了边界单用户、观察性数据部署层无随机对照probe 套件接近饱和85–95%质量持平受仪器灵敏度限制逐字历史类任务审计、取证、合规在 lossy fold 的适用域之外22% 的有效压缩是模型在无 nudge 轮次自发发起的5 天日志窗口 23/103但模型不会自发使用恢复工具——这是doctrine 蒸馏进权重路线的动机。5.4 缓存经济学与容量上限缓存读取占比按调用间隔分层2 分钟 →94.2%占 89% 流量2–10 分钟 → 70.2%60 分钟 → 9.1%——单调衰减是 provider 侧 TTL 过期的签名不是布局问题。miss 归因里只有16%的 token 可由新增后缀解释若 miss 只来自新内容读取占比应接近 98%。主宿主混合值 90.7%、ework 宿主 88.3%含一个无 prefix cache 的端点低于布局上限纯属空闲期上游缓存过期。单会话容量上限[A: 离散事件仿真参数拟合自生产数据]1M token 窗口理论支撑28.6B token / 106 天首月 3.0B第三个月末 21.1B而没有 fold同一会话约104 次调用~53M token就撞穿窗口——约 550× 的总工作量差距。注意这是建模上限与 §5.1 的多会话实测语料是两个口径不能并排比。六、落地前值得记住的几件事先装再调默认配置75%/95% 压力线 50k 增长门本身就是论文验证过的跨负载稳健工作点不要先调参再跑。跑之前/acp看一眼 boot 体积跑起来之后盯[acp-usage]的 cache hit 列——95% 以下先查归因再怀疑配置。长会话真正的收益在马拉松区间229M 压缩 token 中 62% 集中在 1.3% 的千消息以上会话论文称之为marathon phenomenon短会话 benchmark 观测不到这个收益所以也别指望跑一小时就看出省了多少。稳定性不是靠人盯self-update advisory bili doctor 日志轮转构成闭环跨天会话出问题时/__bili/status、/acp-cache [full]和 web sessions 页是第一现场。诚实的期望管理200K 窗口够用是经验命题适用域是论文观察到的 coding-agent 任务混合逐字历史类工作不在 fold 的承诺范围内论文里白纸黑字写了 What we do not claim。一句话总结全流程一条npm install接入compress三级合并把节奏钉在增长门上/acp与/acp-cache把缓存健康变成每天可见的数字——然后让日志替你证明一个 1M 窗口的会话跑到 12,000 次调用时上下文还在锯齿里振荡而不是在悬崖边。【免费下载链接】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），仅供参考