一次五小时连续会话的 token 账本

一次五小时连续会话的 token 账本

一次连续五小时的编码会话，token 到底花在哪里、缓存有没有帮上忙，决定了这个会话还能不能继续。这篇复盘记录的是把亿级上下文压缩（ranxianglei/billion-context）架在助手与模型 API 之间之后，我在一次长会话里观察到的真实走向：上下文被反复折叠，前缀缓存却始终保持在健康区间。

先搭好一层代理

压缩代理架在任意编程助手与其模型 API 之间，用 acp-kernel 压缩重写 Anthropic/OpenAI 流，调度原则是「何时压缩、压缩什么 —— 由模型决定，而非硬截断」。装好之后先确认服务活着、以及它转发到哪：

curl -s http://localhost:8787/__bili/health

curl -s http://localhost:8787/__bili/stats

第一条返回 {"ok":true,"upstream":"https://api.anthropic.com"}，第二条在发过真实请求后给出会话统计。日志落在 ~/.local/state/billion-context/bili.log，每个请求打印一行 [acp-usage] round N input=X cached=Y (cache hit Z%)。账本就是从这里读出来的。

前缀缓存命中率的健康区间

会话跑起来之后，最该盯的不是消耗了多少 token，而是缓存命中率。README 给的经验值是：健康会话的前缀缓存命中率在 95–97% 左右，压缩本身的代价 ≤2%。

这个数字重要，是因为压缩与普通摘要器的根本差别就在这里。宿主自带的摘要器一旦触发，往往要重写很大一段历史，缓存前缀随之失效；而这里的压缩是增量、可逆、对前缀缓存友好的：摘要在小范围内写入，可按需解压，缓存前缀保持完整。折叠动作本身只吃掉很小一块重付成本，而不是让整段前缀重新计费。

/acp-cache 报告里的四块怎么读

在客户端里敲 /acp-cache，会打出一份文字总结报告，顶部带一个可点击的 Web UI 链接，点进去是网页版会话页（折线图加逐断点归因）。报告分块，读法各有分工：

• GRAND LEDGER：总账 —— 总输入、总命中、hit%，直接给出 HEALTHY 或异常判定。
• FOLD ECONOMICS：每次折叠的经济账 —— 净省了多少、这一折有没有回本。
• LINE ITEMS：只列异常行 —— hit 低于 85% 或 miss 大于等于 5000 的那些。

HTTP 同款接口是 GET /__bili/cache-report，/acp-cache full 则列出每一折每一行。日常我只看 GRAND LEDGER 的判定，出现异常时再往下翻 LINE ITEMS。

miss 的三类拆解

GRAND LEDGER 把 miss 拆成三类，这是整份报告里最有信息量的部分：

• new content：新增内容导致的 miss —— 真实新信息进入上下文，本就无法命中，属于正常成本。
• compress re-pay：压缩重付 —— 折叠动作重写的那一小段，占比应很小，符合压缩代价 ≤2% 的预期。
• upstream-ttl-or-client-rewrite：上游缓存 TTL 到期，或客户端改写了请求。

真正需要追的是第三类。README 给出的常见原因按概率排序是：① 上游缓存 TTL 到期（报告里表现为 stable-prefix miss，top spikes 会点出闲置时长）② 切换了模型 ③ bili 的 bug（欢迎带报告页提 issue）④ 其他/未知。注意「上游 TTL 到期」排在第一位 —— 五小时会话里中途停手去干别的，回来命中率掉一截，大概率不是压缩的问题。

四个上下文工具在什么时机被调用

代理向对话注入四个上下文管理工具，模型在上下文增长时自行调用，代理在服务端执行折叠：

• compress：把一段消息范围折叠成详细摘要 —— 需要腾地方时调用。
• decompress：需要精确细节时恢复某个已压缩范围 —— 模型觉得摘要不够精确、要回原始细节时调用。
• search_context：在压缩摘要与可见消息中做关键词检索 —— 想确认某段历史里写过什么时调用。
• acp_status：上下文用量概览加哪些区间仍可压缩 —— 判断下一步怎么处理上下文时调用。

关键是「模型会自主使用以上工具管控上下文，无需人工干预」。沿途还有一个温和的增长 nudge（按设计固定约 50K token 步长，可用 compress.nudgeGrowthTokens 调整）提醒它动手；仅输入就超窗时，预检作为硬兜底触发。

一个参照系：README 的生产规模数据

单场会话的感受容易失真，拿 README 的纵向研究当参照系：四个半月、三宿主、174,327 次模型调用、187.6 亿累计输入 token（三宿主合计约 247 亿），204,800-token 窗口零违规，马拉松会话 8,584–12,049 次调用。

这组数据说明「在很长的时间跨度里，token 可以持续穿过同一个窗口」，但不等于项目已生产验证稳定 —— 项目自述状态是「早期」，协议处理和压缩通过了 mock 测试（500+ 项通过），真实模型集成测试是下一里程碑。

实践中的取舍

并行装了两套压缩，结果压了两遍。 宿主原生插件与独立进程内扩展（billion-context-pi、opencode-acp）互斥，同时生效就是双重压缩。安装器会替换旧条目（裸名、npm: 别名、带版本号、路径形式都认）并把原配置快照到 .bili-bak；手动安装时，原生入口加载时会同步设置 BILLION_CONTEXT_NATIVE=<host>，让独立扩展自动退出。我的做法是只留一条路径，安装前先备份。

OpenCode 上直接写裸包名会双重压缩。 把裸 npm 包名写进真实配置的插件列表后，必须同时设 "compaction": { "auto": false }，否则 OpenCode 的原生自动压缩会叠加进来。这两件事平时由 bili plugin install opencode 代做，手动改配置就得自己补齐，动手前先备份该配置文件。

命中率掉了别先怀疑插件。 健康区间就是 95–97%，压缩本身只吃 ≤2%。掉下去时按概率归因，用 /acp-cache 或 GET /__bili/cache-report 拿归因，而不是硬猜着去关功能。

总结

一次五小时会话的账本，最终落在三件事上：命中率是否稳在 95–97%、折叠是否回本、miss 是否集中在可解释的那一类；想对照同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单。

适合与不适合

适合：需要把单次编码会话拉长到数小时甚至数天的开发者；在小窗口里跑长任务、又不想频繁重开会话的人；愿意按账本（命中率、折叠经济账）做调优的人；能接受在助手与模型 API 之间加一层代理的团队。

不适合：把稳定性当首要前提的生产环境 —— 项目自述状态是「早期」，真实模型集成测试还是下一里程碑；对在本机信任一个本地 CA 有顾虑的严格安全策略机器 —— 走证书 MITM 的客户端需要这么做；以及有对外署名合规负担的产品 —— 许可为 MIT 加一条附加条款，终端用户可见或可交互且使用了本软件的产品须在首页、文档或「关于/致谢」页面注明并附仓库链接。

标签：亿级上下文压缩、DeepSeek Harness、前缀缓存、长会话实践

本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。