billion-context：把上下文压缩做成「可逆折叠」，让 200K 窗口的编码智能体跑出月级长会话

一、导读

长会话正在成为编码智能体的第一瓶颈：工具输出不断堆积，触发一次性自动压缩后摘要不可逆、细节永久丢失，前缀缓存也被整段作废。开源项目 billion-context（命令行名 bili）给出了另一条路——一个介于智能体与模型 API 之间的透明压缩代理，让模型自己决定「何时压缩、压缩什么」，摘要分层折叠且每一块都可恢复。它随仓库开源了一篇 4.5 个月生产环境的纵向研究论文：174,327 次模型调用累计处理 187 亿输入 token，204,800 窗口上零越界，独立第三方评测在 ContextBench 上拿下第一。截至 2026-11-09，该项目当日 GitHub 涨星 460、总星 5,170，npm 周下载量 848,207（2026-11-01 至 11-07），是这个赛道近期最值得关注的新工程。

二、项目速览

项目	内容
仓库	ranxianglei/billion-context
定位	上下文压缩代理 / 插件：介于任意编码智能体与模型 API 之间，改写 Anthropic 与 OpenAI 流量
作者	ranxianglei（Xianglei Ran），个人主导开发，另有少量社区贡献者
语言与运行时	TypeScript；Node 22+（生产建议 Node 24，直接用内置 `node:sqlite`）
协议支持	Anthropic Messages、OpenAI Chat Completions、OpenAI Responses（含跨协议转换）
客户端适配	20+ 编码智能体：Claude Code、Codex、Gemini CLI、Qwen Code、OpenCode、Zed、Aider 等
许可证	MIT + 一条署名附加条款（可见产品需在首页或文档署名并回链仓库）
版本节奏	约 1 至 3 天一个 release，最新 v0.1.213（2026-11-07 发布）
数据（截至 2026-11-09）	GitHub 5,170 星、当日涨星 460；npm 周下载 848,207；406 fork、923 个开放 issue

三、为什么是它：涨星动因

第一，它踩中了当下最普遍的痛。编码智能体用户基数在 2026 年暴涨，而主流 CLI 的出厂设置仍是「80% 阈值触发的一次性全史压缩」：摘要不可逆、单粒度、时机与任务无关。论文引用的 Compaction Cliff 研究给出的量化证据相当刺眼——20 个生产配置下，一轮 /compact 式压缩后安全规则存活率只有 53%，五轮后剩 10%。用过 Claude Code 长会话的工程师对这种「压缩后忘了当初为什么改」的体验都有体感，而 billion-context 是第一个把替代方案做到生产可用并给出完整数据的项目。

第二，数据的可信度罕见地高。大多数上下文管理项目只有 demo 或单点 benchmark，billion-context 同时拿出了三样东西：一篇带证据分级的预印本论文（[V] 实测 / [A] 模拟 / [P] 计划）、一组 1,500 题的独立第三方横评（对比 full 上下文与三路 RAG）、以及可复现的 /acp-cache 缓存归因报表。批评性结论也没有藏：第三方评测里它在逐字检索上明显输给 RAG，LongMemEval-S 上输给完整上下文——这种「自曝短板」的姿态在涨星项目里不多见。

第三，中文开发者社区的推力。作者写了完整的中英双语文档，适配的 20 多个客户端里包含 iFlow CLI、Qwen Code、dsh 等国产智能体，还维护了三个 QQ 交流群（两个已满员）。HN 上 2026-11-08 的「Goodbye Claude, hello Pi」讨论里，有用户把 billion-context 描述为「基本上给你无限的上下文」。社区好评加上 84.8 万的周下载量，说明这不是空涨星。

四、架构原理

4.1 整体架构：一个代理，三种接入

billion-context 架构手绘图：客户端层、三种接入方式、代理核心（会话身份解析、压缩内核流水线、四个上下文工具、分层块存储）与模型 API 的分层关系及数据流

billion-context 的系统形态是一句话可以讲完的：它坐在智能体客户端与模型 API 之间，拦截请求、重建上下文、再转发给上游。模型 API 侧支持 Anthropic Messages、OpenAI Chat 与 Responses 三种线协议（含跨协议转换），客户端侧零适配——任何能改 baseURL 的智能体都能接。整体分层如下：

