billion-context：让模型自己折叠上下文，代价是让代理看到一切
大多数编程 agent 处理上下文窗口的方式都一样：等快满了，一口气全部总结，祈祷没丢掉要紧的东西。billion-context 把这个决定交给了模型自己。这个 MIT 许可的项目周末上了 GitHub Trending，周日涨了 460 星，总共大约 5,000。v0.1.213 在 11 月 7 日 UTC 23:25 发布。
它夹在你的 agent 和 Anthropic 或 OpenAI 的 API 之间，往对话里塞四个工具：compress 把一段消息折叠成详细摘要，decompress 在需要原文细节时还原，search_context 在摘要和可见消息里做关键词搜索，acp_status 显示窗口用了多少、哪些还能折。上下文涨起来时，模型自己调用。摘要是小段小段写的，前缀不动，所以作者说正常会话能保持 95% 到 97% 的提示缓存命中率，压缩本身的开销不超过 2%。
数字都很大，也都是作者自己的：「token 少用 5 倍」，单个会话能连跑好几天，一项 4.5 个月的研究里有 174,327 次模型调用、187.6 亿输入 token，在 204,800 token 的模型上零次溢出窗口。仓库里附了论文，还有一套跑在 LongMemEval-S、ContextBench、MemoryAgentBench 上的 1,500 题评测，但那是作者在自己仓库里跑的。当成强主张看，别当结论。
最扎眼的是支持列表：Claude Code、Codex、OpenCode、Pi、Gemini CLI、Kimi、Qwen Code、Copilot CLI、Kiro、Zed、Goose 等等。对那些没有插件接口的闭源二进制，接入方式是「cert-MITM」：在本地装一张证书，让代理能解密并改写你的模型流量。能用，但这也是一条完整的信任边界。agent 发出去的所有东西，代码和密钥在内，都以明文经过它。
方向是对的。上下文管理正在从各家 agent 里搬出来，变成共享的一层；可还原、对缓存友好的压缩，也确实比一次性大总结强。只是把 TLS 交出去之前，先读读代码。
来源：https://github.com/ranxianglei/billion-context
← 返回所有文章
它夹在你的 agent 和 Anthropic 或 OpenAI 的 API 之间，往对话里塞四个工具：compress 把一段消息折叠成详细摘要，decompress 在需要原文细节时还原，search_context 在摘要和可见消息里做关键词搜索，acp_status 显示窗口用了多少、哪些还能折。上下文涨起来时，模型自己调用。摘要是小段小段写的，前缀不动，所以作者说正常会话能保持 95% 到 97% 的提示缓存命中率，压缩本身的开销不超过 2%。
数字都很大，也都是作者自己的：「token 少用 5 倍」，单个会话能连跑好几天，一项 4.5 个月的研究里有 174,327 次模型调用、187.6 亿输入 token，在 204,800 token 的模型上零次溢出窗口。仓库里附了论文，还有一套跑在 LongMemEval-S、ContextBench、MemoryAgentBench 上的 1,500 题评测，但那是作者在自己仓库里跑的。当成强主张看，别当结论。
最扎眼的是支持列表：Claude Code、Codex、OpenCode、Pi、Gemini CLI、Kimi、Qwen Code、Copilot CLI、Kiro、Zed、Goose 等等。对那些没有插件接口的闭源二进制，接入方式是「cert-MITM」：在本地装一张证书，让代理能解密并改写你的模型流量。能用，但这也是一条完整的信任边界。agent 发出去的所有东西，代码和密钥在内，都以明文经过它。
方向是对的。上下文管理正在从各家 agent 里搬出来，变成共享的一层；可还原、对缓存友好的压缩，也确实比一次性大总结强。只是把 TLS 交出去之前，先读读代码。
来源：https://github.com/ranxianglei/billion-context
评论