Agent上下文管理实战：5种压缩策略、3类记忆形态与4条选型红线

1. 为什么上下文管理成了Agent落地的第一道坎

做过Agent项目的人都有一个共同体会：模型能力本身往往不是瓶颈，真正让人头疼的是上下文窗口的消耗速度。一个稍微复杂点的任务，工具调用返回的JSON、历史对话、系统提示词、检索到的文档片段，几轮下来就能把窗口塞满。更麻烦的是，塞满之后模型的表现会明显下降——不是简单地"记不住"，而是注意力被稀释，关键信息淹没在大量冗余内容里。

这个项目标题涉及的核心问题就是：当Agent的上下文快要撑爆时，我们到底该怎么压缩、怎么记忆、怎么选型。标题里提到的"5种压缩、3类记忆形态及4条选型红线"，加上MemGPT、ACON与Context Editing这几个代表性方案，基本覆盖了当前上下文工程的主要技术路线。

这篇文章适合正在做Agent应用开发、遇到过上下文溢出问题、或者正在纠结记忆方案选型的工程师。我会从实际项目经验出发，把每种压缩策略的适用场景、每类记忆形态的工程实现、以及选型时容易踩的坑讲清楚。不会停留在概念层面，而是给出可以直接参考的参数、代码结构和判断依据。

先说一个基本认知：上下文压缩和记忆策略不是两个独立的问题，它们是一体两面的。压缩解决的是"当前窗口内怎么塞下更多有效信息"，记忆解决的是"窗口外的信息怎么在需要时被召回"。两者配合不好，要么压缩得太狠导致信息丢失，要么记忆召回不准导致答非所问。

2. 五种上下文压缩策略的深度拆解

2.1 滑动窗口压缩：最简单也最容易翻车

滑动窗口是最直观的压缩方式——保留最近N轮对话，丢弃更早的内容。实现上通常维护一个固定长度的消息队列，新消息入队时旧消息出队。

听起来很简单，但实际操作中有几个关键参数需要仔细调：

• 窗口大小：不是越大越好。我试过在同一个任务上分别用8轮、16轮、32轮窗口，结果16轮的综合表现最好。8轮丢信息太多，32轮则因为历史噪声干扰导致模型注意力分散。
• 保留锚点：系统提示词和第一条用户指令通常需要永久保留，不能参与滑动。否则多轮之后模型会"忘记"自己的角色设定。
• 边界处理：当一条工具调用消息被截断时，对应的返回结果也要一起处理，否则会出现"调用了但没结果"的悬空状态。

注意：滑动窗口最大的坑是"看似省了token，实则丢了关键约束"。比如用户在第三轮提到的"不要用某格式输出"，到第十轮就被滑走了，模型又开始用那个格式。

2.2 摘要压缩：用一次模型调用换长期记忆

摘要压缩的思路是：当上下文达到阈值时，调用模型对早期对话生成摘要，用摘要替换原始消息。这样既保留了核心信息，又大幅减少了token占用。

工程实现上，我通常这样设计：

def compress_with_summary(messages, threshold=3000, keep_recent=6): if count_tokens(messages) < threshold: return messages old_messages = messages[:-keep_recent] recent_messages = messages[-keep_recent:] summary_prompt = "请将以下对话压缩为要点摘要，保留所有约束条件、已确认的事实和未完成的任务：" summary = call_llm(summary_prompt + format_messages(old_messages)) return [{"role": "system", "content": f"[历史摘要] {summary}"}] + recent_messages

关键参数是keep_recent——最近几轮不参与摘要。这个值太小会导致摘要频繁触发，太大则压缩效果不明显。根据我的经验，6到10轮是个比较稳的区间。

摘要压缩的核心难点在于摘要质量的稳定性。模型生成的摘要可能遗漏关键约束，也可能把不确定的信息写成确定的事实。我的做法是在摘要提示词里强制要求"逐条列出所有约束条件和未完成任务"，并且对摘要结果做一次校验——检查是否包含原始对话中的否定词和数字。

2.3 结构化提取压缩：把对话变成状态机

这是我认为最被低估的一种压缩方式。它的核心思想是：不保留对话原文，而是把对话中产生的关键信息提取成结构化字段。

比如一个订票Agent，经过几轮对话后，不需要保留"用户说想周五走""用户说预算不超过两千""用户说最好直飞"这些原始消息，而是维护一个状态对象：

{ "departure_day": "Friday", "budget_max": 2000, "prefer_direct": true, "confirmed": false }

这种压缩方式的token效率极高，而且状态清晰可控。但它有一个前提：任务领域必须是可结构化的。对于开放式对话或创意类任务，强行结构化反而会丢失大量语义信息。

