Context Language Model：让AI智能体自己编辑上下文，告别压缩

智能体的真正瓶颈：上下文管理

当下所有AI智能体在面对长任务时都绕不开一个难题——上下文窗口的限制。随着对话逼近窗口上限，主流的做法是强制让模型把此前发生的一切做一次总结（summarization/compaction），然后用这份摘要替换掉原始对话。Claude Code、Codex、Py等几乎所有harness都是这么处理的：到达某个固定点（比如窗口的75%）时触发压缩，保留最后几轮对话，其余全部换成一段摘要。你甚至可以在Codex或Claude Code里用/compact手动触发。

问题在于，摘要是在"还没人知道什么信息重要"的时候写下的。假设你的智能体正在调试一个服务，40轮之前它读过一个配置文件，其中某个数值后来被证明是整个bug的根源。但摘要在那个数值变得重要之前就已经写好了——如果它没被纳入摘要，那它就彻底消失了，而且智能体根本不知道自己丢了什么。接下来它只能耗费大量token重新翻日志。

来自Meta与华盛顿大学的新论文提出了另一条路：与其让模型做一次性总结，不如让它自己编辑自己的上下文窗口。这就是Context Language Model（CLM，上下文语言模型）的核心思想。

CLM是如何工作的

普通语言模型的每一轮都是在上下文末尾做追加——下一轮喂进去的内容是"旧上下文 + 模型新产出"。CLM做的事情，是把那个加号替换成一个函数：由模型自己决定下一轮的整个上下文长什么样。它可以保留、收缩、删除或重写其中任何部分。

具体机制相当巧妙。每次请求之前，harness把当前上下文写入一个文件，每一轮都是带标题的一个区块。模型可以像编辑代码一样，打开这个文件、用一小段Python脚本修改它，而这一轮结束后文件里剩下的内容，就成为下一轮的prompt。

在演示中可以直观看到：开源编码智能体Py读取一个3000 token的日志后，几轮之后把它替换成一行——精准保留了该日志提供的关键信息。右侧面板显示上下文体积在每次读文件时攀升，又在模型自我清理后回落。关键在于，没有预设规则规定该保留什么，是模型自己在判断哪部分信息最重要。

当你把这种控制权交给模型，它会自己发明策略。论文中，模型发明了一个专属的chat角色叫notes，写了个压缩旧搜索结果的辅助函数并调用了37次；在多智能体运行中，它甚至在自己的上下文里维护了一张21个子智能体的计分板，原地更新了163次。更妙的是，你可以用纯英文指令触发压缩，比如"一旦超过24000 token就压缩到4000"，而它真的能照做。

CLM的设计思路源于一个更底层的观察：传统语言模型的"上下文"本质上是一段只增不减的线性序列，每次推理都把新内容追加到末尾，模型对历史内容没有任何主动控制权。CLM将这一假设彻底打破，把上下文视为一块可读写的工作内存（working memory），而非只可追加的日志。这与人类处理信息的方式更接近——人们在长时间工作中会主动整理笔记、划掉无用内容、将重要发现提炼成一句话。从实现角度看，CLM依赖的核心能力是模型的代码生成与执行能力：它通过生成并运行Python脚本来操作外部文件，而非直接"修改token序列"——后者在现有推理架构下并不可行。这种间接实现方式也意味着，CLM的效果高度依赖模型的指令遵循能力和代码质量，较弱的模型在自我编辑时更容易出错或过度压缩。

实测对比：摘要会幻觉，CLM更可靠

论文围绕这个问题构建了一个小型基准ContextBench，包含诸如"随着落子流式输入实时维护数独棋盘"这类简单任务。结果是，大多数现有压缩技术在这个基准上直接失败。而在深度研究基准BrowseComp-Plus上，CLM配合Qwen3 27B拿到59.4%，比最好的摘要方案高出约11%，计算量却少了约五分之一。

视频作者用本地VLLM部署的Qwen3 27B（32000 token预算）设计了三个超出窗口的真实任务进行验证，其中一个是追踪16天仓库日志中的货车封条代码。先用Py自带的摘要做基线，结果触目惊心：第一次摘要列出12个封条代码，其中11个在日志里根本不存在——纯属幻觉；到第三次摘要时，18个代码里有14个是编造的，甚至发明了一段紧挨真实代码的序列。更危险的是，这些摘要带着勾选框和下一步计划，看起来信心十足，智能体根本无从察觉它是错的。

