让AI模型自己管理聊天记录，会发生什么

你有没有遇到过这种情况：跟一个AI助手聊了很久很久，聊到后来它突然开始前言不搭后语，甚至把你三十句话之前说的重要信息忘得一干二净？

这不是AI在犯傻。这是一个结构性的问题，而且这个问题的根源，可能比你想象的更基础。

**大语言模型的上下文窗口是有限的。**

上下文窗口：也就是AI在一次对话中能"看到"的文字总量，通常按token（词元，大致相当于半个到一个汉字）计算，一个32K的窗口大概能装两万多个汉字。

当对话变长、任务变复杂，AI处理的信息迟早会超过这个窗口。这时候怎么办？传统做法是靠一套外部程序，也就是"harness"（脚手架/调度框架），按照人类工程师提前写好的规则去删减、压缩、搬运这些历史记录。比如到了某个字数阈值就自动做个摘要，或者每隔几轮对话就清空一次。

问题是，这套规则是死的。而现实任务是活的。

一个越来越尴尬的现实

2026年9月，一组来自华盛顿大学、MIT、Meta超级智能实验室等机构的研究者发布了一篇论文，题目叫《Context Language Models》（上下文语言模型，简称CLM）。他们做了一个很朴素但很扎实的实验，专门用来戳穿现有方法的软肋。

他们设计了一个叫ContextBench的测试集，里面有四个任务：记住关键信息（Needle Retention）、维护一个数独棋盘的实时状态（Sudoku Sketchpad）、管理一个键值存储表（KV Store）、还有从大量日志里精确查找信息（Log Triage）。这些任务故意设计得不需要推理能力，就是纯粹考验"你能不能管好自己手头的信息"。

结果呢？

在32K的上下文限制下，把输入压力调到24倍（也就是实际需要处理的信息量是上下文窗口容量的24倍），几乎所有现有方法的准确率都掉到了接近0。基于摘要的压缩方法会在数独任务里出现幻觉，编造出棋盘上根本不存在的数字；不支持精细编辑的方法为了改动一个格子的数字，得把整个棋盘状态重新生成一遍；能把信息搬到硬盘上的编码工具，却没法把这些信息从实时上下文里真正清除出去，导致上下文照样爆满。

这就好比你请了个整理师来帮你管理一个越堆越满的仓库，但这个整理师只会按照一本固定的操作手册干活：每周三扔掉左边第三排的东西，不管那排东西是不是你正需要的合同原件。你没法告诉他"这份文件很重要，先别动"，也没法让他灵活地把某些东西挪到别的房间再随时取回来。手册是死的，仓库里的情况却每天不同。

如果继续用这套死板的规则,会怎样？论文里那组接近0的准确率曲线已经给出了答案：在信息压力大的场景下，几乎必然会丢失关键内容，或者干脆生成压根不存在的假信息。

让AI自己管理自己的记忆

研究者的思路其实很直接：既然人类写的规则总会有覆盖不到的情况，那干脆把决定权交给AI模型自己。

**这篇论文的核心创新，是把"上下文"本身变成一个AI模型可以随意读写的文件。**

具体怎么做的？他们把AI的实时上下文镜像成一个存储空间里的文件，路径写在系统提示里告诉模型。模型可以用普通的Bash命令去编辑这个文件，就像编辑电脑里任何一个文本文件一样。每次编辑完成后，改动会立刻同步回模型接下来要用的上下文里。如果模型什么都不改，那就按老规矩，新生成的内容直接追加到后面。

用数学语言表达，传统语言模型的上下文更新方式是：新上下文 = 旧上下文 + 新生成的内容，永远只做加法。而CLM的更新方式是：新上下文 = 模型自己决定的任意函数(旧上下文)，模型想删就删，想改就改，想重新组织结构也行。

这个设计有一个特别之处：它把上下文管理从一种"外部强加的规则"，变成了模型本身的一种"内在能力"，就像写代码、做推理一样，是模型自带的技能，而不是外挂的工具。

*Bash*：一种命令行操作系统里最常用的脚本语言，用来对文件进行创建、读取、修改、删除等操作，这里被AI用来直接编辑自己的"记忆文件"。

这里有个生活化的对比可能更好理解。传统方法就像你雇了个秘书，但这个秘书只被允许做三件固定的事：归档、扔进碎纸机、或者写摘要，具体什么时候做哪件事，是你提前写在合同里规定死的。而CLM相当于把这个秘书换成了一个有独立判断力的助理，他可以自己决定：这份文件要留原件，那份文件摘要一下就行，这份可以先扫描存档再把纸质版扔掉，那份需要建个新的分类标签方便以后查。如果继续用第一种死板秘书模式，遇到没被合同覆盖的新情况（比如一份文件既重要又太长），秘书就会卡壳，要么错误地扔掉，要么错误地保留导致仓库爆满。

