0x00 序※
用了一个多月的 AstrBot 之后，我换了 Hermes Agent。起因很简单：虽然给 AstrBot 接了记忆插件，但记忆不好用——命中率低、经常记不准，用起来像鸡肋。Hermes 给了我一个真正的记忆引擎，但它是个黑盒：事实存在 SQLite 里，只有模型自己能查。直到我把这份记忆映射进 Trilium 知识图谱，一切才豁然开朗。
AstrBot 不是没有记忆方案。我用的记忆插件是 iris_chat_memory——三层记忆架构：L1 消息缓冲（短期工作记忆，自动总结写入 L2）、L2 记忆库（FAISS + SQLite 向量检索 + 遗忘算法）、L3 知识图谱（实体关系提取 + 图增强检索），加上自动学习的用户/群聊画像。这套设计本身相当完整，理论上能做到自动记忆。
但在我的实际使用中，效果并不理想。为了让记忆更准，我还在角色卡（persona）里额外写了提示词增强：每轮对话前先"搜索记忆再回答"，对话结束再"提取关键信息保存"。即便如此，跑下来命中率还是不高：模型不是每次都记得搜，搜了也不一定搜得准，提取时还会丢上下文、记错事实。对话一长，记忆就是一笔糊涂账。
为什么选 Holographic※
所以换到 Hermes 时，我首先看的不是功能多不多，而是记忆是否原生自动。Hermes 的记忆引擎是框架层内置的：会话自动同步、结束自动提取、每轮自动检索注入，不需要我写任何提示词。自带 8 个记忆提供者，选型对比如下：
| 提供者 | 存储 | 费用 | 特点 |
|---|---|---|---|
| Honcho | 云 | 付费 | 辩证用户建模，数据过外部 API |
| Mem0 | 云 | 付费 | LLM 事实提取，数据过外部 API |
| Hindsight | 云/本地 | 免费/付费 | 知识图谱 + reflect 合成，基于 CUDA 需 GPU |
| RetainDB | 云 | $20/月 | 增量压缩 |
| ByteRover | 本地/云 | 免费/付费 | 预压缩提取 |
| Holographic | 本地 | 免费 | HRR 向量 + 信任评分，无依赖 |
最后选了 Holographic：纯本地 SQLite 存储，无外部依赖，数据完全自持；HRR 向量方案轻量，不需要 GPU，跑在 8G 内存的服务器上毫无压力。加上它自带的实体解析和信任评分机制，正好是我要的"轻量本地优先"。
选定 Holographic 的过程中，还接触过另一个主流方案。狐狸在 arch 群里推荐了他的文章《构建个人 AI 工程知识操作系统：Hermes + OpenViking 多层记忆架构实践》，把 Hermes 和字节跳动的 OpenViking 结合，用 L0/L1/L2 分层加载解决"记忆全塞 Prompt"的问题。OpenViking 的思路确实漂亮：文件系统范式（viking:// 协议）、分层上下文、目录递归检索，本质是把 Agent 的上下文当成一个可浏览的文件柜。
但我最终没有选 OpenViking，这个决定可以从分析和决策两个层面来看。
分析层面，两个方案的差异本质上是两种知识组织范式的竞争：
一是存储范式。OpenViking 是文件系统范式——树状目录，每条知识挂在一个层级路径下；知识图谱则是网状——节点 + 关系边，一条事实可以同时关联多个维度。真实世界知识是跨领域的（"这个客户是 VIP 且最近投诉过"同时属于客户运营和客诉处理），树状目录只能放一个位置，图却能天然表达这种多重归属。
二是知识资产的归属。OpenViking 是给 Agent 用的独立记忆库，意味着要再维护一套与人类知识库并行的系统；而我在 Trilium 已有 1900+ 笔记、2280+ 属性、121 条双向链接——如果让 AI 记忆和人类知识同源共生，记忆就能借用笔记网络的上下文，而不是孤岛。
三是工程成本。OpenViking 需要运行独立 server（openviking-server），生态相对早期；Trilium 我已经稳定维护多年，ETAPI 成熟，noteMap 可视化开箱即用。多养一个服务换取的能力提升，对我的场景不成比例。
决策层面，回到我自己的实际需求，两条理由就够硬：
第一，我的量级不需要分层加载，检索模型不同。OpenViking 的 L0/L1/L2 分层是面向高量级记忆的成熟设计——记忆积累到几千条、全量注入 Token 爆炸时，它确实是有力的优势。但 Holographic 的检索方式更接近启发式：按信任评分和检索命中选择性注入，我的记忆量级下成本完全可控，性能足够。这不是否定分层加载，而是场景不匹配——面向高量级的优势我暂时用不上，等记忆真涨到那个量级，再引入不迟。
第二，我需要的是图结构，不是文件树。我要的不是一个新的记忆系统，而是复用 Trilium 已有的图数据结构——节点、~关系边、#标签、noteMap、笔记网络。AI 的记忆长在同一个图里，直接借用 Trilium 的知识图谱和双向链接，这是文件树给不了的。
一句话总结：OpenViking 解决的是"记忆太多怎么高效喂"的问题，而我的问题是"记忆和知识怎么在一个图上同构"。分析上分层加载是面向高量级的好设计，但我的场景性能已足够、更需要图结构——所以最终选了 Trilium 知识图谱。
记忆引擎：HRR 全息表示※
Hermes 的记忆引擎（Holographic）核心是全息约简表示（HRR）——一个 1995 年就提出的向量符号架构。它把每个概念编码成固定维度的相位向量，用三个代数操作组合知识：
- bind（绑定）：相位相加，两个概念绑成一个复合向量——"用户 绑定 Arch Linux"
- unbind（解绑）：相位相减，从复合向量里检索——"解绑出 Arch Linux"
- bundle（叠加）：相位平均，合并多个概念成一张"记忆快照"
关键设计：每个概念用 SHA-256 确定性生成向量，跨进程、跨机器编码一致。存储落在 SQLite：facts 表（内容/信任评分/类别/标签）、entities 表（实体/类型/别名）、fact_entities 表（关系）。加上 FTS5 全文索引和 1024 维 HRR 向量，构成一个轻量完整的记忆三元组库。
为什么想把它接进 Trilium※
黑盒记忆有个实际限制：对话内可以编辑、沉淀，但不能外部观察和修改。模型记住的"用户用 Arch Linux"，在对话里可以纠正它、补充它，但想跳出对话去看全部记忆、或直接批量修改，做不到。而 Trilium 本身就是图结构——笔记是节点、~关系是边、#标签是属性，和记忆引擎的 实体-事实-关系 三元组天然同构。
更实际的需求：我在 Trilium 里攒了 1900+ 条笔记，那才是我真正想沉淀的知识。如果 AI 的记忆能和它打通，记忆就不再是进程里的临时数据，而是可以长期演进的知识资产。
双向同步的实现※
核心是一个脚本（hermes-memory-sync.py），用 ETAPI 操作 Trilium：
正向：fact_store 的实体 → Trilium 实体节点（按主机/设备/系统分域，服务挂到所属主机下）；事实 → 事实节点（带 #category/#tags/#trust）；关系 → ~runsOn/~entity 边。用 #syncKey 做幂等锚点，增量同步不重复建节点。
反向：Trilium 里改事实内容、调标签 → 回写 fact_store。冲突靠时间戳仲裁——谁最后修改谁赢，杜绝正反向循环覆盖。
定时任务每 30 分钟自动跑一次。现在打开 Trilium 的 noteMap，能直接看到记忆图谱：sad 服务器连着 14 个服务，每台主机是一个节点，事实是连接线——AI 的记忆第一次变得可见。
踩过的坑※
ETAPI 的 content 接口要 text/plain 而非 JSON，否则 500；fact_store 的时间戳是 naive、Trilium 是 aware，直接比较抛异常；正反向同步会互相覆盖，必须时间戳仲裁；Trilium 的 noteMap 关系模式只显示 ~relation 边，树形层级不画线……每个坑都沉淀成了 skill，下次不再踩。
0xFF 跋※
记忆引擎接进 Trilium 只是第一步。接下来想做几件事：一是把反向同步做得更聪明——用户手动在图谱里加关系，能自动提炼成新事实；二是让记忆的信任评分可视化，图谱里显示每条事实的置信度；三是探索 HRR 向量和 Trilium 全文检索的混合召回——语义相似和关键词精确各取所长。
AI 的记忆不再是黑盒。它长在笔记里，看得见、改得动、能沉淀。这才是记忆该有的样子。
参考资料※
- 狐狸的博客《构建个人 AI 工程知识操作系统：Hermes + OpenViking 多层记忆架构实践》——OpenViking 多层记忆架构的实践启发
- OpenViking（字节跳动开源，Context Database for AI Agents）——文件系统范式记忆库
- Hermes Agent 官方文档：Memory Providers——8 种记忆提供者对比
- Hermes Agent（Nous Research）——本文主角
- Trilium Notes——知识图谱载体
