实例：Gbrain+Obsidian 人机双消AI知识库

🧪 实例：Gbrain+Obsidian 人机双消 AI 知识库

这不是运行实例——这是基于你当前 Trilium 实例的替代方案对比与迁移预研（B+C 定位）。分析如果从 Trilium 切换到 Obsidian，什么变、什么不变、成本如何、收益如何。

一、一句话差异

📖 Trilium（你现在的）
数据库（SQLite）→ ce5 富文本
内置 MCP Server + REST API
Relation Map 手动建立
1133 篇笔记，目录树组织
Web UI 访问，Docker 运行
AI 通过 MCP 读写
📔 Obsidian（替代方案）
文件系统（Markdown）→ .md 纯文本
obsidian-mcp 社区插件
Graph View 自动生成
目录=文件夹，文件=笔记
本地/同步盘/任意静态服务器
AI 通过 MCP 读改.md 文件
💡 最大区别：Trilium 是"数据库→暴露 API"模式；Obsidian 是"文件系统→直接读写"模式。Obsidian 天然就是 Karpathy 说的 LLM Wiki 模式——AI 直接读写.md 文件，不需要额外解析和转换。代价是失去了 ce5 富文本排版和内置 MCP Server。

二、每个组件的变化

组件Trilium 方案（当前）Obsidian 方案（如果换）变化评估
📖 笔记存储 Trilium 数据库 (SQLite)
ce5 HTML 格式		 文件系统（文件夹 + .md）
纯文本 Markdown 格式		 🟡 格式转换
ce5 HTML → Markdown 可自动化，但富文本（表格/卡片/渐变标题）需降级为纯 MD 或保留 HTML fragment
🔗 MCP 接入 Trilium 内置 MCP Server
（Node.js 进程，配置即用）		 obsidian-mcp 社区包
（Node.js，操作文件名+内容）		 🟢 对等替换
两者都是 MCP 协议，切换后 Hermes 的 MCP 配置只需改工具名，使用模式类似：read_note / search_notes / create_note
🧠 gbrain Hermes Docker 内嵌
API 调 gbrain 逻辑		 不变
gbrain + PostgreSQL 仍在独立 Docker 中		 🟢 零影响
gbrain 不依赖 Trilium 也不依赖 Obsidian，它只认通过 API 写入的实体数据
📜 同步脚本 阅读 Trilium REST API → 提取实体 → 写入 gbrain 监听 .md 文件变更 → 解析 frontmatter + 内容 → 写入 gbrain
或：同样走 obsidian-mcp		 🟡 实现方式不同
逻辑（抽取实体→写入 gbrain）不变，但数据源从 API 轮询变成文件监听
🗄️ PostgreSQL gbrain 的独立数据库 不变
同一套 PostgreSQL		 🟢 零影响
🤖 Hermes 通过 MCP 写 ce5 HTML 通过 obsidian-mcp 写 .md
（需调整 write_note 格式）		 🟡 工具格式调整
Hermes 写入时从生成 HTML 改为生成 Markdown，需要改 Skills 里的写笔记模板
👤 人类界面 Trilium Web UI（ce5 富文本编辑器） Obsidian 桌面/移动客户端
（Markdown 编辑器 + WYSIWYG 模式）		 🟡 体验风格不同
Trilium 树形目录 vs Obsidian 文件侧栏。Obsidian 的插件生态远强于 Trilium
🛠️ Skills / Cron / Memory Hermes 专属 不变
这些跟笔记存储无关，完全不需改动		 🟢 零影响

三、Obsidian 优于 Trilium 的地方

  1. 📁 天然可持续性（LLM Wiki 模式）
    笔记是.md 文件，不是数据库记录。AI 和人类读的是同一个文件。换任何工具都能读。没有数据库导出/迁移的问题。 git 做版本控制天生支持。直接对应 Karpathy 的"文件系统"路线。
  2. 🔌 插件生态远超 Trilium
    Obsidian 有数千社区插件：Graph View、Kanban、Dataview、Excalidraw、AI 插件……Trilium 的插件能力相对弱很多。特别是已有社区维护的 obsidian-mcp 和 AI 辅助写作插件。
  3. 🌐 多端同步更自由
    Trilium 同步需要同一套 Docker 服务。Obsidian 可用 Obsidian Sync（官方加密同步）、git（自己可控）、iCloud/OneDrive 等。且文件可以同时被多个工具编辑。
  4. 🧮 Graph View 自动生成
    Obsidian 的图谱是自动的——根据 [[wiki link]] 自动生成关联图。Trilium 的 Relation Map 需要手动维护。这对 gbrain 的"关系抽取"是天然补充。
  5. 💻 开发者友好
    文件即 API。你可以在终端直接 grep、sed、rename、批量操作。不需要通过 REST API 或 MCP 来"翻译"。这也是 LLM 读起来最自然的格式。
⚠️ 但 Obsidian 也有不如 Trilium 的地方：
· 没有内置 MCP Server（需要社区插件，稳定性略差）
· 没有 ce5 富文本排版（卡片/渐变标题/内联样式需要 HTML 或插件）
· 没有内置 REST API（需要额外搭桥）
· Obsidian 是桌面/移动应用，不是 Web 服务——headless 模式下 obsidian-mcp 进程独立运行，但你无法在浏览器里编辑

四、过渡方案：双跑与逐步迁移

你不需要"某一天把所有笔记搬过去"。可以有过渡期：

阶段 1：数据双写（0 成本）

当前 Trilium 笔记（1133 篇）
    │
    ├─ 人类：继续在 Trilium ce5 界面读写（不变）
    └─ AI（Hermes）：同时写入 Trilium（MCP）+ 导出为 .md 到 Obsidian vault 目录
        → Hermes 每次创建/更新笔记时，额外写一份 .md 到文件系统
        → Obsidian vault 自动看到新文件（它监听的目录就是.vault）