flowchart LR
    subgraph client ["客户端（Claude Code / Codex / OpenCode 等 20+）"]
        AG[智能体循环：工具调用与会话历史]
    end
    subgraph bili ["billion-context 代理（默认 127.0.0.1:8787）"]
        SESS[会话身份解析<br/>header / body / 前缀亲和]
        KERNEL[acp-kernel 压缩内核<br/>9 阶段每轮流水线]
        TOOLS[注入 4 个上下文工具<br/>compress / decompress /<br/>search_context / acp_status]
        CACHE[块状态与存储<br/>SQLite WAL + zstd]
    end
    UP[模型 API<br/>Anthropic / OpenAI Chat / Responses]
    AG -- "HTTP 请求（三种接入方式之一）" --> SESS
    SESS --> KERNEL
    KERNEL --> TOOLS
    TOOLS --> CACHE
    KERNEL -- "重建后的请求" --> UP
    UP -- "SSE 流式响应" --> AG

三种接入方式覆盖了从零配置到深度集成的全部光谱。最通用的是 URL 前缀法：把客户端的 baseURL 从 https://api.anthropic.com 改成 http://localhost:8787/bili/https://api.anthropic.com，上游完整地址嵌在路径里，代理据此转发。最透明的是启动器法：bili claude、bili codex 一条命令同时拉起代理与客户端，真实配置文件一个字节不动——对支持代理环境变量的客户端走证书 MITM（只对白名单的模型域名 TLS 终结，其余流量盲隧），对支持 baseURL 覆盖的客户端走 /bili/ 重写。最原生的是插件法：bili plugin install pi 直接把代理注册进客户端的插件体系，随客户端启动。三种方式的取舍写在每一行启动命令的帮助文本里，这层「适配矩阵」工程是项目点击率背后的真实苦功。

4.2 内核与 fold 布局：摘要的「LSM 树」

核心压缩逻辑在独立内核 acp-kernel（约 1 万行 TypeScript、零宿主依赖、550+ 测试）里，对外暴露一个纯函数式接口：processTurn(state, messages, config) 返回新状态、渲染后的消息列表与副作用。每轮请求按固定顺序过 9 个阶段：assign-refs（给新消息铸造稳定的 mNNNNN 引用号）→ sync-blocks（把新内容投影到块边界）→ merge-blocks（合并相邻可压缩区段）→ prune（执行预算不变量）→ filter（按角色与内容类型的可见性规则）→ hide-compress-calls（把压缩工具调用从渲染视图中摘除）→ nudge-inject（按需注入压缩提醒）→ emergency-truncate（最后手段的硬截断）→ render-refs（输出带引用标签的最终消息列表）。宿主永远不直接改历史，所有簿记都在内核里。

数据结构上，压缩产物是块（CompressionBlock）：{ blockId, tier ∈ {1,2,3}, topic, summary, directMessageIds, effectiveMessageIds, generation ∈ {young, old}, active }。tier-1 块摘要连续消息区段；tier-1 质量积累后，tier-2 把块折叠成新块（directBlockIds 指向来源）；tier-3 同理再折一层。论文把这个结构叫「散文上的 LSM 树」：年轻代吸收写入、老年代持有压缩后的历史，压缩是增量式的而非全史重做。effectiveMessageIds 传递性地覆盖每块代表的全部原始消息，所以任意层级的再压缩都不会丢失血缘；decompress 可以把任一块的源内容重新激活回上下文，decompress-to-file 模式则把全文写到文件系统——既保住 KV 缓存前缀，又让模型能按需读到全保真内容。这就是标题里「可逆折叠」的准确含义：与一次性压缩把源文本直接丢弃不同，fold 里的每一份摘要都保留逐块恢复的指针。

生产语料的块分布印证了分层的意义：tier-1 占驻留摘要空间的 92%，tier-2 占 7%，tier-3 不到 1%——但 tier-2 与 tier-3 合计承载了 37% 的已代表历史。宝塔结构让摘要质量的增长逐层衰减，这正是单会话容量随长度亚线性增长的原因。

4.3 谁来决定压缩：模型驱动 + 成长门控

传统方案与 billion-context 的分野在「决策权」。阈值自动压缩有三个结构性缺陷：模型不知情（触发与选材由阈值决定）、不能拒绝（触发即必须压）、不能选择（全史压成一个不透明团块）。billion-context 的回答分两层。

