Contextual Memory Virtualisation: DAG-Based State Management and Structurally Lossless Trimming for LLM Agents Cosmo Santoni | 2026-02 | Category: agent
CMV 处于 agent 上下文管理与 agent serving 基础设施两个研究簇的交叉地带。以下按关联紧密度排序：
agent 上下文管理领域的其他所有工作——Continuum 的 KV cache TTL [2511.02230]、SideQuest 的辅助线程 eviction [2602.22603]、SAGA 的 WA-LRU [2605.00528]、PBKV 的分层淘汰 [2605.06472]——全部在 serving 基础设施层 运行，管理 GPU 显存中的 KV cache。它们解决的是"在一次 agent 执行中如何高效管理内存"。
CMV 独特地在 用户工具层 运行，操作的是磁盘上的 JSONL 文件。它解决的是"跨多次 agent 会话如何复用累积理解"——一个 serving 层完全不触及的问题。即使 Continuum 完美保留了 KV cache、SAGA 完美预测了 cache 复用，用户仍然需要 CMV 的 snapshot/branch 来避免新会话从零开始重建上下文。
增量 vs 全新：跨会话持久化是 CMV 的独有贡献，不是对已有方案的增量改进。
SideQuest 用 LRM 自身的语义推理判断 tool response 是否过期，215 条训练 trace 即可激活 eviction 能力，精度损失仅 2–5% [2602.22603]。CMV 完全不做语义判断——按类型盲删 tool output、base64、metadata，"结构无损"但可能丢失模型后续推理所需的信息 [2602.22402]。
这是一个 fundamental trade-off：
| 维度 | CMV | SideQuest |
|---|---|---|
| 决策者 | 静态规则（7 条 trim rule） | LRM 语义推理 |
| 额外计算 | 零（纯文本处理） | 辅助线程 ~110–140 token/次 |
| 训练需求 | 无 | 215 条 LoRA 微调 |
| 精度保证 | 无测量 | FRAMES −2%, BrowseComp −5% |
| 适用范围 | 任何遵循 tool_use/tool_result schema 的 API | 仅 gpt-oss-20b（未验证其他模型） |
CMV 的零计算成本使其可以无条件部署，但缺少精度保证是一个显著弱点。
CMV 的四个原语（Snapshot, Branch, Trim, Tree）全部由用户手动触发 [2602.22402]。用户决定何时快照、何时分支、何时裁剪。
相比之下，Continuum 的 TTL 自动计算 [2511.02230]、SAGA 的 WA-LRU 自动淘汰 [2605.00528]、PBKV 的预测驱动淘汰 [2605.06472]、PASTE 的投机执行 [2603.18897] 全部是自动化的。Claude Code 自身的 5 层 compaction 也是自动的 [2604.14228]。
CMV 在 autonomy 光谱上处于最低端——这既是其弱点（需要人工判断），也是其优势（不会做出错误的自动决策）。
CMV 的 break-even 分析（$n^* = \lceil \Delta_{\text{penalty}} / \Delta_{\text{savings}} \rceil + 1$）[2602.22402] 是 agent 类别中唯一显式建模 prompt caching 经济性的工作。Continuum、SAGA、PBKV 都以延迟或 TCT 为优化目标，未考虑 API 定价对决策的影响。对于 API 付费用户，CMV 的经济模型提供了"该不该 trim"的定量决策工具。
CMV 的 DAG 状态模型从 OS virtual memory 和 Git 版本控制借鉴类比 [2602.22402]，SAGA 的 AEG [2605.00528] 和 SGH 的 scheduler DAG [2604.11378] 也用 DAG 建模 agent 行为。但这三者的 DAG 语义完全不同：
| 系统 | DAG 节点 | DAG 边 | 用途 |
|---|---|---|---|
| CMV | 不可变快照 | 分支关系 | 会话状态版本控制 |
| SAGA AEG | LLM 推理步骤 | 转移概率 | 预测 KV cache 复用 |
| SGH | 任务节点 | 依赖关系 | 调度并行执行 |
CMV 的 DAG 在形式化上最简单（实际是 directed tree，DAG 术语是为未来 merge 预留的 [2602.22402]），但在概念上最接近 Git——这使其对开发者用户有天然的 mental model 优势。
CMV 的全部实验数据来自单个用户三个月的 Claude Code 会话 [2602.22402]。对比 SideQuest 的 424+500 个标准 benchmark 样本 [2602.22603]、SAGA 的 500+812 个 benchmark 任务 [2605.00528]、PBKV 的三个 benchmark × 两个模型的全量评估 [2605.06472]，CMV 的评估在统计上几乎不可信。
具体攻击：bloat profile 分布（16% mixed vs 84% conversational）可能是该用户特有的编码风格的产物。一个大量使用 image generation、web scraping 或代码执行的用户可能有完全不同的分布——mixed 比例可能高达 50%+ 或低至 5%。没有多用户验证，论文的 "20% mean reduction" 数字不可泛化。
论文明确承认："branching 带来的 context rebuilding 避免是 primary value proposition，但仅以定性论述支撑" [2602.22402]。"10–20 turns / 15–30 min" 的 rebuilding 成本是观察性估计，没有 A/B 对照实验。
具体攻击：如果 CMV 的主要价值无法量化，那么论文实际量化的 trimming 价值（20% mean reduction, 40-turn break-even for conversational sessions）本身可能不足以证明方法的价值。64/76 个 conversational 会话的 break-even 需要 40 轮——许多会话在此之前就会自然结束，使 trimming 成为净亏损。论文通过 60-turn cap 淡化了这一点。
CMV 声称保留所有 user/assistant 消息 [2602.22402]，但 SideQuest 的实验清楚展示了 heuristic eviction 可能导致 20–60%+ 的 non-completion rate [2602.22603]。CMV 删除的 tool output 可能包含模型后续推理所需的关键信息。
具体攻击：一个具体的失败场景——用户在 session A 中让模型读取一个 800 行的配置文件并分析其结构。模型的 assistant response 总结了关键配置项。用户 snapshot + branch 并 trim 后，原始 800 行文件内容被 stub 为 "[Trimmed: ~3200 chars]"。在新分支中，用户问"那个配置文件的第 73 行是什么"——模型只有自己的总结，没有原始内容，必须重新读取文件（如果文件仍然存在的话）。这是 CMV 自己承认的缓解策略（"如果模型需要文件内容，简单重新读取"）[2602.22402]，但重新读取本身就是 token 成本——trim 节省的 token 可能被后续重读部分吞噬。这个交互成本从未被测量。
Dive into Claude Code 揭示了 Claude Code 已经有五层渐进式 compaction pipeline [2604.14228]，且 Anthropic 持续迭代这些机制（5 pre-model shapers + model-generated summary）。如果 Anthropic 改进 auto-compact 的保真度（例如将 98% 压缩率降为 80%，同时保留更多结构化信息），或引入原生的 session branching（Claude Code 已有 --fork 和 /rewind），CMV 的价值空间将被大幅压缩。
具体攻击：CMV 在 userland 解决的问题（孤儿 tool result、pre-compaction 跳过、base64 剥离）本质上都是 API schema 设计和 agent runtime 设计的缺陷 [2602.22402]。三遍架构存在的唯一原因是 LLM API 的 tool_use/tool_result 严格配对约束——未来 API 松绑此约束将使 Pass 2 完全消失。CMV 是对当前系统缺陷的 patch，不是对新能力的发明。
Cost model 假设 $h = 0.9$ 缓存命中率 [2602.22402]，但 trim 本身会破坏 prompt prefix，导致首轮 $h = 0$。论文在 break-even 分析中已考虑了这一点（$C_{\text{cold}}$），但更深层的问题是：如果用户在 branch 后的前几轮频繁修改方向（常见于探索性编码），每次方向变化都可能导致缓存失效，使后续轮的 $h$ 远低于 0.9。此外，Anthropic 的定价策略可能改变——cache read/write 价格比、上下文窗口大小、甚至从 per-token 转向 subscription——都会使经济模型的数字失效。
CMV 在 agent 生态中占据一个独特但脆弱的位置——在系统层面缺失原语时的 userland 替代方案。
类比：早期 Unix 没有虚拟内存时，应用程序自己做 overlay 管理；有了 OS 级 VM 后 overlay 消失了。CMV 自己也明确使用了这个类比 [2602.22402]，但讽刺的是，这个类比暗示 CMV 的终局是被系统层吸收——当 Claude Code（或竞品）原生支持 named snapshots、DAG branching、selective trimming 时，CMV 就不再需要了。
SGH 论文对此提供了理论框架：SGH 认为 agent 执行应该从 opaque Agent Loop 迈向 structured graph harness [2604.11378]。如果 agent runtime 演进到 SGH 描述的方向——每个节点有独立 context、plan 可版本化、recovery 有界——CMV 解决的问题在架构层面就被消解了。
CMV 的参考实现已开源（github.com/CosmoNaught/claude-code-cmv）[2602.22402]，但论文未报告除作者外的用户采用数据。作为一个针对 Claude Code 的 CLI wrapper，其潜在用户群限于 Claude Code 用户且有长会话 context 管理需求的开发者。
CMV 与 serving 层方案（Continuum、SAGA、PBKV）不冲突——它们在栈的不同层面运行。一个完整的 agent context 管理方案可以同时包含：
但这种互补性也意味着 CMV 的"独特贡献"仅限于第 1 层——这一层的复杂度和技术壁垒远低于 2 和 3。
CMV 的价值窗口取决于两个外部因素：
CMV 的规则化裁剪（零计算成本、无训练需求）与 SideQuest 的语义推理 eviction（高精度、需要训练和额外推理）处于 trade-off 的两极 [2602.22603]。一个自然的混合是：CMV 的三遍扫描做确定性基线清理（base64、metadata、orphan tool results 这些永远安全删除的内容），然后用 SideQuest 风格的语义推理做选择性 tool output eviction（判断哪些 tool output 的语义已被 assistant response 完全吸收）。
这正是 PBKV 的"确定性护栏 + 概率系统"分层架构 [2605.06472] 在 conversation log 层面的等价物。PBKV 的 Lipschitz 退化保证 [2605.06472] 提供了一个可借鉴的理论框架——确保语义 eviction 的增益随预测精度连续变化而不断崖式下降。
当前 CMV 的 branch 操作需要创建新会话并从零加载 JSONL 到 API——代价是 $0.53（84k token at cache-write rate）[2602.22402]。如果 serving 层支持 SAGA 风格的 session-affinity [2605.00528] 或 Continuum 风格的 KV cache TTL [2511.02230]，可以将 snapshot 操作与 GPU 端的 KV cache 快照绑定——branch 时不需要重新 prefill，而是直接 fork GPU 上已有的 KV cache。这将 branch 的一次性成本从 $0.53 降到接近 $0。
CMV 依赖用户手动决定何时 snapshot/branch [2602.22402]。PASTE 展示了 agent tool-call 模式的可预测性（55% edit→test、51% search→fetch）[2603.18897]；PBKV 展示了 GraphSAGE 可以高精度预测 agent 调用序列 [2605.06472]。一个自然的扩展是用类似的模式挖掘自动识别"高价值 snapshot 时机"——例如当模型完成了一个大型架构分析（检测方式：连续多轮 file read 后跟一个长 assistant response），自动提示或执行 snapshot。
CMV 当前是单用户 CLI 工具 [2602.22402]。Claude Code 的 agent teams 模式已经支持多 agent 协作（约 7× token 消耗）[2604.14228]。将 CMV 的 DAG 扩展为多用户共享——用户 A 的 architecture analysis snapshot 可以被用户 B fork 用于 feature implementation——需要解决权限控制、并发分支合并、冲突解决等问题。这本质上是将 CMV 从"Git for conversations"的类比推进到真正实现 Git 的多人协作语义。
SGH 的 bounded termination 证明和 contract validation [2604.11378] 提供了一个可借鉴的框架。CMV 可以引入 trim contract——对每次 trim 操作定义"什么必须保留"的形式化约束（不仅是 user/assistant 消息，还包括特定 tool 调用的输出，如测试结果、错误信息），并在 trim 后验证 contract 满足。这将 CMV 的"structurally lossless"声明从自然语言升格为可验证的形式化属性。CPU-Centric 的 profiling 数据 [2511.00739] 可以指导 contract 设计——哪些 tool output 类型对后续推理最关键，应该被 contract 保护。