推文

@kafkaup · 2026-10-16 03:59

4.5 个月、174,327 次模型调用、累计 187 亿输入 token，跑在 204800 token 的窗口上，零次越界。这是 billion-context 仓库里那篇 paper 给出的纵向统计，单个会话最长撑过一万两千次调用。 它本身不是一个 agent，而是夹在 agent 和模型 API 之间的代理。你把客户端的 base URL 指向它，它解析 Anthropic 或 OpenAI 形状的请求，用 acp-kernel 做压缩，再转发给真正的模型，最后重写流式响应。 关键差别在压缩的决定权。代理会往对话里注入四个工具：compress 把一段消息折叠成详细摘要，decompress 在需要原文时还原，search_context 在摘要和可见消息里做关键词检索，acp_status 看当前用量和还能压哪些区间。什么时候压、压哪一段，由模型自己判断，不是到了阈值就一刀切。 对比宿主内置的 summarizer，它强调三点：增量、可逆、对前缀缓存友好。摘要按小区间写入，前缀不被破坏，README 说健康会话的缓存命中率应该在 95% 到 97%，压缩本身只占 2% 以内的开销。命中率持续偏低，先查上游缓存 TTL 和是否中途换了模型。 客户端覆盖面挺大，pi、opencode、dsh、kimi、claude、codex、gemini CLI、qwen 都有对应接入方式。但要注意代价：有些客户端只能走 launcher，有些要靠证书 MITM，jcode 这类编译好的 Rust 二进制干脆没有原生插件位。那张客户端对照表本身就说明了接入成本不均匀，上手前值得先翻一遍 CLIENTS.md 找自己那一行。 今日 +246 star · TypeScript · 总计 772 #ClaudeCode #AIAgent https://github.com/ranxianglei/billion-context

曝光 201 · 评论 0 · 点赞 1 · 书签 0 · 曝光/时 36.977625142037645