Hermes 存储栈全景分析: 从记忆到知识的全自动流水线

一、全景总览：Hermes 处理用户输入的全自动流程链路

当用户通过 Telegram（或 CLI/Discord）发送一条消息给 Hermes，Agent Core 按以下顺序自动触发多层存储系统的读写：

用户输入 ----> [1] Gateway 接收
                |
                +---> [2] 系统提示词构建 (注入 MEMORY 扁平文件)
                |      +---> MEMORY.md (memory tool 写入, ~2.3KB)
                |      +---> USER.md (用户画像, ~1.2KB)
                |
                +---> [3] 上下文注入 (Holographic 事实库检索)
                |      +---> memory_store.db (fact_store检索, 50条)
                |      +---> FTS5 全文搜索 + HRR 向量近似
                |      +---> 实体解析 (entity resolution)
                |
                +---> [4] LLM 推理 (deepseek-v4-flash)
                |      +---> 调用 Tools: terminal, delegate_task, cronjob
                |      +---> 调用 MCP Tools: gbrain, trilium, pinchtab
                |
                +---> [5] Tool 调用中触发的其他存储
                |      +---> GBrain MCP -> 语义检索 (search/query/get_page)
                |      +---> Trilium MCP -> 层级知识库读写
                |      +---> Obsidian MCP/文件 -> MD 笔记读写 (待配置)
                |      +---> Git 仓库 -> 代码版本管理
                |      +---> MySQL -> 业务数据查询
                |
                +---> [6] 会话存储
                |      +---> state.db (128MB, 对话历史)
                |      +---> response_store.db (响应缓存)
                |
                +---> [7] 输出 -> Telegram 回复

注: [2] 和 [3] 是双轨并行的, 互不替代。memory 工具写扁平文件, fact_store 工具写 SQLite DB。

二、各存储栈独立分析

1. Hermes 内置扁平文件记忆 (memory 工具)

本质: Flat-file key-value store, 两个 MD 文件 + 字符上限 (8800/5500).

维度	说明
Pipeline 角色	每轮对话开始时, 系统提示词直接从 MEMORY.md/USER.md 读取内容注入到 LLM 上下文。这是 Hermes 记得你的最基本通道。
生命周期	永久保存, 除非手动清理或 config 调整限额。无 TTL 机制。
数据生长机制	每次 Agent 调用 memory(action='add') 时追加内容到文件末尾, 按 sec 符号分隔。达到字符上限 (8800/5500) 后需手工裁剪。字符硬限制。
交互链	memory tool -> MEMORY.md/USER.md -> system prompt -> LLM。无搜索, 无查询, 每轮全量注入。

2. Holographic 记忆 (fact_store 工具)

本质: SQLite DB + FTS5 全文搜索 + HRR 代数向量 (零神经网络, 纯 CPU us 级计算)。

维度	说明
Pipeline 角色	Agent 在构建上下文时调用 fact_store 辅助检索。支持: 关键词搜索 (FTS5), 实体探查 (probe entity), 多实体推理 (reason across entities), 矛盾检测。按需检索, 非全量注入。
生命周期	永久保存于 memory_store.db (436KB, 50条事实)。带 trust_score 和 fact_feedback 训练机制。
数据生长机制	fact_store(add) -> 写入 facts 表 -> 计算 HRR 1024维向量 (8KB/条) -> 更新 FTS5 -> 关联实体 -> 更新 memory_banks。无字符上限。
交互链	fact_store tool -> memory_store.db -> FTS5+HRR 双管道 -> LLM 上下文。FTS5 是主力, HRR 做结构近似。

3. GBrain (Garry Tan 个人知识脑)

本质: Postgres-native 混合 RAG (嵌入向量 + 关键词), Bun.js 实现。以 MCP Server 形式集成到 Hermes。

