Hermes Agent vs OpenClaw 记忆模块深度对比

两个 Agent 都用纯文本文件做记忆，都不依赖向量数据库。但冻结注入 vs 实时注入、硬上限 vs 无上限、fork 子 Agent review vs 手动 skill，每个差异背后都是不同的工程取舍。

---

一、记忆系统的核心矛盾

所有 LLM 都是无状态的。每次 API 调用，模型从空白开始，看到的只有你塞进去的 token。所谓的”记忆”——用户偏好、上下文、跨 session 知识——全靠 Agent 框架自己在调用之间拼装。

这就引出了三个要回答的问题：

1. 存什么？ 哪些东西值得记住，哪些该忘掉
2. 怎么存？ 文件、数据库、向量，还是混合
3. 怎么喂？ 什么时候注入 context、什么时候检索、什么时候压缩

Hermes Agent 和 OpenClaw 对这三个问题的答案完全不同。

---

二、概览

维度	Hermes Agent	OpenClaw
存储介质	纯文本文件（MEMORY.md + USER.md）+ SQLite + FTS5	纯文本文件（MEMORY.md）+ JSONL + SQLite
人格分层	SOUL.md 单层合并	SOUL.md → IDENTITY.md → USER.md 三层分离
注入方式	冻结注入 system prompt（整个 session 不变）	每轮重读重注入
Prefix Cache	✅ 全程命中	❌ 每轮破缓存
字符上限	硬上限 2200（MEMORY.md）+ 1375（USER.md）	无硬上限
mid-session 写入	延迟生效（下个 session）	即时生效（下一轮）
外部 Provider	插件架构（Honcho/Mem0/Holographic 等）	无官方插件机制
Skill 管理	fork 子 Agent 自动收集	手动 skill 目录
历史检索	session_search（FTS5 全文搜索）	无内置
压缩策略	五阶段渐进压缩，累积摘要	总结后删除原文
可调试性	文件直读，git 追踪	检索管线黑盒

---

三、核心差异逐层拆解

3.1 冻结注入 vs 实时注入

这是两个框架最本质的差异。

Hermes 的冻结注入：

Session 开始:
  → 读 MEMORY.md + USER.md 全文
  → 制作"快照"注入 system prompt
  → 首次 API 调用 → 建立 KV Cache（Prefix Cache）

对话进行中（system prompt 不变）:
  → 每次 API 调用命中 KV Cache ⚡

mid-session 写入:
  → 文件已更新
  → 但 system prompt 里的快照不变

下个 Session:
  → 重新读取（含新内容）
  → 制作新快照，重建 KV Cache

设计逻辑：性能优先，延迟生效。system prompt 不变才能保住 prefix cache，省下 80%+ 的输入 token 重计算成本。

OpenClaw 的实时注入：

每轮对话:
  → 重读 MEMORY.md
  → 重注入 context

写入时:
  → 文件更新
  → 下一轮直接生效

设计逻辑：即时感知优先。写入即生效，但代价是每轮 system prompt 变化 → Prefix Cache 完全失效。

实际影响：

对于一个 24/7 运行的 Agent，每天几十到几百次 API 调用，每轮破 cache 的额外累积成本很大。Anthropic 的 Prefix Cache 定价是缓存命中输入 token 打 90% 折扣——这意味着 OpenClaw 每轮都在付全额。

但这个取舍不是单方面的好或坏。对于 Cursor 这种交互式 IDE 插件，用户期望写完就生效，延迟一轮会感觉很蠢。对于后台运行的 agent，延迟一轮可以接受，省钱更重要。

3.2 记忆容量管理

Hermes 的硬上限：

文件	上限	用途
MEMORY.md	2200 字符	Agent 的环境/项目事实笔记
USER.md	1375 字符	用户画像、偏好

为什么要设上限？

正常情况下，2000 tokens 的记忆内容中，每条约占 0.26% 的注意力权重。膨胀到 5000 tokens 后，每条只剩 0.02%。上限就是一道硬约束，迫使 Agent 只保留最有价值的信息。超过上限时触发压缩，优先保留用户偏好和环境事实。

上限不是随便定的。2200 字符刚好能装 15-20 条记忆条目，每条约 100-150 字——够一个 session 用。1375 字符也是一个精炼的用户快照，快速加载。

OpenClaw 的无上限：

没有硬性容量限制。Agent 自己决定写什么、删什么。

理论上更灵活——你可以记住更多东西。但实践中暴露的问题：记忆膨胀到几千甚至上万字符后，注意力稀释严重。LLM 的压缩行为不可预测，你不知道它在写了很多行后，会去掉哪些。

Nishant Soni 那篇《I’ve Seen a Thousand OpenClaw Deploys》的 HN 文章里提到：OpenClaw 的 MEMORY.md 在 context 溢出时可能被压缩，而且 LLM 做压缩时可能会删除你认为重要的信息。你都不知道它丢了什么。

3.3 MemoryProvider 插件架构

Hermes 的插件体系：

MemoryProvider（ABC）
├── initialize()        → 连接、创建资源
├── system_prompt_block() → 注入 system prompt 的静态文本
├── prefetch()          → 每轮对话前的 recall
├── sync_turn()         → 每轮对话后的写入
├── get_tool_schemas()  → 工具 schema
├── handle_tool_call()  → 工具调用分发
├── shutdown()          → 清理退出
└── 可选 hooks:
    ├── on_turn_start()
    ├── on_session_end()
    ├── on_pre_compress()
    ├── on_memory_write()
    └── on_delegation()

