大模型开始自己删上下文了

大模型正在学会自己删上下文：一个值得盯住的研究方向（还不是落地能力）

2025年10月，来自 Meta、MIT 和 华盛顿大学 的研究团队在 arXiv 上发布了预印本论文 《Context Language Models》（上下文语言模型，下称 CLM）。核心思路只有一句话——别再让工程师在外面写摘要、压缩、检索的规则了，让模型自己管理和编辑自己的上下文。

据论文作者报告，这种方式在任务性能和上下文 token 消耗上都有可观改善。但必须先说清楚定位：这是一篇方法论验证性质的研究论文，不是一项已经落地的产品能力。截至发稿，这些结果来自作者自建的评测设置，尚无独立第三方复现。本文讨论的，是它指向的方向，以及这个方向对数据基础设施的含义。

这件事在数据基础设施圈子里，比在算法圈子里更值得聊。因为过去十年，数据平台的人干的事本质上就一件：决定什么数据、以什么形态、在什么时机被送进计算引擎。现在，这个决策权第一次从「系统外的预定义机制」转移到「模型自己手上」的可能路径。

这不是一个小改进，是一次治理权的移交——如果它跑得通的话。

⚠️ 上下文管理，一直是人在替模型干活

金句先放这儿：上下文窗口每翻一倍，工程师的信任就打一次折。

这不是修辞，是有公开评测数据撑腰的。先看两组第三方基准：

• RULER（NVIDIA，2024，arXiv:2404.06654）系统测量了宣称支持 128K 上下文的模型的真实有效长度，结论是：多数模型的「有效上下文」明显短于「标称上下文」，例如 GPT-4 标称 128K，实际有效长度约 64K。
• NoLiMa（2025，arXiv:2502.05167）在排除词汇匹配线索的条件下评测了 11 个主流模型，其中 10 个在 32K 上下文长度下，准确率跌破自身短上下文（1K）基线的 50%。

也就是说，上下文越长，模型越容易「胡言乱语」，这是可复现的实验事实。

场景很熟悉。一个企业级 Agent 应用，接上公司知识库，跑长任务。跑到第几十轮，模型开始输出退化——上面两组基准解释了其中一部分原因：上下文塞满了过期信息、冗余中间结果和早已失效的指令，干扰了注意力分配。于是工程团队开始打补丁：写摘要策略，把历史对话压成一段总结；上 RAG，按需检索外部知识；做 token 预算管理，超了就截断。

这些手段有个共同点：全部是预定义的。什么时候摘、怎么压、检索什么，都是工程师在系统外事先写好的规则。模型只是被动的容器，内容进进出出，它自己说了不算。

数据平台的老人一看就懂：这不就是早年数仓里靠人写 ETL 脚本管理数据的翻版吗？数据什么时候清洗、怎么分层、过期了怎么归档，全是人工预定义的流水线。后来湖仓和数据编排工具的演进方向，恰恰是把越来越多的「数据决策」交给系统自动化。

上下文管理现在也可能走到同一条路上。

💡 CLM 的关键变化：模型拿到了编辑权（在论文的实验设置里）

CLM 做的事情，是把摘要、压缩、信息检索这三种预定义机制，变成模型自身的一种能力——模型在推理过程中可以主动地管理、编辑自己的上下文：删掉不重要的，压缩冗余的，保留关键的。

用一个流程图对比一下两种范式：

关键差异在两点。

第一，决策时机。传统机制是「事前规则」——任务开始前就定好压缩策略；CLM 是「事中决策」——模型边推理边判断哪些上下文还有价值。

第二，决策主体。摘要规则写得再精细，也是对模型需求的「外部猜测」；模型自己最清楚推理到哪一步需要什么信息。这和数据平台里「让数据库自己做查询优化，而不是让工程师手动调执行计划」的逻辑，一模一样。

