Coding Agent 里的上下文 Compact,到底在压缩什么

如果你用过 Claude Code、Cursor 或者别的AI编程助手,大概都遇到过这种情况,聊着聊着突然弹出一条提示,说要压缩对话历史 了。紧接着,Agent好像变得有点"失忆",之前讨论过的某个变量名、某条报错信息,说没就没了。这背后的机制,就是本文要聊的上下文 compact(有时也叫上下文压缩、上下文紧凑化)。

这事儿听起来技术,但道理并不复杂,说白了就是Agent的工作记忆快装不下了,得想办法腾地方。问题在于,怎么腾地方才能既省了空间,又不丢关键信息,这里面藏着不少门道,也是眼下Agent工程领域最活跃的战场之一。


🧠 为什么Agent会缺"内存"

要理解compact,得先明白LLM的上下文窗口是怎么回事。你可以把它想象成Agent的短时记忆容量,无论是200K还是400K token,都是有硬上限的。而Coding Agent这类应用特别费token,原因很直接,读一个文件、跑一条命令、看一段报错,全都要塞进上下文里。

Anthropic的工程团队讲过一个很形象的说法,叫注意力预算 (attention budget)。Transformer架构的核心机制是让每个token都能"看到"其他所有token,这意味着n个token之间要处理 O(n2)O(n^2) O(n2)级别的关联关系。上下文越长,模型的注意力就被拉得越薄,检索准确率反而下降,这个现象业内叫context rot,直译就是"上下文腐烂"。换句话说,硬塞更多信息进去,不一定管用,甚至可能起反作用。

于是矛盾就出来了,Agent执行的任务越复杂、越长时间运行,产生的中间数据就越多,可上下文窗口就那么大,装不下所有历史。Compact,正是解决这个矛盾的关键一环。


🔍 Compact涉及的核心概念

聊清楚compact,绕不开三个容易被混着用的词,压缩(compression)摘要(summarization)紧凑化(compaction)。这三者机制完全不同,行业内其实还没统一叫法,Anthropic习惯把服务端摘要API也称作compaction,但严格意义上讲,它们的差别相当本质。

方式 机制 幻觉风险 可读性 代表场景
摘要(Summarization) LLM重新生成一段总结文字 中到高 是,但已改写 Claude Code的/compact命令
压缩(Compression) 编码为不透明格式 未知 部分厂商专有方案
紧凑化(Compaction,严格定义) 删除低价值token,保留内容原样 几乎为零 是,完全保留 Morph Compact等产品

这张表其实揭示了compact的核心矛盾 ,摘要能大幅压缩篇幅(能到70-90%),但代价是内容被改写 了,报错信息、文件路径这些需要精确匹配的细节容易走样。而严格意义的紧凑化坚持逐字保留 ,删就删干净,留就原样留,不会把src/api/webhooks/stripe.ts:98这样精确的路径,改写成"处理Stripe的那个文件"这种模糊说法。

对写代码的Agent来说,这个区别致命,因为它经常需要精确匹配错误字符串来做grep检索,或者原样引用某一行代码去做修改。一旦这些细节被"意译"了,Agent的后续操作基本等于抓瞎。

再往下细分,业内实践中常见的compact手法大致分这几类:

  1. 只保留文件最新版本,同一个文件被反复读取、编辑,历史版本全部丢弃,只留最后一次
  2. 裁剪终端输出 ,一次npm run build可能刷几千行日志,绝大部分是噪音,只保留开头结尾,中间砍掉
  3. 压缩工具调用结果,把原始JSON换成一句话总结,比如把大段监控日志换成*"8月25日错误率飙升"*这一句话
  4. 保护关键片段,通过完整性校验,确保系统提示词(system prompt)这种定义Agent身份和能力的核心内容不被意外裁掉

用一张流程图大概能看出compact在整个会话生命周期里的位置。

flowchart TD A[对话持续进行] --> B{Token总量接近上限?} B -- 否 --> A B -- 是 --> C[触发Compact] C --> D[评估内容,区分高价值/低价值token] D --> E1[摘要方式,LLM重写为总结] D --> E2[紧凑化方式,直接删除低信号内容] E1 --> F[生成新的精简上下文] E2 --> F F --> G[对话继续,原始细节部分丢失]

🚀 最新的发展方向

这块领域这一年多进展很快,几条主线值得拎出来说说。

自动化触发,而非用户手动操作

早期的compact更多是用户手动敲/compact命令触发,现在主流Agent(比如Claude Code)已经做到自动检测接近上限时触发,用户几乎无感。Zed这类IDE集成的Agent面板,也是从最初的手动命令一步步演进到自动化管理。

服务端专业化API出现

一个挺有意思的趋势是,compact本身正在变成一种独立的付费服务。Morph推出的"Compact API"就是个典型例子,主打逐字保真,官方给出的数据是压缩率50-70%,处理速度33000+ token/秒,号称零幻觉风险。这说明compact已经不只是Agent内部一个隐藏步骤,而是能拆出来单独优化、单独卖钱的技术模块了。

自适应压缩框架(ACON等)

比单纯"删或者不删"更进一步的思路,是让系统根据当前任务动态判断哪些内容该保留、该压到什么程度,而不是用一刀切的规则。这类自适应压缩框架正在成为学术界和工业界共同关注的方向。

"context engineering"逐渐取代粗暴compact

