Hermes 的记忆层有 8 种实现，我为什么选了最反常识的那个

最近在折腾 Hermes Agent，发现一个有意思的事：它的记忆层不是一个方案，而是 8 个可以热插拔的 Provider。

存储方式从最古老的 Markdown 文件，到最时髦的知识图谱；部署方式从一个 SQLite 文件，到一整套云端托管。更骚的是，其中有一个叫 Holographic 的，既不用向量，也不用图谱，用的是一种我大学数值分析课上睡过去的数学——HRR（Holographic Reduced Representations）。

用了一圈之后，我把默认配置改成了 Holographic。这篇就来聊聊为什么。

先把 8 个方案摆上桌

Hermes 的 Memory Provider 设计很克制——它没想给你"一个打天下"的方案，而是承认不同场景需要不同的存储和检索策略。

我按"有多轻"排了个序，从最轻到最重：

排序逻辑很简单：外部依赖越少越轻，初始化越傻瓜越轻，检索越不依赖 LLM 越轻。

三种存储范式，三种哲学

把 8 个方案按存储方式归类，会发现它们其实代表了三种完全不同的"记忆哲学"。

范式一：文档即记忆（Markdown）

代表：ByteRover、Hermes 自带的 MEMORY.md

最朴素也最人本的设计——记忆就是一堆 Markdown 文件，你能读，Agent 也能读。

.brv/context-tree/
├── authentication/
│   ├── context.md          # 域级概览
│   └── jwt-implementation/
│       └── context.md      # 主题级概览

ByteRover 的聪明之处在于分层加载：L0 摘要（100 tokens）→ L1 概览（2K tokens）→ L2 全文。Agent 先看摘要，需要细节再深入，官方说能省 80-90% 的 token。

优点：透明、可读、可 Git 版本控制、离线可用。 缺点：检索基本靠关键词或 LLM 读全文，模糊语义搜索是短板。

范式二：向量即记忆（Vector）

代表：Mem0、Honcho、RetainDB、Supermemory

当下最主流的方案。把每条记忆 embedding 成向量，检索时算余弦相似度。

Mem0 是这个流派的明星（GitHub 25k+ stars），管线很清晰：

对话 → LLM 提取事实 → 冲突检测去重 → 存入向量库 → 检索时向量召回 + reranker

优点：模糊语义搜索强，"类似这样的有哪些"这种问题答得好。 缺点：要么自己跑 Qdrant/pgvector，要么上云端付钱；检索精度其实不如宣传的那么神——LongMemEval 基准上 Mem0 只有 67.6%，是所有方案里最低的。

范式三：图谱即记忆（Graph）

代表：Hindsight、Mem0 的图模式

不只是记事实，还记事实之间的关系。"小明养了橘子" + "橘子是一只猫" + "猫通常讨厌洗澡" ——图谱能推理出"小明家可能需要宠物沐浴服务"这种跨三条边的关联。

Hindsight 是这条路的标杆，本地嵌入式 PostgreSQL + 知识图谱 + 多策略检索（语义 + BM25 + 图谱 + 时序）+ reranker，LongMemEval 拿到 94.6%。

优点：复杂关系推理强，支持时序演变。 缺点：最重——要 PostgreSQL，要 LLM 抽实体关系，检索延迟最高。

番外篇：代数即记忆（HRR）

代表：Holographic（独一份）

这就是那个反常识的方案。它既不算向量，也不算图谱，而是把记忆表示成可叠加的复值向量，检索时不是算相似度，是直接做代数运算。

我第一次看文档的时候反应是："这不就是数值分析课睡过去那节课的内容吗？"

但用起来真的很爽。

Holographic 实测：亚毫秒检索是怎么做到的

讲点真实使用体验。

一条命令开跑

hermes memory setup   # 选 holographic
hermes config set memory.provider holographic

它需要的东西只有两样：

• • ✅ SQLite（Python 自带）
• • ✅ NumPy（可选，没有的话降级到 FTS5）

不需要：Docker、PostgreSQL、Redis、Qdrant、API Key、云账号、网络连接。

所有数据存在 ~/.hermes/memory_store.db 一个文件里。

HRR 代数检索到底在干嘛

这个我多花点篇幅讲，因为这是 Holographic 最特别的地方，也是文档里语焉不详的部分。

先回顾传统向量检索怎么工作：

1. 1. 用预训练模型（BGE、OpenAI embedding）把每条记忆 embedding 成一个向量
2. 2. 你提一个问题，把问题也 embedding
3. 3. 把问题向量和库里每一条算余弦相似度
4. 4. 取最相似的 top-k 返回

复杂度 O(N×D)：N 是库里记忆条数，D 是向量维度。记忆越多，查询越慢。而且离不开一个预训练 embedding 模型。