论文作者报告的实验结果可以概括为：在作者自建的长上下文任务集上，经过训练的 CLM 模型与固定上下文的基线相比，能以显著更短的上下文达到持平或更高的任务准确率，同时降低上下文 token 消耗。注意两点限定：一是这些数字来自小规模模型与作者自选的任务设置；二是尚无独立复现，具体数字请以论文原文为准。

性能提升的逻辑容易理解——上下文更干净，干扰信息更少；效率提升则指向了长上下文推理最现实的痛点：钱。

🔋 省的每一分算力，都是真金白银

金句：长上下文不是白给的，每一万 token 都在账上。

做平台的人都算过这笔账。Agent 应用跑长任务，上下文线性增长，推理成本跟着线性涨，延迟也跟着涨。这不是估算，云厂商的价目表上白纸黑字写着：

一个日均百万次调用的 Agent 产品，上下文管理策略从「全量保留」改成「精细压缩」，成本差出数倍并不夸张——尤其当你的上下文长度刚好踩进厂商的加价区间。

这也是为什么过去两年，上下文压缩成了创业热点：一堆公司在做 prompt 压缩、记忆分层、上下文缓存。但市面上的主流方案仍然是外挂式的——在模型外面套一层管理系统，用规则和缓存去伺候模型。这一层目前是已落地、已商业化的；而 CLM 的路线激进之处在于，它干脆想把这层外挂拆掉——目前这只存在于论文里。

据多位跟进过长上下文优化的人士私下交流，外挂方案最大的尴尬是「两头不讨好」：压得太狠，Agent 忘事，用户骂；压得轻，成本下不来，老板骂。让模型自己删，理论上能找到更贴近任务需求的删除边界。

（原稿此处有一张「长上下文成本构成」的饼图，因无法给出可查证的出处，已删除。上表中的第三方评测与官方定价数据，才是可以放心引用的部分。）

当然，要泼一盆冷水：省算力的前提是「删得对」。如果模型把不该删的关键约束删了，任务失败的返工成本可能比省下的 token 更贵。可靠性账本上，这不只是一道加法题。

🚗 对数据平台的真正冲击：上下文工程可能成为新基建

金句：如果 Agent 时代的「存储引擎」是上下文，那么谁掌管它，谁就是新厂商。

拉长视角看，CLM 这类工作对数据基础设施的意义，可能比论文本身的指标更重要。

过去两年，业内一个共识正在形成：Agent 的核心竞争力之一，是上下文工程（Context Engineering）——如何组织、筛选、投喂信息给模型。围绕这件事，目前已经落地了一条产业链：向量数据库做检索，记忆框架做分层存储，中间件做压缩路由。

如果 CLM 路线跑通，这条链路的形态会变。原本在外部中间件里完成的摘要与压缩，部分下沉为模型内建能力；外部系统的工作重心，从「替模型决定给什么」转向「准备好模型可以自由调度的上下文池」。对做 RAG 平台、Agent 中间件的团队来说，这是一次需要认真对待的边界重构——你的核心功能，可能被下一版模型原生化。

历史 repeats itself。数据库厂商当年把手工分库分表做进了分布式引擎，编排厂商把手工调度做进了声明式管道。每一次「人工机制被引擎内化」，都伴随着一批外挂工具的退场和新基建的立起来。

不过更要冷静。CLM 目前仍停留在研究验证阶段，距离在生产环境大规模落地，还要回答几个工程问题：自我编辑的行为如何审计？删错了如何回滚？多租户场景下如何保证上下文编辑的隔离与合规？这些问题不解决，企业客户不会把「模型自己删上下文」写进采购清单——数据治理那套审计与可控性的老规矩，在 AI 时代一条都不会少。

小结：哪些已落地，哪些是方向

把话说清楚，分两栏：

已落地的能力（今天就能用）：预定义摘要与压缩、RAG 检索、记忆分层、上下文缓存——成熟、可审计、有商业产品支撑，也是今天 Agent 应用上下文管理的全部现实。

研究方向（值得关注，还不是能力）：CLM 这类「模型自我管理上下文」的方法。论文作者报告了性能与 token 消耗的双重改善，但结果来自作者自建评测，无第三方复