Agent 的上下文压缩不是省 Token而是给模型做注意力管理灵感来源本文受腾讯技术工程公众号文章《横向拆解Claude Code、Codex等六大Agent上下文压缩策略后我们做了第 7 个》作者 mervynyang2026-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 自己按需换入换出。这些做法背后的共同点比具体实现更重要分层渐进先截断、再替换、最后才摘要。成本递增字符串处理、占位符替换、LLM 摘要不能混成一个动作。保护近端最近几轮对话不能随便动这是模型短期连贯性的来源。用户消息优先用户的目标、约束、代码和纠错是任务的根。增量摘要优于全量摘要维护一份持续更新的状态比反复重写全部历史更稳定。压缩边界要单调同一段历史在不同轮次里不能一会儿是原文、一会儿是占位符否则缓存和模型认知都会被扰乱。我更喜欢的抽象四级水位线如果把 Agent 的上下文看成一块内存水位线是很自然的抽象。低水位时不要优化。上下文还清爽模型能处理就别为了“显得高级”提前改写历史。中水位时做轻量整理。比如截短很老的工具输出只保留命令、前几行、结果数量和完整日志位置。此时不调用 LLM因为很多空间可以靠确定性规则释放。高水位时做更强的释压。老的工具结果可以变成占位符旧的 assistant 解释可以裁短重复的中间输出可以移出模型上下文。但用户纯文本、近端消息、关键工具结果仍然要保护。临界水位时才让 LLM 参与摘要。摘要也不应该每次重写全部历史而是把“上次摘要 新增历史”合并成新的结构化状态。好的摘要至少要保留当前目标、已完成事项、关键文件、未解决问题、用户偏好、重要错误和下一步动作。这里的关键不是阈值具体设成 60%、80% 还是 95%而是让压缩从“事故响应”变成“持续维护”。云端 Agent 比本地 CLI 更难本地 CLI 的上下文压缩更多是在当前进程里解决“模型还能不能继续干活”。云端 Agent 还要面对几个额外问题。第一完整日志不能丢。工具输出可以不塞进上下文但应该落盘前端和审计系统能按需回取。模型看到的是截断版系统保存的是完整版。第二压缩决策要跨轮一致。云端服务会重启请求可能漂到另一个实例。如果第 8 轮把某个工具输出截成 A第 21 轮又重新判断成 BPrompt Cache 会失效模型也会觉得同一段历史“变脸”。第三多用户隔离不能省。压缩状态、完整日志、SSE 通知、缓存 key都必须绑定 userId 和 sessionId。上下文压错内容会让模型糊涂压错用户则是安全事故。第四工具要分级。Skill、Task、用户问答、读取类工具、搜索类工具、构建日志它们的信息密度不一样。统一阈值看似简单实际是在把关键状态和噪声混在一起处理。真正要守住的红线压缩系统最大的失败不是压得不够狠而是压错了。我会把这些内容列为任何级别都不能随意改写的红线最近几轮对话。用户纯文本指令。明确标记为 protected 的片段。会话状态类工具输出。用户回答和交互式确认。当前任务的待办列表和下一步计划。如果上下文已经满到连这些都保不住那宁愿让系统显式失败也不要用错误压缩制造一个“看起来还在继续、实际已经偏航”的 Agent。可观测性也属于压缩系统上下文压缩如果只在后台默默发生调参会变成玄学。一个可用的 Agent 平台至少应该记录每轮压缩触发的水位、真实 token 使用量、截断了哪些 part、替换了哪些 part、是否调用摘要、预计节省多少 token、缓存命中了多少历史决策。更进一步可以把这些信息展示给用户或开发者这一轮为什么压缩压缩了什么哪些内容仍可回取。这样上下文管理才从黑箱变成工程系统。最后Agent 工程正在从“会调用工具”进入“能长期工作”的阶段。长期工作不只需要更大的上下文窗口还需要更好的上下文秩序。上下文压缩的本质不是把文本变短而是把信号重新排布。让模型少看噪声多看目标少背历史多读状态少在旧输出里迷路多沿着当前任务推进。未来的 Agent 平台可能都会有自己的上下文内存管理器。它不一定叫 compaction也不一定显式暴露给用户但它会决定一个 Agent 能否从“聊几轮还行”走到“真正接住一整段复杂工作”。