我在一个客服Agent项目里用过这种方式，把用户意图、订单号、问题类型、已尝试的解决方案提取成JSON状态，上下文占用从平均4000token降到了800token左右，而且模型的表现更稳定了——因为它不需要从一堆对话里"猜"当前状态。

2.4 检索式压缩：只放相关的，不放全部的

检索式压缩的思路是：不把所有历史都塞进上下文，而是把历史存到外部存储，每轮根据当前查询检索最相关的片段注入上下文。

这其实就是RAG的思路用在对话历史上。实现上需要注意：

• 检索粒度：按轮次检索还是按片段检索？我倾向于按语义片段检索，因为一轮对话可能包含多个独立信息点。
• 检索数量：通常top-3到top-5就够了，太多会引入噪声。
• 时效性加权：越近的对话权重越高，可以在相似度分数上乘以一个时间衰减因子。

这种方式的优势是上下文利用率高，缺点是检索本身有延迟，而且检索不准时会直接导致信息缺失。适合历史很长但每轮只需要少量相关信息的场景。

2.5 分层压缩：不同信息用不同策略

实际项目里，我很少只用一种压缩方式，而是分层处理：

分层压缩的核心原则是：越关键、越稳定的信息，压缩越轻；越冗余、越时效性的信息，压缩越重。这样既保证了关键约束不丢失，又最大化了窗口利用率。

3. 三类记忆形态的工程实现

3.1 短期记忆：窗口内的精细管理

短期记忆就是当前上下文窗口内的信息。很多人觉得短期记忆不需要特别设计，反正就在窗口里。但实际上，短期记忆的组织方式直接影响模型的表现。

我的经验是，短期记忆需要做到"三清"：

• 角色清：每条消息的角色明确，system、user、assistant、tool不混用。
• 时序清：消息顺序严格按时间排列，工具调用和返回紧挨着。
• 边界清：不同任务阶段的消息用分隔标记隔开，比如[阶段：信息收集]、[阶段：方案确认]。

另外，短期记忆里要避免"僵尸消息"——那些已经处理完、不再有信息量的消息。比如工具返回了一个大JSON，但其中只有两个字段有用，那这个JSON就不该完整留在窗口里，应该提取关键字段后替换。

3.2 长期记忆：跨会话的信息持久化

长期记忆解决的是"这次聊完，下次还记得"的问题。实现上通常有三种路线：

路线一：向量库存储。把重要信息embedding后存入向量库，下次对话时检索。优点是实现简单，缺点是检索精度依赖embedding质量，而且无法处理结构化查询。

路线二：结构化数据库。把用户偏好、历史事实存成结构化记录。优点是查询精确，缺点是需要预先定义schema，灵活性差。

路线三：混合存储。结构化字段用数据库，非结构化内容用向量库，检索时两路合并。这是我在生产环境里用得最多的方案。

长期记忆的关键设计点是写入时机。不是每轮对话都写，而是在检测到"值得记住的信息"时才写。我的做法是设置一个轻量级的判断逻辑：包含用户偏好、明确事实、重要决策的消息才触发写入。

3.3 工作记忆：任务执行中的临时状态

工作记忆是介于短期和长期之间的一层，专门用于当前任务的执行状态。比如一个多步推理任务，工作记忆里存的是"当前进行到第几步""哪些子任务已完成""哪些中间结果需要保留"。

这一层最容易被忽略，但它对复杂任务的成功率影响很大。我在一个多步数据分析Agent里加了工作记忆层之后，任务完成率从62%提升到了81%。原因很简单：模型不需要每步都从对话历史里重新推断"我做到哪了"，直接从工作记忆里读就行。

工作记忆的实现通常是一个任务级的JSON对象，随任务创建而创建，随任务结束而销毁。它不跨会话，也不长期保留，但在任务执行期间每轮都会注入上下文。

4. 四条选型红线：什么情况下绝对不能选某种方案

4.1 红线一：任务有硬约束时，不能用纯摘要压缩

如果任务中存在必须严格遵守的约束条件（比如"输出必须是合法JSON""金额不能超过预算"），纯摘要压缩是危险的。因为摘要是有损的，模型可能在摘要时把"不能超过"写成"大约"，把"必须"写成"建议"。

这种情况下，约束条件必须走结构化提取，单独维护，不参与摘要。

4.2 红线二：延迟敏感场景，不能用检索式压缩

检索式压缩每轮都需要做一次向量检索，这会增加几百毫秒的延迟。对于实时对话场景，这个延迟可能不可接受。如果延迟预算紧张，优先考虑滑动窗口加结构化提取的组合。

