我们引入上下文语言模型（Context Language Models，CLMs），这是一种能够原生管理自身上下文的语言模型。具体实现方式是将上下文视作一个文件，并赋予模型对该文件进行无限制更新的能力，使模型在生成过程中自主维护所需的信息，而不再依赖外部固定的上下文窗口。
正文
上下文语言模型（Context Language Models）
我们提出上下文语言模型（CLM），这类语言模型能原生地管理自身上下文。实现方式是把上下文当作一个文件，允许模型对这个文件做不受限制的更新。这样模型可以自己学会哪些内容最值得保留在上下文中，也能自然扩展到多智能体系统——多个智能体的上下文作为文件并存。用现有模型零样本构建的 CLM，在多种任务上超过了当前最先进的上下文管理策略：在 BrowseComp-Plus 上准确率高 11.4%、FLOPs 少 21.5%；在 12 小时的 EdgeBench 上得分高 5%、FLOPs 少 59%；在 24 小时的多仓库智能体集群任务上，相同算力下提升幅度高 65%。此外，把上下文管理从外部框架控制转为模型的内在行为后，CLM 自然支持以上下文方式和参数化方式学习上下文管理策略。CLM 可以用自然语言指令引导，这些指令通过标准的技能优化循环演化，在一个上下文管理任务上把留出集准确率最多提升 35.9 个百分点，同时减少算力。我们还提出一种面向 CLM 的在线强化学习方法，让 Qwen3.5-9B 在 BrowseComp-Plus 上的表现提升 47.6%，FLOPs 少用 12%。最后，我们为 CLM 服务共同设计了 Suffix Cache Reuse，在性能相同时比标准 SGLang 进一步减少 35% 的服务端算力。
评论
讨论整体偏向兴奋：多数人认为上下文管理是 LLM 尚未解决的大痛点，自管上下文是值得关注的方向；分歧在于该由模型自己承担，还是交给外部机制，以免主智能体把注意力浪费在打理记忆上。
认为上下文管理是 LLM 剩下的硬骨头，值得让模型自己学
- 上下文管理是现代 LLM 最麻烦的遗留问题之一，把上下文当成模型可自由改写的文件，正对这个痛点，而且团队还顺带研究了缓存失效的解法（较多人） > 上下文管理是当前 LLM 最头疼的几件事之一，所以这个方向可能很重要。（@svachalek）
认为让主智能体自己管上下文是在浪费注意力
- 注意力和算力都是稀缺资源，让智能体去解决自己的记忆危机，就少了解决真正任务的资源；更合理的做法是另设一个「管理智能体」来调度主智能体的上下文，跑在不同节奏上，主智能体为此花零 token，缓存何时失效也更好控制（较多人） > 你是想让智能体去处理自己的记忆危机，还是去解决真正的任务？（@bob1029）
认为这只是把文件当下一段上下文喂进去，现有模型也能做
- 把文件作为后续上下文发过去，今天任何模型都能实现，区别只在于改动越深、缓存未命中的代价越高；而 CLM 直接忽略重算，这才是它的特别之处（少数人） > 这个技巧今天用任何模型都能做，只要把文件当作下一段上下文发过去。（@visarga）
认为迟早要重造 LLM 的内存层级与数据库抽象
- 把上下文当文件，等于给 LLM 造了一块内存，那接下来是不是得重新发明 MMU 以及随之而来的一整套抽象；更进一步，CLM 未来可能变成与实际模型联合训练的独立模型，上下文会出现数据库那样的冷热页分层，有人预测一年内会出现「把上下文当数据库」的论文（较多人） > 所以这就像 RAM，只不过是给 LLM 用的？我们是不是得为 LLM 重新发明 MMU？（@plastic-enjoyer）
认为这是「苦涩的教训」又一次应验
- 通用方法加算力再次胜出，这次发生在上下文管理领域（少数人）
有价值的补充
- 最反直觉的发现可能是：团队无视常规缓存规则，保留了无效的缓存后缀，性能却没有受损（@Bolwin）。这暗示缓存失效的代价未必如直觉中那么高。
- 有人指出相关工作「递归语言模型」值得一并参考（@killerstorm）。