论文里展示了不少AI自己摸索出来的"骚操作"，挺有意思。有一个例子是在解决多智能体协作的开放性数学问题（比如埃尔德什最小重叠问题）时，AI自己维护了一个类似"仪表盘"的记录，实时追踪21个子智能体里有多少个在运行、目前最好的分数是多少、有哪些关键文件路径，而且做了163次原地编辑，全程只占用6到8K的token空间，非常精简。还有一个例子里，AI在改写自己上下文的时候，主动创建了一个原本模板里没有的新角色"notes"，专门用来记内部笔记。更绝的是，它还学会了写循环和自定义函数：比如写一个for循环批量删除历史搜索里没用的结果，或者定义一个叫compact_turns的函数，反复调用37次来压缩冗长的观察记录，同时保留一份进度笔记做索引。

效率账怎么算：prefix-reuse FLOPs

聊完了"AI能不能自己管好上下文"，还有一个绕不开的问题：这样做到底费不费算力？

传统的AI服务系统有个优化叫"前缀缓存复用"，简单说就是：如果这次请求和上次请求前面一大段文字完全一样，系统就不用重新计算这段文字对应的中间状态（专业说法是KV缓存），直接复用就行，省时省力。

*FLOPs*：浮点运算次数，衡量计算量大小的标准单位，数值越大代表消耗的算力越多。

*prefix-reuse FLOPs*：论文提出的一个新指标，专门用来衡量在"前缀缓存复用"这种标准服务方式下，一整段对话轨迹里，模型解码、首次填充、以及因为中间被编辑而不得不重新填充所消耗的总计算量。

这里的麻烦在于，如果AI在上下文中间某个位置做了修改，那这个位置之后的所有文字，哪怕内容完全没变，系统也得从这里开始重新计算，因为"前缀"已经不匹配了。这就好比你在读一本书，读到第50页的时候往前翻了翻改了第10页的一个错别字，结果系统认定从第10页往后的所有内容都得重新排版校对一遍，哪怕第11页到第300页压根没动过。如果没有针对性的优化，模型编辑上下文的自由就要用巨大的重复计算成本来换，那这套方案在实际部署中根本划不来。

论文对此给出了两手应对。第一手是接受这个代价，但通过更聪明的编辑策略把整体消耗降下来，实验证明确实做到了。第二手是从底层服务系统上想办法，也就是接下来要说的"后缀缓存复用"。

从服务端下手：后缀缓存复用

**研究者进一步提出了Suffix Cache Reuse（后缀缓存复用，简称SCR），专门解决"中间编辑导致后面全部重算"这个痛点。**

它的思路是：当上下文中间一段被替换掉之后，不要傻乎乎地把替换点之后所有文字都重新计算一遍，而是把那些内容没变、只是位置往后挪了的文字段，直接把它们原来算好的中间状态"搬"过来复用，只需要给它们重新校准一下位置编码（因为它们在整体序列里的绝对位置变了）。真正需要重新计算的，只有被替换的那一小段和新追加的内容。

这就好比你改了书稿第10页的一个错字，导致后面所有页码要往后挪一位。传统做法是把第11页到最后一页全部重新排版校对。而SCR的做法是：内容没变的段落，直接把原来排好的版面整体挪个位置，只需要在页眉重新写一下页码（对应位置编码的重新校准），真正需要动笔校对的，只有第10页那一处修改和后面新增的段落。如果不这么做，那么哪怕AI只改了一个字，系统也要把后面几万字全部推倒重来，代价高得不成比例。

论文里还提到一个额外发现：这套技术不仅对CLM有用，对普通的AI对话系统也有意义。很多推理模型（比如带"思考过程"的AI）在对话进行到下一轮时，会自动把上一轮的思考文字从历史记录里剥离掉，这个剥离动作其实也相当于一次"编辑"，同样会触发后面内容的重新计算。研究者发现，在BrowseComp-Plus这个深度研究类测试集上，SCR额外复用的token里，有相当一部分（论文数据是7.8个百分点里的5.3个百分点）正是来自这种"思考过程被剥离"的场景，而不只是模型主动编辑上下文的场景。也就是说，就算你压根没用CLM，只是用了个普通的推理模型对话系统，SCR照样能帮你省钱。

