每年10 月前后，总有一篇论文悄悄改写 agent 基建的讨论框架。今年的候选之一是 9 月 29 日提交、10 月 1 日登上 HN 的 Context Language Models（arXiv:2609.37725）：来自华盛顿大学、AI2、Meta 等机构、作者列表里有 Luke Zettlemoyer 和 Pang Wei Koh 的这项工作，提出了一个简单到近乎冒犯的主张——上下文管理不该由外部 harness 做，该由模型自己做。
一、核心主张：上下文是一个文件
现在的 agent 栈里，上下文管理是一层外部中间件：压缩旧的、检索相关的、丢弃无关的，决策逻辑写在 harness 代码里。CLM 把这个决策权交还给模型：把上下文当作一份文件，允许模型对它做不受限制的更新——重写、删除、总结、扩写，一切由模型自己决定。
这个设计带来两个直接后果：
- 模型必须在训练或提示中学会「什么值得留在上下文里」，这从工程规则变成了可学习的行为；
- 多 agent 系统有了天然的表达：每个 agent 的上下文就是一份文件，协作变成共享文档式的读写。
二、零样本成绩：先赢一轮再说
最能说明问题的是 CLM 用现成模型零样本实现时的成绩——还没有任何训练介入，就全面超过了专门的 SOTA 上下文管理策略：
- BrowseComp-Plus：准确率高 11.4 个百分点，FLOPs 反而省 21.5；
- EdgeBench（12 小时长任务）：分数高 5 个百分点，FLOPs 省 59；
- 24 小时多仓库 agent 集群任务：相同算力下改进幅度高出 65 个百分点。
第三个数字尤其值得咀嚼：任务越长、agent 越多，CLM 的相对优势越大。外部 harness 的管理策略是人工写死的，任务形态一变就失配；模型自己管理的策略随任务自适应，长时任务正是失配最严重的地方。
三、训练加成：技能优化与在线 RL
零样本只是下限，论文真正想证明的是「管理能力可学习」：
技能优化回路：用标准的 skill-optimization loop 进化自然语言指令来引导 CLM 的管理行为，held-out 的上下文管理任务上最高提升 35.9 个百分点，同时降低算力消耗。这说明管理策略可以用「写说明书」的方式持续迭代。
在线强化学习：为 CLM 定制的 RL 方法让 Qwen3.5-9B 在 BrowseComp-Plus 上提升 47.6 个百分点，FLOPs 还省了 12。参数化学习意味着模型把管理策略烙进权重，不再依赖运行时指令。
服务端配套：自由改写会破坏前缀缓存，论文协同设计了 Suffix Cache Reuse，匹配性能下服务端算力比标准 SGLang 再降 35——没有这一块，CLM 只能停在论文里。
四、接口设计细读：模型对上下文文件能做什么
论文对「不受限制的更新」给出的操作面值得细看。模型可以重写整个上下文文件，也可以做局部编辑：删除已完成的中间产物、把重复出现的信息折叠成一句、把长时间不用的细节挪出活跃区、为即将开展的新子任务预写骨架。每次操作后模型继续在同一份文件上推理，harness 不做任何拦截或校对。
这个设计的巧妙之处在于它复用了模型已有的能力：编辑文档本来就是 LLM 最熟悉的任务形态，不需要学习新的工具调用协议。零样本可用的原因正在于此——提示词只需告诉模型「你的上下文是一个你可以随时编辑的文件」，其余行为自然涌现。训练阶段要学的只是「什么时候编辑、编辑成什么样」，而不是「怎么编辑」。
多 agent 场景由此获得了统一抽象：agent 之间的协调不再需要设计消息协议，读写彼此的上下文文件就是协作界面。论文的 24 小时集群实验里，一个 agent 的调查结论写进共享文件，另一个 agent 接手时直接在文件上继续推进，中间没有转译损耗。这个抽象简单，但把当前多 agent 框架里最容易出错的「状态同步」问题整个消掉了。
五、与长上下文、KV 压缩路线的关系
上下文工程有三个技术方向常常被混为一谈，CLM 的位置需要放准。
拉长窗口是算力路线：上下文不够长就加。它不丢信息，但注意力计算与缓存成本随长度增长，而且「塞得下」从来不等于「用得好」——lost-in-the-middle 类现象说明模型对超长上下文的利用效率会衰减。
KV 缓存压缩是存储路线：保留窗口但压缩中间状态。它省算力，但对「哪些内容重要」的判断是静态的、结构驱动的。
CLM 是语义路线：不改模型结构，不改缓存，而是让模型在语义层面决定留什么。三个方向其实正交——窗口可以继续加长，缓存可以继续压缩，而「内容取舍」这门课 CLM 证明模型自己学得比人工规则好。对部署者来说，三者叠加才是终局形态：长窗口保证塞得下，压缩保证存得起，CLM 式管理保证用得准。
六、给你的落地判断
三类团队应该把这篇论文放进本周阅读清单。做长时 agent 产品的：24 小时任务上 65 个百分点的改进差距说明，运行时间越长，外部管理的失配成本越高，你的 harness 层值得按 CLM 的方向做一次架构预演。做多 agent 框架的：文件化上下文作为协作原语，值得和你们现有的消息传递机制做一次 A/B。做推理服务的：Suffix Cache Reuse 比 CLM 本身更快落地，35 个百分比的服务端算力节省与模型无关，检查你们的网关是否已经支持后缀复用。
需要保持审慎的地方也有两点：论文的任务域集中在检索、长时与代码仓库场景，开放式创作类任务上管理收益未测；「模型删错关键信息」的失败模式论文用可恢复性缓解——文件改错了可以靠外部快照回滚——但这层保险在生产环境里需要自己补。
七、放在 harness 时代的坐标系里看
最近两周的技术新闻里，「harness」是高频词：Pi 1.0 把极简 harness 做成产品，多篇 arXiv 论文在优化 harness 的形态。CLM 提供的是一个反向的思考实验：如果模型自己就是最好的 harness 呢？
短期结论是分工不变：今天的模型仍需要外部系统管持久化、跨会话记忆与权限边界。但 CLM 用数据划出了一条清楚的退出斜线——管理能力每内化一分，harness 的职责就后退一步。做 agent 基建的产品值得把这篇论文当作路线图的警示：你现在重投入的那层中间件，可能正处在被模型本体吸收的路径上。
而对研究者，这篇论文留下的开放问题同样诱人：改写上下文的安全边界如何约束（模型删错关键信息怎么办）、文件化的上下文与参数化记忆如何配比、以及当每个模型都自带管理能力时，多模型协作的协议该长什么样。
论文与代码已公开，Qwen3.5-9B 上的 RL 结果意味着复现门槛不高。如果你在做一个长时运行 agent 产品，本周值得安排一次精读。