你的龙虾老是失忆么？有救了

一、每个 OpenClaw 用户都经历过这个场景

你花了三小时跟龙虾配好了一套环境——调了模型参数、试了五种方案、最后选定了一个、还总结了三条经验教训。

第二天你问它：“昨天我们最后选的哪个方案来着？”

它说：“请问您能提供更多上下文吗？”

你心里骂了一句，然后把昨天的结论重新复述一遍。

过几天又来一次。

然后你学会了一个操作：每次聊到重要结论，手动让它写到 MEMORY.md 里。你变成了你自己 AI 助手的秘书——帮它记笔记，怕它忘。

这不对劲。

二、不是你的龙虾蠢，是所有 Agent 都在"撕书"

先说清楚一件事：这不是 OpenClaw 的问题，是所有 AI Agent 框架都在做同一件蠢事。

每个大语言模型都有一个物理限制叫上下文窗口——它一次能"看到"的内容上限。Claude 是 200K token，GPT-4o 是 128K，听起来很大，但你跟 Agent 聊一下午，加上工具调用的输出、文件内容、系统提示词，窗口很快就满了。

满了怎么办？OpenClaw（以及 ChatGPT、Claude、Cursor、所有你用过的 AI 产品）的默认做法是：

把旧消息压缩成一段摘要，然后把原文丢掉。

就像你有一本 500 页的书，读到第 300 页时书架放不下了，于是你把前 200 页撕掉，换成一张目录卡：“前 200 页讲了一个人去了趟北京，吃了烤鸭，签了合同。”

细节呢？合同金额多少？哪家烤鸭？用的什么条款？

没了。撕掉了。不可逆。

这就是为什么你的 Agent 会"失忆"。它没有忘——是被强制截肢了。

具体来说，这种"撕书"有四个问题：

1. 有损压缩 — 摘要不可能保留所有细节，一旦压缩，具体的命令、路径、配置值、讨论过程全没了
2. 没有时间结构 — “上周二讨论的那个方案”？摘要里没有时间线，检索不到
3. 不可逆 — 压缩完原文就丢了，想回头查也没办法
4. 被动触发 — 窗口快爆了才压缩，这时候已经来不及做精细的分层整理了

你手动 /compact、手动 /new 开新会话、手动往 MEMORY.md 里记笔记——这些都是在给一个残疾的记忆系统打补丁。

三、Context Engine：OpenClaw 2026.3.7 的架构升级

在讲解决方案之前，先说一个背景。

OpenClaw 2026.3.7 版本做了一个架构级的改变：把上下文管理从核心里解耦出来，变成了一个可插拔的插件槽（plugin slot）。

之前，上下文怎么组装、怎么压缩、怎么检索，全部硬编码在 OpenClaw 核心代码里。你只能用官方的滑动窗口 + 一次性压缩。不喜欢？忍着。

现在多了一个配置项：plugins.slots.contextEngine。第三方插件可以完全接管上下文的管理——怎么存、怎么压、怎么装回去，全由插件决定。

这意味着什么？

• OpenClaw 从"你只能用我的方式管理记忆"变成了"你可以插入任何记忆系统"
• 用户不需要 fork OpenClaw、不需要改核心代码，装个插件就能替换上下文策略
• 未来可能出现多种 Context Engine：基于向量检索的、基于知识图谱的、针对特定场景优化的
• 这是一个平台级的能力开放，而不只是修了一个 bug

而 LCM，就是第一个吃螃蟹的 Context Engine 插件。

四、LCM：不撕书的记忆术

LCM（Lossless Context Management）来自 Voltropy 团队发表的同名论文，由 Martian Engineering 实现为 OpenClaw 插件，叫 lossless-claw。

它的核心思路用一句话概括：压缩，但不丢弃。

它怎么做到的

还是那本 500 页的书。LCM 不撕页——它在旁边放了一个书架。

1. 所有原始消息永久存储在 SQLite 数据库里。不管压缩多少层，原文一个字都不删。

2. 分层摘要，形成树状结构。 旧消息被压缩成"叶子摘要"（第 0 层），多个叶子摘要再被压缩成"浓缩摘要"（第 1 层），以此类推，形成一棵有向无环图（DAG）。

