最近在折腾 Hermes Agent，发现一个有意思的事：它的记忆层不是一个方案，而是 8 个可以热插拔的 Provider。
存储方式从最古老的 Markdown 文件，到最时髦的知识图谱；部署方式从一个 SQLite 文件，到一整套云端托管。更骚的是，其中有一个叫 Holographic 的，既不用向量，也不用图谱，用的是一种我大学数值分析课上睡过去的数学——HRR（Holographic Reduced Representations）。
用了一圈之后，我把默认配置改成了 Holographic。这篇就来聊聊为什么。
先把 8 个方案摆上桌
Hermes 的 Memory Provider 设计很克制——它没想给你"一个打天下"的方案，而是承认不同场景需要不同的存储和检索策略。
我按"有多轻"排了个序，从最轻到最重：
| 排名 | Provider | 存储后端 | 数据结构 | 部署方式 | 初始化 |
|---|---|---|---|---|---|
| 1 | Holographic | SQLite | HRR 代数向量 + 事实三元组 | 纯本地 | 零配置 |
| 2 | ByteRover | Markdown 文件树 | 层级知识树（L0/L1/L2） | 本地优先 + 可选云同步 | 装 CLI |
| 3 | Hindsight | PostgreSQL | 知识图谱 + 事实 + 实体 | 本地 daemon / Docker | hermes memory setup |
| 4 | OpenViking | 自托管文件数据库 | 文件系统层级 | 跑 openviking-server | 启动服务 |
| 5 | Mem0 | Qdrant / pgvector | 向量嵌入 + 图谱 | 云端 / Docker Compose | 简单设置 |
| 6 | Honcho | PostgreSQL + Redis | 用户表示 + 会话摘要 | 云端 / Docker/K3s | 配置较复杂 |
| 7 | RetainDB | 云端托管数据库 | 向量 + BM25 索引 | 仅云端 | API Key |
| 8 | Supermemory | 云端托管数据库 | 向量 + 会话图谱 | 仅云端 | API Key |
排序逻辑很简单：外部依赖越少越轻，初始化越傻瓜越轻，检索越不依赖 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. 用预训练模型（BGE、OpenAI embedding）把每条记忆 embedding 成一个向量
- 2. 你提一个问题，把问题也 embedding
- 3. 把问题向量和库里每一条算余弦相似度
- 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. 拆三元组：
(小明, 养了, 橘子) - 2. 三个词分别
encode_atom拿到 3 个 1024 维向量（缓存命中就直接读） - 3. 用圆周卷积
⊛把三个向量揉成一个 binding（仍然 1024 维）：binding = vec(小明) ⊛ vec(养了) ⊛ vec(橘子)
- 4. 把这个 binding 加到全局记忆向量 M 上：
M = M + binding
- 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 上。它内部是混合检索：
| 引擎 | 擅长 | 操作 |
|---|---|---|
| HRR 代数 | 实体关系组合查询 | probe / related / reason / contradict |
| FTS5 全文 | 关键词模糊匹配 | search |
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 文件里，亚毫秒检索，零依赖，离线可用"——这种朴素的安全感，是任何花哨方案都换不来的。
至少对我这种个人用户，够了。