效果：Trilium 继续正常使用，同时 .md 版本自动积累。Obsidian 端可以开始阅读和整理。哪天决定完全切过去，所有笔记已经原生 .md 就绪。

阶段 2：迁移历史笔记（需要自动化脚本）

  • 方式一：用 Trilium 的导出功能（支持 Markdown 导出）批量导出 1133 篇笔记
  • 方式二：写脚本遍历 Trilium REST API / MCP，逐篇读取 ce5 HTML → 转成 Markdown（html2md 库）+ 保留 frontmatter
  • 需要处理：目录树 → 文件夹结构映射、Relation Map → [[wiki link]] 转换、附件/图片链接迁移
预期工作量
· 自动转换脚本：≈ 4-8 h（含处理 frontmatter / wiki link / 附件路径）
· 质量抽检 + 手动修复长尾：≈ 4-8 h（主要是含复杂表格和排版的笔记）
· 双写模式改造：≈ 2-4 h（Hermes Skills 里改 write_note 逻辑）
· 合计：≈ 1-2 天

阶段 3：完全切换

当天决定切过去时：

  • 停止 Trilium Docker（或保留只读不写）
  • Hermes 的 MCP 工具从 trilium-mcp 改为 obsidian-mcp
  • 同步脚本从"轮询 Trilium API"改为"监听 vault 文件变更"
  • 开始使用 Obsidian 客户端编辑笔记
  • gbrain 数据不动——PostgreSQL 还在，实体映射仍然可用

五、迁移后架构（目标状态）

组件存在形态协作方式跟现在比的变化
📔 Obsidian Vault 文件目录 + .md 文件
可用 git 做版本控制		 · AI 通过 obsidian-mcp 读写
· 人类用 Obsidian 客户端编辑		 🟡 从 ce5 HTML → 纯 Markdown
从 Web UI → 桌面/移动客户端
🧠 gbrain 独立 Docker（改造后）
或保持 Hermes 内嵌（当前）		 · AI 通过 MCP/REST 查询实体
· 同步脚本写入实体		 🟢 不变
📜 同步脚本 独立 Docker（需要改造） 监听 vault 文件 → 提取实体 → 写 gbrain API 🟡 触发方式从 API 轮询改为文件监听
🗄️ PostgreSQL 独立数据库 gbrain 读写 🟢 完全不变
🤖 任意 AI 框架 独立 Docker 或进程 通过 MCP 调 obsidian-mcp + gbrain-mcp 🟢 跟现在的 MCP 模式完全一致，只是 MCP Server 地址变了

完整数据流

你提问 → AI 回答
你 → (Telegram) → AI 框架
   ├─ MCP → obsidian-mcp → 搜索 .md 笔记 → 返回内容
   └─ MCP → gbrain-mcp → 查询实体 → 返回关系
   ▼ 综合回答

AI 写入笔记
AI 框架 → MCP → obsidian-mcp → 创建/更新 .md 文件
文件变化 → (文件监听) → 同步脚本 → 写入 gbrain

人类编辑笔记
你在 Obsidian 客户端改 .md 文件
文件变化 → (文件监听) → 同步脚本 → 更新 gbrain 实体
▲ （Trilium 方案中这一条需要你手动在 ce5 里编辑，AI 再 MCP 去读，Obsidian 直接通过文件变化实时触发）

六、什么情况下值得切

你的情况建议
短期内没有迁移计划，Trilium 已经用得好好的 不动。Trilium 的 ce5 富文本 + 内置 MCP 是目前最佳组合。把精力放在 gbrain 独立化上。
有计划实验新 AI 框架，想降低试错成本 两个选择：① 先做 gbrain 独立化（1-2 天）→ 做到快速切换新框架；② 同时双写 Obsidian vault（加 0.5-1 天）→ 为后续留选择余地
感觉 Trilium 的富文本代价太高（AI 写 ce5 HTML 生成太重，改格式麻烦） 切到 Obsidian + Markdown。AI 写 Markdown 比写 ce5 HTML 简单得多，人类看 Markdown 也流畅。代价是失去 ce5 的卡片/渐变色等视觉排版。
需要多人协作 + git 版本控制 Obsidian 优势明显。Trilium 虽有协作但不如文件 + git 灵活。
需要 ce5 富文本排版（你现在的笔记用了大量渐变标题、卡片、内联样式） 留在 Trilium。Obsidian 的 Markdown 做不到同等级别的视觉表达，或者需要额外插件（如 Excalidraw / HTML 内嵌）。
💡 我的判断：你现在 Trilium 的 ce5 排版用得挺深的（方案报告的彩色卡片、渐变标题等），切换 Obsidian 的视觉成本不低。但 Markdown 对 AI 更友好。一个折中路线是双写——Trilium 保留作为人类主要编辑界面，同时 .md 版本自动积累作为 AI 消费的纯净副本。这样就两全了。

七、参考资源

  • obsidian-mcp — https://github.com/nicholasgriffintn/mcp-obsidian (社区 MCP 桥接)
  • Obsidian 官方 — https://obsidian.md
  • Karpathy LLM Wiki — Karpathy 的 raw/wiki + git 设计模式，Obsidian vault 天然符合
  • Trilium 实例笔记 — 本目录下的「实例：Gbrain+Trilium 人机双消AI知识库」，介绍了当前架构的详细情况

更新说明：本文为替代方案对比与迁移预研。不是运行实例记录。
维护建议：如果后续决定开始迁移或双跑，可更新本文记录实际操作中发现的问题和解法。