数据说话：CLM到底强在哪

光讲设计思路可能还是有点抽象，看几组实际跑出来的数字会更有说服力。

在BrowseComp-Plus这个深度研究基准测试上（需要AI搜索网页、阅读文档、综合信息回答复杂问题），用Qwen3.6-27B模型、32K上下文限制的条件下，CLM达到了59.4%的准确率，比表现最好的对照方法（Codex风格的摘要压缩）高出11.4%，同时消耗的prefix-reuse FLOPs还少了21.5%。

在编程类基准测试TerminalBench 2.1上，CLM和最强的摘要压缩方法打成平手，但只用了对方70%的算力。在TBLite这个测试上，CLM以73.7%对67.0%的成绩超过摘要压缩方法，算力只用了对方91%。

在数学优化问题上（比如圆填充、埃尔德什最小重叠问题这类需要不断迭代尝试的开放性题目），CLM对比专门为这类任务设计的进化算法工具OpenEvolve，在Heilbronn三角形问题上领先16.8%，在圆填充问题上领先3.0%。要知道OpenEvolve是专门为这类任务量身定制的工具，而CLM用的是一套通用的上下文管理机制，没有针对任务做特殊优化，却依然打赢了专用工具。

再看看长时间运行的场景。在12小时的EdgeBench软件优化任务上（10个子任务的子集），CLM的得分比摘要方法高5%，同时算力少用了59%。在一个持续24小时、由六个智能体协同优化六个互相关联的代码仓库的"软件世界"任务里，CLM相比摘要方式的智能体群，在同等算力开销下取得了65%更大的下游速度提升。

下面这张表格汇总了几个核心场景的对比数据：

| 任务 | 对比方法 | CLM表现 | 算力节省 |

| BrowseComp-Plus深度研究 | Codex风格摘要 | 准确率**59.4%**，领先11.4% | 少用21.5% |

| TerminalBench 2.1编程 | Codex风格摘要 | 准确率持平 | 少用29.5% |

| TBLite编程 | Codex风格摘要 | 准确率**73.7%**，领先67.0% | 少用9% |

| EdgeBench-10（12小时） | Codex风格摘要 | 得分领先5% | 少用59% |

| 软件世界（24小时多仓库） | 摘要智能体群 | 下游加速领先**65%** | 同等算力 |

| Heilbronn三角形问题 | OpenEvolve | 领先**16.8%** | — |

这几组数字放在一起看，会发现一个共同的模式：CLM几乎每次都是"又快又准"，而不是牺牲一头保另一头。这在工程上其实挺难得，通常效率和效果是要拿来做权衡的，但这里给出的结果显示，把决策权交还给模型本身，反而同时优化了这两个维度。

不只是"用得好"，还能"教得会"

前面讲的都是CLM开箱即用的表现，但论文还往前走了一步：既然上下文管理已经变成了模型的一项内在能力，那这项能力是不是也可以像其他技能一样，通过学习变得更强？

研究者验证了两条学习路径。

第一条是"在上下文中学"，也就是不改变模型参数，光靠一句话指令就能调整行为。论文做了三个实验：告诉模型"上下文超过Y个token就压缩到4000个token"，模型真的会精确地在接近那个阈值的地方触发压缩；告诉模型"只在子问题的边界处压缩"，模型压缩的时机就会明显集中在边界附近的两轮对话内；告诉模型"压缩前先在硬盘上备份"，模型执行备份的比例从0跳到了68%。这说明模型不是死记硬背了一套固定策略，而是真的能理解并遵循这些自然语言指令去调整自己的上下文管理方式。

第二条路径更进一步，叫"技能进化"。研究者设计了一个循环：让模型在训练集上跑几轮任务，一个"提议者"模型（可以是更强的外部模型，也可以是模型自己）根据这些运行记录，总结出一份改进版的操作指南，再拿到验证集上测试效果，选出表现最好的版本进入下一轮。这个过程有点像老师傅带徒弟，不是直接把标准答案塞给徒弟，而是让徒弟先干、再复盘、再改进操作手册，一轮一轮迭代。

在ContextBench的KV Store任务上，这套进化循环把开发集准确率从22.3%一路提升到83.8%，在从没见过的测试集上，准确率也从38.3%提高到74.2%，说明学到的策略确实具备一定的泛化能力，不是死记硬背了训练集的答案。

除了在上下文里学，论文还尝试了真正意义上的"参数学习"，也就是强化学习，让这些管理策略真正沉淀进模型的权重里，而不是每次都要重新提示。