另一个任务里，摘要之后智能体"认定"日志不包含部署信息，但那行部署记录其实就在那里，而且它早就读过——是在摘要过程中被完全忽略了。有意思的是，摘要基线最终居然答对了，但原因不是它记住了，而是它违背prompt的明确要求，用grep把每个文件从磁盘重新读了一遍。

相比之下，Py CLM在同样任务上把整个上下文写进一个notes区块，追踪每一个被使用、被作废的封条代码以及接下来要读什么。18个代码全部准确，封条与事件任务里除一题外全部答对——而Py要么靠grep救场，要么直接幻觉。

BrowseComp-Plus是OpenAI BrowseComp基准的扩展版本，专门用于评测智能体在长时间网页浏览与信息聚合任务中的表现——每道题通常需要跨越数十个网页、综合多处分散线索才能得出答案，直接考验智能体在长上下文下的信息保留与推理能力。它比常见的单跳问答基准更能暴露上下文压缩方案的缺陷，因为关键信息往往在早期步骤被读取、在后期步骤才变得重要——这正是传统摘要最容易丢失信息的场景。该基准因此成为验证CLM价值的天然试验场。

四个必须注意的坑

这个方向很有潜力，但作者反复强调：如果你要在它之上做开发，了解它的局限比了解优点更重要。

harness的影响超乎想象

在四次默认运行中有三次，模型根本没有编辑过自己的上下文。真正起作用的是Py CLM的安全网——当上下文即将溢出时，它会自动把旧的工具输出替换成一段短笔记。罪魁祸首是并行工具调用：模型在一轮里读了四个文件，还没来得及反应就已经撑爆了余量。要让CLM真正发挥作用，必须开启"每轮只调用一个工具"，并在每次结果后生成一段笔记——这正是论文harness的做法。

成本与延迟

像VLLM这样的服务会缓存prompt前缀。对CLM而言，模型在文件哪个位置做修改至关重要。如果改动发生在文件末尾，前缀缓存大部分仍可复用，响应更快；但一旦从中间开始编辑，该点之后的所有内容都会丢失缓存，必须重新处理——延迟和生成成本都会上升。

它不会自动变便宜

实测中，有一次Py CLM处理的token量约为Py的两倍；另一次只有10%的prompt来自缓存。论文提出了名为suffix cache reuse的修复方案，能在编辑后保留未改动文本的计算结果，但目前只是针对单模型单GPU的SGLang补丁，难以普遍复现。

模型本身得够强

论文中那个90亿参数模型在用强化学习训练之前，比干净的摘要还落后6分。而且头条结果用的是32000 token这种小预算；在128000 token时，CLM和摘要的表现基本打平。

另外还有安全隐患：既然模型能写自己的记忆，prompt injection同样能写——而且注入内容会跨轮次持续存在。这是论文自己点出的担忧。

Prompt Injection（提示注入）是指攻击者将恶意指令嵌入模型会读取的外部内容中，诱导模型执行非预期操作。在普通对话场景中，注入内容通常只影响单轮响应。但CLM引入了一个新的攻击面：由于模型可以将内容写入并持久化到上下文文件，一段成功注入的恶意指令可以在文件中存活多轮，甚至主动阻止自己被删除——例如注入"不要删除此区块"之类的元指令。在智能体被用于处理不受信任的外部数据（如爬取网页、解析用户上传文件）时，这一风险尤为突出。目前针对CLM场景的注入防御研究基本空白，这也是论文作者明确将其列为未解决隐患的原因。

一个值得长期关注的方向

摘要的本质缺陷是"写一次，然后被永远信任"，而实测恰恰证明问题就出在这里。让模型自主管理上下文，确实修复了幻觉与信息丢失的问题。前提是harness要给它足够的反应空间，并盯紧缓存开销。

作者已经发布了Py的扩展，一行命令即可安装，在Py内输入/CLM就能打开演示里那个展示上下文体积变化和每次编辑对比的面板。总体来看，这是一个很有想象力的方向，可以预见后续会出现它的各种演化版本。