OpenHuman：個人 AI 長期記憶平台
核心設計
- 118+ 第三方服務整合，OAuth 快速連接
- 每 20 分鐘自動同步，建立 Memory Tree 記憶系統
- TokenJuice：送入 LLM 前自動壓縮（HTML→Markdown、去冗餘）
- Obsidian 相容的 Markdown 知識庫輸出
- 支援 Ollama 本地模型
Memory Trees 機制深度拆解
OpenHuman 的記憶不是線性時間軸，而是自動聚類成主題樹：Gmail 中的會議記錄→自動關聯到對應的 GitHub issue→再關聯到 Notion 的專案筆記。這跟 Hermes 的 holographic memory（跨實體關聯推理）思路一致，但實作方式不同：
| 維度 | OpenHuman | Hermes Holographic Memory |
|---|---|---|
| 記憶來源 | 外部服務（Gmail/GitHub/Slack） | 對話上下文 + fact_store + MEMORY |
| 關聯方式 | 自動主題聚類 + 時間語義 | 實體解析 + trust score + 跨實體推理 |
| 壓縮機制 | TokenJuice（HTML→MD + 去冗餘） | sleep consolidation（多輪循環壓縮） |
| 儲存 | SQLite + Markdown 檔案 | 記憶體 + fact_store + JSON |
| 部署 | 桌面 App（Tauri） | Linux 伺服器背景執行 |
TokenJuice 壓縮原理
TokenJuice 是 OpenHuman 的關鍵技術：同步進來的原始資料（HTML 郵件、JSON API 回應）經過多層壓縮後才送入 LLM。第一層：HTML→Markdown（剝除樣式/腳本/追蹤碼）。第二層：去除重複資訊（同一封郵件的多個副本、GitHub notification 與實際 issue 的重疊內容）。第三層：只保留最近 N 天內的變更，舊資料以摘要形式存在。
Hermes 的 sleep consolidation 做類似的事，但壓縮對象是對話紀錄而非外部服務資料。兩者可互補：OpenHuman 壓縮外部資料源給 Hermes 當上下文。
118 服務整合的篩選策略
不是 118 個服務都值得連。OpenHuman 的設計哲學是「寧多勿少」——給你全部 connector，你自己選要開哪些。實務上最有價值的是：Gmail（郵件脈絡）、GitHub（開發活動）、Slack/Discord（團隊討論）、Notion（個人筆記）、Google Calendar（時間脈絡）。其他 100+ 個服務對大多數人無感。
Local-First 架構的利弊
所有資料存本地 SQLite，不上傳雲端——這是 OpenHuman 最突出的隱私賣點。但代價是：多裝置同步需自己解決（iCloud/Dropbox/Syncthing），沒有瀏覽器介面（必須裝桌面 App），手機無法存取。這跟 Hermes 的伺服器部署模式是相反的取捨。
什麼場景適合用 OpenHuman 而非 Hermes
| 場景 | OpenHuman | Hermes |
|---|---|---|
| 記住過去三個月的 GitHub issue 討論 | OAuth 同步，自動關聯 | 需手動貼連結 |
| 每天自動摘要 Email 重點 | Gmail connector + local LLM | 無 Email 整合 |
| 部署網站、跑 cron、管理 Docker | 無法 | 核心能力 |
| 跨服務搜尋「上週討論過的那個 bug」 | Memory Tree 查詢 | session_search |
限制
- 需要桌面環境（Tauri App），不適合 headless 伺服器
- 118 個 connector 維護品質參差不齊，部分已過時
- TokenJuice 壓縮可能遺漏重要細節（語義壓縮 ≠ 無損）
- 社群活躍度中等，roadmap 不明確
我的判斷
OpenHuman 和 Hermes 不競爭——一個是「個人記憶助理」，一個是「任務執行代理人」。理想組合是 OpenHuman 當記憶後端、Hermes 當執行前端。但目前兩者整合成本太高（需自建 bridge），短期內不適合。
值得持續追蹤的是 Memory Trees 的自動聚類演算法——如果它能從原始資料中自動建立跨服務關聯，那比 Hermes 目前的手動 fact_store.add() 更先進。等 OpenHuman 提供 API 而非僅桌面 App 時再評估整合。