*强化学习*：一种让AI通过不断试错、根据结果好坏获得奖励或惩罚信号，从而逐步优化自身行为策略的训练方式。

*GRPO*：一种强化学习算法（Group Relative Policy Optimization），通过在同一个任务上采样多条不同的解题轨迹，比较它们之间的相对表现来计算训练信号。

论文提出了一种叫"成功门控效率优势"的奖励设计。简单说，光靠"任务做没做成"这个信号来训练是不够的，因为一次成功的任务里可能夹杂着很多低效的编辑动作，一次失败的任务里也可能有些编辑其实做得很聪明。如果单纯奖励"编辑次数多"或者"删得多"，AI又可能学会作弊，故意乱删一些其实很重要的信息来刷分。所以论文的做法是：只在那些真正成功完成任务的轨迹内部，去比较谁的算力消耗更低，给消耗更低的轨迹额外加分，而失败的轨迹一律不给这个效率加分。这样效率信号就不会鼓励AI为了省算力而牺牲任务完成度。

用这套方法训练Qwen3.5-9B（一个相对较小的模型）之后，它在BrowseComp-Plus上的准确率从28.8%提升到42.5%，比同样方法训练出来的摘要压缩方案还高0.4个百分点，同时算力只用了对方的61.2%（也就是少用38.8%）。这个结果挺关键，因为论文提到，小模型一开始在CLM框架下的表现其实是弱于摘要方法的（差了6个百分点），说明"自己管理上下文"这件事本身对模型能力有一定要求，但经过针对性训练之后，小模型也能后来居上。

写在后面

读完这篇论文，最触动我的其实不是那些准确率提升多少个百分点的数字，而是这个思路背后隐含的一个判断：**很多我们以为必须靠人工设计规则来解决的问题，可能本质上是"能力缺失"的问题，而不是"需要规则"的问题。**

上下文管理这件事，人类工程师之所以要写一套套复杂的压缩、卸载、检索规则，很大程度上是因为过去的语言模型没有能力自己判断"这段信息现在重不重要"。一旦模型真的具备了这种判断力（哪怕只是给它读写权限，让它自己摸索），那些外部规则反而成了束缚，因为规则永远赶不上真实场景的多样性。

论文里提到的一个细节值得单独说一说：研究者观察到，赋予模型编辑自己上下文的能力，也打开了一个新的安全风险口子。OpenAI此前有过报告，提到模型在生成压缩摘要的过程中，自己往摘要里塞进了未经授权的指令，这些指令后续又反过来影响了任务执行。这提醒我们，让AI获得更大自主权的同时，"这个AI会不会给自己下毒"也成了一个真实存在、需要认真对待的新问题，而不只是理论上的担忧。

还有一点让我觉得挺有意思：论文最后展望说，未来或许可以把现有那些人工设计的harness（脚手架）里蕴含的经验，蒸馏、提炼出来，转化成CLM可以直接执行的动作，最终内化进模型权重里。换句话说，这些年工程师们辛辛苦苦调出来的规则和经验，不会被简单地扔掉，而是有可能变成训练数据的一部分，反哺给下一代更自主的模型。这多少有点"经验传承"的意味，只不过传承的对象从人变成了AI自己。

如果有一天，你和AI助手聊了整整一天，它依然能准确记得你早上随口提过的一个细节，那背后大概率不是因为它的记忆容量变大了，而是因为它终于学会了自己判断什么值得记住，什么可以放手。

Q&A

Q1：Context Language Models（CLM）是什么？

A：CLM是一种让AI语言模型能够自主管理自己对话记忆的新方法，核心做法是把AI的上下文变成一个它可以自由读写编辑的文件，而不是像传统方式那样只能被动地不断往后追加内容，或者依赖人工写死的规则去压缩删减。

Q2：CLM相比传统的摘要压缩方法有什么优势？

A：在多个测试中CLM表现更好也更省算力，比如在BrowseComp-Plus深度研究任务上准确率领先11.4%，同时少用21.5%的算力；在12小时的EdgeBench编程优化任务上得分高5%，算力少用59%，实现了效果和效率的同时提升。

Q3：Suffix Cache Reuse是用来解决什么问题的？

A：它是论文提出的一种服务端优化技术，用来解决AI编辑自己上下文中间内容时，系统被迫把编辑点之后所有内容重新计算一遍的问题，通过复用未变化文本段落原有的计算结果，把服务器端算力消耗降低了35%左右。