第一层是代理注入的 4 个上下文工具。compress 把一段消息范围折叠成摘要；decompress 恢复被压缩的范围；search_context 对摘要块与可见消息做关键词检索；acp_status 报告当前上下文构成与可压缩区段。模型在会话中自己调用它们——生产日志显示，五天窗口里 103 次有效压缩中有 23 次（22%）发生在引擎没有注入任何提醒的回合，即模型自发管理上下文。

第二层是成长门控的按需触发。上下文超过窗口的约 0.45、且自上次压缩后增长超过约 50K token 时，代理注入一条「压缩提醒」：附带候选区段的精确清单（真实 token 数、消息数、工具/文本构成）与压缩指导，压缩完成后立即从上下文摘除、不留痕迹。三条交互细节值得展开，它们都是踩坑后的产物。其一，提醒永不披露填充率——告诉模型「只用 20%」会让它锚定在「看起来健康」上拒绝压缩，隐去数字才能让判断落在任务本身。其二，模型有权拒绝压缩——提醒措辞是「保持上下文精炼的效率提醒」而非溢出警告，调试进行到一半时拒绝压缩是质量阀门而非失败。其三，压缩决策利用瞬态注意力：待压缩区段在 compress 调用时完整浮现，决策做完就从工作集移除——用完整注意力做决策，而脚手架本身不占后续上下文。

protected zone 则由内核硬性保证而非提示词请求：压缩工具调用本身、最近区（最后约 5 条消息或约 5K token 的硬下限，生产中实际近区大得多）、最后一条用户消息、承载任务意图的首条用户消息，永远可见。提示词可以请求压缩任何内容，内核执行地板。

4.4 压缩学说：把判断力写成可版本化的文本

模型凭什么压得对？答案是一份叫 doctrine（学说）的可执行提示词规范，随内核版本化发布。它的判据只有一条：当前任务步骤是否还需要这段内容——不是「旧不旧」，不是「大不大」。围绕它有两大失败模式的平衡（过度压缩毁细节、压缩不足淹上下文）、KEEP/DROP 清单和预算优先序。KEEP 类包括：带行号的文件路径、签名与承重代码行、精确错误字符串、附带理由的决策、精确数值、目标演化、供后续恢复的消息引用。DROP 类包括：结果提取后的冗长日志、重复读取、死胡同探索（但教训要保留）、通向结论的过程。预算紧张时的优先序：目标 > 决策与理由 > 产物 > 结论 > 教训。

这份学说的位置很讲究：它是训练侧压缩方法（AgentFold 等用 SFT 把压缩策略烧进权重）的提示词侧替代物——策略以可检查、可版本化、可按宿主覆盖的文本存在，几天内迭代，跨模型迁移零成本（生产中同一份学说未经修改跑在 GLM-5.1/5.2/5.3、Qwen 与 GPT 级模型上）。近期版本还开放了分层覆盖面：Layer 0 允许宿主在显式 acknowledgeRisk 门控下改写四条承重压缩规则，Layer 1 提供三态章节覆盖。论文进一步指出学说的终局是「蒸馏进权重」——日志里的压缩决策本身就是现成的 SFT 课程。

4.5 性能取舍：增量压缩为什么同时保住质量、缓存与成本

整个系统的负载-bearing 设计决策只有一条：每轮只压缩上次压缩以来新增的增量，永不重写全史。论文用专节论证它的四重收益。

质量上，每轮压缩的对象是任务已消费的增量（门控下限约 50K、有效下限约 22.5K），以高容量低密度的工具输出为主——丢弃细节的风险落在已用完的材料上，而不是正在使用的内容上。生产数据：压缩输出中位仅 185 token（97.5% 不超过 2K）；全块压缩比中位 7.9×，工具主导块中位 24×（p75 达 45×，极值超过 3000×）；重载会话均值约 900K token 的历史只驻留约 13K 摘要，宏观压缩比约 70×。

缓存上，历史只追加、压缩只「去激活」后缀区段，KV 缓存前缀永不失效。这是 94.2% 缓存读占比（调用间隔小于 2 分钟的活跃流量）的结构性前提；混合值 88.3–90.7% 偏低的原因是供应商侧缓存过期——未命中归因显示仅 16% 的未命中来自新增后缀，84% 带供应商逐出特征。反观重写式压缩，每次触发都把整个前缀打掉重来。

