我为什么离开了 OpenClaw
说实话，OpenClaw 是我用过的第一个真正的 AI Agent 框架。技能系统、跨平台同步、AGENTS.md 指令格式——这些设计思路是对的。但它有一个根本性的问题：它记不住事儿。
不是偶尔忘，是系统性地忘。你跟它说了一下午的需求细节，聊到第 30 轮的时候，它开始问你「你说的那个项目叫什么来着？」。你在周五精心调好的人格和规则，周一回来发现它变成了一张白纸。
这不是我的个例。有人在 Hacker News 上分析了大约 1000 个 OpenClaw 部署，得出的结论是「零个合法用例」——主要原因就是记忆不可靠。167 个赞，评论区一堆人在说同样的事。
我自己踩过的坑包括但不限于：
- 跟它讨论完一个复杂的技术方案，中间它做了 compaction（压缩历史对话），再问它细节就含糊其辞了
- 配好的人格在 session 重启后丢失，因为 compaction 时人格信息被当成「不太重要的上下文」给丢弃了
- 发送邮件时搞错了收件人，因为它忘了之前的对话里谁说了一定要来、谁说不来
OpenClaw 失忆的技术根因
问题出在 OpenClaw 的记忆架构上。核心机制是有损压缩（lossy compaction）。
它是怎么工作的
OpenClaw 的上下文管理比较直接：把所有东西塞进 context window，满了就触发 compaction。Compaction 做的事情是用 LLM 把旧对话总结成一段摘要，然后用摘要替换原始对话。
问题是，你没法预测摘要会丢掉什么。
人格设置可能被当成背景噪音。特定事实（比如「张三说不来」）被总结成「讨论了活动安排」。用户偏好压缩没了。而且这一切静默发生——你不知道压缩已经丢掉了关键信息，直到出错。
为什么「文件式记忆」不够
OpenClaw 后来加了文件系统的记忆层，按日期/月份/年份组织。思路是：重要的东西写到文件里，下次用的时候读出来。
但这个设计有个根本矛盾：大脑不是一叠文件。你回忆昨晚的对话时不会去「索引」某个日期的文件。人类记忆是一张网，重要的东西自然浮现，不重要的自然淡出。文件系统做不到——你得先知道「我要找什么」才能去找，但很多时候你不知道自己忘了什么。
社区的挣扎
社区里能看到各种试图修补这个问题的方案：
- Lossless Claw：用 DAG（有向无环图）保留完整的上下文链路，不做摘要。思路是对的，但代价是 context 会越来越大
- Super Memory 插件：第三方插件试图用向量搜索增强检索
- 三层记忆架构：短期/工作/长期分层管理
这些方案都在缓解症状，但没有从根本上解决问题：OpenClaw 的记忆和上下文是耦合在一起的。记忆依赖上下文窗口，上下文满了就必须压缩，压缩就必然丢信息。
迁移到 Hermes
我用 Hermes Agent 现在有一段时间了，配合 Karpathy 的 llm-wiki 思路和 Obsidian 管理知识库。架构层面的差异很大。
四层记忆分离
Hermes 最聪明的地方在于把记忆拆成四层，每层有自己的存储位置、加载时机和容量边界。
第一层：Prompt Memory（MEMORY.md + USER.md）
这是「永远在线」的记忆。每次 session 启动就自动注入系统 prompt，不需要 agent 主动去加载。存在 ~/.hermes/memories/ 目录下，有明确的字符数上限（总共约 3500 字符）。
上限看着小，但这恰恰是关键——它迫使 agent 做筛选，只保留真正重要的东西，而不是把所有对话都往里塞。编辑操作有 add/replace/remove 三种，精确控制。
还有一个细节很重要：session 内编辑的记忆要到下一个 session 才生效。这保证了系统 prompt 的稳定性，不会因为中间写了一次记忆就打乱 Anthropic 的 prefix cache。
第二层：Session Search（SQLite + FTS5）
所有历史对话存进 SQLite，用 FTS5 做全文搜索。当 agent 判断需要过去上下文的时候，它会主动查询，找到相关的 session，然后把结果交给一个小模型做摘要后再注入。
这两点设计我很认同：
- 检索和注入是分离的——不是把所有历史都塞进 context，而是按需取用
- 摘要在注入前完成——不会因为检索到大量历史而撑爆 context window
第三层：Skills（程序记忆）
Skills 是 ~/.hermes/skills/ 下的 markdown 文件，记录的是「怎么做一件事」的方法论。比如怎么部署博客、怎么做代码审查、怎么跑量化回测。
加载方式用了 progressive disclosure：默认只加载名字和一行摘要，只有当任务匹配时才加载完整内容。这意味着即使你有 200 个 skill，token 消耗和 40 个差不多。
agent 会自己创建和更新 skill。触发条件包括：用了 5 次以上工具调用、从错误中恢复、用户纠正了做法。这个自我改进循环是 Hermes 用得越久越好用的原因。
第四层：Honcho（用户建模）
被动层，不需要 agent 主动写。它跨 session 建立对用户的理解——沟通风格、技术背景、偏好。这一层是可选的，适合日常个人助手场景。
Context 压缩的 LINEAGE 设计
Hermes 也有 context 压缩，但做法不同。
当对话太长的时候：
- 一个哨兵机制在到达硬限制之前触发
- 用辅助模型扫描整个对话
- 压缩中间轮次，但保留血统（lineage）——压缩后的内容有引用链指向原始对话，原始对话存在 SQLite 里不会丢
- 同时检查是否值得把一些内容存入 MEMORY.md
关键区别：OpenClaw 压缩后原始信息就没了，Hermes 压缩后原始信息还在 SQLite 里，以后需要的时候可以通过 Session Search 找回来。
SOUL.md：人格的热插拔
Hermes 的人格定义在一个叫 SOUL.md 的文件里，每次消息都重新加载（不需要重启）。人格是系统 prompt 的第一个 slot，最高优先级。
这解决了 OpenClaw 的另一个痛点：人格信息是写在对话上下文里的，压缩的时候可能被丢掉。Hermes 把人格放在 prompt 的固定位置，不会被压缩波及。
我的方案：Hermes + llm-wiki + Obsidian
Karpathy 前段时间提了一个概念叫 llm-wiki：用 markdown 文件构建一个结构化的知识库，让 LLM 可以在里面检索和积累知识。
我把这个思路和 Hermes 结合起来了：
Obsidian Vault
├── wiki/ ← 结构化知识库（llm-wiki 思路）
│ ├── entities/ ← 实体页（Hermes Agent、OpenClaw、腾讯...）
│ ├── concepts/ ← 概念页（上下文工程、Agent 记忆...）
│ ├── comparisons/← 对比页
│ └── raw/ ← 不可变原始资料
├── AI/ ← 日常 AI 笔记
├── 投资/ ← 投资研究
├── 01_输出/ ← 博客文章（publish: true 发布）
└── 00_Clippings/ ← 外部文章剪藏
三层系统各有分工：
- Hermes MEMORY.md：存储「agent 需要每次都知道的事」——用户偏好、环境配置、操作约定。字符有限，只存精华
- wiki/ 知识库：存储「值得长期积累的结构化知识」——概念、实体、对比分析。有 schema 约束，有交叉链接
- Session Search：存储「过去发生了什么」——可检索的完整对话历史
这个组合用了三个月，没有出现过 OpenClaw 那种「聊着聊着就忘了」的问题。
不是说 Hermes 完美
Hermes 不是完美的。配置比 OpenClaw 复杂，光搞清楚四层记忆各自的使用场景就花了我不少时间。skill 系统虽然能自动创建，但前期需要手动引导才能建立起来。社区规模也比 OpenClaw 小很多，遇到问题基本只能看源码。
但有一个问题它确实解决了：我可以信任它记住了我说过的话。对于一个 24/7 运行的个人 agent 来说，这是底线要求。
Nishant Soni 那篇文章里有一句话我一直记得：「一个你需要每次都去验证的自治 agent，只是一个多了几个步骤的聊天机器人。」
说的就是记忆。没有可靠的记忆，agent 的自治就是空谈。
参考资料
- Hermes Agent 官方架构文档
- Inside Hermes Agent: How a Self-Improving AI Agent Actually Works — Mr. Ånand
- I Fixed OpenClaw’s Biggest Problem (Memory) — Algo Insights
- OpenClaw’s memory is unreliable, and you don’t know when it will break — Nishant Soni (HN 167 points)
- Karpathy llm-wiki Gist
- Google Agent 白皮书系列：Agents、Agents Companion、Agent Framework