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

えいみや

334人浏览 · 2026-06-17 17:10:09

えいみや · 2026-06-17 17:10:09 发布

写在前面：从“能塞多少”到“该留下什么”

过去两年，大模型有一个很明显的军备竞赛：

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 延迟	用户是否更快看到响应
答案准确率	是否损害质量
引用命中率	是否还能找到证据
拒答率	不确定时是否能承认不知道
返工率	用户是否需要继续追问修正