成本上，计费 token 跟随工作量而非历史长度：对照实验里压缩臂计费下降 31–54%，重读（重新获取已压缩内容）调用下降 63%。有个诚实的归因值得转述：静默对照组（只带学说文本与消息标签、不执行任何压缩）就复现了几乎全部重读下降（-62% 对 -63% 头条值）——说明判断内容本身承载了大部分收益，而非压缩机制本身。

容量上，宝塔分层让单会话容量亚线性增长：以 1M 窗口为例，闭合推导加离散事件模拟给出 106 天约 28.6B token 的理论上限（模拟拟合值，与实测语料统计口径不同，不可直接并列）；无折叠时同会话约 104 次调用即触窗，两者相差约 550 倍。最长的生产会话跑了 12,049 次调用、累计 1.52B token，平均上下文仅约 126K。

4.6 与同类架构路线的差异

论文用「渐近保留率 × 驻留质量」两轴给六条路线定位：滑动窗口的窗口外内容保留率为零；阈值自动压缩每轮以 ρ≈0.4–0.6 几何衰减，四轮后只剩 3–13%；外部记忆（Mem0、Zep 类）写入时不可逆——事实存下来了，过程性上下文（为什么这个修法有效）当场丢失；训练侧压缩要为每个框架定制检查点；LCM 类无损递归保留率 100% 但驻留质量不衰减，窗口反而更快填满。fold 是唯一同时满足「渐近保留率恒为正（单次折叠约 1/8，不随轮次复利衰减）+ 驻留质量亚线性增长」的组合——生产语料里 tier-2 再蒸馏只触及 1,711 块中的 60 块（3.5%），二次损失可忽略。与已发布过的跨会话记忆系统（如 claude-mem）也不同：billion-context 管的是单会话内的生命周期，不替代外部长期记忆。

五、应用场景

billion-context 应用场景手绘图：长会话编码、自主智能体服务、多模型路由与成本优化三大场景的折叠压缩流程

场景一：日复一日的长会话编码（核心场景）

痛点：在同一个仓库里连续工作数天，会话历史膨胀到几十万 token，Claude Code 触发自动压缩后忘记早期决策，或者干脆撞上窗口上限被迫开新会话、从头恢复上下文。解决：bili plugin install claude 一条命令装成原生插件（托管设置块 + SessionStart 钩子 + MCP shell，端口漂移自愈），之后照常使用 claude——代理在后台压缩，四工具供模型自行调用。最小示例：

# 方式 A：仓库即 Claude Code 插件市场
/plugin marketplace add ranxianglei/billion-context
/plugin install billion-context@billion-context
/billion-context:bili-setup   # 自动执行 bili plugin install claude

# 方式 B：启动器（不动任何配置文件）
bili claude

# 验证：健康检查 + 首个真实请求后看压缩活动
curl -s http://localhost:8787/__bili/health
curl -s http://localhost:8787/__bili/stats

收益（论文生产数据，2026-04-23 至 09-07）：204,800 窗口模型上 42,986 次调用零越界、峰值 198,628；活跃节奏下缓存读占比 94.2%——按缓存 token 约为新鲜输入 10% 价格的行业定价，等效输入成本大致减半。适用边界：需要逐字审计、合规取证或同时重构多约束并集超出任何摘要容量的任务不在有损折叠的支持范围内（恢复可用但模型不会自发用）；16K 级小窗口下约 2K token 的学说文本是每调用约 25% 的固定开销，64K 以上才摊薄。

场景二：常驻自主智能体服务

痛点：无人值守的智能体服务（聊天机器人驱动的自动工作流）7×24 运行，会话要么频繁重启丢上下文，要么膨胀到拖垮推理服务。解决：仓库论文记录了第三个宿主的部署形态——Linux 常驻服务机跑 OpenCode + 本地 vLLM（Qwen3.8-27B，262,144 窗口），12.2 天里 629 个会话、32,733 次调用零越界，单会话马拉松跨越 6.2 天。最小示例：

# 服务器常驻：Web UI 8787 + 会话数据落盘
npm install -g billion-context --prefix=~/.local
bili start
# 需要跨机器服务时（仅限可信内网，代理无鉴权）：
bili --host 0.0.0.0
# 定期维护存储
bili sessions ls && bili storage gc --dry-run