HRR 走了完全不同的路——没有预训练模型，也没有向量库。它靠哈希函数实时生成向量，把所有记忆叠加进同一个 1024 维向量里，查询时直接"解出"答案。

第 0 步：每个词的 1024 维向量从哪来？

这是最反常识的点。传统 RAG 要靠大模型预训练生成词向量；HRR 完全不用——它对每个单词用一个固定的哈希函数实时算出来：

DIM = 1024  # 源码里硬编码的全局常量

def encode_atom(word: str):
    # 1. 拿单词文本做 SHA256，算出固定随机种子
    seed = int(sha256(word.encode()).hexdigest()[:16], 16)
    # 2. 用这个种子生成 1024 维的随机相位向量
    rng = np.random.default_rng(seed)
    return rng.uniform(0, 2*np.pi, size=DIM)

两个关键性质：

• • 确定性：同一个词（比如 橘子），不管什么时候、重启多少次程序，算出来的 1024 维向量永远一模一样——因为种子来自哈希。
• • 近似正交：不同单词的哈希种子不同，生成的向量在 1024 维空间里天然几乎垂直（相似度接近 0）。这是 HRR 卷积运算的数学前提。

这些向量不存磁盘。运行时在内存里开个 cache = {单词: 向量} 字典，第一次用到某个词就算一次塞进去，下次直接读。重启清空也没关系，再算一遍还是同一个向量。

存的时候：把事实揉成向量，全部相加

每条事实先拆成 (主语, 关系, 宾语) 三元组。比如存"小明养了橘子"：

1. 1. 拆三元组：(小明, 养了, 橘子)
2. 2. 三个词分别 encode_atom 拿到 3 个 1024 维向量（缓存命中就直接读）
3. 3. 用圆周卷积 ⊛ 把三个向量揉成一个 binding（仍然 1024 维）：

   binding = vec(小明) ⊛ vec(养了) ⊛ vec(橘子)

4. 4. 把这个 binding 加到全局记忆向量 M 上：

   M = M + binding

5. 5. 落盘：原始三元组文本和 binding 写进 SQLite 的 fact_store 表，更新后的 M 写进 hrr_global_state 表（只有一行，专门存这 1024 个浮点数）。

最关键的一步来了——所有事实的 binding 直接相加，全部叠进同一个 1024 维向量 M：

M = binding(小明养了橘子)
  + binding(橘子讨厌洗澡)
  + binding(小明给橘子梳毛)
  + ...

不管你存了多少条事实，M 永远是 1024 维。所有记忆都"叠"在这一个向量里，互相干扰但能近似恢复。这是 HRR 最反直觉的地方：信息不是按条目存的，而是按叠加存的。

查的时候：给一个 cue，反卷积解出答案

你想知道"小明养了什么"，构造一个 cue（提示向量）：

cue = vec(小明) ⊛ vec(养了)          # 用相同的卷积运算造钥匙
result = unbind(M, cue)              # 反卷积，把答案分量"解"出来

数学上，反卷积会"对齐"到当初绑定时用的 vec(橘子) 这个分量；其他事实因为是用不同的 key 绑定的，对齐后变成背景噪声。最后把 result 跟 cache 里所有原子向量（小明、橘子、洗澡、梳毛……）算一次相似度，最接近的就是答案——橘子。

为什么能做到亚毫秒

整个查询就是几次固定大小的向量运算（卷积 + 反卷积 + 点积），没有"扫表"这一步。复杂度是 O(D)，D 固定为 1024。无论库里有 100 条还是 10 万条事实，单次查询的计算量完全一样。

加上 M 常驻内存（SQLite 那份只是持久化备份，重启时加载回内存），实际查询连磁盘都不用读。

这就是"亚毫秒"的来源——它把检索问题变成了固定维度的代数运算。

代价是：它是精确匹配友好，模糊查询不友好。问"小明养了什么"答得好，因为这是按 key 取 value；问"类似橘子的宠物有哪些"答不上来，因为原子向量是随机哈希生成的，词与词之间没有语义关系（橘子 和 猫 的向量相似度，跟 橘子 和 键盘 的相似度一样，都接近 0）。

双引擎：HRR + FTS5

Holographic 其实很务实，没把宝全押在 HRR 上。它内部是混合检索：

9 个操作里有 4 个是 HRR 独门的，剩下的是常规 CRUD + 关键词搜索。

信任评分：非对称惩罚的小心思

每条事实有一个 0.0–1.0 的 trust 分数，默认 0.5。用户反馈：

• • helpful → trust += 0.05
• • unhelpful → trust -= 0.10