维度	说明
Pipeline 角色	知识检索层。作为 MCP Server (stdio) 运行在 Hermes 内部, search/query/get_page 工具直接注册到 Hermes 工具列表。AI 在对话中检测到实体后主动调用 MCP 工具查询, 结果注入上下文回复。
生命周期	Persistent in brain.pglite (PGLite 引擎), 可重新导入重建。单进程, 适合 < 1000 文件。每日 1AM 由 cron master 自动维护 (dream)。
数据生长机制	两条路径: (A) Trilium 笔记每日自动同步 (sitemap → ETAPI → gbrain import); (B) 手动 gbrain put 直接写 PGLite DB。嵌入向量经 V100 生成, pgvector 存储, RRF 混合搜索。
交互链	Agent -> MCP tool (search/get_page) -> gbrain serve (stdio) -> PGLite -> 结果。MCP 原生集成, 非 cron 旁路。

4. Trilium (层级知识库)

本质: 层级笔记数据库, 独立 Docker 容器运行 (外部服务器)。通过 Hermes 内置 MCP 适配器 (ETAPI 封装) 提供工具。

维度	说明
Pipeline 角色	长期结构化知识层。Agent 按需调用 MCP tools (search_notes, read_note, create_note, update_note), 同时是知识库外部发布层 (share links)。Trilium 笔记每日通过 cron master 同步到 gbrain 做语义检索。
生命周期	数据永久保存在 Trilium Docker 容器内。创建到删除完全由用户/Hermes控制。
数据生长机制	MCP create_note / update_note 新增和编辑笔记。Sitemap cron (每日1AM) 自动爬取 ~519 个 URL 并更新 sitemap.xml。
交互链	Agent -> Hermes MCP tools -> ETAPI REST -> Trilium Docker。旁路: cron master 任务 2 (trilium-sync) 批量导入 gbrain。

5. Obsidian（分析 — 未配置）

本质: 本地优先的 Markdown 笔记系统。支持 [[wikilink]]、YAML frontmatter、标签、图谱视图。
状态: 分析阶段, 未实际部署。

维度

分析

Pipeline 角色

三种潜在集成模式, 可叠加使用:

A. MCP Server（推荐, 结构化访问）
Obsidian 安装 Local REST API 社区插件 → 暴露 REST 端点 → Hermes 通过 obsidian-mcp（社区项目）注册为 MCP 工具。
工具: search, read, write, create, delete 笔记。最接近 Trilium MCP 的体验。

B. 直接文件访问（最简, 无中间件）
Obsidian vault 目录通过 volume 映射或网络共享挂载到 Hermes 容器 → Hermes 直接 read_file/write_file/search_files 操作 .md 文件。
优点: 零部署, 读写速度最快。缺点: 无结构化 API, 无搜索索引。

C. gbrain 同步桥（语义检索）
将 Obsidian vault 的 .md 文件定时同步到 gbrain, 与 Trilium 笔记统一在 gbrain 语义搜索。
管道: vault/ 目录 → rsync/cron → gbrain import → extract links → embed。

与 Trilium 对比

	Trilium	Obsidian
API 协议	ETAPI (REST) 原生	需插件 + MCP 桥接
文件格式	私有 HTML 存储	纯 .md, 原生可读
[[wikilink]]	❌ 内容中无 wikilink	✅ 原生支持, gbrain extract links 可直接利用
部署形态	独立 Docker 容器	桌面应用 + vault 目录
公开分享	✅ shareAlias / share 链接	需 Publish 插件或第三方

对 gbrain 的价值

关键差异: Obsidian 笔记原生包含 [[wikilink]], 这正好是 gbrain extract links 需要的格式。

当前 Trilium 笔记缺少 wikilink 导致 gbrain 的 graph_coverage 和 brain_score 偏低。 Obsidian 数据源的加入可显著提升这些指标:
- gbrain extract links 能扫描到 Obsidian 笔记间的引用关系
- 知识图谱覆盖率从 0% 提升到可度量水平
- brain_score 中 link coverage 部分可获得有效分数

估值增量: 若导入 200+ 篇含 wikilink 的 Obsidian 笔记, 预估 graph_coverage 从当前 ~5% 升至 30-50%, brain_score 从 ~46 升至 60+。

Hermes 集成方式

推荐: 同时启用 A + C:
- A (MCP): 安装 Obsidian Local REST API 插件 + 配置 obsidian-mcp → Hermes tools 自动获得 search_notes / read_note / write_note 等工具。AI 在对话中直接读写 vault。
- C (gbrain): vault .md 目录通过 rsync 同步到 gbrain 可读路径 → 加入 gbrain import 管道 → Obsidian 笔记和 Trilium 笔记在同一 gbrain 中统一语义检索。