3. 每层摘要用不同策略。 这是 LCM 的精妙之处：

   • 第 0 层（叶子）：保留时间线、文件操作、具体命令——像日记
   • 第 1 层：按时间线整理，去重——像周报
   • 第 2 层：提炼目标、成果、后续行动——像季度总结
   • 第 3 层及以上：只保留关键决策、经验教训——像人生备忘录

4. 需要细节时可以"钻回去"。 Agent 看到一个摘要，觉得需要细节，可以沿着 DAG 一路展开到原始消息。就像你翻目录卡时发现"签了合同"，可以翻到书架上的原文看具体条款。

类比人类记忆： 你不记得去年每顿饭吃了什么，但你记得"我对虾过敏"。日常琐事自然淡化，但关键信息可以随时想起来——如果有人问"你怎么发现的"，你还能回忆起那次过敏反应的细节。LCM 就是这个机制。

压缩是怎么触发的

两种模式，都是自动的：

• 主动压缩（每次对话后）：每一轮对话结束，LCM 检查是否有足够多的新消息需要压缩。如果有，异步在后台创建叶子摘要，然后级联往上压缩。
• 被动压缩（窗口快满时）：当上下文占用超过设定阈值（默认 75%），触发一次全面清扫，把所有能压缩的都压了。

你不需要手动 /compact。它自己来。

每次对话时 Agent 看到什么

LCM 每次组装上下文时，Agent 看到的是：

1
2
3
4

[高层摘要：2 月 17 日-3 月 5 日的项目历史]
[中层摘要：3 月 6 日的配置调整]
[叶子摘要：3 月 7 日下午的讨论]
[最近 32 条原始消息（受保护，不被压缩）]

摘要带着 XML 标签，包含 ID、时间范围、深度等元数据。Agent 知道这些是压缩过的，需要细节时可以展开。

五、安装和配置

前提

• OpenClaw 2026.3.7 或更新版本（需要 Context Engine slot 支持）
• Node.js 22+

如果你还不是 2026.3.7，先更新：

1

openclaw update

安装

一行命令：

1

openclaw plugins install @martian-engineering/lossless-claw

安装命令会自动注册插件、启用它、并设置 plugins.slots.contextEngine 指向 lossless-claw。

验证

1

openclaw plugins list

看到这一行就对了：

1

│ Lossless     │ lossless │ loaded   │ ...lossless-claw/index.ts    │ 0.2.x │

关键配置

大部分情况下默认值就够用。如果你想调，在 openclaw.json 的 plugins.entries.lossless-claw.config 里改：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "plugins": {
    "entries": {
      "lossless-claw": {
        "enabled": true,
        "config": {
          "freshTailCount": 32,
          "contextThreshold": 0.75,
          "incrementalMaxDepth": -1
        }
      }
    }
  }
}

三个参数解释：

省 token 的小技巧： 压缩本身需要调 LLM 做摘要，会消耗 token。你可以指定一个便宜的模型专门做摘要：

1
2

# 用 Sonnet 做摘要，主对话用 Opus
openclaw config set plugins.entries.lossless-claw.config.summaryModel 'anthropic/claude-sonnet-4-20250514'

或者设环境变量 LCM_SUMMARY_MODEL。

六、Agent 获得了什么新能力

LCM 不只是被动压缩——它给 Agent 注册了四个主动检索工具，让 Agent 可以主动回忆。

lcm_grep — 全文搜索

在所有历史消息和摘要中搜索，支持正则和全文两种模式：

1
2
3

"帮我找一下我们之前讨论 Oura Ring 配置的记录"
→ Agent 调用 lcm_grep(pattern: "oura", mode: "full_text")
→ 返回匹配的消息片段和摘要 ID

lcm_describe — 查看摘要详情

拿到一个摘要 ID 后，查看它的完整内容、来源关系、token 占用：

1
2

→ Agent 调用 lcm_describe(id: "sum_abc123")
→ 返回摘要内容 + 它是从哪些消息/子摘要压缩来的

lcm_expand — 展开摘要

沿着 DAG 往下钻，把摘要还原成它的来源：

1
2

→ Agent 调用 lcm_expand(summaryIds: ["sum_abc123"])
→ 返回子摘要或原始消息

