一、数据载体的四类划分
不同系统的数据在私密性、格式独占性、变更追踪性、规模四个维度上有本质差异。正确做法是分类施策：
第一类：私有数据库载体（Proprietary DB）
数据存储在应用的专有数据库中。载体形态是二进制 DB 文件（SQLite 等）或纯内存数据，仅供所属应用独有读写。Git 无法做有意义的 diff。备份/恢复依赖应用导出或文件级冷备。
| 系统 | 载体形态 | 备份/恢复 | Git |
|---|---|---|---|
| Trilium 笔记 | document.db（SQLite，独立服务器） | ETAPI 导出 ZIP/JSON，或 sqlite3 .backup 冷备 DB 文件 | ❌ |
| Hermes Holographic | 事实数据库，无文件暴露 | 不可导出。对话中自然积累，丢失后需重新积累 | ❌ |
| gBrain PGLite | brain.pglite（嵌入式 PostgreSQL） | 消费者，不需要备份。重建时从 source 仓库重新拉取+索引 | ❌ |
第二类：高变动/体量大/DB 文件载体（Volatile Large DB）
数据量大、变更频繁、存储在 SQLite DB 文件中。Git 对二进制 DB 文件没有有意义的 diff，但文件本身可以冷备和恢复。不适合 Git 版本管理，但适合定期冷备。
| 系统 | 载体形态 | 备份/恢复 | Git |
|---|---|---|---|
| Hermes Session | /opt/data/state.db（SQLite，224MB） | cp / rsync / sqlite3 .backup 冷备。复制回原路径即可恢复 | ❌ |
第三类：可 Git 化的程序数据文件（Program Data Files）
数据在磁盘上有明确的文件形态，格式由特定程序定义和消费（自定义分隔符、特定 frontmatter 等），但文件是纯文本，Git 可做有意义的 diff。重建时从 Git 克隆即可恢复全部文件。
| 系统 | 载体形态 | 备份/恢复 | Git |
|---|---|---|---|
| Hermes Memory | /opt/data/memories/MEMORY.md / USER.md，条目以 § 分隔 | 从 Git 恢复文件 | ✅ 每次写入触发变更，diff 可读 |
| Hermes Skills | ~/./skills/*/SKILL.md（YAML frontmatter + Markdown） | 从 Git 恢复文件 | ✅ 原生 |
| Cron 任务脚本 | /opt/data/scripts/*.sh / .py | 从 Git 恢复程序文件；调度配置重建时重新配 | ✅ 程序文件 |
第四类：非私有化通用数据载体——Git 原生追踪（Universal Portable Data）
数据采用开放纯文本格式，任何程序都可以零成本一致地读写。Git diff 清晰可读。这是"一份源数据映射三个应用"的理想作用域。
| 系统 | 载体形态 | 备份/恢复 | Git |
|---|---|---|---|
| Obsidian 笔记 | knowledge-base/ 下纯 Markdown（.md）文件 | git clone 即可。所有程序即时可用 | ✅ 原生 |
二、审视所有系统的三个角度
审视角度一：角色——生产者 or 消费者？
每个系统在知识管线中扮演不同角色。区分谁是原始素材的生产者、谁是加工/消费/传递者，才能确定哪些数据需要持久化、哪些可以重建。
| 系统 | 角色 | 说明 |
|---|---|---|
| Obsidian | 生产者 | 用户在此写 Markdown，产出一手知识文档 |
| Trilium | 生产者 | 用户在此写 CKEditor5 富文本笔记，产出一手知识 |
| Hermes Memory | 生产者（副产品） | 对话中提炼的结构化记忆，是对话的副产品而非独立创作 |
| Hermes Skills | 生产者（程序定义） | 用户或 Hermes 定义的工作流模板，是程序性知识 |
| Cron 脚本 | 生产者（程序定义） | 用户或 Hermes 定义的任务程序 |
| Cron 调度配置 | 元数据 | 调度时间和方式，不是内容性知识，不值得持久化 |
| Hermes Session | 记录者 | 记录对话过程，不产出独立知识 |
| Hermes Holographic | 记录者（积累） | 对话中积累的事实关系，无独立创作 |
| gBrain | 纯消费者 | 从 Trilium/Obsidian 拉取，只做索引加工。重建时从源再拉，不需要备份 |
▎关键判断
- 纯消费者不需要备份——gBrain 是唯一纯消费者，重建时 git clone source 仓库再 gbrain sources add 即可。它的 PGLite 数据库是缓存，不值得持久化。
- 生产者需要区分"主动创作"和"对话副产品"：Obsidian 和 Trilium 的笔记是用户主动写的一手知识，最有价值，需要可靠的持久化策略。Hermes Memory 是对话中自然提炼的副产品，丢失成本较高但可以重新积累。
- Cron 调度配置是元数据而非内容——它描述"什么时候运行"，而不是"运行什么"。脚本文件才是内容的载体。元数据在重建时花 30 秒重新定义即可。
- 只有生产者（含副产品）需要纳入持久化体系。记录者和消费者只需要运行环境的保障（分布式、重建脚本），不需要数据备份。
审视角度二：可追踪性——Git 能否跟踪变动？
从 Git 能否追踪数据变更的维度审视所有系统。决定哪些载体可以纳入 Git 版本管理、哪些只能冷备。
| 系统 | 载体形态 | Git 可追踪 | 原因 |
|---|---|---|---|
| Obsidian 笔记 | 纯 Markdown（.md） | ✅ 原生 | 纯文本，Git diff 清晰可读 |
| Hermes Memory | .md 文件，§ 分隔 | ✅ 可追踪 | 纯文本，每次写入产生可读 diff |
| Hermes Skills | SKILL.md，YAML frontmatter | ✅ 可追踪 | 纯文本，diff 显示 frontmatter 和内容变更 |
| Cron 脚本 | .sh / .py 可执行文件 | ✅ 可追踪 | 纯文本代码，diff 显示逻辑变更 |
| Trilium 笔记 | document.db（SQLite） | ❌ 不可 | 二进制 DB，Git 无法逐变更 diff |
| gBrain PGLite | brain.pglite | ❌ 不可 | 二进制 DB |
| Hermes Session | state.db（SQLite，224MB） | ❌ 不可 | 二进制 DB，体量大 |
| Hermes Holographic | 事实数据库，无文件 | ❌ 不可 | 无文件暴露 |
▎关键判断
- 纯文本 ≠ 自动可 Git 追踪——纯文本是 Git 可追踪的必要条件但不是充分条件。一个 10MB 的纯文本日志文件虽然格式是文本，但每行都在变，Git 的 diff 和存储都会失效。所以在"可追踪性"之上还需要考虑变更粒度和体量。当前范围内第三类和第四类符合条件。
- Git 可追踪的载体可以做到"真增量备份"——每天 commit 一次，git push，每次只传输变更部分。不可追踪的二进制载体（SQLite DB）只能做全量冷备，即使只改了一条记录也要复制整个文件。
- 第三类（可 Git 化）和第四类（通用）在可追踪性上一样好——都是纯文本 diff。区别只在消费环节：第三类需程序特定解析，第四类任何程序零成本。
- Session（224MB）是最尴尬的——它既不像第一类（无文件）无法备份，也不像第三类（纯文本）可 Git 追踪。作为一个 SQLite DB 文件，它只能冷备。224MB 的冷备成本还算可接受，但如果再增长就需要考虑压缩或归档策略。
审视角度三：非私有化——任意程序可零成本一致读取？
数据的开放程度决定了"一份源数据映射多应用"的可行性。通用格式才能实现零成本一致性消费。
| 系统 | 载体形态 | 非私有化 | 消费方 |
|---|---|---|---|
| Obsidian 笔记 | 纯 Markdown（.md） | ✅ 完全开放 | Obsidian、gBrain、Hermes、VS Code、任何文本编辑器 |
| Cron 脚本 | .sh / .py | ✅ 完全开放 | bash、python3、任何解释器、文本编辑器 |
| Hermes Memory | .md 文件，§ 分隔 | ⚠️ 半开放 | 可读（纯文本），但 § 格式是 Hermes 独有，其他程序无法自动解析 |
| Hermes Skills | SKILL.md，YAML frontmatter | ⚠️ 半开放 | 可读，但 frontmatter 是 Hermes 约定 |
| Trilium 笔记 | document.db（SQLite） | ❌ 私有 | 仅 Trilium 可消费 |
| gBrain PGLite | brain.pglite | ❌ 私有 | 仅 gBrain 可消费 |
| Hermes Session | state.db（SQLite） | ❌ 私有 | 仅 Hermes session_search 可消费 |
| Hermes Holographic | 事实数据库 | ❌ 私有 | 仅 Hermes fact_store 可消费 |
▎关键判断
- 完全开放的格式只有两种：纯 Markdown（Obsidian）和可执行脚本（Cron .sh/.py）。这两者任何程序零成本消费——不需要许可、不需要 SDK、不需要解析器。
- 半开放格式的实质问题是"格式约定不在数据本身"：§ 分隔符和 YAML frontmatter 不是标准的一部分。作为一个新程序，我不知道 .md 文件里 § 是什么意思。这和"只要读 JSON 就能理解"的开放格式有本质区别。
- 半开放格式可以通过薄解析器桥接到第四类：例如写一个小工具把 § 分隔的 Memory 文件转换为标准 Markdown（每个 § 段变成一个 ## 标题段落），这样其他程序也可以消费。但这是转换，不是原生的零成本。
- 私有格式不是"坏"的，它们只是不适合多应用共享：Trilium 的 SQLite 对 Trilium 用户来说是极致体验（富文本编辑、树结构、share 链接）。私有格式的代价是一旦离开这个程序，数据就"锁"在里面了。这就是 ETAPI 导出存在的意义——提供一个逃离的通道。
- 私有格式适合做"写入口"，开放格式适合做"交换格式"：在 Trilium 中写笔记（利用其编辑器体验），定期 ETAPI 导出为开放格式到 Git 仓库，供 gBrain/Hermes 消费。这是从私有→开放的最佳实践路径。
三、消费关系矩阵
| 数据源 | 生产方 | 存储载体类别 | 载体位置/形态 | gBrain 消费 | Hermes 消费 | Obsidian 消费 | Git 版本 |
|---|---|---|---|---|---|---|---|
| Trilium 笔记 | 你（Web UI） | 第一类 | document.db（SQLite） | ⚠️ 通过导出桥接 | MCP 工具直接读 | ❌ | ❌ ETAPI 导出快照 |
| Hermes Holographic | 对话积累 | 第一类 | 无文件暴露 | ❌ | fact_store 查询 | ❌ | ❌ |
| gBrain 索引 | 自动同步 | 第一类（消费者） | brain.pglite | （本身） | MCP 查询 | ❌ | ❌ 可重建 |
| Hermes Session | 对话记录 | 第二类 | /opt/data/state.db（224MB） | ❌ | session_search | ❌ | ❌ 冷备可恢复 |
| Hermes Memory | 对话积累 | 第三类 | /opt/data/memories/MEMORY.md | ❌ | 运行时注入 | ⚠️ 可读但 § 需解析 | ✅ 文件级 |
| Hermes Skills | 你 / Hermes | 第三类 | ~/./skills/*/SKILL.md | ❌ | skill_view 加载 | ❌ | ✅ 原生 |
| Cron 任务脚本 | 你 / Hermes | 第三类 | /opt/data/scripts/*.sh/.py | ❌ | terminal 执行 | ❌ | ✅ 程序文件 |
| Cron 调度配置 | 你 / Hermes | 元数据（不持化） | Hermes 内部表 | ❌ | cronjob 工具定义 | ❌ | ❌ 重建时重新配 |
| Obsidian 笔记 | 你（桌面端） | 第四类 | knowledge-base/ 下 .md 文件 | sources add 索引 | read_file / gbrain 查询 | （编辑源） | ✅ 原生 |
四、各类重建/恢复方式总结
| 类别 | 系统 | 完全丢失后的恢复方式 | 恢复成本 |
|---|---|---|---|
| 第一类 | Trilium 笔记 | ① 有 ETAPI 导出快照 → 逐笔记重建。② 有 SQLite 冷备 → 替换 document.db | 中 |
| 第一类 | Hermes Holographic | 不可恢复。对话中自然重新积累 | 高（时间成本） |
| 第一类 | gBrain PGLite | 从 source 仓库 git pull → 重新索引。完全可重建 | 低（自动） |
| 第二类 | Hermes Session | 有 state.db 冷备 → 复制回来。无冷备则不可恢复 | 低 |
| 第三类 | Hermes Memory | 从 Git 恢复 MEMORY.md / USER.md | 低 |
| 第三类 | Hermes Skills | 从 Git 恢复 skills/ | 低 |
| 第三类 | Cron 脚本 | 从 Git 恢复 scripts/；调度元数据重新配 | 低 |
| 第四类 | Obsidian 笔记（.md 知识库） | git clone 即可。所有程序自动可用 | 极低（即时） |
五、Git 架构落地后的应用方式
以 Obsidian 为写入口、纯 Markdown 为交换格式、Git 为版本管理层、gBrain 为语义检索层、Hermes 为消费端的管线：
- 写：你在 Obsidian 中写 Markdown 笔记
- 存：Git commit & push 到 knowledge-base 仓库
- 索引：服务端拉取 → gBrain sources add 自动分块嵌入
- 消费：Hermes 在对话中通过 MCP 工具 query/search/think 检索知识
- 重建：完全丢失时 git clone 即可，gBrain 重新索引，所有程序即时可用
Obsidian（写）→ Git 版本管理 → gBrain sources 索引 → Hermes 召回，这是最终目标。Markdown 零成本一致性消费的特性使得 Trilium 等私有格式的笔记需要额外桥接才能进入这个管线，但它们的原始数据仍保留在原有载体中。