路径 B (直接文件访问) 作为 fallback, 无需额外配置。

同步管道设计 (参考)

仿照 trilium-sync.py 的 sameet 驱动模式, 但使用文件系统变化检测:

  obsidian-sync.sh (每日 cron):
    1. rsync vault/ → /opt/data/obsidian-brain/
    2. gbrain import /opt/data/obsidian-brain/ --no-embed
    3. gbrain extract links --source db
    4. gbrain embed --stale

或更轻量的方案: Hermes cron master 添加任务 5, 在 trilium-sync 之后执行。

交互链（最佳路径）

Agent -> MCP tool (search/read/write_note) -> obsidian-mcp -> Local REST API -> vault .md
Agent -> MCP tool (gbrain search) -> gbrain (含 Obsidian 笔记内容)

6. Git 仓库

本质: 代码和配置的版本化存储, Hermes 通过 terminal/git CLI 与之交互。

维度	说明
Pipeline 角色	代码开发基础层。terminal(git) 执行 clone/commit/push/PR。技能外部来源 (hermes skills tap add REPO)。--worktree 模式并行管理。
生命周期	完全由 git 控制。Hermes 只是 git CLI 调用者, 不管理生命周期。
数据生长机制	git commit/push 产生增量历史。由代码提交量和二进制文件决定。
交互链	Agent -> terminal(git) -> git CLI -> 远程 GitHub/GitLab。

7. MySQL 数据库

本质: 关系型数据库, 通过 terminal(mysql client) 或 MCP 访问。当前环境未配置。

维度	说明
Pipeline 角色	业务数据查询/写入层。terminal(mysql -e) 或 MCP-for-MySQL 执行 SQL。读取已有业务系统结构化数据。
生命周期	MySQL 实例独立运行, Hermes 仅做客户端访问。
数据生长机制	INSERT/UPDATE 由 Hermes 在推理中生成。依赖表结构和访问凭证。
交互链	Agent -> terminal("mysql -e 'SELECT ...'") -> MySQL -> stdout -> 上下文。或 MCP-for-MySQL。

三、分层作用链 (热 -> 温 -> 冷)

+-- 热层 (每轮对话必用) ----------------------------------------------------+
|                                                                           |
|  MEMORY (扁平文件)   <->   Holographic (SQLite)                           |
|   注入: 每轮全量            注入: 按需 FTS5+HRR 检索                      |
|   写入: memory tool          写入: fact_store tool                         |
|   上限: 8800 字符            上限: 仅磁盘                                 |
|                                                                           |
+-- 温层 (按需触发, MCP 统一接口) -------------------------------------------+
|                                                                           |
|  用户输入分析 -> AI 检测实体 -> 决定调用哪些 MCP 工具                      |
|       |                                                                    |
|       +---> GBrain MCP     <- 混合 RAG 语义检索 (search/get_page/query)  |
|       +---> Trilium MCP    <- 层级知识库读写 (search_notes/read_note)     |
|       +---> Obsidian MCP   <- MD 笔记 API (search/read/write) [待配置]   |
|       +---> Obsidian 目录  <- 文件直接访问 (file tools) [待配置]           |
|       +---> Git            <- 代码开发 (terminal + git CLI)                |
|       +---> MySQL          <- 业务数据 (terminal / MCP)                    |
|                                                                           |
+-- 冷层 (后台持久化) ------------------------------------------------------+
|                                                                           |
|  state.db (128MB)           -> session_search 跨会话回溯                  |
|  sessions/ 目录              -> 对话历史文件                               |
|  kanban.db (看板)            -> 任务管理                                   |
|  response_store.db (缓存)    -> 减少重复 LLM 调用                         |
|                                                                           |
+---------------------------------------------------------------------------+

四、数据生长统计与磁盘占用