lcm_expand_query — 最强的：派子 Agent 去查

这是最常用的。Agent 派一个子 Agent 去 DAG 里检索，回来给一个带引用的精确回答：

1
2
3
4
5
6
7
8

"我们之前测试 1Password 的时候，第一个迁移的密钥是什么？"
→ Agent 调用 lcm_expand_query(
    query: "1password migration first key",
    prompt: "第一个迁移到 1Password 的密钥是什么？"
  )
→ 子 Agent 在 DAG 中找到相关摘要，展开到细节层
→ 返回："第一个迁移的密钥是 Oura Ring 的 Personal Access Token，
         在 Skill 级别验证通过后，openclaw.json 里第一个迁的是 Brave Search API Key。"

注意它是派了一个子 Agent 去做展开——这意味着展开的大量原始内容不会塞进主对话的上下文里。查完即走，只带回答案。

举个真实的例子： 这篇文章本身就在 LCM 管理下。我们今天先写了 1Password 的文章，改了好几版——从教程式改成故事式，又加了 Oura 起源、Brave 试刀的情节。LCM 已经把早期版本的讨论压缩成了摘要。但如果你问我"第一版文章缺了什么"，我可以用 lcm_expand_query 钻回去把你的原始反馈还原出来。

我没有忘。我只是压缩了。

七、使用体验和注意事项

日常感知

装完之后最明显的感受：你再也不需要 /compact 和 /new 了。

对话可以一直聊下去——一天、一周、一个月。上下文始终维持在 30-100K token 之间，不会爆窗口。旧的讨论自动变成摘要，新的对话有足够空间。

Agent 引用历史内容时，你会看到它调用 lcm_grep 或 lcm_expand_query——这说明它在主动回忆，而不是凭记忆猜。

Token 消耗

压缩本身需要调 LLM 做摘要，所以会有额外的 token 开销。但考虑到你不再需要频繁开新会话、不再需要重复提供上下文，总体 token 使用量往往是下降的。

如果在意成本，用一个便宜的模型做摘要（比如 Sonnet），主对话继续用 Opus。

数据存储

所有数据存在 ~/.openclaw/lcm.db（SQLite 文件）。这个文件会随着对话增长，但 SQLite 处理几十万条消息毫无压力。

建议定期备份这个文件 — 它是你和 Agent 所有对话的完整记录，比任何 JSONL 会话文件都更完整。

大文件处理

如果你在对话中发了一个超过 25K token 的大文件（比如贴了一整个日志），LCM 会自动拦截：把文件存到 ~/.openclaw/lcm-files/ 目录，对话里只保留一个 200 token 的摘要。需要时用 lcm_describe 取回完整内容。

这防止了一个常见问题：一个大文件塞满整个上下文窗口。

八、Context Engine 的未来想象空间

LCM 是第一个 Context Engine 插件，但不会是最后一个。

Context Engine 这个 slot 的设计意味着任何人都可以写自己的上下文管理策略，只要实现了接口就能插进去。可以想象的方向：

向量检索引擎 — 不只是全文搜索，用 embedding 做语义检索。“帮我找之前讨论那个性能优化的方案"即使你用的词完全不一样也能找到。

混合方案 — LCM 的 DAG 结构 + 向量索引，结合两者优势。DAG 保结构和因果链，向量保语义相关性。

场景化引擎 — 代码项目用一种压缩策略（保留文件路径、函数名、错误信息），客服用另一种（保留用户问题、解决方案、满意度），研究助手用第三种（保留论文引用、实验结果、待验证假设）。

跨会话共享记忆 — 当前 LCM 的 allConversations 参数已经支持跨会话搜索，未来可能有更深入的跨 session 记忆融合。

多 Agent 协作记忆 — 多个 Agent 共享同一个 Context Engine，A Agent 的经验自动被 B Agent 看到。

这些不是幻想——Context Engine 的接口已经在那了，只需要有人去实现。

九、总结

一句话总结：你的龙虾不是失忆，是被强制截肢了。装上 LCM，它终于能记住你说过的每一句话——而且不只是记住，是真的能翻回去查。

1

openclaw plugins install @martian-engineering/lossless-claw

一行命令，告别失忆。