上下文窗口不是“内存”——Context Engineering中的信息压缩与优先级淘汰策略

“把整本书塞进窗口模型就什么都能记住”——一个代价高昂的幻觉2026年Gemini 2.0宣称支持2M Token上下文Claude 4做到500KGPT-5到了1M。看起来一个窗口能塞下一整本书、整个代码库、一整个月的聊天记录。但你试过就知道把500页技术文档塞进去模型到第200页时已经忘了第10页讲什么在Cursor里打开整个项目Agent改到第3个文件时开始“幻觉”把过去100轮对话全部传进去模型的回复越来越平庸。问题不在窗口大小在上下文管理。Andrej Karpathy把LLM比作新型操作系统——LLM是CPU上下文窗口是RAM。和RAM一样上下文窗口容量有限无法容纳所有来源的信息。但很多开发者把上下文当成了“硬盘”——能塞多少塞多少塞不下就扩。这是一种根本性的误解。上下文是栈内存聊天记录是堆上的日志文件。栈上放的是当前执行帧需要的数据堆上存的是完整历史。把全部历史搬到栈上结果就是栈溢出——对应到LLM就是注意力稀释和上下文溢出。即使到了2026年上下文窗口中间位置的召回率仍然比首尾低20-40%。这是Transformer注意力机制的结构性问题不是简单扩窗口能解决的。真正决定AI应用效果的不是能塞多少Token而是如何像操作系统一样管理上下文什么该常驻、什么该检索、什么该压缩、什么该淘汰。今天我们从信息压缩和优先级淘汰两个维度拆解Context Engineering的核心方法论。一、信息压缩让每个Token都有价值1.1 为什么压缩不可避免Agent执行长任务时每一轮“调用工具→拿到结果→再思考”都会往历史里追加大量内容读了哪些文件、跑了哪些命令、命令吐了多长的日志……几十轮下来历史轻松膨胀到几十万Token。撞上窗口上限会发生三件事Provider直接报context overflow每轮把全部历史重发一遍Token越多越贵粗暴截断会把最初的任务目标也一起截掉。多个案例研究表明经过压缩可以在保持甚至提升准确率的同时砍掉50-75%的Token。压缩不是妥协是必要的基础设施。1.2 三种压缩范式上下文压缩方法主要分为三类提取式压缩Extractive Compression从原始上下文中选择最重要的片段保留删除冗余。2025年的研究ICML论文表明提取式压缩是一个非常强的选择通常能在10倍以上压缩率下保持极小的精度损失。EXIT框架Extractive Context Compression通过动态调整查询复杂度和检索质量在QA任务上超越了现有压缩方法和未压缩的基线。生成式压缩Generative Compression用LLM本身将长文本重写为更短的摘要。这是DeepAgents等框架采用的默认方案——当上下文压力增大时调用LLM生成结构化摘要替换旧消息。但生成式压缩是“查询无关的”query-blind和有损的它不知道用户接下来会问什么。选择性压缩Selective Compression混合策略——只压缩次要块保留关键块的原始形式。Meta的REFRAG框架采用RL策略以“下一段预测困惑度”为负奖励困惑度越高说明块越重要决定保留哪些上下文块的原始形式。这一框架在仅保留核心内容的原始Token情况下实现了30.85倍的TTFT加速、将LLM上下文处理长度扩展16倍。1.3 DeepAgents的分层压缩从最便宜的开始LangChain的Deep Agents SDK实现了一套分层压缩Tiered Compression策略按上下文压力递增的顺序依次应用第一层卸载大工具输出Offloading large tool results。当检测到工具响应超过20,000 Token时Deep Agents将其卸载到文件系统替换为文件路径引用和前10行预览。Agent需要时可以重新读取或搜索该内容。第二层卸载大工具输入Offloading large tool inputs。文件写入和编辑操作会在对话历史中留下包含完整文件内容的工具调用。由于这些内容已经持久化到文件系统当会话上下文超过模型可用窗口的85%时Deep Agents会截断旧工具调用替换为磁盘文件指针。第三层摘要生成Summarization。当前两层卸载无法腾出足够空间时LLM生成结构化摘要——包括会话意图、已创建的工件和后续步骤——替换完整消息历史。这种“从最便宜的开始”的设计哲学避免了在每一轮都触发昂贵的LLM摘要调用。1.4 自主压缩让Agent自己决定何时“清场”LangChain在2026年3月更进一步在Deep Agents SDK中为Agent暴露了一个compact_conversation工具让模型在合适的时机自主触发上下文压缩。什么时候是“合适的时机”在干净的任务边界用户示意进入新任务、从大量上下文中提取出结果之后、在消费大量新上下文之前、在进入复杂多步流程之前、以及当新需求使先前上下文失效时。“我们普遍看好这个想法harness应该在可能的情况下‘让路’并利用底层推理模型的改进。”——LangChain团队固定阈值压缩比如85%触发的问题在于有好的压缩时机和坏的压缩时机。在复杂重构过程中压缩不合适但在开始新任务时压缩非常合适。把决策权交给Agent自己让压缩从“被动防御”变成“主动策略”。二、优先级淘汰不是所有Token都生而平等2.1 淘汰策略的演化从“按时间”到“按价值”当前大多数Agent框架的默认淘汰机制是近因截断recency truncation——当上下文超过Token预算时丢弃最早的消息。这种策略是“主题盲”topic-blind的。一个在会话早期建立的事实仅仅因为“老”就被丢弃了——即使当前用户查询恰恰问的是这个事实。相反冗长但无关的近期内容却被保留。需要跨多轮回忆信息的Agent——这正是记忆的典型场景——恰恰是近因截断最失效的地方。近因截断是把上下文当成“队列”——先进先出。但上下文不是队列它是一个信息检索问题。2.2 基于新颖性的淘汰用信息量替代Token数一篇2026年7月的论文《Context by Distinct Information》提出了一个根本性的视角转变上下文应该按“不同信息条目”来度量而不是按Token。在一个典型的上下文流中同一个名称在对话中反复出现检索到的段落重复陈述了早期的事实同一个工具反复输出相同的状态记录一个代码标识符出现数百次一个日志模板触发了数千次。标准的内存方案却仍然按Token来计量。该论文提出的“新颖性门控缓存”novelty-gated cache只在传入的key是新颖时才打开缓存槽使内存规模与不同条目的数量成比例而非Token数量。实验表明在字符级控制下新颖性门控注意力达到了全注意力的性能同时只关注了约一半的Token。核心洞察信息密度决定了上下文的价值Token数量只是载体。2.3 基于规划感知的淘汰知道“下一步要什么”PAACE框架Plan-Aware Automated Context Engineering将上下文管理建模为一个关联记忆塑造associative memory shaping问题。它学会根据记忆元素与即将到来的规划步骤的关联相关性associative relevance选择性地保留、重写、压缩或丢弃记忆元素。这意味着淘汰决策不是基于“这条消息有多老”而是基于“这条消息对下一步任务有多重要”。在RAG场景中PACMS框架Submodular Context Selection将记忆条目、对话轮次和工具输出视为一个统一的候选池在组装Prompt的时刻按相关性进行选择。它不依赖于近因截断或查询无关的压缩而是在每一轮决策时动态选择最相关的上下文子集。2.4 上下文分层五级缓存模型一篇系统性的上下文管理文章提出了五级缓存模型L1缓存系统指令~2K Tokens——CPU寄存器级别。存放模型身份、行为规则、输出约束。生命周期最长几乎不变。L2缓存工作记忆~1K Tokens——当前任务的核心上下文。L3缓存RAG检索结果——按需检索的动态知识。L4缓存对话历史摘要——压缩后的长期记忆。L5缓存完整对话日志——持久化存储仅在需要时召回。每一层有不同的容量、生命周期和刷新策略。设计一个生产级上下文系统本质上就是在定义这五级缓存。三、工程实践从理论到代码3.1 优先级系统给上下文标“价”一个成熟的上下文工程方案需要一个优先级系统Priority System——不是所有上下文都生而平等。fromtypingimportDict,List,TuplefromenumimportEnumclassContextPriority(Enum):CRITICAL0# 永不淘汰系统指令、核心约束HIGH1# 最后淘汰当前任务目标、关键事实MEDIUM2# 可压缩历史对话、工具调用记录LOW3# 优先淘汰冗长输出、调试日志classPrioritizedContext:def__init__(self):self.items:List[Tuple[str,ContextPriority,str]][]defadd(self,content:str,priority:ContextPriority):self.items.append((content,priority,))defevict_until(self,target_tokens:int,token_counter)-List[str]:按优先级从低到高淘汰直到Token数降到目标值sorted_itemssorted(self.items,keylambdax:x[1].value)kept[]current_tokens0forcontent,priority,_insorted_items:tokenstoken_counter(content)ifcurrent_tokenstokenstarget_tokens:kept.append(content)current_tokenstokenselse:# 对MEDIUM和LOW优先级的内容尝试压缩ifpriorityin[ContextPriority.MEDIUM,ContextPriority.LOW]:compressedself._compress(content,target_tokens-current_tokens)ifcompressed:kept.append(compressed)breakreturnkeptdef_compress(self,content:str,budget:int)-str:使用LLM或提取式方法压缩内容到预算内# 实现略可调用LLM生成摘要或使用提取式压缩pass3.2 DeepAgents压缩中间件实战fromdeepagents.middleware.summarizationimport(SummarizationMiddleware,SummarizationToolMiddleware,)fromlangchain.agentsimportcreate_agentfromlangchain_openaiimportChatOpenAI# 自动压缩中间件在85%阈值时触发auto_compressSummarizationMiddleware(modelgpt-4o,threshold0.85,# 上下文使用率达到85%时触发压缩)# 手动压缩工具让Agent自己决定何时压缩manual_compressSummarizationToolMiddleware(modelgpt-4o,)agentcreate_agent(modelChatOpenAI(modelgpt-4o),tools[search_tool,file_tool],middleware[auto_compress,manual_compress],)SummarizationMiddleware自动监控Token数量在超出阈值时将历史对话压缩为高质量摘要保留最近消息。SummarizationToolMiddleware则暴露一个compact_conversation工具让Agent或人工审批流程按需触发压缩。3.3 双缓冲压缩零停机上下文刷新LangChain社区在2026年2月提出了双缓冲上下文窗口中间件double-buffer context window middleware——在可配置阈值默认70%处建立检查点后台继续工作的同时运行摘要生成然后在交换阈值默认95%处切换到预构建的后台缓冲区。这解决了压缩期间服务中断的问题——Agent不用“停下来等摘要做完”压缩在后台透明进行。四、总结上下文管理的三条铁律铁律一上下文不是硬盘是缓存。不要试图把“所有东西”塞进上下文。上下文是工作内存不是持久存储。把信息分层——哪些常驻、哪些检索、哪些压缩、哪些淘汰——是Context Engineering的第一课。铁律二压缩先选最便宜的。DeepAgents的三层压缩卸载输出→卸载输入→摘要给出了一个清晰的优先级先做零成本的引用替换再做低成本的截断最后才做高成本的LLM摘要。铁律三淘汰看价值不看年龄。近因截断是一个“懒惰”的默认值。对于需要跨多轮记忆的Agent基于相关性、新颖性或规划感知的淘汰策略远比“丢掉最早的”更有效。上下文窗口会继续扩大——1M、2M、10M。但“Lost in the Middle”不会消失。真正决定AI应用上限的从来不是窗口能塞多少Token而是你能在有限的Token预算内塞进多少有效信息。Context Engineering的本质是在有损信道中最大化信号-令牌比。