Self-GC 深度拆解：当 Java GC 思想入侵 LLM 上下文治理

> 演讲：郝栩彬，小红书 AI 工程架构师 > 场景：AiCon 全球人工智能开发与应用大会（2026.6.26-27，上海） > 一句话定位：**借鉴 Java GC 思想，将多轮 Agent Session 上下文对象化治理，结合前缀缓存约束实现 15%-20% 净 input TPM 降幅** --- ## 一、问题的本质：长程 Agent 的「内存泄漏」 截图中透露了一个关键数据： - **平均 input 约 70k tokens** - **平均 TPM 约 1 亿 tokens** - **系统瓶颈正从「模型单步能力」转向「能否在有限上下文、缓存窗口和持续工具交互约束下长期稳定运行」** 这不是性能优化，这是**生存问题**。 当 Agent 运行 10 轮、20 轮、100 轮后，上下文像滚雪球一样膨胀。每一轮都需要「回看」之前所有的动作和观测，输入输出比可达 **100:1**。这意味着： > 每生成 1 个 token 的回答，需要处理 100 个 token 的上下文。 传统解决方案是「上下文压缩」——等窗口满了再一次性压缩。但 Self-GC 团队发现了一个被忽视的空白地带： **现有工作大多聚焦上下文接近上限后的最终 compaction，但对进入重压缩之前的前序整理层，以及压缩过程与 Prompt Cache 的协同考虑仍然不足。** 这就像 Java 程序只在内存耗尽时才触发 Full GC，而不是在日常运行中持续做 Minor GC。Self-GC 的洞察是：**上下文治理应该前置到运行过程，而不是等到危机时刻才救火。** --- ## 二、Self-GC 的核心设计：从「垃圾回收」到「上下文回收」 ### 思想渊源：Java GC 的对象生命周期管理 Java GC 的核心不是「删除垃圾」，而是**对运行时对象进行持续的生命周期管理**： - 新生对象在 Eden 区快速创建和销毁 - 存活对象晋升到 Survivor 区 - 长期存活对象进入 Old Generation - GC 不是一次性事件，是**分代、增量、并发**的持续过程 Self-GC 将这一思想映射到 Agent 上下文： | Java GC 概念 | Self-GC 映射 | |-------------|-------------| | 对象 | 上下文片段（对话轮次、工具调用、观测结果） | | 引用计数 | 显式寻址（哪些上下文片段被后续轮次引用） | | Eden 区快速回收 | 低损 prune/mask/fold（轻量压缩） | | Survivor 晋升 | 重要上下文进入「保留层」 | | Old Generation | 长期记忆/外部存储（超出上下文窗口） | | Full GC | 最终 compaction（窗口接近上限时的重压缩） | | 并发标记 | plan/commit 解耦（先标记再执行） | ### 四大技术机制 **1. 显式寻址（Explicit Addressing）** 传统的上下文管理是「线性堆叠」——每一轮都 append 到末尾。Self-GC 引入显式寻址，让每个上下文片段都有唯一的「地址」，后续轮次可以通过引用而不是复制来引用历史内容。 这类似于从「值传递」到「引用传递」的转变：不需要把整段历史复制到当前 prompt，只需要一个指针。 **2. 低损 prune/mask/fold（三阶段轻量压缩）** - **prune**：删除低价值片段（如重复的工具调用结果、已确认成功的中间步骤） - **mask**：保留片段但标记为「只读摘要」，不展开完整内容 - **fold**：将多个相关片段折叠为结构化摘要 关键在于「低损」——不是粗暴截断，而是有选择地保留信息密度。 **3. plan/commit 解耦** 借鉴数据库事务的两阶段提交： - **plan 阶段**：评估哪些上下文片段可以被压缩、如何压缩、预期信息损失 - **commit 阶段**：实际执行压缩，但只在验证压缩质量达标后才提交 这给了系统一个「反悔」的机会——如果 plan 发现某段上下文被频繁引用，就推迟对它的压缩。 **4. cache-aware delayed commit** 这是 Self-GC 最精妙的设计：**压缩操作不是即时执行的，而是延迟到前缀缓存失效的「间隙」中执行。** 前缀缓存（Prefix Cache）的原理是：只要请求的前缀和缓存中的相同，就复用 KV Cache 跳过重复计算。但如果在多轮对话中修改了前面的上下文，前缀发生变化，缓存就失效了。 Self-GC 的 cache-aware delayed commit 策略： - 监测前缀缓存的命中模式 - 在缓存命中的「热区」内，避免任何会改变前缀的压缩操作 - 只在缓存自然失效（TTL 到期、新会话开始）时执行积压的压缩任务 这就像 Java 的并发标记-清除：在业务低峰期执行 GC，避免影响在线服务的响应延迟。 --- ## 三、为什么不是「等满了再压缩」？ ### 传统 compaction 的问题 | 问题 | 说明 | |------|------| | **延迟突刺** | 压缩是计算密集型操作，在窗口接近上限时触发会导致响应延迟飙升 | | **信息损失集中** | 一次性压缩太多内容，容易丢失关键信息 | | **缓存抖动** | 大规模修改上下文导致前缀缓存频繁失效 | | **无差别压缩** | 不区分重要和不重要的内容，压缩策略粗糙 | ### Self-GC 的渐进式优势 | 维度 | 传统 compaction | Self-GC | |------|----------------|---------| | 时机 | 被动触发（窗口满） | 主动治理（运行过程中持续） | | 粒度 | 粗（整段截断/摘要） | 细（片段级 prune/mask/fold） | | 缓存友好 | 差（大规模修改前缀） | 优（cache-aware delayed commit） | | 信息保留 | 低（无差别压缩） | 高（显式寻址 + plan/commit 评估） | | 延迟影响 | 高（集中计算） | 低（增量、延迟执行） | --- ## 四、行业坐标：Self-GC 在上下文治理谱系中的位置 ### 现有方案对比 | 方案 | 策略 | 与 Self-GC 的差异 | |------|------|------------------| | **Claude Code** | 92% 阈值触发 + 8 段式结构化摘要 | 压缩时机固定阈值，无缓存感知 | | **Gemini CLI** | 70% 阈值 + 5 段式摘要 + 文件系统持久化 | 更早触发，但仍是被动式 | | **Manus** | 上下文状态机 + 遮蔽代替删除 | 关注工具管理，非通用上下文治理 | | **OpenClaw /compact** | 用户/系统触发压缩 | 手动/半自动，无运行时治理 | | **Mem0 / MemOS** | 跨会话记忆存储 + 按需召回 | 解决「跨会话」记忆，不解决「单会话内」膨胀 | | **LLMLingua** | 提示压缩（token 级） | 纯压缩算法，无 Agent 运行状态感知 | ### Self-GC 的独特定位 Self-GC 不是「另一种压缩算法」，而是**第一个将「运行时对象生命周期管理」思想系统性地引入 Agent 上下文治理的方案**。它的独特之处在于： 1. **运行时持续治理**：不是等危机再救火，是日常维护 2. **缓存协同设计**：压缩不是孤立的，是和前缀缓存深度协同的 3. **模型无关**：作为 harness 能力，不绑定特定模型 4. **可逆与可评估**：plan/commit 解耦提供了「反悔」和「效果评估」机制 --- ## 五、量化收益：15%-20% 净 input TPM 降幅意味着什么？ ### 场景换算 以截图中的数据为基准： - **平均 input 70k tokens** - **平均 TPM 1 亿 tokens** - **假设 100:1 的输入输出比** **传统方案的成本结构**： - 每轮发送 70k input + 700 output - 10 轮后 input 膨胀到 700k（全部历史堆叠） - 假设 API 定价 $0.01/1k input tokens - 10 轮成本 = 700k × $0.01/1k = **$7.0** **Self-GC 优化后**： - 通过渐进式压缩，10 轮后有效 input 控制在 560k-595k（降幅 15%-20%） - 10 轮成本 = 560k × $0.01/1k = **$5.6** - **单会话节省 $1.4** 在大规模场景下（TPM 1 亿 = 约 1428 轮/分钟，假设每轮 70k input）： - 每分钟节省 15%-20% 的 input tokens = **节省 1.5M-2.0M tokens/分钟** - 按 $0.01/1k 计算 = **节省 $15-$20/分钟** - **年化节省约 $788k-$1.05M**（假设 24×7 运行） 这还不包括**前缀缓存命中带来的额外节省**（缓存读取成本通常为正常的 10%）。 --- ## 六、一个更深层的追问：上下文治理的终极形态是什么？ Self-GC 让我意识到，Agent 上下文管理正在经历一场 **从「内存管理」到「操作系统化」** 的范式演进： ### 阶段一：无管理（原始态） - 上下文无限堆叠 - 窗口满了就报错或截断 - 代表：早期 ChatGPT API 调用 ### 阶段二：被动压缩（当前主流） - 设定阈值，超过后一次性压缩 - Claude Code、Gemini CLI、OpenClaw /compact - 问题是：压缩时机不可控、信息损失不可评估 ### 阶段三：运行时治理（Self-GC 所在） - 持续监控、渐进压缩、缓存协同 - 引入「对象生命周期」概念 - 类似 Java GC 的分代管理 ### 阶段四：上下文操作系统（未来） 我猜测的终极形态： > **一个完整的「上下文操作系统」（Context OS），包含：** > - **虚拟内存**：超出窗口的上下文自动换出到外部存储（向量 DB、图数据库、文件系统） > - **页式管理**：将上下文分割为固定大小的「页」，按需加载 > - **引用计数 + 垃圾回收**：自动识别无引用上下文并回收 > - **缓存层次结构**：L1（当前窗口）、L2（近期缓存）、L3（外部存储） > - **进程隔离**：不同 Agent/工具之间的上下文隔离与共享机制 > - **快照与回滚**：关键决策点保存上下文快照，支持回溯 Self-GC 是阶段三的代表。它证明了：**上下文治理不是「压缩算法」的问题，而是「运行时系统」的问题。** --- ## 七、费曼视角：一句话总结 > Self-GC 的本质是：**把「等满了再扔」变成「边用边整理」。** > > 你的房间不会因为一天不整理就变成垃圾堆，是因为你每天都在做 minor GC。Agent 的上下文也一样——不是等到 200k tokens 才慌慌张张地压缩，而是在每一轮结束后顺手把不重要的东西收一收。 > > 更妙的是，Self-GC 发现了「整理」和「缓存」之间的张力：你一边想整理房间，一边又担心把常用的东西收起来后下次找不到。所以它的解决方案是——只在「你出门的时候」（缓存失效间隙）才做大规模整理，平时只收拾那些明显是垃圾的东西。 > > 这不是技术创新，这是**工程直觉**。 --- ## 参考信息 - 演讲信息：AiCon 2026，郝栩彬《Self-GC：一种结合前缀缓存约束的多轮 Agent 上下文治理方案》 - 相关技术背景：Java GC（分代、增量、并发）、vLLM Prefix Caching（Radix Tree）、Claude Code 8 段式摘要、Gemini CLI 70/30 策略 - 行业实践：Manus KV 缓存命中率优化、OpenClaw context compaction、Mem0 跨会话记忆 #Agent上下文治理 #Self-GC #前缀缓存 #LLM推理优化 #小红书 #AiCon2026