4.3 红线三：信息密度低的对话，不值得上复杂压缩

有些对话本身就是短平快的，比如简单的问答。这种场景下，上下文根本不会溢出，上复杂的压缩策略反而是过度工程。判断标准很简单：如果平均对话轮次少于10轮，且每轮token少于200，直接用滑动窗口就够了。

4.4 红线四：没有评估体系时，不要同时上多种压缩

多种压缩策略叠加时，效果不是简单相加，而是可能相互干扰。比如摘要压缩和检索压缩同时用，可能出现"摘要里有的信息检索又召回一遍"的冗余。如果没有完善的评估体系来衡量每种策略的贡献，很容易越调越乱。

我的建议是：先用一种策略，建立评估基线，再逐步叠加，每次只改一个变量。

5. MemGPT、ACON与Context Editing的路线对比

5.1 MemGPT：把上下文管理做成操作系统

MemGPT的核心思路是把LLM的上下文窗口当作"内存"，把外部存储当作"硬盘"，通过函数调用实现类似操作系统的分页机制。模型可以主动决定"把什么写入长期存储""从长期存储读什么回来"。

这个方案的优势是通用性强，不依赖特定任务结构。缺点是模型需要学会使用这套机制，对提示词工程要求高，而且每次读写都是一次额外的模型调用，成本和延迟都会增加。

适合场景：开放式对话、个人助手类应用，任务边界不清晰但需要长期记忆。

5.2 ACON：面向压缩的主动管理

ACON的思路更聚焦在压缩本身，它强调"主动压缩"——不是等上下文满了才压缩，而是在合适的时机主动触发压缩，并且对压缩过程做精细控制。

相比MemGPT，ACON更轻量，不需要模型学会一套复杂的调用协议。它更像是一个中间件，在消息进出时做处理。

适合场景：任务结构相对清晰、对压缩质量要求高的应用。

5.3 Context Editing：精细化的上下文编辑

Context Editing的思路是提供一套编辑原语，让开发者可以精确控制上下文的每一部分——哪些保留、哪些删除、哪些替换、哪些合并。它不预设压缩策略，而是提供工具。

这个方案灵活性最高，但也最依赖开发者的判断。用得好效果很好，用不好就是一堆手动规则。

适合场景：有明确上下文管理需求、且团队有足够工程能力做精细化控制的场景。

5.4 三条路线的选型对照

6. 实操中的常见问题与排查技巧

6.1 压缩后模型"失忆"怎么办

这是最常见的问题。排查顺序是：

1. 检查压缩是否丢失了系统提示词中的关键约束。
2. 检查摘要是否把否定句写成了肯定句。
3. 检查结构化提取是否遗漏了字段。
4. 检查检索召回是否命中了正确的片段。

我的经验是，80%的"失忆"问题出在摘要环节。解决办法是在摘要提示词里加一条："必须原样保留所有否定词和数字"。

6.2 压缩触发太频繁导致成本上升

压缩本身是要调用模型的，如果触发太频繁，成本可能比不压缩还高。调整方向：

• 提高触发阈值，不要一超就压。
• 增大keep_recent，减少参与压缩的消息量。
• 对短消息不做压缩，只对长消息做。

6.3 多轮之后上下文又满了

这说明压缩策略的"回收效率"不够。检查两点：一是压缩后的内容是否还在持续增长（比如摘要越写越长），二是是否有新的信息在持续注入但没有被压缩覆盖。解决办法是给摘要设置长度上限，并且定期对摘要本身做二次压缩。

6.4 工具调用结果太大怎么处理

工具返回的大JSON是上下文杀手。我的做法是在工具层就做截断和提取，只返回必要字段。如果工具层改不了，就在消息入上下文前加一个预处理步骤，提取关键字段后替换原始结果。

提示：永远不要让原始的工具返回直接进上下文，一定要过一层处理。

7. 我在实际项目中的组合方案

经过几个项目的迭代，我目前比较稳定的组合是：滑动窗口 + 结构化提取 + 摘要压缩 + 检索式长期记忆。

具体配置是：最近8轮走滑动窗口，任务约束走结构化状态对象，8轮以前的对话走摘要压缩，跨会话信息走向量库检索。工作记忆单独维护一个任务状态JSON。

这套组合在客服Agent和多步分析Agent上都跑得比较稳，上下文占用控制在窗口的60%以内，任务完成率比纯滑动窗口方案提升了约20个百分点。

最后分享一个小技巧：在系统提示词里加一句"当前上下文使用率约为X%"，让模型自己知道还剩多少空间，它在决定是否调用工具、是否展开细节时会更有分寸。这个改动很小，但实测有效。