企业官网建设流程全解析

Agent 记东西，像往黑板上写。只能往上加，擦不掉。——今天所有主流 Agent 框架都是这么干的。

它没报错，也没有任何提示。它就是少了一样东西，而它自己不知道。

这期讲的是这件事怎么发生的，以及 Meta Superintelligence Labs 带着华盛顿大学、MIT 和 Trillium Labs 在9 月 29 号挂上 arXiv 的一种新做法（论文叫Context Language Models，代码在facebookresearch/context-language-models）。

先从第 80 轮那次重跑看起。

第 80 轮那次重跑

你让Agent 改一个老项目。跑到第 40 轮，它读了配置文件，拿到一个端口号。你接着让它干别的，改了七八个文件。第 80 轮，你让它把配置改回去重跑。

它没报错。它很自信地给了一个端口号。

那个号是它自己编的。

它就编一个，还不报错。压缩策略最难防的就是这里。

它不是算错了。它手里那份东西里根本没有那个端口号了——那份东西长得挺完整，读起来也顺，就是没有那一行。关键在于，它也不知道自己已经没有它了。

丢东西这件事之所以难防，不是 Agent 笨。是它丢得静悄悄。

原来那块黑板

写满了会怎样？得重抄一遍，前面全擦掉。

主流 Agent 框架（Claude Code、Codex、Pi）给的记忆，本质是一面黑板。

每轮对话、每次工具返回、每步推理，都往上面加一行。加东西可以，擦东西不行。写到窗口的 75% 左右就触发一次摘要，把前面绝大部分擦掉重抄成一段浓缩版，只留最近几轮原文。你也可以手动敲/compact提前触发。

回到刚才那个端口号。摘要发生在某两个回合之间，它不问你"第 80 轮要干什么"，它只按规则抄。抄完那一行就没了。

擦的时候谁说了算？外面那个管家，照老规矩来。

重抄这件事由外面的人决定。框架按写死的规则判断哪些该留、哪些该擦，模型没有发言权。

它擦的时候知道啥？不知道。它只看眼前，料不到以后。

这是要命的一条。

摘要是在某个具体时刻写的，写的那一刻，没人有办法知道第 60 轮会用上第 12 轮读到的哪个值。写摘要的人不知道，看摘要的 Agent 也不知道——所以它不会停下来问，只会拿一个编的数接着往下走。

还有个更绕的：摘要的摘要。你手动多压几次，或者长任务自己触发多次压缩，就变成摘要的摘要，每一轮都在丢一点，最后剩下一份读起来很顺、其实已经空了的东西。

论文把这件事说得很直：agent harness 那些"总结 / 截断 / 检索"的固定策略，才是长任务的绑定约束，不是模型本身。

CLM：一本它自己揣着的笔记本

改动就一句话：

把上下文变成一个文件，模型拿着文件路径，用普通命令行工具去改它。

CLM 的做法不一样在哪？不是黑板了，是一本笔记本。

笔记本这个比方，关键在第三条。前两条是权限问题——从"别人擦"变成"自己擦"。第三条才是那只靴子：做判断的人换成了当事人。模型在动手的那一刻，手上有完整的目标和完整的现场，它自己知道第 80 轮要拿那个端口号，所以那行不会丢。

这跟"帮我总结一下"不是一回事。这是"你自己看着办，要留的留，要删的删，要改写的改写"。

这本子能干什么？划掉不要的，写小字记账，随手翻页。

改完立刻生效？下一轮它看到的就是改过的。

模型下一轮看到什么，取决于它刚才对自己的上下文做了什么。上下文不再是一份只能追加的记录，是一个它能动手改的工作区。

这套玩法不用训练。不训一个参数，现有模型直接套上就有效果。论文顺手还试了在线 RL，Qwen3.5-9B 在BrowseComp-Plus 上提升 47.6%，FLOPs 还省 12%。

这些玩法没人教它

这套本事谁教的？没人教，它自己学会记账了。

论文里记了三条它自己干出来的事：给自己造了个叫notes的角色声明，纯用来做内部记账；写了个辅助函数专门压缩旧的搜索结果，来回调了几十次；一次多 Agent 实验里维护了一张 21 个子Agent 的实时记分板，原地更新了一百多次。

没人写进提示词，没人规定格式。作者管这叫零样本——不是夸它聪明，是给了一个能动手的空间，它自己找出了怎么用。

还有一条结论挺有意思：RL 在 CLM 上比在普通 LM 上更好做信用分配。因为模型对上下文的每一次编辑都是显式的、可读的判断——哪条重要、哪条没用，它写出来了，不用猜。

省了多少

这么干能省多少？答得更准，还能更省算力。

三个都不需要训练。EdgeBench 那行最狠——跑 12 小时的任务，算力少用近六成，准确率还上去了。

还有一个数字容易被忽略：用自然语言指令（走 skill 优化循环）能教上下文管理策略，在留出数据上最多提升 35.9 个百分点。也就是说"怎么管上下文"这件事本身也能变成可优化的目标，不用写死在代码里。

两个坑

那没有代价吗？有，改狠了会变慢，坏指令会赖着。

改中间会破掉前缀缓存。模型上下文是个 KV 缓存，前面的算好了后面接着用。在中间动一刀，后面全部作废。论文自己做了配套优化叫 Suffix Cache Reuse——把还活着的部分挪一挪，只重算真变了的那段，在 BrowseComp-Plus 上做到性能持平、服务端算力比标准 SGLang 少 35%。第三方视频解读里提到"最差可能慢 70 倍"，这个数字我没在论文正文核实到，只当参考。

Prompt injection 会长期驻留。普通摘要有个副作用是"冲淡"——恶意指令混在摘要里，多轮之后可能被稀释掉。CLM 的上下文是模型自己写的文件，它还打算写长期笔记。注入的指令会一直在那儿。这是 CLM 自己论文里承认的安全问题。

还有一个论文自己说的观察，值得单独拎出来：harness 的配置方式会直接影响效果。开了并行工具调用之后，模型几乎不怎么自己编辑上下文了，退化成兜底逻辑在压缩。

这条最有意思，因为它反着证明了前面的道理。模型会去用你给它的空间——你把空间收走，它就退回老路。所以不是"CLM 一套上去就一定灵"，得真的留出动手的空间。

怎么用，我的判断

如果你手上已经有一个跑长任务的 Agent，先试一处：让它重写自己的压缩决策，不用整套换掉。仓库里有clm-minimal实现和clm-harborCLI，能接 OpenAI 兼容端点，跑起来看行为就行。

CLM 动的是"谁决定压缩"，不是"怎么压缩"。过去这层是 harness 的，框架写死规则，模型被动接受；现在收回来了，理由很朴素——压缩之前要做判断的是模型，因为它知道第 60 轮要用什么，第 40 轮的人不知道。

代价也实在：延迟不确定性变大，安全面变宽。所以短期内更可能是混合——harness 管硬边界（上下文总长、超时、权限），模型管软决策（什么值得留）。并行工具调用那条观察就是在说这条边界画在哪儿：硬边界给多了，模型就不动手了。

最后一件我会继续盯的事：论文把上下文管理从框架挪进模型，而同期 turbopuffer 那家做 serverless 向量数据库的公司在往反方向走，宣布要把向量检索降级成"只是一个二级索引"。两个独立团队，一个从上面收，一个从下面收，中间的中间件层正在被两头挤。这个结构比 CLM 本身更值得盯。

出处：arXiv 2026-09-29，Meta Superintelligence Labs / University of Washington / MIT / Trillium Labs。

漫画由 AI 辅助生成，人工逐字终审。