ClawVM：当AI Agent装上操作系统的虚拟内存

核心直觉：你的Agent不是模型不够聪明，而是它的"操作系统"在掉链子。1960年代就解决了的内存管理问题，今天的AI框架却还在用"尽力而为"的野路子。

一、Agent 失忆的真相

先讲一个场景。

你让 Claude Code 重构一个大型项目。它读了几十个文件，分析了依赖关系，制定了迁移计划，开始执行。三小时后，进度 80%，突然——上下文满了。框架做了 compaction（压缩），把一些"看起来不重要的"历史记录丢掉了。

然后它忘了自己为什么要重构。开始重复之前已经做过的工作。或者更糟：覆盖了刚写好的新代码，因为它不记得自己已经改过了。

你查日志，没有报错。一切看起来正常。但 Agent 就是"疯了"。

这不是科幻。这是 OpenClaw、Claude Code、Cursor 等工具的 issue tracker 里每天都在发生的事：

• 状态在压缩后丢失 —— 重要的约束条件被 summary 替代，然后消失
• 重置时跳过刷新 —— session 重启，脏数据没写回，从头开始
• 写回时覆盖新数据 —— flush 操作不是 merge 而是 overwrite，新状态被旧状态覆盖

论文作者翻遍了 GitHub issue 和社区报告，发现这些故障有惊人的规律性。熟悉存储系统的人一眼就能认出来：lost writes、stale reads、torn pages——这是分布式存储的经典故障模式，1960 年代就研究透了。

但 AI Agent 的框架，在 2026 年还在犯同样的错误。

二、为什么现有的解法不够

现有的 Agent 框架不是没有内存管理。OpenClaw 提供了：

• pruning —— 剪掉"不重要"的历史
• retrieval —— 从外部存储找回相关内容
• compaction —— 压缩上下文，保留 summary
• pre-compaction flush —— 压缩前把数据写回外部存储
• external memory plugins —— Mem0、Cognee、QMD 等插件

这些都是好工具，但有个根本问题：没有 enforceable contract（可强制执行的契约）。

Pruning 决定什么该剪、什么该留，但这个决策是 best-effort 的——"尽力而为"，不保证结果。Compaction 后的 summary 可能漏掉关键约束。Flush 可能被跳过。Writeback 可能是破坏性的覆盖，而不是合并。

换句话说：框架提供了工具，但不保证你用对了。就像操作系统给你提供了文件系统 API，但不保证你的数据一定能写到磁盘上——这还怎么玩？

三、ClawVM 的洞察：把虚拟内存做 literal，不只是比喻

ClawVM 的核心主张很简单：

当运行时需要管理一个快速但稀缺的存储层（context window）和一个慢速但持久的存储层（外部存储）时，答案是虚拟内存，不是尽力而为的启发式。

这不是新观点。1960 年代的操作系统设计者就明白了：应用程序不应该管理物理内存，操作系统应该。应用可以请求、读写，但 residency（驻留）、eviction（淘汰）、durability（持久化）应该由 OS 保证。

Agent 的 harness（框架）就是 Agent 的 OS。它负责组装 prompt、调度工具、观察生命周期事件。它天然是放置内存契约的地方。

ClawVM 做了三件事，把虚拟内存从比喻变成实现：

四、类型化页面与最小保真度：给记忆加上防伪标签

ClawVM 把 Agent 状态拆分成 typed pages（类型化页面）。

每个 page 不是无结构的文本块，而是有类型的：指令、约束、计划、工具输出、用户偏好……每种类型有它自己的最小保真度（minimum-fidelity invariant）—— "我可以被压缩到什么地步，但不能更差了"。

举个例子：

• 指令页：可以压缩成摘要，但不能丢掉"必须遵守"的约束
• 计划页：可以简化步骤，但不能丢掉依赖关系
• 工具输出页：可以保留关键字段，但不能完全丢弃

这个"防伪标签"是 harness 强制执行的。如果 token budget 不够，page 可以 degrade（降级），但不能 violate invariant。如果无论如何都不够，系统会 raise an observable fault（可观察的故障）—— 而不是静默丢失数据。

五、多分辨率表示：四个版本的"应急预案"

这是 ClawVM 最巧妙的设计之一。

每个 page 预生成四个版本：

1. Full fidelity —— 完整内容
2. Compressed —— 压缩版（如 LLMLingua-2 处理后的）
3. Structured fields —— 只保留关键字段
4. Pointer —— 极简的指针/引用，知道去哪里找完整版

当 token budget 紧张时，harness 不需要临时做决策——它直接查表，按预设规则降级。从 full 到 compressed 到 fields 到 pointer，零风险、毫秒级。

这就像是餐厅备了四个版本的菜单：完整版、精简版、今日特选、以及"请看黑板"。客人多的时候，直接换小菜单，而不是临时决定删掉哪些菜。

六、验证写回：终结覆盖灾难

现有框架的 flush 操作有个致命问题：它是破坏性的。

