首页 / GitHub 趋势 / 长会话怎么做到一个月不爆…
AI 与机器学习

长会话怎么做到一个月不爆上下文?billion-context 的分层压缩

ranxianglei/billion-context

GitHub 仓库
ranxianglei/billion-context
总 Stars
★ 3,717
主要语言
TypeScript
查看 GitHub 项目

结论先行:billion-context 拿了 3,717 个 star,主语言 TypeScript,LICENSE 文件为 MIT,2026 年 11 月 2 日仍在推送,当天发了 v0.1.212。本篇取自月榜补位。它是给长会话用的上下文压缩插件:坐在智能体与模型 API 之间,边跑边把已消耗的对话压成分层摘要,号称 100K 上下文就够、token 省 5 倍、单个会话能跑一个月、累计数十亿 token。

它是什么

实现上是一个代理:改写 Anthropic 与 OpenAI 的数据流,压缩由 acp-kernel 在服务端执行。压缩是增量、可逆、前缀缓存友好的:摘要按小范围写,缓存前缀不断,需要时能解压回原文。代理给对话注入 4 个工具:compress 折叠一段消息、decompress 需要精确细节时恢复、search_context 在摘要里搜关键词、acp_status 看上下文用量与还可压缩的范围,压缩的时机与内容由模型自己决定,不是硬截断。

能干嘛

长编码会话的上下文越跑越贵、窗口一满就降级或中断,它把旧对话压成摘要接着跑,同一个会话能撑几天甚至更久。客户端覆盖 Claude Code、Codex、Cursor、Pi、OpenCode、Kimi 等,用 bili 启动器或插件接入。仓库自带评测称 ContextBench 0.3097 分、LongMemEval-S 79.20%,好于对照 RAG 方案——这是仓库自述,引用时注明出处,别当第三方结论。

压缩会不会丢关键细节?

有可能,这正是它留 decompress 与 search_context 的原因:摘要丢了的精确数字、文件名与报错原文,需要时再解压回来核对。仓库称健康会话缓存命中率 95%–97%,这是它自己的口径。关键决策与数字先记到会话外的笔记里,别把唯一一份真相只押在摘要上。

适合谁 / 注意点

适合会话动辄跑几天、token 账单吃紧的重度智能体用户。注意 open issue 高达 741 个,版本三天连发 v0.1.210 到 v0.1.212, issue 积压与版本节奏都要先看。部分客户端走证书中间人姿态接入,流量要过它的代理,隐私敏感的项目先读 CLIENTS 文档里自己那一款的接法,再决定用启动器还是原生插件。

站长点评:我挑它,是因为长会话的上下文账是真实痛点,但我对“5 倍”这类数字保持怀疑:评测是仓库自己跑的,自己的会话先小规模对比一周,token 与回答质量两本账一起记。741 个 open issue 是个提醒:先看最近的 issue 是不是正在修你关心的客户端,再装。

项目地址:https://github.com/ranxianglei/billion-context

核验记录:2026 年 11 月 3 日经 GitHub API 核验 stars、语言与推送时间,许可证以 LICENSE 文件的 MIT 为准,本篇取自月榜补位已如实写明。

⬇ 下载区(本站中转)

本站服务器实时中转 GitHub 文件,国内网络也可稳定下载;也可使用右侧官方链接。 本项目遵循 NOASSERTION 许可证。

📦 源码包(默认分支 ZIP)本站下载官方下载

要下载其他 GitHub 项目?试试本站的 GitHub 加速下载工具,粘贴链接即可中转。

AI 与机器学习 效率工具 每日榜单

相关推荐