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 上下文：

四大技术机制

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 的渐进式优势

四、行业坐标：Self-GC 在上下文治理谱系中的位置

现有方案对比

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