收益：驻留 KV 缓存随有界带缩放（实测 vLLM 平均上下文 70K 对 262K 窗口），同卡可并发更多会话；预算可预测——压缩臂计费标准差比基线低 4–7 倍，这对容量规划是实打实的工程属性。适用边界：多副本部署需要按会话头做 L7 粘性路由（按 ClientIP 哈希会在副本故障时丢光会话状态）；长会话单实例是设计决定，没有跨实例共享存储。

场景三：多模型混用与路由网关叠加

痛点：团队同时用 Anthropic 与 OpenAI 协议的模型，或在智能体前面挂了 magpie、opencodex 这类账号池路由网关，压缩层不知道该插在哪。解决：billion-context 支持三线协议与跨协议转换，且明确规定了顺序——压缩发生在路由之前：客户端指向 bili，bili 通过 /bili/ 前缀指向网关（http://localhost:8787/bili/http://127.0.0.1:3425），凭据留在网关、哑键透传。最小示例：

export ANTHROPIC_BASE_URL=http://localhost:8787/bili/http://127.0.0.1:3425
export ANTHROPIC_API_KEY=magpie   # 哑键，真实凭据在网关侧
claude

收益：进入网关任一账号的请求都已完成压缩；切换账号导致的缓存失效会被 /acp-cache 报表的 KEY SWITCHES 段单独归因，不冒充 TTL 过期。适用边界：网关路由的模型名对窗口查询不透明，需在配置的 models.<name>.context 里显式声明窗口，否则落到回退窗口。

场景四：上下文健康的可观测性

痛点：长会话账单异常或质量下降，工程师分不清是压缩 bug、缓存过期还是换模型导致。解决：/acp-cache 在客户端里直接渲染四段式报表——GRAND LEDGER（总账 + 健康判定：健康会话前缀缓存命中率 95–97%，压缩自身开销不超过 2%）、FOLD ECONOMICS（每次折叠净省 token 与回本判定）、LINE ITEMS（仅列异常：命中低于 85% 或未命中超 5000）、MODEL/KEY SWITCHES（换模型换密钥的缓存失效归因）。最小示例：客户端里输入 /acp-cache，或 curl http://localhost:8787/__bili/cache-report。收益：把「为什么变贵了」从玄学变成归因报表。适用边界：需要真实流量积累后有解读价值，空会话无意义。

六、快速上手

最省事的路径是启动器方式，一条命令同时拉起代理与客户端，不改任何配置文件：

# 安装（用户级前缀，避免 sudo 与 EACCES）
npm install -g billion-context --prefix=~/.local

# 启动器：按使用的客户端选一条
bili claude      # Claude Code
bili codex       # OpenAI Codex CLI
bili opencode    # OpenCode 1.x / 2.x
bili gemini      # Gemini CLI（GOOGLE_GEMINI_BASE_URL 重写）

# 或最通用的 URL 前缀：客户端 baseURL 前面加上代理地址
# http://localhost:8787/bili/https://api.openai.com/v1

# 健康检查与实时统计
curl -s http://localhost:8787/__bili/health
# → {"ok":true,"upstream":"https://api.anthropic.com"}

运维要点四条。端口：手动 bili start 固定占 8787，各启动器与钩子自拉起的代理落在 18787 起的自管理区，冲突自动 +1。存储：会话状态在 ~/.local/share/billion-context/（SQLite WAL，Windows 建议把该目录加入杀毒软件排除项避免 EPERM）。更新：默认每 3 分钟检查 npm 并原地安装，重启进程生效；舰队升级按 15 分钟到 48 小时的随机窗口错峰滚动，配合公共策略文件可全局 hold 或封锁坏版本。验证：真实请求一轮后在日志（~/.local/state/billion-context/bili.log）里看 [acp-usage] 行的缓存命中率，或直接 /acp-cache。

七、横向对比