存储系统	当前体积	介质	增长模式
扁平文件记忆	~3.5KB	~/.hermes/memories/	字符硬上限, 需手动清理
Holographic DB	436KB	memory_store.db	50条事实, 8KB/条定长向量
对话历史	128MB	state.db	持续增长, 90天自动清理
Trilium 知识库	MB~GB级	Docker 容器内	随笔记创建持续增长
GBrain	~KB级	brain.pglite	随 Trilium 同步 + 手动写入增长
Obsidian vault	— (未配置)	需配置 vault 目录或 Docker 映射	随笔记创建增长
Kanban	100KB	kanban.db	随任务量增长

五、当前架构的关键洞察

1. 双轨记忆是设计特征, 不是 bug
memory 工具写扁平文件, fact_store 工具写 holographic SQLite。并行的两个独立系统, 互不替代。切换 memory.provider 不会迁移旧数据也不会改变 memory 工具的写入目标。

2. FTS5 是 Holo 记忆的主力, HRR 是辅助
Holographic 的核心搜索能力来自 SQLite FTS5 全文检索。HRR 向量提供轻量结构近似 (无神经网络的语义相似度)。与 GBrain (真嵌入向量模型) 完全不同。

3. MCP 是温层存储的统一接口
GBrain、Trilium、Obsidian 都通过 MCP 协议统一暴露给 Hermes。这是 AI 存取外部数据的主要架构模式。

4. Cron master 仍是知识库维护的调度中心
当前 Hermes cron master 统一调度 4 个任务 (session-transcripts → trilium-sync → gbrain dream → sitemap), 各组件自身不含有维护能力。这是改善方向。

5. gbrain 是统一语义检索层
无论数据源是 Trilium、Obsidian 还是手动写入, gbrain 提供唯一入口进行语义检索。多个作者工具, 一个搜索引擎。

6. Obsidian 是唯一能提升 gbrain graph_coverage 的数据源
当前 Trilium 笔记不含 [[wikilink]], gbrain 的 link extraction 无法生成知识图谱。Obsidian 原生 wikilink 可以填充这个空白, 预期 brain_score 从 ~46 可升至 60+。

7. 温热冷三层天然对应访问频率
热层 (memory + holographic) 每轮自动注入/检索。温层 (GBrain/Trilium/Obsidian/Git/MySQL) 按意图触发。冷层 (state.db/sessions) 仅跨会话回溯。

六、最佳架构演进方向 (低耦合·高内聚·配置化)

当前架构中, Hermes 承担了过多的调度职责 (cron master 管理所有组件的维护)。最佳架构应让每个组件自含自管, 通过 MCP 协议互联。

目标架构（含 Obsidian）

┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ Hermes       │   │ Trilium      │   │ gbrain       │   │ Obsidian     │
│ Container    │   │ Container    │   │ Container    │   │ (Host/卷)    │
│              │   │              │   │              │   │              │
│ [角色]       │   │ [角色]       │   │ [角色]       │   │ [角色]       │
│ 对话编排     │   │ 笔记编辑    │   │ 语义检索     │   │ MD 笔记编辑  │
│              │   │              │   │              │   │              │
│ [暴露]       │   │ [暴露]       │   │ [暴露]       │   │ [暴露]       │
│ · MCP client │   │ · ETAPI      │   │ · MCP HTTP   │   │ · MCP (通过  │
│ · Skills/Mem │   │ · MCP 侧车   │   │ · CLI 内部   │   │   obsidian-  │
│              │   │              │   │              │   │   mcp 桥接)  │
│ [维护]       │   │ [维护]       │   │ [维护]       │   │              │
│ · 写         │   │ · 备份 cron  │   │ · dream cron │   │ [维护]       │
│   transcripts│   │              │   │ · embed cron │   │ · rsync     │
│ · 无知识     │   │              │   │ · 轮询       │   │   vault →   │
│   库维护     │   │              │   │   Trilium    │   │   gbrain    │
│              │   │              │   │   ETAPI      │   │              │
│              │   │              │   │              │   │              │
│              │   │              │   │ · 轮询       │   │              │
│              │   │              │   │   Obsidian   │   │              │
│              │   │              │   │   vault 目录 │   │              │
└──────┬───────┘   └──────┬───────┘   └──────┬───────┘   └──────┬───────┘
       │                  │                  │                  │
       │ MCP     MCP      │                  │   rsync vault    │
       │ search/ (trilium │  ETAPI 轮询      │   (gbrain 主动)  │
       │ query)  /侧车)   ◄──────────────────┘                  │
       │                  │                                     │
       ▼                  ▼                                     ▼
    ┌──────────────────────────────────────────────────────────────────┐
    │               Docker Network (内部) + 共享卷                      │
    │          MCP × ETAPI × rsync × 共享卷                            │
    └──────────────────────────────────────────────────────────────────┘

