Agent上下文爆了怎么办？五种压缩思路与记忆管理实战

上周帮一位粉丝复盘某大厂的 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。对这类 Agent 记忆与工程实践感兴趣的话，云栈社区也有不少同路人在讨论，值得翻一翻。