Agent 的上下文压缩：不是省 Token，而是给模型做注意力管理

灵感来源：本文受腾讯技术工程公众号文章《横向拆解Claude Code、Codex等六大Agent上下文压缩策略后，我们做了第 7 个》（作者 mervynyang，2026-06-08）的启发。原文横向拆解了 Claude Code、Codex CLI、OpenCode、Cline、Cursor、Amp、MemGPT/Letta 等上下文压缩方案，并介绍了 MUR AI 的四级水位线实践。本文不是复述原文，而是基于阅读后的工程理解，整理一套更通用的 Agent 上下文压缩设计思路。

先说结论

Agent 的上下文压缩，表面上是在省 token，实际上是在保护模型的注意力。

长上下文窗口让我们误以为“能塞进去”就等于“模型能稳定使用”。但真实的 Agent 工作流里，噪声增长得很快：工具输出、构建日志、搜索结果、重复解释、历史尝试、过期中间结论，都会和真正重要的用户目标混在一起。上下文越长，模型越容易把注意力花在错误位置。

所以压缩系统不应该被设计成“快爆了才救火”的兜底逻辑。它更像一套持续运行的内存管理器：哪些东西必须原样保留，哪些东西可以降级成摘要，哪些东西只需要留一个可回溯的指针，哪些东西应该从模型视野里移走。

第一代问题：等到爆仓才动手

最粗糙的做法通常是：上下文快满了，触发一次全量摘要，把前面的对话揉成一段文本，然后继续。

这个方案好实现，但问题也很明显。

首先，它是悬崖式的。系统平时什么都不做，直到模型已经被大量噪声拖慢、注意力已经开始漂移，才突然把历史压成摘要。其次，全量摘要很容易丢掉细节。变量名、错误栈、用户原话、文件路径、已经失败过的尝试，这些恰恰是 Agent 继续干活最需要的上下文。

更麻烦的是，它把不同信息当成了同一种东西。5000 行日志和用户贴的一段关键代码，在 token 数上可能差不多，但价值完全不同。前者可以截断，后者一旦压坏，任务目标就会变形。

这也是上下文压缩最核心的设计原则：不要只看长度，要看信息角色。

第二代共识：分层、渐进、保护近端

几个主流 Agent 的方案各不相同，但方向正在收敛。

Claude Code 倾向于把上下文管理拆成多段流水线，便宜的本地处理先做，真正需要模型参与的摘要放到最后。Codex CLI 更强调保护近期用户消息，把压缩看成一次工作交接。OpenCode 关注可恢复性，用隐藏和摘要组合保留回退空间。Cline 提供手动和自动两种压缩入口。Cursor 在压缩之外强调历史可搜索。Amp 更激进，认为长线程本身就是问题，倾向于通过 handoff 切换到新线程。MemGPT/Letta 则把上下文视作 RAM，把长期历史视作外部记忆，让 Agent 自己按需换入换出。

这些做法背后的共同点，比具体实现更重要：

1. 分层渐进：先截断、再替换、最后才摘要。
2. 成本递增：字符串处理、占位符替换、LLM 摘要不能混成一个动作。
3. 保护近端：最近几轮对话不能随便动，这是模型短期连贯性的来源。
4. 用户消息优先：用户的目标、约束、代码和纠错，是任务的根。
5. 增量摘要优于全量摘要：维护一份持续更新的状态，比反复重写全部历史更稳定。
6. 压缩边界要单调：同一段历史在不同轮次里不能一会儿是原文、一会儿是占位符，否则缓存和模型认知都会被扰乱。

我更喜欢的抽象：四级水位线

如果把 Agent 的上下文看成一块内存，水位线是很自然的抽象。

低水位时，不要优化。上下文还清爽，模型能处理，就别为了“显得高级”提前改写历史。

中水位时，做轻量整理。比如截短很老的工具输出，只保留命令、前几行、结果数量和完整日志位置。此时不调用 LLM，因为很多空间可以靠确定性规则释放。

高水位时，做更强的释压。老的工具结果可以变成占位符，旧的 assistant 解释可以裁短，重复的中间输出可以移出模型上下文。但用户纯文本、近端消息、关键工具结果仍然要保护。

临界水位时，才让 LLM 参与摘要。摘要也不应该每次重写全部历史，而是把“上次摘要 + 新增历史”合并成新的结构化状态。好的摘要至少要保留：当前目标、已完成事项、关键文件、未解决问题、用户偏好、重要错误和下一步动作。

这里的关键不是阈值具体设成 60%、80% 还是 95%，而是让压缩从“事故响应”变成“持续维护”。

云端 Agent 比本地 CLI 更难

本地 CLI 的上下文压缩，更多是在当前进程里解决“模型还能不能继续干活”。云端 Agent 还要面对几个额外问题。

第一，完整日志不能丢。工具输出可以不塞进上下文，但应该落盘，前端和审计系统能按需回取。模型看到的是截断版，系统保存的是完整版。

第二，压缩决策要跨轮一致。云端服务会重启，请求可能漂到另一个实例。如果第 8 轮把某个工具输出截成 A，第 21 轮又重新判断成 B，Prompt Cache 会失效，模型也会觉得同一段历史“变脸”。

第三，多用户隔离不能省。压缩状态、完整日志、SSE 通知、缓存 key，都必须绑定 userId 和 sessionId。上下文压错内容会让模型糊涂，压错用户则是安全事故。

第四，工具要分级。Skill、Task、用户问答、读取类工具、搜索类工具、构建日志，它们的信息密度不一样。统一阈值看似简单，实际是在把关键状态和噪声混在一起处理。

真正要守住的红线

压缩系统最大的失败，不是压得不够狠，而是压错了。

我会把这些内容列为任何级别都不能随意改写的红线：

1. 最近几轮对话。
2. 用户纯文本指令。
3. 明确标记为 protected 的片段。
4. 会话状态类工具输出。
5. 用户回答和交互式确认。
6. 当前任务的待办列表和下一步计划。

如果上下文已经满到连这些都保不住，那宁愿让系统显式失败，也不要用错误压缩制造一个“看起来还在继续、实际已经偏航”的 Agent。

可观测性也属于压缩系统

上下文压缩如果只在后台默默发生，调参会变成玄学。

一个可用的 Agent 平台，至少应该记录每轮压缩触发的水位、真实 token 使用量、截断了哪些 part、替换了哪些 part、是否调用摘要、预计节省多少 token、缓存命中了多少历史决策。

更进一步，可以把这些信息展示给用户或开发者：这一轮为什么压缩，压缩了什么，哪些内容仍可回取。这样上下文管理才从黑箱变成工程系统。

最后

Agent 工程正在从“会调用工具”进入“能长期工作”的阶段。长期工作不只需要更大的上下文窗口，还需要更好的上下文秩序。

上下文压缩的本质，不是把文本变短，而是把信号重新排布。让模型少看噪声，多看目标；少背历史，多读状态；少在旧输出里迷路，多沿着当前任务推进。

未来的 Agent 平台，可能都会有自己的上下文内存管理器。它不一定叫 compaction，也不一定显式暴露给用户，但它会决定一个 Agent 能否从“聊几轮还行”，走到“真正接住一整段复杂工作”。