内置 BuiltinMemoryProvider 始终激活（MEMORY.md + USER.md）。可以挂载一个外部 provider——Honcho、Hindsight、Mem0、Holographic、Supermemory、RetainDB、OpenViking 均有官方插件。外部 provider 是增量的，不会取代内置的。

只允许一个外部 provider 的原因：避免 tool schema 膨胀和记忆后端冲突。

OpenClaw： 无官方插件机制。社区有人用 Mem0 等外部工具补强，但需要自己写胶水代码。

3.4 Skill 自动收集

Hermes 的闭环系统：

复杂任务完成（工具调用 ≥ 10 次）
  → 返回最终回答给用户
  → 后台 fork 子 Agent
  → 子 Agent 冷启动 Review：
      1. 有试错过程？
      2. 有思路转变？
      3. 用户有特别偏好？
      4. 下次还用得上？
  → 任一回答"是"且无现成 skill → skill_manage(action='create')
  → 有类似 skill 需补充 → skill_manage(action='patch')
  → 不值得 → 跳过
  → 通知用户

为什么 fork 子 Agent 而不是主 Agent 直接处理？

	主 Agent 直接处理	fork 子 Agent
响应速度	❌ 用户要等	✅ 后台静默
上下文污染	❌ review 思考污染主对话	✅ 独立不污染
判断客观性	❌ 带任务惯性	✅ 冷启动旁观者

SKILL.md 文件结构：

~/.hermes/skills/
├── my-skill/
│   ├── SKILL.md          ← 核心文件（触发条件+步骤+避坑）
│   ├── references/       ← 参考资料
│   ├── templates/        ← 模板文件
│   └── scripts/          ← 辅助脚本
└── category-name/
    └── another-skill/
        └── SKILL.md

安全机制：命名校验（小写+连字符+最长64字符）、大小限制（SKILL.md 最大 100KB）、安全扫描（注入/外泄）、回滚机制、只读保护。

OpenClaw： 有 skill 目录（~/.openclaw/skills/），但无自动发现机制。需要用户或 Agent 手动创建。没有 review 阶段，不会在任务完成后自动提炼可复用知识。

3.5 记忆 vs Skill：数据模型差异

维度	记忆（MEMORY.md）	Skill（SKILL.md）
存储内容	事实性信息	过程性知识
回答的问题	”世界是什么样的？"	"下次怎么干？“
典型内容	用户偏好、环境配置、项目状态	操作步骤、避坑指南、最佳实践
触发写入	memory 工具 / 手动	skill_manage 工具 / nudge
生效时机	下个 session	下个 session（重建索引后）
更新方式	追加、替换、删除条目	create / edit / patch
组织形式	两段式（Agent 笔记 + 用户画像）	分类目录 + 独立 skill 包

两个系统在 Hermes 里的定位：记忆是”事实”（用户喜欢 pnpm），skill 是”过程”（用 pnpm 搭建 monorepo 的步骤）。两者共享同一个 nudge 机制触发，但写入路径和处理逻辑完全分开。

3.6 对话历史检索

Hermes： session_search 工具使用 SQLite FTS5 全文检索。Agent 可以主动搜索过去所有 session——“我们之前讨论过什么什么”——生成摘要后注入当前上下文。用的时候能回忆起来，不用的时候不占空间。

压缩后的子 session 通过 parent_session_id 链回原 session，跨 session 也能追溯到完整对话链。

OpenClaw： 无内置跨 session 搜索。依赖 MEMORY.md 中的摘要记录。如果 Agent 当时没记，后面就找不到了。

---

四、关键设计决策总结

决策	Hermes 的选择	OpenClaw 的选择	本质取舍
记忆注入时机	session 开始冻结	每轮刷新	性能 vs 即时性
记忆容量	硬上限 2200+1375	无上限	精炼 vs 完整
外部记忆后端	插件架构 + 单实例	无插件	扩展性 vs 简单
技能管理	子 Agent 自动收集	手动	自动化 vs 可控
对话历史	FTS5 持久化 + 搜索	无内置	历史可追溯 vs 无额外存储
人格体系	单层 SOUL.md	三层 SOUL/IDENTITY/USER	简单 vs 分层
上下文工程	保 Prefix Cache	保实时	成本 vs 响应

---

五、适用场景

Hermes 更合适的场景：

• 24/7 后台运行，对成本敏感
• 需要可靠的跨 session 记忆
• 工作流固定，需要技能复利累积
• 用户习惯先思考再做，不要求即时感知

OpenClaw 更合适的场景：

• 交互式 IDE 使用，写完就想生效
• 需要精细的人格分层（多人格切换）
• 对实现简单性要求高，不关心插件扩展
• 单 session 为主，跨 session 需求少

两个框架在记忆逻辑上的差异，说到底就是一句话：你是愿意多付一点钱换来即时生效，还是愿意等一轮换来稳定省心。 没有对错，取决于你的使用模式。

---

参考资料

• Hermes Agent 官方架构文档
• Inside Hermes Agent: How a Self-Improving AI Agent Actually Works
• OpenClaw’s memory is unreliable, and you don’t know when it will break
• OpenClaw GitHub