Agent 把上下文写回外部存储，通常是 overwrite——新内容覆盖旧内容。但如果外部存储里已经有了更新版本（比如另一个 session 写的），overwrite 就会把新数据丢掉。

ClawVM 的 writeback 是 staged + validated 的：

1. Stage：先把修改暂存，不直接写入
2. Validate：检查外部存储的当前版本，确认没有冲突
3. Commit：验证通过后，原子性提交

这本质上是一个简化版的三阶段提交（3PC）。不是让模型决定怎么写，而是 harness 强制执行：dirty state（脏数据）必须在销毁前 committed，critical state（关键状态）必须在 compaction 后 surviving。

七、故障模型：让不可见的变成可见的

前面说的所有机制，最终都指向一个目标：observable faults（可观察的故障）。

现在的 Agent 失忆，最烦人的不是丢失数据，而是你不知道丢了什么。日志里没有错误，结果就是不对，但你无从调试。

ClawVM 的故障模型把内存管理决策变得可观察、可重放（replayable）：

• Refetch fault：需要的 page 不在 resident set 里，需要重新获取
• Duplicate-tool fault：因为丢失了之前的工具调用结果，重复执行
• Post-compaction bootstrap fault：压缩后丢失了启动状态，Agent 需要重新初始化
• Flush-miss fault：脏数据没来得及写回就被销毁

这些 fault 不是静默发生的——它们被显式 raise，带有上下文信息，可以被记录、被重放、被调试。而且论文证明：只要 minimum-fidelity set 能 fit 进 token budget，这些 fault 可以被降到 零。

八、实验结果：零故障不是神话

论文在四类合成 workload 和 12 个真实 session trace 上做了测试。

基准线对比：

ClawVM 在所有 token budget 下都做到了零 policy-controllable fault。一个 offline oracle（有未来知识的最优策略）验证了：在线策略已经达到了理论最优，没有剩余优化空间。

性能开销：median < 50μs per turn。对 Agent 的响应时间来说，这几乎不可感知。

九、阿喀琉斯之踵：完美的保险箱与伪造的宝石

但 ClawVM 不是银弹。论文坦诚地指出了它的根本局限：

ClawVM 保证的是物理层面的正确性——数据不会丢、不会覆盖、不会静默消失。但它不保证语义层面的正确性。

换句话说：ClawVM 是一个完美的保险箱。它保证你放进去的东西不会丢、不会被偷换。但如果放进去的是一颗假宝石（AI 幻觉），保险箱只会忠实地保护这颗假宝石。

这是一个深层问题。Agent 可能生成一个格式完美、内容全错的"技能"，ClawVM 会把它当成 critical state 保护起来，在多个 session 之间持久化。结果不是失忆，而是记错了，并且永远忘不掉。

这引出一个更哲学的问题：在 AI 系统中，持久化错误是否比丢失正确更危险？

丢失数据，Agent 可以从头再来。但持久化一个错误的约束或计划，Agent 会一错再错，而且因为 ClawVM 的保护，这个错误不会被覆盖。

十、定位与关系：ClawVM 不是银弹，是基础设施

ClawVM 在 Agent 生态中的位置很重要。它不是替代 MemGPT、A-MEM、Mem0 这些系统，而是给它们提供一个强制执行的底层。

• MemGPT：让模型自己决定 paging 策略，但把 residency 和 writeback 的决策权留给模型
• A-MEM：用 Zettelkasten 方式组织长期记忆，动态构建笔记网络
• Mem0/Cognee/QMD：提升检索质量，但不保证检索到的内容不被后续操作覆盖

ClawVM 可以和它们组合：MemGPT 的模型驱动策略可以作为 ClawVM 的 paging heuristic，但 ClawVM 强制执行 lifecycle-complete writeback 和 observable fault。

论文作者的总结很到位：

"You do not need the model to manage its own memory well. You need the harness to enforce a contract."

结语

ClawVM 的优雅之处，在于它把一个 60 年前的操作系统洞察，应用到了 AI Agent 的内存管理上。

它没发明新算法，没训练新模型，只是做了该做的事：把 Agent 框架从"尽力而为"的脚本集合，升级成有契约保证的运行时。

类型化页面、多分辨率表示、验证写回、可观察故障——这些不是 AI 的创新，是系统工程的常识。但正是这种"把常识落地"的功夫，解决了每天都在折磨开发者的 Agent 失忆问题。

当然，ClawVM 解决的是物理层，不是语义层。完美的保险箱保护不了假宝石。这是留给下一代 Agent 系统的挑战：如何在保证数据不丢的同时，确保数据不错？

或许答案在另一个方向——不是让记忆更可靠，而是让 Agent 学会怀疑自己的记忆。但这已经是另一个故事了。

参考来源：

• Rafique, M. & Bindschaedler, L. (2026). "ClawVM: Harness-Managed Virtual Memory for Stateful Tool-Using LLM Agents." EuroMLSys'26.
• arXiv:2604.10352
• 作者博客: https://binds.ch/blog/clawvm-euromlsys-2026

#论文解读 #费曼风格 #AI #Agent #虚拟内存 #系统架构 #小凯