上下文不是越长越好：AI Agent 正在进入“上下文压缩”时代

写在前面从“能塞多少”到“该留下什么”过去两年大模型有一个很明显的军备竞赛8K 上下文 32K 上下文 128K 上下文 200K 上下文 1M 上下文。很多人的第一反应是太好了以后不用做检索、不用做摘要、不用裁剪直接把资料全塞进去。这是一种很自然但也很危险的想法。长上下文确实有价值。它让模型能阅读更长的文档、更多的代码、更完整的对话历史。但在真实系统里长上下文不是免费的午餐。它会带来三个问题更高成本 更高延迟 更多噪音。尤其是 AI Agent。普通聊天最多是人问一句、模型答一句。Agent 不一样它会不断读文件 调用工具 查看日志 生成计划 执行下一步 把结果继续放回上下文。上下文像滚雪球一样变大。所以AI 应用的趋势正在从“谁能塞更多 token”转向“谁能保留更有用的上下文”。这就是上下文压缩。本文实战口径本文不把 context compression 写成论文摘要而是按真实 Agent 系统的问题来讲问题说明长上下文为什么不等于高质量上下文太长会让模型分心压缩和摘要有什么区别摘要只是其中一种压缩范围更广Agent 为什么更需要压缩多轮工具调用会产生大量低价值上下文新研究在解决什么LCLM、query-aware compression、token merging工程上怎么落地先从日志、RAG、历史对话三类内容做起一句话总结长上下文解决的是“放不下”的问题上下文压缩解决的是“该放什么”的问题。一、长上下文的第一个幻觉能放下不代表能用好很多人把上下文窗口理解成硬盘容量窗口越大能装的东西越多 装得越多模型知道得越多 模型知道得越多回答越准。但模型的上下文更像工作台不是仓库。工作台上东西太少确实做不了事但东西太多扳手、图纸、螺丝、发票、说明书、旧版本草稿全混在一起效率也会下降。在 RAG 里这个问题很常见检索系统把相似文档都找出来 TopK 设置很大 每个 chunk 都很长 模型收到一堆看似相关但版本不同的资料 最后回答混合了新旧规则。在代码 Agent 里也一样模型读了 20 个文件 真正需要修改的是 2 个 其余文件只是名字相似 测试日志又塞进来几百行 模型开始在无关代码里找线索。这不是模型“不聪明”而是上下文没有治理。二、上下文压缩不是简单摘要一提到压缩很多人马上想到把长文总结成短文。这只是最朴素的一种方式。真正的上下文压缩至少有几类类型做法适合场景去重压缩删除重复内容日志、历史对话、重复文档选择压缩只保留相关片段RAG、搜索结果、代码上下文结构压缩保留结构删细节JSON、表格、代码 AST摘要压缩把多段内容压成状态对话历史、会议记录语义压缩用模型或 embedding 保留含义长文档、复杂资料latent 压缩把 token 映射成短的隐表示长上下文推理基础设施它们解决的问题不同。客服对话历史可以摘要。合同关键条款不能随便摘要最好保留原文。命令行日志可以抽取错误行。代码不能像普通自然语言一样乱删否则会破坏依赖关系。所以上下文压缩不是“把内容变短”这么简单而是在任务目标下保留足够支持答案的最小上下文。三、为什么 Agent 比聊天更需要压缩Agent 的上下文压力来自循环。一次普通问答用户问题 → 模型回答一次 Agent 任务用户目标 → 计划 → 工具调用 → 工具结果 → 重新计划 → 再调用工具 → 再读取结果 → 生成最终答案每一步都会产生新的上下文。如果 Agent 没有压缩机制它会慢慢背上一个越来越重的包袱一开始只带需求 后来带上文件内容 再后来带上命令输出 再后来带上失败记录 最后每一步都在重复携带过去的噪音。这就是长程 Agent 的核心瓶颈之一。一个运行 3 分钟的 Agent也许还可以靠大上下文硬扛。一个运行 30 分钟、跨多个工具、多次检索、多轮修复的 Agent就必须学会“忘记低价值内容”。否则它会同时遇到上下文窗口满 响应变慢 成本升高 回答被旧信息干扰 失败重试越来越贵。四、2026 年的新信号压缩开始进入基础设施层2026 年 6 月的论文《End-to-End Context Compression at Scale》提出了 Latent Context Language Models也就是 LCLM。它的核心思路不是先把完整上下文喂给大模型再想办法删 KV cache而是在进入 decoder 之前就用 encoder 把长 token 序列压成更短的 latent embeddings。论文里训练了 0.6B encoder 和 4B decoder 的组合并尝试 1:4、1:8、1:16 的压缩比。它要解决的是长上下文推理中的内存、速度和质量平衡问题。这件事的意义不在于普通开发者明天就能把 LCLM 接到业务里而在于它释放了一个信号上下文压缩不再只是 prompt 技巧 它正在变成大模型基础设施的一部分。过去的思路是给模型更大的窗口。现在的新问题是能不能在模型真正推理前把上下文变成更短、更有信息密度的表示如果这个方向成熟未来的 Agent 可能不是每一步都拖着完整历史而是粗读压缩上下文 发现相关区域 再按需展开原文。这很像人类读资料先扫目录和摘要发现关键章节再回头看原文。五、工程落地先别追论文从三类上下文开始对普通团队来说现在不需要一上来训练压缩模型。真正该做的是先处理三类最容易浪费 token 的上下文。1. 历史对话不要无限把完整聊天记录塞回模型。可以改成状态式记忆用户身份企业版客户 当前目标确认是否符合退款条件 已知事实购买日期 2026-05-20合同中包含年度订阅 待确认是否已超过可退款期限。这种压缩比“过去 20 轮完整对话”更有用。2. RAG 检索结果不要只调大 TopK。应该增加重排序 去重 版本过滤 来源优先级 按问题类型选择 chunk。如果用户问的是“当前政策”旧版本文档就应该降权甚至不进入上下文。3. 工具输出Agent 调用工具后不要把完整输出原样塞回去。比如测试日志模型通常不需要所有通过的测试 所有依赖加载记录 所有进度条 重复堆栈。它需要的是哪个命令失败 失败的测试名 关键错误行 可能相关的文件路径 退出码。这类压缩不需要深度学习规则就能做出很大收益。六、一个实战流程给 Agent 加上下文压缩层可以按这个顺序改造先记录上下文来源每次模型调用前记录输入 token 的构成system prompt多少 history多少 retrieval多少 tool results多少 user input多少。没有这个数据就不要谈优化。给每类内容设置上限例如历史对话最多 1500 token 工具输出最多 2000 token RAG 证据最多 5000 token 超过就进入压缩流程。先做无损或低风险压缩比如删除重复行 折叠成功日志 保留错误上下文前后 20 行 JSON 只保留关键字段 长列表只保留 top items。再做任务相关选择用户问退款就优先保留退款政策。用户修 bug就优先保留报错、调用链和相关函数。用户写周报就优先保留结果、指标和变化。最后才考虑模型摘要摘要有成本也有信息损失。不能把所有压缩都交给模型总结尤其是合同、代码、报错、财务数据这类场景。七、压缩的风险别把证据压没了上下文压缩最危险的地方是看起来一切正常。模型仍然会回答。回答仍然很流畅。但关键证据可能已经在压缩时被删掉了。常见事故包括删掉了限制条件 删掉了例外条款 删掉了版本号 删掉了错误堆栈的第一处异常 删掉了代码里的类型约束 把多个来源摘要成了一个看似确定的结论。所以压缩策略要分级。场景压缩策略普通闲聊可以大胆摘要客服 FAQ保留关键政策原文合同审阅保留引用和条款编号代码修复保留结构和依赖关系医疗法律金融尽量保守允许找不到一句话压缩不是为了让模型少看而是为了让模型看见真正该看的。八、最终评价上下文工程会成为 AI 应用的基本功Prompt 工程解决的是“怎么问”。RAG 解决的是“从哪里找”。上下文工程解决的是“最终让模型看什么”。未来的 AI 应用尤其是 Agent不会只拼模型大小和上下文长度。真正拉开差距的会是会不会记录上下文 会不会裁剪噪音 会不会保留证据 会不会按任务选择信息 会不会在成本、延迟和质量之间做平衡。长上下文让 AI 能读更多东西。上下文压缩让 AI 少读废话。一句话总结AI Agent 的下一阶段不是无限扩上下文而是学会像一个靠谱的人一样做笔记、删噪音、留证据。九、一个可执行的上下文压缩实验如果要把这篇写成真正有操作价值的文章最好加一个小实验。实验目标同一个问题 同一批资料 比较不压缩、简单摘要、任务相关压缩三种上下文 观察 token、延迟和回答质量。可以选一个内部知识库场景。比如准备 8 段资料当前退款政策 旧版退款政策 企业版合同条款 个人版 FAQ 客服话术 销售培训材料 一次客户投诉记录 一份无关产品说明。然后问企业版客户购买 20 天后申请退款是否符合退款条件请引用依据。三种上下文策略策略做法预期问题不压缩8 段全部放入上下文token 高旧版本可能干扰简单摘要每段压成一句摘要关键条款可能丢失任务相关压缩保留企业版、退款、当前版本、引用原文成本低证据更集中评估时不要只看回答像不像还要看是否引用当前版本 是否区分企业版和个人版 是否提到购买天数 是否说明不确定条件 是否引用原文 输入 token 降了多少。这个实验的价值在于它能让读者直观看到上下文压缩不是把文字变短而是把证据变集中。十、上下文压缩的 4 层架构生产系统里不建议把压缩逻辑散落在各个 prompt 里。更清晰的方式是把它设计成 4 层。1. 输入清洗层处理明显无用内容空行 乱码 重复页眉页脚 PDF 转文本残留 HTML 标签 日志里的颜色控制符。这一层基本不需要模型规则就够。2. 相关性选择层根据当前任务筛选内容用户问退款就保留退款相关 用户问安装就保留安装相关 用户问报错就保留错误和相关配置。这一层可以用 embedding、关键词、reranker、规则混合。3. 结构压缩层不同数据用不同方式压缩JSON 保留关键字段 表格保留相关行列 日志保留错误摘要 对话保留状态 代码保留函数签名和调用关系。4. 证据保留层这是最后一道安全线。所有关键回答都应该能回到原始证据来源文件 段落位置 条款编号 日志行号 代码路径 版本时间。如果压缩后失去来源这个压缩策略在企业场景里就不可靠。十一、Agent 记忆应该分冷热Agent 的上下文不要只有“带上”和“丢掉”两种状态。更合理的是分冷热。记忆类型内容使用方式热上下文当前步骤必须用的信息每轮直接带入温上下文近期相关但不一定每轮用摘要后带入冷上下文历史材料、旧工具结果存储起来需要时检索原始证据文档、日志、代码原文按需展开比如一个代码 Agent 修复 bug热上下文失败测试、当前修改文件、关键报错 温上下文已尝试方案、当前假设 冷上下文完整搜索结果、历史日志 原始证据源文件和测试文件。这样 Agent 就不会每一步都背着完整历史跑。这也是长期 Agent 必须具备的能力它要能记住状态但不能把所有历史都塞进当前工作台。十二、判断压缩是否成功的指标压缩不是上线一个函数就结束。至少要看 6 个指标指标含义输入 token 降幅成本是否真的下降首 token 延迟用户是否更快看到响应答案准确率是否损害质量引用命中率是否还能找到证据拒答率不确定时是否能承认不知道返工率用户是否需要继续追问修正特别注意如果 token 降了 60%但用户追问次数增加 50%整体体验未必变好。上下文压缩的成功标准不是单次请求变短而是整条任务链路更稳、更便宜、更可控。