关键原则: gbrain 作为统一语义检索层, 主动轮询所有数据源 (Trilium ETAPI + Obsidian vault 目录), 统一提供 search/query/get_page。Hermes 只消费 MCP, 不管理知识库的同步。

Obsidian 在架构中的位置

数据源	作者工具	AI 接口	同步到 gbrain	独特价值
Trilium	Web UI	MCP (ETAPI封装)	ETAPI 轮询	层级结构 + 公开分享
Obsidian	桌面 App	MCP (REST桥接)	rsync vault 目录	[[wikilink]]图谱 + 纯 md 可读
手动	AI 对话	gbrain put	即时写入	对话中产生的知识即时入库

核心变化（含 Obsidian）

维度	当前	最佳	原则
gbrain 位置	Hermes 容器内 (stdio MCP)	独立容器 (HTTP MCP)	低耦合
同步调度	Hermes cron master 管全部	各容器自管	高内聚
trilium MCP	Hermes 内置适配器	trilium-mcp 侧车 (独立进程)	可复用
obsidian MCP	未配置	obsidian-mcp 桥接 (Local REST API)	可复用
obsidian→gbrain	未配置	rsync vault + gbrain import	统一检索
gbrain DB	PGLite (单进程, 无 HTTP MCP)	pgvector 或 PGLite+socat	配置化
数据流	Hermes 编排双向	单向 (所有 → gbrain 轮询)	低耦合

数据流 (全单向)

Trilium (笔记)  ── ETAPI 轮询 ──→  gbrain (语义检索)
Obsidian (vault) ── rsync ─────→  gbrain (语义检索 + [[wikilink]] 图谱)
Hermes (会话)   ── 共享卷 ────→  gbrain (dream synthesize)

Hermes ←─ MCP ── gbrain (search/query/get_page)
Hermes ←─ MCP ── Trilium (search_notes/read_note/create_note)
Hermes ←─ MCP ── Obsidian (search/read/write via obsidian-mcp)

无循环依赖, 无双向引用。每个容器开或关不影响其他容器。gbrain 统一维护所有数据源的同步和检索。

迁移路径

Phase	内容	成本
1	gbrain 独立 Docker + socat TCP→stdio + 内部 cron 自管维护	1-2 天
2	gbrain 迁 pgvector → 原生 HTTP MCP, HNSW 索引	按需
3	trilium-mcp 侧车容器 + obsidian-mcp 桥接部署	1 天
4	Obsidian vault → gbrain 同步管道 + extract links + embed	0.5 天
5	Hermes cron master 瘦身: 只留 Hermes 自身任务	0.5 天

七、一句话定位

扁平文件记忆 - "Hermes 的便利贴": 最简最直接, 每轮全量注入, 有字符上限。

Holographic DB - "Hermes 的笔记本": 结构化持久, 按需检索, 零外部依赖的代数记忆。

GBrain - "外挂知识大脑": 统一语义检索层, 聚合 Trilium + Obsidian + 手动写入, MCP 原生集成。

Trilium - "层级知识库": 层级笔记 + ETAPI + MCP, 每日同步到 gbrain。公开分享。

Obsidian - "图谱笔记库": 原生 [[wikilink]], obsidian-mcp 桥接 + gbrain 同步, 可提升 graph_coverage (待配置)。

Git - "代码的时光机": 版本化管理, terminal 工具调用。

MySQL - "业务数据仓库": 关系型查询, terminal/MCP 调用 (当前未配置)。

📅 最后更新: 2026-05-21 · 新增: Obsidian 完整分析 (§2-§7) · 最佳架构含 Obsidian