注意惩罚是奖励的两倍。这是个聪明的设计——记忆系统最大的敌人不是漏记，而是噪音累积。一旦确认错误，要快速清掉；确认有用，慢慢加。

这个理念和我之前研究 OpenClaw 的 Dreaming 巩固机制是相通的：重要的事说三遍才记住，错的事一次就纠偏。

一段真实的使用

举个跟工作无关的例子——假设你要 Agent 帮你管理宠物信息，让它记几条事实：

> fact_store(action='add', content='小明养了橘子')
> fact_store(action='add', content='橘子讨厌洗澡')
> fact_store(action='add', content='小明每周给橘子梳毛')

下次会话，Holographic 自动从这些事实里抽出实体：小明、橘子、洗澡、梳毛。然后你可以这么查：

> fact_store(action='reason', entities=['小明', '橘子'])
→ 返回："小明养了橘子" + "小明每周给橘子梳毛"

reason 是 HRR 的杀手锏——它能回答"同时涉及 A 和 B 的事实"。这是纯关键词搜索做不到的，因为单条事实里可能根本没同时出现这两个词。

SQLite 里能看到什么

sqlite3 ~/.hermes/memory_store.db \
  "SELECT fact_id, content, trust_score FROM facts ORDER BY trust_score DESC LIMIT 10;"

fact_id | content                       | trust_score
--------+-------------------------------+------------
f_0042  | 小明每周给橘子梳毛              | 0.65
f_0039  | 橘子讨厌洗澡                    | 0.55
f_0038  | 小明养了橘子                    | 0.50

清清楚楚，没有任何黑盒。这一点对我是决定性的——我不希望我的"记忆"是一坨我自己都看不懂的向量矩阵。

我选 Holographic 的真实理由

讲了这么多技术细节，说点朴素的。

1. 我是懒人。 配 PostgreSQL、写 Docker Compose、注册云账号、申请 API Key——这些事每多一步，"用起来"的概率就降一半。Holographic 零配置，装好 Hermes 就能用。

2. 经常离线。 飞机上、高铁上、咖啡馆破 Wi-Fi，都是常态。云端方案在这些场景下直接报废。

3. 想要数据主权。 我的记忆是我的。一个 SQLite 文件，我能备份、能 Git 跟踪、能用 sqlite3 命令查、能写脚本批量改。换成云端服务，这些自由都没了。

4. 性能足够。 几百条事实的库，HRR 运算几乎瞬时。我又不是要在亿级数据上做实时推理。

5. 概念优雅但门槛低。 HRR 数学很深，但我不用懂也能用——add/search/reason 三个操作覆盖 90% 场景。

但它确实有短板

不说缺点就是软文了。

模糊语义搜索不行。 "类似 XXX 的东西有哪些"这类问题，Holographic 的 FTS5 经常答非所问。如果你重度依赖语义召回，去用 Mem0 或 Hindsight。

单用户设计。 SQLite 文件锁不支持并发写，多 Agent 同时往里塞事实会有竞争。团队场景老老实实上 Hindsight 或 ByteRover Cloud。

数据量天花板。 没做分片，几十万条会掉性能。但说实话，个人用户很难撞到这个上限——你一辈子能产生多少条值得记住的事实？

记忆提取靠会话后批处理。 不像 Mem0 有服务端 LLM 实时抽取，Holographic 默认是会话结束时一次性提取（auto_extract），实时性弱一些。

选型决策树

把所有方案压缩成一句话：

• • 追求极致轻量、离线、可控 → Holographic（你正在看的这篇）
• • 想要 Markdown 透明 + Git 版本控制 → ByteRover
• • 要图谱推理 + 高精度（94.6%） → Hindsight
• • 自托管团队、要省 token → OpenViking
• • 最快启动、懒得管 → Mem0 云端版
• • 多 Agent 深度用户建模 → Honcho

如果还是选不出来，就用 Holographic 跑两周，跑下来你会发现——大部分人的记忆需求，根本用不到知识图谱和向量数据库。

写在最后

Hermes 这套 8 Provider 的设计给我一个启发：记忆系统没有银弹，但有合适的 trade-off。

向量数据库很酷，知识图谱很美，但"我的记忆存在一个我能打开的 SQLite 文件里，亚毫秒检索，零依赖，离线可用"——这种朴素的安全感，是任何花哨方案都换不来的。

至少对我这种个人用户，够了。

你现在的 Agent 用的是什么记忆方案？ 还是根本没配？留言聊聊，我很好奇大家在这块踩过什么坑——尤其是从向量数据库换回 Markdown 的反向操作，是不是只有我一个人。

本文基于 Hermes Agent 官方文档与源码分析，HRR 原理参考 Plate 1995 的原始论文。所有命令与配置已实测。