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: trilium, pinchtab
                |
                +---> [5] Tool 调用中触发的其他存储
                |      +---> Trilium MCP -> 知识库读写
                |      +---> GBrain (cron同步) -> 混合 RAG 检索
                |      +---> Git 仓库 -> 代码版本管理
                |      +---> MySQL -> 业务数据查询
                |      +---> Obsidian MCP/目录 -> 笔记读写
                |
                +---> [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 实现, 独立运行于 Hermes 之外。

维度	说明
Pipeline 角色	侧通道 (旁路) 知识库。不直接参与对话上下文注入。通过 cron 定时脚本 (gbrain.sh) 或手动触发 gbrain query 使用。
生命周期	Persistent in brain.pglite (PGLite 引擎), 可重新导入重建。单进程, 适合 < 1000 文件。
数据生长机制	gbrain import -> 嵌入向量 (AI Gateway) -> pgvector 存储 -> RRF 混合搜索。随导入文档数增长。
交互链	Hermes cron -> gbrain.sh -> query/search -> stdout -> 回传 Hermes。或 Telegram -> terminal -> gbrain。

4. Trilium MCP (知识库)

本质: 层级笔记数据库, MCP 协议 (Node.js stdio) 直接调用, 运行在独立 Docker 容器中。

维度	说明
Pipeline 角色	长期结构化知识层。Agent 按需调用 MCP tools (search_notes, read_note, create_note), 同时是知识库外部发布层 (share links)。
生命周期	数据永久保存在 Trilium Docker 容器内。创建到删除完全由用户/Hermes控制。
数据生长机制	MCP create_note 新增笔记。Sitemap cron (每日1AM) 自动爬取 ~519 个 URL。随笔记创建持续增长。
交互链	Agent -> MCP tool -> Node.js (trilium-mcp) -> HTTPS ETAPI -> Trilium Docker。旁路: cron 定期 sitemap。

5. 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。

6. 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。

7. Obsidian MCP

本质: 通过 MCP 协议让 Hermes 直接读写 Obsidian vault。当前未配置。

维度	说明
Pipeline 角色	Markdown 笔记的 API 层。MCP 封装 Obsidian REST API, 搜索/读取/创建/修改 vault 笔记。
生命周期	MCP 进程随 gateway 启动/停止。笔记数据由 Obsidian vault 管理。
数据生长机制	MCP create/write 新建/修改 .md 文件。被 Obsidian 客户端和文件系统直接访问。
交互链	Agent -> MCP Tool -> MCP Server -> Obsidian REST API -> 结构化内容。

8. Obsidian Markdown 文件目录映射

本质: Hermes 直接通过文件系统工具访问 Obsidian vault 目录中的 .md 文件。

维度	说明
Pipeline 角色	直接文件访问模式。read_file/write_file/search_files 直接读写 *.md, 跳过 MCP 中间层。
生命周期	文件由文件系统管理。访问在每次 tool call 内瞬态完成。
数据生长机制	write_file 创建/覆盖, search_files 查找, patch 修改, terminal 批量操作。平面文件。
交互链	Agent -> read_file/write_file/search_files -> 直接文件 I/O -> 文件内容。速度最快。

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

+-- 热层 (每轮对话必用) ----------------------------------------------------+
|                                                                           |
|  MEMORY (扁平文件)   <->   Holographic (SQLite)                           |
|   注入: 每轮全量            注入: 按需 FTS5+HRR 检索                      |
|   写入: memory tool          写入: fact_store tool                         |
|   上限: 8800 字符            上限: 仅磁盘                                 |
|                                                                           |
+-- 温层 (按需触发) --------------------------------------------------------+
|                                                                           |
|  用户输入分析 -> 决定调用哪些工具                                          |
|       |                                                                    |
|       +---> Trilium MCP    <- 知识库读写 (MCP, 独立 Docker)               |
|       +---> GBrain         <- 混合 RAG (旁路通道, cron 驱动)               |
|       +---> Git            <- 代码开发 (terminal + git CLI)                |
|       +---> MySQL          <- 业务数据 (terminal / MCP)                    |
|       +---> Obsidian MCP   <- MD 笔记 API (MCP)                           |
|       +---> Obsidian MD 目录 <- 文件直接访问 (file tools)                  |
|                                                                           |
+-- 冷层 (后台持久化) ------------------------------------------------------+
|                                                                           |
|  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	随导入文档数增长
Kanban	100KB	kanban.db	随任务量增长

五、关键矛盾与架构洞察

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

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

3. 旁路维护架构 (side-channel)
Trilium 和 GBrain 都采用侧通道维护: Hermes cron 定时触发脚本, 通过 API/MCP 更新外部系统。不修改服务器端配置, 不放 Token 到被管理端, 完全可装卸。

4. MCP 是温层存储的统一接口
Trilium, Obsidian, MySQL 都通过 MCP 协议统一暴露给 Hermes: 进程管理, 工具注册, JSON-RPC 调用。这是存取外部数据的主要架构模式。

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

六、总结: 一句话定位

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

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

GBrain - "外挂知识大脑": 真正嵌入向量 RAG, 独立维护, cron 旁路接入。

Trilium MCP - "结构化的维基百科": 层级知识库, MCP 直接读写, 公开分享。

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

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

Obsidian MCP - "MD 笔记 API": 结构化 API 访问 vault (当前未配置)。

Obsidian MD 目录 - "直接用文件工具读写": 最直接的 .md 文件访问 (当前未配置)。