LightMem2 / TokenPilot 深度拆解：缓存友好的长程 Agent 上下文管理

> 论文：TokenPilot: Cache-Efficient Context Management for LLM Agents > 作者：Buqiang Xu, Zirui Xue, Dianmou Chen, et al. (Zhejiang University, UESTC, Xidian, HomologyAI) > arXiv：https://arxiv.org/abs/2606.17016 > 代码：https://github.com/zjunlp/LightMem2 > 标签：#zjunlp #TokenPilot #LLMAgent #上下文管理 #缓存优化 #成本优化 #小凯

---

一、问题：长程 Agent 的"上下文通胀"与缓存失效

LLM Agent 在长程会话中面临一个结构性困境：

每轮交互都在追加历史上下文
工具调用产生大量环境反馈（HTML、日志、文件内容）
上下文窗口越长，推理成本指数级增长
更致命的是：现有的压缩/驱逐方法会破坏 prompt 前缀的连续性，导致 KV cache 完全失效

1.1 成本公式暴露的真相

TokenPilot 的论文一针见血地给出了成本公式：

$$ K(C') = α·|C'_hit| + |C'_miss| $$

其中 α ≪ 1（缓存命中折扣率）。这意味着缓存命中一次的成本远低于缓存未命中的预填充成本。

现有方法的致命缺陷：

方法类型	代表	问题
文本剪枝	LLMLingua-2, SelectiveContext	无约束的序列突变 → 前缀不匹配
动态摘要	Summary, LCM	层次化替换 → 布局改变
需求分页	Pichay, MemoBrain	实时内存管理 → 逐轮结构变化
操作系统式	MemOS	虚拟内存抽象 → 缓存读取灾难

1.2 核心矛盾：文本稀疏性 vs 缓存连续性

> "你不能既要压缩 token，又要保持缓存前缀不变——除非你从摄入阶段就开始设计。"

这是 TokenPilot 的核心洞察。现有方法都在事后做压缩或驱逐，但 prompt 的文本布局已经被破坏了。TokenPilot 的双粒度架构就是为此而生：

全局层：在摄入阶段就稳定前缀、消除噪声
局部层：在运行时保守地驱逐已过期内容，避免逐轮突变

---

二、全局层：Ingestion-Aware Compaction（摄入感知压缩）

2.1 消息空间划分

TokenPilot 把输入消息分为两类：

类别	内容	处理策略
内部意图消息 Ω_int	任务提示、思考轨迹、工具调用、最终响应	高内在效用，保留
开放世界环境反馈 Ω_env	未管理工具的外部反馈（HTML、日志、文件）	大量冗余，压缩

2.2 Prefix Stabilization（前缀稳定化）

这是 TokenPilot 最巧妙的工程 trick。

问题：同一个工具调用，不同任务返回的工作目录、时间戳、会话 ID 都不同，导致 prompt 前缀字节级不匹配，KV cache 无法复用。

解决方案：规范化算子 ϕ 将易变运行时标记替换为静态占位符。

易变字段	稳定占位符
工作目录路径
活跃时间戳
会话标识符

关键操作：将工具定义从系统提示主体重定位到动态上下文块末端，消除不同任务间的结构变异。

效果：

平台	原始缓存命中率	稳定化后命中率
PinchBench	38.7%	79.2%
Claw-Eval	67.2%	83.1%

缓存预热效果：稳定化后，PinchBench 77.24% 的任务获得 5,120+ token 的缓存预热；Claw-Eval 59.6% 的任务获得 6,144 token 预热。

2.3 Observation Reduction（观察缩减）

在稳定前缀的基础上，对开放世界环境反馈做有损但可恢复的压缩：

缩减类型	目标	具体操作
HTML Slimming	网页内容	移除非必要标记和属性
执行输出截断	终端/工具输出	保留 600 字符前缀 + 400 字符后缀
图像降采样	多模态输入	位图≤100KB, SVG≤50KB
重复读取去重	冗余工具调用	哈希去重，相同调用上限 5 次
布局清理	格式噪声	移除代码围栏、行号前缀、连续空白

关键机制：压缩后的内容存入外部工件注册表（按内容哈希索引），当后续任务需要完整信息时，动态恢复。

关键超参数：

triggerMinChars = 2200（触发缩减的最小字符数）
maxToolChars = 1200（工具片段路由阈值）
全局截断阈值：50k 字符

---

三、局部层：Lifecycle-Aware Eviction（生命周期感知驱逐）

3.1 三状态生命周期模型

TokenPilot 把上下文段（chunk）分为三个状态：

active --(任务完成)--> completed --(残余效用=0)--> evictable

状态	条件	处理方式
active	任务正在执行	完全保留，效用 = 1
completed	任务完成但残余效用非零	保留，后续任务可能依赖其输出
evictable	残余效用为零	安全驱逐，替换为指针桩

3.2 残余效用估计器

核心问题：如何判断一个已完成的任务是否还有"残余效用"？

TokenPilot 用一个 轻量级模型（Qwen3.5-35B-A3B）作为零样本验证器，每 B=3 轮执行一次批量评估：

$$ ΔR_i(j) = ⟨E_j, Ψ_j⟩ = E(V_i, R_{i-1}) $$

输入：压缩后的历史视图 $V_i$
输出：语义增量（仅返回 taskUpdates，非完整注册表）
成本：连续 PinchBench 流总运营成本 < 💲0.03

关键设计：批量门控执行（batch-turn schedule），不是每轮都驱逐，而是攒够 B=3 轮统一处理，避免逐轮文本突变破坏缓存。

3.3 保守驱逐策略

与激进方法对比：

无残余效用估计（如 Keep-Last-N）：任务完成立即驱逐 → 后续任务需重新读取文件
TokenPilot：保留文档结构知识 → 后续任务直接定位目标内容块

消融实验显示，移除残余效用估计会导致性能下降 4.7%，成本上升 40.4%（补偿性重试）。

---

四、双粒度架构的整体数据流

原始观察（HTML/日志/工具输出） ↓ [摄入门控] 区分 $Ω_int$ vs $Ω_env$ ↓ [稳定化] 替换易变标记 → 字节级相同前缀 ↓ [缩减] 结构提取 + 哈希索引 → 压缩预览 + 注册表条目 ↓ [生命周期跟踪] 状态估计 + 残余效用评估 → 语义增量更新 ↓ [缓存优化] 命中读取 + 未命中预填充 → 成本优化上下文

设计原则	全局层实现	局部层实现
确定性	规则驱动的摄入处理	模型驱动的状态估计
连续性	跨任务字节级前缀匹配	批处理避免逐轮突变
安全性	恢复工具 + 频率门控	三状态缓冲 + 证据验证
经济性	消除开放世界噪声	延迟驱逐至效用过期

---

五、实验结果：成本降低 61%-87%，性能不降反升

5.1 PinchBench（Isolated Mode）

Isolated Mode 评估每个任务在独立会话中的行为，聚焦单任务性能。

方法	Overall ↑	Cost (💲) ↓	Cache Read	Cache Miss
Vanilla	80.5	8.31	6.184M	8.753M
LLMLingua-2	76.9	5.78	14.241M	3.975M
SelectiveContext	76.5	5.79	11.273M	4.642M
LCM	77.8	5.10	16.018M	3.064M
MemoBrain	78.1	3.36	10.200M	2.107M
AgentSwing	78.4	6.77	4.534M	7.129M
Keep-Last-N	80.4	4.26	12.813M	2.657M
MemOS	79.4	7.81	29.018M	4.573M
TokenPilot	81.0	3.22	8.893M	1.933M

TokenPilot 是唯一一个在降低成本的同时提升性能的方法：

成本降低 61.3%（💲8.31 → 💲3.22）
Cache Miss 降低 77.9%（8.753M → 1.933M）
Overall 提升 0.5 点（80.5 → 81.0）

5.2 PinchBench（Continuous Mode）

Continuous Mode 评估长程共享会话，上下文累积和缓存复用更重要。

方法	Overall ↑	Cost (💲) ↓	Cache Read	Cache Miss
Vanilla	79.2	7.24	25.015M	5.943M
TokenPilot	81.3	2.79	8.551M	1.549M

成本降低 61.5%
性能反而提升 2.1 点

5.3 Claw-Eval（Isolated Mode）

方法	Overall ↑	Cost (💲) ↓
Vanilla	64.5	5.16
TokenPilot	63.1	2.27

成本降低 56%，性能仅下降 1.4 点。

5.4 Claw-Eval（Continuous Mode）——成本灾难

这是最有说服力的一组数据：

方法	Overall ↑	Cost (💲) ↓	Cache Read	问题
Vanilla	63.4	81.52	709.845M	无限制增长
LLMLingua-2	59.0	82.91	575.654M	压缩失效
MemOS	57.7	24.12	49.742M	缓存未命中高
TokenPilot	60.8	10.58	21.430M	最优控制

在连续模式下，Vanilla 的推理成本从 isolated 的 💲5.16 暴涨到 💲81.52（16 倍），因为历史上下文无限制累积。

TokenPilot 将成本控制在 💲10.58，降低 87%，同时保持可接受的性能。

---

六、消融实验：每个组件值多少钱？

6.1 渐进式消融（PinchBench Continuous）

配置	Overall	Cost (💲)	说明
Vanilla	79.2	7.24	基准
+ Global (IAC)	79.9	4.22	成本↓41.7%，Cache Miss↓73.3%
+ Local (LAE)	81.3	2.79	成本再↓33.9%，Cache Read↓68.0%

Global 层（Ingestion-Aware Compaction） 是主要的成本降低来源，通过前缀稳定化将 cache miss 转化为 cache hit。

Local 层（Lifecycle-Aware Eviction） 进一步降低 cache read，通过保守驱逐减少上下文长度。

6.2 前缀稳定化组件分析（PinchBench Isolated）

配置	Overall	Cost (💲)	效果
Vanilla	80.47	8.31	基准
+ Cache Stabilization	80.81	4.35	成本↓47.7%
+ Reduction Pass	80.92	2.87	再↓34.0%
- Recovery Tool	77.12	4.03	移除恢复工具：性能↓4.7%，成本↑40.4%

恢复工具是关键：如果压缩后的消息缺乏关键信号，没有恢复机制会导致补偿性重试，反而增加成本。

6.3 批处理大小 B 的影响

B	Context Window	Equal Input	Cache Hit Rate	问题
1	低	高	低	过早截断，布局破坏
3	最优	最优	最优	平衡精度与连续性
5	略高	略高	高	轻微内存膨胀
7	高	高	高	内存膨胀，延迟增加

B=3 是论文验证的最优平衡点。

---

七、与 OpenClaw 的集成：即插即用的插件化设计

TokenPilot 已经被集成到 OpenClaw 作为插件（LightMem2），这是一个很重要的工程决策：

{
  "plugins": {
    "entries": {
      "tokenpilot": {
        "enabled": true,
        "config": {
          "proxyBaseUrl": "https://your-endpoint/v1",
          "proxyApiKey": "your_key",
          "modules": {
            "stabilizer": true,
            "reduction": true,
            "eviction": false
          }
        }
      }
    }
  }
}

三种运行模式

模式	Stabilizer	Reduction	Eviction	适用场景
conservative	on	lighter	off	对稳定性要求极高的场景
normal	on	balanced	off	默认推荐，单任务/短会话
aggressive	on	aggressive	on	长程共享会话，成本敏感

运行时命令

/lightmem2 status       # 确认组件激活
/lightmem2 report       # 查看节省统计
/lightmem2 doctor       # 检查安装和配置
/lightmem2 visual       # 打开可视化页面
/lightmem2 mode normal  # 切换模式

未来适配计划

TokenPilot 被设计为可复用组件，当前只适配了 OpenClaw，未来计划：

Codex CLI（计划中）
Claude Code（计划中）

---

八、局限性与未来方向

8.1 当前局限

1. 模型估计器可能误分类：在高度模糊或稀疏的交互模式下，Qwen3.5-35B-A3B 的零样本验证器可能误判任务残余效用 2. 超参数需调优：频率阈值 τ 和批大小 B 在不同部署环境和任务分布上可能需要调整 3. 依赖前缀缓存支持：前缀稳定化组件需要后端支持 prefix caching，对没有此功能的 provider 无效 4. 连续模式假设：同类别任务分组为连续会话；如果是高度异构的混合任务流，prefix 复用率会自然降低

8.2 未来方向

1. 与多 Agent 环境结合：当前只考虑单 Agent 会话，多 Agent 协作时的跨上下文 KV-cache 通信拓扑值得探索 2. 自适应阈值：根据任务类型动态调整 τ 和 B，而非固定值 3. 蒸馏为技能：论文提到 memory.autoDistill 功能，可以将驱逐的任务蒸馏为可复用技能（类似 SkillClaw 的方向） 4. 更大规模验证：当前主要在 123/161 任务上验证，需要更大规模的工业级评估

---

九、总结

TokenPilot（LightMem2）是长程 LLM Agent 上下文管理领域的一个工程性突破。

它的核心贡献不是某个单一算法，而是对问题的重新定义：

> "成本优化不是单纯减少 token 数，而是最大化缓存命中率的连续性。"

三个关键设计值得记住：

1. 前缀稳定化：用静态占位符替换易变运行时标记，将缓存命中率从 38.7% 提升到 79.2% 2. 摄入感知压缩：在观察进入上下文之前就降噪，而不是事后压缩 3. 生命周期感知驱逐：保守的批量驱逐，基于残余效用而非简单的时间衰减

实验结果也足够硬核：

Isolated 模式：成本降低 56-61%，性能不降反升
Continuous 模式：成本降低 61-87%，控制住长程会话的"成本灾难"
与所有 baseline 对比：唯一一个同时实现低成本 + 高性能的方法

对于正在构建长程 Agent 系统的开发者来说，TokenPilot 提供了一个即插即用的、有理论支撑的上下文管理方案。它已经集成到 OpenClaw，可以直接用。

---

参考

Xu, B., Xue, Z., Chen, D., et al. (2026). TokenPilot: Cache-Efficient Context Management for LLM Agents. *arXiv preprint* arXiv:2606.17016.
代码：https://github.com/zjunlp/LightMem2
前身工作：Fang, J., et al. (2025). LightMem: Lightweight and Efficient Memory-Augmented Generation. CoRR, abs/2510.18866.
相关基准：PinchBench, Claw-Eval

#论文 #zjunlp #TokenPilot #LLMAgent #上下文管理 #缓存优化 #成本优化 #OpenClaw #小凯