生产级Agent的分层压缩机制是什么

回复 Erfan： 生产级 Agent（比如 Claude Code、Cursor、Manus 这类）不会把“上下文满了做一次全量摘要”当成唯一的压缩手段，而是按成本、可逆性和对 KV Cache 的影响，拆成从轻到重的四层漏斗： 第一层：入库前截断与落盘（零模型成本，不破 KV Cache） 这是最前置的一层，发生在工具返回结果还没塞进消息队列的那一刻。 比如跑测试吐了 5 万行日志、或者读了一个超大文件，框架层直接拦截：把完整原文写进本地临时文件，上下文里只放头尾各几十行加上文件路径和行号索引。 核心逻辑是“可逆卸载”——模型真需要看细节时，自己调 grep 或分段读取工具去磁盘拿，从源头防止垃圾大文本污染上下文前缀。 第二层：旧工具输出瘦身 / 观测值折叠（Observation Pruning，极低成本） 随着推理步数增加，十几轮之前看过的网页 DOM、文件全文或命令输出，实际上已经用完了。 在还没触发大模型摘要之前，先把超过 N 轮之前的重型 Tool Result 原地替换成简短占位符（比如“已读取 xxx.ts 第 1-200 行，内容已折叠，如需重看请再次调用读取”），但完整保留当时的助手思考和工具调用参数。这样只丢掉最占地方的“原材料”，不丢推理链路。 第三层：子 Agent 上下文隔离（架构级天生压缩） 遇到“全仓库搜索某个调用链”或“连读 10 篇文档对比”这种注定会产生海量中间废料的探索型任务，主 Agent 不亲自干，而是派生一个独立上下文的 Sub-agent 去跑。 子 Agent 在自己的沙盒里消耗掉几万 Token 的搜索和试错过程，最后只把几百字的最终结论返回给主 Agent，子上下文直接销毁。这本质上是用架构隔离代替事后压缩，主 Agent 的 KV Cache 纹丝不动。 第四层：阈值触发的结构化摘要（Compaction，重度兜底） 当上面三层都拦不住、总上下文达到窗口的 75%～80% 阈值时，才触发真正的 LLM 摘要压缩： 1. 锁死头部（System Prompt、工具定义、项目级规则文档）和尾部（最近几轮活跃对话及刚读过的关键代码），只把中段历史打包压缩。 2. 不用开放式总结，而是用固定 Schema 强制提取结构化状态：用户核心目标、已完成的文件修改清单、踩过且已排除的死胡同、当前卡点与下一步计划。 3. 压缩生成的摘要作为新的固定前缀插在头部后面，开启下一轮高 KV Cache 命中的周期。 简单总结：生产级分层压缩的核心原则是“先规则截断、再架构隔离、最后才动用大模型摘要”，并且优先做可逆的外部落盘（给路径让模型按需重读），最后才做不可逆的有损概括。