维度	billion-context	阈值自动压缩（Claude Code /compact 出厂行为）	外部记忆系统（claude-mem / Mem0 类）	训练侧压缩（AgentFold 类）
触发方	模型自主 + 成长门控兜底	固定阈值（约 80% 窗口）	会话结束时提取	训练后的策略
粒度	区段级，tier-1/2/3 分层	全史压成单一团块	事实/要点抽取入库	训练决定的算子
可逆性	每块可 decompress 逐块恢复	不可逆，源文本丢弃	写入时不可逆（过程性上下文丢失）	取决于实现
缓存影响	前缀永不失效（活跃期命中率 94.2%）	每次触发整段作废	不影响会话缓存	不影响
跨会话记忆	无（单会话内管理）	无	有（核心卖点）	无
保留率行为	恒定约 1/8，不随轮次衰减	ρ^k 几何衰减，四轮剩 3–13%	取决于抽取保真度	待验证
接入成本	三种方式，零适配到插件级	零（出厂自带）	宿主插件	需要定制训练
已知短板	逐字检索弱、小窗口学说开销	细节永久丢失（安全规则五轮后剩 10%）	不管会话内膨胀	每框架一个检查点

一句话选型：会话内膨胀与缓存经济交给 billion-context，跨会话记忆交给 claude-mem 类系统，静态语料的逐字检索交给 RAG——三者正交，可叠加。

八、局限与风险

证据侧：生产研究是单专家用户的观察性数据，作者自己声明只主张生态效度、不主张人群代表性；28.6B 单会话容量是拟合模拟值而非实测；对照实验仅在 qwen3.8-27b 单模型、温度 0 下跑，探测套件已近饱和（85–95%），质量持平的结论受测量灵敏度约束。

能力边界：第三方评测划出了清晰的分界线——197K 语料中的单句逐字针检索（AR）从完整上下文的 69.0% 掉到 27.0%，静态逐字查找应选 RAG；LongMemEval-S 上它以 79.20% 输给完整上下文的 83.20%（保留了 95.2% 精度但省 71.1% 成本，是否划算看场景）；当前规模模型不会自发调用恢复工具，恢复需要在指令里显式要求。

工程与治理：单作者主导（3,700+ 次提交，贡献榜第二名是 CI 机器人），巴士系数偏低；issue 积压 923 个；MIT 附加署名条款对商用产品有额外合规义务；代理本身无鉴权，--host 0.0.0.0 暴露只限可信内网；客户端本地会话文件不会被压缩缩小（只缩发往模型的流量），数千消息后客户端自身可能变慢，官方建议的收敛手段是开新会话。

九、小结与行动建议

billion-context 用「模型自主判断 + 增量折叠 + 逐块可逆」三件套，把上下文管理从一次性截断变成可持续的工程系统，并罕见地配齐了论文、生产数据与第三方评测的完整证据链。行动建议：

Claude Code 重度用户先在低风险项目上试 bili claude（启动器方式零配置残留），用 /acp-cache 观察一周缓存命中与折叠经济，再决定是否常驻。
把它当「会话内压缩」用，不要指望替代跨会话记忆：长期记忆仍需 claude-mem 类系统，静态语料检索仍需 RAG。
精度敏感的逐字任务（合同条款核对、取证）绕开它——第三方评测的 AR 边界已经量化了代价。
关注作者的「学说蒸馏进权重」路线：压缩判断内化到模型后，脚手架提示词的开销会归零，这条线值得持续跟踪。
生产部署锁版本（--build-arg BILI_VERSION=<tag>）或利用错峰滚动更新，避免把开发分支节奏带进关键业务。

参考资料

ranxianglei/billion-context 仓库与 README（接入矩阵、生产数据、FAQ）：https://github.com/ranxianglei/billion-context （获取日期 2026-11-09）
论文《Model-Driven Incremental Hierarchical Compression》（预印本 v0.2，2026-09-07，随仓库 MIT 开源）：仓库 paper/ 目录（获取日期 2026-11-09）
独立第三方评测《1,500-Item Cross-Benchmark Evaluation》（v0.1.202，LongMemEval-S / ContextBench / MemoryAgentBench 五臂横评）：仓库 benchmarks/third-party-1500/ 目录（获取日期 2026-11-09）
npm 下载统计：https://api.npmjs.org/downloads/point/last-week/billion-context （获取日期 2026-11-09，周下载 848,207）
GitHub Releases（v0.1.213，2026-11-07）：https://github.com/ranxianglei/billion-context/releases （获取日期 2026-11-09）
HN 讨论「Goodbye Claude, hello Pi」下用户反馈：https://hn.algolia.com/api/v1/search?query=billion-context （获取日期 2026-11-09）
Compaction Cliff（压缩保真度崩塌研究，论文 §2 引用，arXiv 2608.22752）：转引自 billion-context 论文（获取日期 2026-11-09）