在长程 Agent 场景中，系统瓶颈正从“模型单步能力”转向“能否在有限上下文、缓存窗口和持续工具交互约束下长期稳定运行”。现有工作大多聚焦上下文接近上限后的最终 compaction，但对进入重压缩之前的前序整理层，以及压缩过程与 Prompt Cache 的协同考虑仍然不足。

本次分享将介绍我们在企业内部办公智能体 OpenClaw 上探索的 Self-GC 方案：借鉴 Java GC 对运行时对象持续管理的思想，将多轮 Session 上下文对象化，并通过显式寻址、低损 prune/mask/fold、plan/commit 解耦、cache-aware delayed commit 等机制，把上下文治理前置到运行过程。 实践中，当前场景平均 input 约 70k tokens，平均 TPM 约 1 亿 tokens。结合收益模型，我们将 Self-GC 视为一种模型无关的 harness 能力，而不是某个模型特定技巧。按当前业务规模粗估，线上对 user / tool / skill 三实体采取 GC，净 input TPM 大盘下降 15%。分享将重点展开对象模型设计、前缀缓存协同、幂等恢复、离线效果评估与工程落地路径。

演讲提纲：

1. 问题背景：为什么长程 Agent 需要新的上下文治理方式
   • 长历史、多工具调用、长周期任务的真实系统压力 为什么“快爆窗了再 summary”不够 compaction 为什么正在成为 harness 的核心组成部分
2. 现有方案的不足
   • 常规 self-summary：更像最后阶段集中压缩
   • Tool-result pruning：更偏局部优化 retrieval memory：更像后置外存机制 为什么现有方案大多缺少前序整理层和 cache-aware 设计
3. Self-GC 核心设计
   • 上下文对象化：user turn span / tool object 显式注入 turn id，让模型具备上下文寻址能力 低损整理动作：prune / mask / fold fold 后的幂等恢复：本地文件 / 旁路存储 / read 恢复
4. 把整理前置到运行过程
   • 阈值触发而不是每轮强制执行 after-turn self-review 为什么 fork 完整上下文 + 尾部追加 planning prompt 有利于复用 prefix cache
5. Cache-aware 的关键设计
   • plan first, commit later delayed commit 避免频繁打断前缀一致性 收益函数： Award ≈ N_future × (C - C') - L_cache_break - L_GC 该函数如何同时服务工程评估和后续训练优化
6. 效果评估方法
   • 从真实触发重压缩的 session 中取样 在 25% / 50% / 75% 切点做前序整理模拟 用后续真实对话轨迹做离线评估 如何判断 Self-GC 是否有效、是否值得
   • 工程收益粗估与适用边界
   • 当前业务规模下的 10%–30% 净 TPM 收益区间 哪些场景适合 Self-GC 哪些场景更适合 memory / retrieval / tool pruning
7. 未来工作
   • 模型原生寻址能力 模型自主触发能力 模型原生整理能力

听众收益：

• 获得一套更适合长程 Agent 的上下文治理思路，理解为什么仅靠最终 summary / compaction 不足以支撑真实多轮任务
• 学到一套可落地的 Self-GC 设计框架，包括对象建模、显式寻址、低损整理、幂等恢复、plan/commit 解耦与 cache-aware delayed commit
• 带走一套可复用的工程评估方法，知道如何用真实 session、真实后续轨迹和收益模型来判断一个上下文治理方案是否真的有效、是否值得上线

实践痛点：

• 传统 compaction 大多发生在上下文已经接近上限时，这更像一种最后阶段的集中处理。它虽然能缓解爆窗，但往往介入时机较晚，容易一次性丢失较多结构信息，也难以回答“在进入重压缩之前，系统还能做什么”
• 真实 Agent 的上下文并不是纯文本，而是 user / assistant、多轮工具调用、冗长工具结果、中间计划、失败重试等混合对象。如果缺少对象化表示和显式寻址，模型只能对整段模糊历史做 summary，很难像 GC 一样精确标记和清理具体对象
• 很多压缩方案忽视了 prefix cache。工程上，如果每轮都改写历史前缀，虽然 token 可能变少，但 cache 命中率也可能显著下降，最终吞掉压缩收益
• 低损整理如果没有恢复语义，就很难真正落地。很多被 fold 的工具结果虽然不应继续长期留在主上下文里，但后续又可能需要稳定恢复，因此工程上必须同时解决“如何整理”和“如何幂等恢复”