有个粉丝找我复盘一个大公司的agent三面他说前面聊得都挺顺结果面试官冷不丁问了一句你的Agent上下文爆了咋办他想了半天说那……换一个窗口更大的模型面试官没有否定他笑了笑换了个角度问窗口再大Token是按量计费的延迟也是跟着长度涨的那你的账单和响应时间怎么办他说自己当时心里咯噔了一下好像有点道理但又说不出所以然。面试官接着问那用户在第一轮说过的硬约束跑到第十五轮你还记得吗他想了想说应该记在提示里。面试官点点头又追问那对话中间产生的大量工具调用痕迹呢这些也要常驻吗他犹豫了一下说或者……把它们删掉面试官最后没有给答案只留了一句话你回去想想长窗口解决的是什么问题压缩解决的又是什么问题这两件事是不是一回事。他回来复盘的时候跟我说自己以前一直觉得窗口越大越好从来没把装得下和用得起当成两个问题看。这时候值得问自己一句你在解决的是装得下的问题还是用得起、用得好的问题今天就把这几种上下文压缩的招数说清楚。Agent的记忆不是死记硬背能陪你聊上几个小时、边查资料边写代码的 AI 智能体它靠的其实不是什么玄学。它靠的是一套跟人脑记忆机制颇为相似的取舍系统。它不是把所有对话原封不动地背下来。它是不断地去判断什么该留下来什么该进行压缩什么可以直接扔掉。今天就顺着这条线把这套自动压缩的逻辑给拆开来看一看。顺便再多补几个实打实的例子。先厘清概念上下文就是Agent的工作记录本先来把一个概念给厘清一下Agent 的上下文差不多就等于它随身带着的一本工作记录本。这本本子会越写越厚。原因大致上有三处。一是你来我往的对话历史。二是工具调用留下来的痕迹——去搜索、去读文件、去跑代码请求和返回的结果都得给记下来。三是 Agent 自己嘀咕出来的规划与反思草稿这些虽然是自言自语但是照样占地方。举个具体的场景来说你让一个编程 Agent 帮你去重构一个有几十个文件的代码库。它每读一个文件每跑一次测试日志都往上下文里堆。开发者社区里就有真实的反馈说这类长会话跑到后期上下文的占用能轻松冲到 100% 以上。这就逼得系统必须去做点什么了。不压缩会怎样那不去压缩会怎么样呢先看成本。每次请求都要把整本记录喂给模型Token 的账单就跟着水涨船高了。再看速度。记录越厚处理起来就越慢。更麻烦的是效果会打折扣。这就是学界所说的Lost in the Middle现象。斯坦福团队在 2023 年有一篇论文专门验证过这个事。当关键信息被埋在长文本的中段时模型的准确率会明显地往下滑。反而是开头和结尾的内容更容易被它抓住。最后一条是硬伤。一旦超出了上下文窗口的物理上限就直接报错了。比如有开发者反馈过会话跑到十几万 Token 的时候系统提示输入长度加最大生成长度超过了 20 万上限直接就卡死了。长窗口解决装得下压缩解决用得起、用得好可能有人会说现在动不动就是百万 Token 的长窗口模型不是已经够用了吗——这其实就是那位粉丝在面试现场给出的第一反应。不少大模型确实都把窗口做得很大这个话没错。但这里面其实藏着一个容易被搞混的区别。长窗口解决的是装得下的问题。压缩解决的是用得起、用得好的问题。面试官真正想听的就是这个区别。窗口再大Token 依旧是要按量计费的。推理延迟依旧会随着长度线性增长。中段信息被稀释的风险也不会因为窗口变大了就自动消失。所以在长会话、高频调用、成本敏感的生产场景里压缩仍然是绕不开的基本功。从粗暴到精细五种上下文压缩思路具体怎么去压呢不妨换个角度来看按照从粗暴到精细的顺序梳理一遍。每一种方法的背后都对应着一种取舍的哲学。也各配一个具体的例子。‣ 滑动窗口只留最近几轮最简单也最容易翻车最简单的思路是滑动窗口。就是只保留最近若干轮的对话更早的内容一律给丢掉。比如客服 Agent 只记住最近 10 轮的问答。用户在第 1 轮说过我对海鲜过敏别推荐相关的餐厅。到了第 15 轮再问帮我订个餐厅这条禁忌早被滑出窗口了。Agent 大概率就会踩雷给你推荐海鲜馆。这就是滑动窗口最典型的翻车场景。‣ Token预算裁剪按量计费更贴近现实但本质还是一刀切比滑动窗口稍微聪明一点的是按照 Token 的总量来设预算而不是按轮次去计数。超出了上限就裁掉最旧的部分。这样更贴近模型实际的计费逻辑。但本质上依然是一种一刀切式的遗忘。语义丢失的问题它没有解决。‣ 摘要压缩让模型自己浓缩但摘要不是无损操作真正开始动脑子的是摘要压缩。就是让 Agent 去调用一次模型把久远的对话浓缩成一段结构化的摘要。Anthropic 官方给过一个很具体的案例。在一个批量处理客服工单的 Agent 流程里设定 5000 个 Token 的触发阈值。处理完几张工单之后就自动压缩一次。压缩的时候保留工单已解决、分类结果、处理结论这些要点。而把完整的知识库文章原文、详细的分类过程、草拟出来的回复长文这些占地方但已经用完的中间产物直接给丢掉。然后再干干净净地去处理下一批工单。Claude Code 自己的 auto-compact 机制也是同一套逻辑。默认在上下文用量逼近某个阈值的时候早期版本大约是 8 万到 10 万 Token 的量级触发自动生成一份摘要。这份摘要里包含当前进度、关键决策、未完成的事项。然后拿这份摘要去顶替掉旧消息接着往下跑。官方文档形容这个过程是无感衔接。不过这条流水线也不是绝对稳的。GitHub 上确实有开发者反馈过压缩阈值配置不生效或者压缩本身因为超限而失败进而把会话卡死了。这恰好印证了前面说的那个点——摘要压缩不是无损操作。工程实现上还有不少坑要去填。这种方式的代价是要额外烧一次算力去生成摘要。而且摘要本身也可能会出现偏差或者漏掉一些细节。相当于用信息压缩率去换信息保真度。‣ 向量检索式记忆给Agent接一块外置硬盘再往前走一步是向量检索式的记忆。相当于给 Agent 接了一块外置硬盘。所有历史对话先做向量化存进数据库里。当前的问题来了之后不是把全本翻一遍而是去做一次语义检索把最相关的那几条记忆捞出来拼进上下文里。举个例子来说。一个长期陪伴型的健康助手用户在三个月前提过一句我有乳糖不耐受。三个月之后问晚饭吃点什么好。向量检索会直接把那条旧记忆给召回插到当前的上下文里。而不需要把三个月的所有对话都给塞进去。这条路径目前的生态已经相当成熟了。Pinecone 的定位是纯向量基础设施负责高性能的检索本身。而 Mem0、Zep 这类框架则更进一步直接把记忆的提取、去重、更新都给自动化了。本质上是Pinecone 负责存、Mem0/Zep 负责管这样一个分工组合。这跟前面滑动窗口和摘要那种自己维护一本记录本的思路已经不是一个量级了。‣ 语义压缩用小模型给提示词瘦身还有一种更硬核的瘦身方式。是在提示词送进大模型之前先用一个小模型对它做语义压缩删掉冗余的表达和低信息量的词汇。微软联合清华做的 LLMLingua 系列是这个方向的代表。论文给出的实测数据是这样的在 ShareGPT 对话数据集上4 倍压缩比的时候BLEU、ROUGE 这些指标基本能维持住原有的水平。整体最高可以做到 20 倍的压缩比而且性能损失很小。升级版的 LLMLingua-2 更是把文本长度压到了原来的 20% 左右。处理速度还比前一代快出 3 到 6 倍。这种方法特别适合处理那种夹杂大量检索结果、格式又啰嗦的 RAG 提示词。‣ 上下文外部化拿磁盘空间换上下文空间最后一种思路干脆不在上下文里较劲了。直接把内容给外部化。写成文件、存进数据库或者同步到云笔记。需要的时候再去按需读取特定的片段。本质上就是拿磁盘空间去换上下文空间。Amp这个 Agent 工具的做法就很典型。它提供一个Handoff功能让 Agent 把当前任务的关键信息提炼出来写进一条新消息然后开一个全新的线程接着跑。还有一个Fork功能可以在某个节点复制一份上下文的分支出去处理支线任务用完再合并回来。本质上都是把记忆管理这件事从模型内部搬到了工程层面去显式操作。这套设计思路早在 2023 年就有一篇很有意思的论文把它系统化过了。加州大学伯克利的团队提出的 MemGPT把 LLM 的上下文窗口类比成操作系统的物理内存。主上下文对应内存外部存档对应磁盘。Agent 通过显式的读写工具在这两层之间去搬运数据。比如论文里设计的 archival_memory_insert 和 archival_memory_search 这两个工具就是让 Agent 自己去决定什么时候把信息存盘什么时候再把它捞回来。这个项目后来演化成了开源框架 Letta。和 Mem0、Zep 一起构成了目前 Agent 记忆赛道里比较有代表性的几条技术路线。Letta偏向操作系统式的分层架构适合自托管、要求记忆逻辑可控的场景。Mem0更强调自动化的记忆提取与去重流水线接入成本低。Zep则主打时间感知和知识图谱式的记忆擅长处理那种需要多跳推理和因果追踪的复杂任务。三者各有各的侧重并不是简单的替代关系。真实落地组合拳才是常态实际落地的时候很少有团队只用一招。更常见的是打组合拳。滑动窗口保证最近对话的新鲜感。摘要兜住长期的方向感。向量检索负责精准地召回旧的细节。超长的文档直接外部化落盘。比如阿里这类电商平台的客服系统真实配置可能是这个样子的。最近 5 轮的对话原样保留。用户的会员等级、过敏禁忌这类硬信息常驻在系统提示里不参与压缩——这就是面试里那个第十五轮还记不记得问题的标准答案之一。超过 5000 Token就触发一次摘要。涉及到的商品详情页、物流长文档则走向量检索按需去调取。四种手段各司其职缺了哪一个都不行。每轮对话结束之后系统会去估算当前的 Token 用量。没超预算就先放着。一旦触顶了就按照预设的策略自动整理出一份精简之后的工作记忆。这个过程对用户来说几乎是无感的。压缩不是免费午餐风险与务实应对不过这里要泼一盆冷水。压缩从来都不是免费的午餐。压得太狠会丢掉关键信息造成记忆断片。压得太轻成本和延迟又降不下来等于白忙一场。而且这里有一个还没有被充分讨论的矛盾点。用来做摘要或压缩的那个小模型它自己也可能理解偏差误判什么信息是重要的。这就相当于把风险从上下文过长转移到了压缩环节的可靠性上。前面提到的 Claude Code 压缩阈值配置失灵、压缩过程本身报错卡死会话就是这类风险在实际产品里的真实体现。目前更多还是靠人工设定硬性规则来兜底而不是完全交给自动化。有几个相对务实的应对办法可以参考。给上下文设一个硬性的 Token 预算触顶了才去压缩不要没事就压。把用户一开始提出的硬约束单独抽出来常驻在系统提示层不参与任何压缩的流程。关键的结论第一时间外部化落盘不要只寄希望于流动的对话记忆。长文档优先去走检索或提示词压缩而不是简单粗暴地做摘要。压缩完成之后最好抽查一下关键的数字和专有名词看看有没有被误删。总结说到底上下文窗口不是越大就越值钱。面试官那句除了换长窗口还想过别的办法吗问的其实不是窗口大小而是你有没有把记忆管理当成一个独立的工程问题来对待。能不能判断什么该记住、什么该压缩、什么可以彻底忘掉这才是衡量一个 Agent 是不是真正好用的分水岭。我个人的判断是这样的。短期内长上下文模型和记忆压缩系统会长期并存而不是相互替代。前者负责兜底极端场景。后者负责把日常高频调用的成本和体验做到最优。谁先把压缩后的可靠性这道题给解好谁就更接近真正能长期陪伴用户的那个 Agent。资料展示下面是我整理的AI大模型 学习资料和工具包预览适合收藏后按主题逐步学习