OpenClaw 创始人推荐的插件,让我的 AI 永不遗忘

OpenClaw 创始人 Peter Steinberger 在 X 上推荐了一个插件，说它解决了 AI 的"失忆症"。我装了，然后发现——这可能是我今年装过最值的插件。

但在说它有多好之前，我得先说一个你肯定遇到过的问题：上周和 AI 讨论的技术方案，今天它完全不记得了。你得重新描述一遍，像在跟一个失忆症患者对话。这不是你的 AI 有问题，这是所有 AI Agent 的通病。

！

一、AI 为什么会"健忘"？

所有 AI Agent（包括 OpenClaw）都面临同一个限制：上下文窗口有限。

Claude Opus 4.6 的上下文窗口是 200k token，听起来很大，但如果你每天和 AI 聊几十轮，一周下来就会超过这个限制。超过之后会发生什么？旧消息会被截断丢失。

传统的解决方案叫"滑动窗口"——保留最近的消息，丢弃旧消息。简单粗暴，但信息永久丢失。就像人类的失忆症，无法回忆过去。

举个真实场景：3 月 1 日你问了关于 GitHub Actions 的问题，讨论了半小时，最后找到了解决方案。3 月 15 日你又想起来，问 AI："上次那个 GitHub Actions 配置，最后怎么解决的？"AI 回答："抱歉，我没有找到相关的历史记录。"

这就是我装 Lossless Claw（LCM）的原因。

二、LCM 是什么？一句话讲清楚

Lossless Context Management（LCM）——用 DAG（有向无环图）+ SQLite 替代滑动窗口，让 AI 永不遗忘。

如果用人类记忆来类比：

传统滑动窗口 = 短期记忆（只记得最近的事，旧事忘光）
LCM = 长期记忆 + 笔记本（所有事情都记录下来，需要时可以翻出来）

LCM 有三个关键特性：

永久保存：所有消息存入 SQLite 数据库，永不丢失。

智能压缩：旧消息自动压缩成摘要，节省上下文空间。关键是，这不是"删除"，而是"压缩"——原始消息还在数据库里，摘要链接回源消息，可以随时展开。

主动检索：AI 可以用 lcm_grep 工具搜索历史对话。不用你手动翻记忆文件，AI 自己会去找。

三、它是怎么工作的？

假设你和 AI 聊了 100 轮对话，上下文快满了（达到 75%）。LCM 会自动启动压缩流程。

步骤 1：叶子摘要

将最早的 8 条消息压缩成一个摘要（1200 token）。原始消息保存在数据库中，但从上下文窗口中移除。

步骤 2：层级压缩

如果摘要也多了，再把多个摘要压缩成更高层摘要。形成 DAG 树状结构——摘要的摘要的摘要，可以无限层压缩。

步骤 3：上下文组装

每次对话时，组装"摘要 + 最近 32 条原始消息"。最近的消息永远保持原始状态，旧消息以摘要形式存在。

用表格对比一下效果：

时间	无 LCM	有 LCM
第 1-50 轮	全部保留	全部保留
第 51-100 轮	全部保留	全部保留
第 101 轮	第 1-50 轮被丢弃	第 1-50 轮压缩成摘要
第 150 轮	第 1-100 轮被丢弃	第 1-100 轮压缩成摘要
需要回溯	❌ 无法回溯	✅ 用 lcm_grep 搜索

回到前面那个 GitHub Actions 的例子。有了 LCM，3 月 15 日你问"上次那个配置怎么解决的"，AI 会自动用 lcm_grep（"GitHub Actions"） 搜索 14 天前的对话，立即找到完整的讨论历史和解决方案。

四、它和 MEMORY.md 是什么关系？

很多人问：LCM 是不是要替代 MEMORY.md？

不是。它们是互补关系，不是替代关系。

特性	LCM（对话历史）	MEMORY.md（长期知识）
内容	"我们说过什么"	"重要的结论和知识"
管理	自动	人工策展
格式	SQLite DAG	Markdown 文件
可读性	机器可读	人类可读

场景举例：用户问"上个月我们讨论的那个 GitHub Actions 配置，最后怎么解决的？"

LCM 的作用
：用 lcm_grep（"GitHub Actions"） 搜索上个月的对话记录，找到完整的讨论过程
MEMORY.md 的作用
：如果当时把"最终方案"写进了 MEMORY.md，可以快速找到结论

两者结合 = 既有完整历史，又有精炼知识。LCM 保证"对话历史不丢失"（自动），MEMORY.md 保证"重要知识易检索"（人工策展）。

五、配置复杂度：19 个参数

说完优点，该说缺点了。

LCM 有 19 个配置参数，比 OpenClaw 内置的记忆系统（零配置）复杂得多。但好消息是，你只需要理解 3 个核心参数：

LCM_FRESH_TAIL_COUNT=32：最近 32 条消息永远保持原始状态，不会被压缩成摘要。

LCM_CONTEXT_THRESHOLD=0.75：达到上下文窗口的 75% 时触发压缩。太低会频繁压缩（费钱），太高可能超窗口。

LCM_INCREMENTAL_MAX_DEPTH=-1：允许无限层压缩（摘要的摘要的摘要。。。）。设为 0 只压缩一层，设为 -1 会层层压缩，更省 token 但更费钱。

其他 16 个参数大多数情况下用默认值就行。

六、权衡：优点和缺点

装了 LCM 一周后，我的真实感受：

优点：

🧠 永不遗忘：所有对话历史永久保存，可搜索可回溯
🔍 智能检索：AI 可以主动搜索历史，不用手动翻记忆文件
⚙️ 自动化：达到上下文阈值自动压缩，无需手动干预

缺点：

💰 额外 token 消耗：每次压缩都要调 LLM 生成摘要。如果每天触发 2-3 次压缩，额外成本约为正常对话的 10-20%
💾 需要存储空间：SQLite 数据库会随对话增长。中度使用（每天 50-100 轮对话）约 100-300 MB/月
🔧 配置复杂度：19 个参数，虽然大多数用默认值，但还是比零配置复杂

还有一个隐藏的坑：如果你频繁使用 /new 重置会话，LCM 的优势会被削弱。因为 LCM 是按会话组织数据的，每个会话有独立的 DAG。会话 1 的历史无法被会话 2 访问。

七、适合谁？不适合谁？

装了一周后，我的建议很明确：

适合使用 LCM 的场景：

✅ 长期项目管理（需要追溯几个月前的技术决策）

✅ 知识密集型对话（大量技术讨论、代码审查）

✅ 多轮迭代优化（反复修改同一个项目）

✅ 个人知识库构建（希望 AI 成为"第二大脑"）

不适合使用 LCM 的场景：

❌ 短期临时咨询（一次性问题，不需要长期记忆）

❌ 成本敏感用户（不愿意为压缩摘要支付额外 token 费用）

❌ 频繁切换话题（习惯每天或每个话题用 /new 重置会话）

如果你决定用 LCM，我的建议是：

1。减少使用 /new，让单个会话持续更长时间（比如一周）

2。延长会话生命周期：session.reset.idleMinutes： 10080（7 天）

3。继续要求总结，但频率可以降低（比如每周一次）

4。重要决策和结论仍然手动记录到 MEMORY.md

OpenClaw 创始人推荐这个插件，不是没有道理。它解决的不是"能不能记住"的问题，而是"值不值得记住"的问题。