这可能是最重要的一个转向。行业里逐渐形成一种共识,单纯依赖对话摘要的compact是治标不治本 的方案,真正稳定的长会话Agent,靠的是更系统的上下文工程(context engineering),涉及主动的信息筛选和结构化管理,而不是被动地等token超限了再仓促总结 。

一个很聪明的补充机制叫Pinning (钉住),思路是让用户能主动标记某条消息"无论怎么压缩都不能删",给compact流程加一道人工把关的安全阀。另外还有TODO清单复位的做法,Agent会周期性地把当前任务计划重新插入上下文,靠反复提醒来对抗长会话里注意力涣散的问题。这些手法都不是取代compact,而是想办法削弱它带来的副作用。


⚠️ Compact造成的信息损失,具体丢了啥

聊到这儿,得正面回答这个问题,compact省了空间,但代价也不含糊。

精确字符串失真 。报错信息Error: ECONNREFUSED 127.0.0.1:5432一旦被摘要成"数据库连接出错",Agent就再也没法拿这条报错去做grep匹配,也没法把它原样写进修复提交说明里。这种损失在调试场景里特别致命。

文件路径被意译 。同理,src/api/webhooks/stripe.ts:98这种精确定位信息,摘要式compact很容易把它模糊成"处理支付的那个文件",Agent之后想精准跳转到那一行,基本没戏。

系统提示词意外丢失 。更麻烦的是,有些环境里系统提示词并不是被"保护"起来的特殊内容,而是被当成普通消息处理。一旦触发裁剪,连Agent的身份设定、工具权限说明都可能被误删,直接导致行为失常,业内管这个现象叫context collapse(上下文崩溃)。

技能描述不会随压缩恢复 。Claude Code的文档里提了个具体细节,启动时加载的技能(skill)简要说明,在触发/compact之后并不会自动重新注入,只有Agent实际调用过的技能才会被保留下来。这算是个挺隐蔽的坑,用户完全感知不到。

长期漂移 。最容易被忽视的损失其实是渐进式 的,不是一次compact就出大问题,而是历经多轮压缩之后,Agent对早期约定的细节记忆越来越模糊,任务执行逐渐偏离最初的设计意图,这种现象在业内被称为任务漂移(drift)。

用一个类比来说可能更直观,compact有点像人在做会议摘要,摘要能帮你快速抓住大概方向,但具体某人某句话的措辞、某个数字的小数点位置,一旦省略,后面想精确回溯就麻烦了。对写代码这种极度依赖精确匹配的场景来说,这种"细节损耗"格外扎心。


💡 写在最后

Compact这个技术点,表面上是个工程细节,背后其实映照出整个Agent领域正在经历的转变,从怎么让模型说话更聪明 ,转向怎么让模型在长时间任务里保持清醒。摘要式compact解决了"装不下"的问题,却制造了"记不准"的新问题,而像Morph那样坚持逐字保真的紧凑化方案,以及Pinning、TODO复位这类context engineering手法,本质上都是在补这个窟窿。

未来这个方向大概会继续往两条线走,一条是让压缩本身更智能、更懂得判断什么该留什么该扔,另一条是从源头减少不必要的上下文膨胀,让Agent压根不需要那么频繁地compact。毕竟,最好的内存管理,永远是不需要临时抱佛脚地去清理内存。


参考资料

Zed Industries. Support /compact to summarize conversation history . GitHub Discussions. github.com/zed-industr...

Kargar, Isaac. The Fundamentals of Context Management and Compaction in LLMs . Medium, Feb 2026. kargarisaac.medium.com/the-fundame...

Morph. Context Compaction: Delete Noise, Keep Signal --- Technical Guide . March 2026. www.morphllm.com/context-com...

Anthropic. Explore the context window . Claude Code Docs. code.claude.com/docs/en/con...

Anthropic Engineering. Effective context engineering for AI agents . Sep 2025. www.anthropic.com/engineering...

Barazany. Context Engineering: What Keeps AI Agents From Losing Their Minds . Oct 2025. barazany.dev/blog/contex...

相关推荐
天天喝旺仔15 分钟前
Docker 镜像瘦身实战:多阶段构建把体积缩小 90%
运维·后端·ci/cd·docker·云原生·容器·性能优化
Lost of 程序猿20 分钟前
ASP.NET Core Saga 分布式事务深度实战:备件采购跨服务长流程,如何保证“要么全成,要么全回“
分布式·后端·asp.net
2601_9620710034 分钟前
【Java EE】SpringBoot的创建与简单使用
spring boot·后端·java-ee
Patrick在香港35 分钟前
Claude Prompt Caching 实测账单:第一轮贵 25%,从第二轮开始省 86%
python·prompt·claude·成本优化·prompt缓存·anthropic api
新时代牛马37 分钟前
字符设备注册:从cdev_add 到chrdev_open 的 VFS路径
python
life16938 分钟前
python requests采集同花顺F10、龙虎榜数据
python·同花顺·龙虎榜
angushine1 小时前
qwen3-tts使用实例
python·tts
摇滚侠1 小时前
《SpringBoot 3:入门与应用实战》第 9 章 使用 WebMvc 开发进阶 阅读笔记 24
spring boot·笔记·后端
元界metalite1 小时前
SpringBoot开发企业后台-操作日志记录的最佳实践
后端