OpenHuman 是什麼？Local-first 記憶、Agent 工作流與雲端邊界

先說結論：local-first 指的是哪一層？#

「local-first」很容易被理解成所有功能都離線執行，但 OpenHuman 官方文件描述的是分層架構。個人知識庫以本機儲存為中心，模型、搜尋與第三方整合則有各自的路由。

這張表也解釋了為什麼「資料存在本機」不等於「所有處理都在本機」。如果你要求完全離線，不能只看 Memory Tree 的儲存位置，還要逐一檢查模型、搜尋、語音與整合功能。

OpenHuman 想解決的不是聊天，而是長期脈絡#

一般聊天工具的上下文多半以單次對話為中心。OpenHuman 想把個人 AI 拆成三個可長期累積的部分：

• 記憶層：把文件、對話與整合來源轉成可以搜尋、摘要與回收的個人知識。
• 編排層：把研究、整理、產出與工具操作組成可重複執行的工作流。
• 執行層：依任務呼叫模型、網頁搜尋、MCP server 或外部服務。

這個方向和只靠 prompt 維持角色設定不同。記憶是可保存與搬移的資料，工作流則是可再次執行的流程。若你也在比較其他個人 Agent，可以先看 OpenClaw 本機記憶設定；兩者都在處理長期脈絡，但操作介面、資料結構與外部能力的組合方式不同。

Memory Tree 如何把資料變成可用記憶#

依 OpenHuman 目前的架構文件，資料進入 Memory Tree 後，大致會經過這條流程：

1
整合來源或本機內容
2
  → 正規化成 Markdown
3
  → 切分內容並寫入 SQLite／Wiki
4
  → 建立 embedding、分數與摘要
5
  → 依目前問題取回相關節點
6
  → 壓縮後送進模型上下文

官方文件也提到，整合來源會定期擷取更新，內容經正規化後寫入 workspace 內的 memory_tree/chunks.db，可閱讀的 Markdown 則放在 wiki/。這個設計有兩個實際意義。

第一，記憶不只藏在應用程式專用的遠端帳號裡。Markdown 讓使用者能直接閱讀與整理，SQLite 則負責更適合程式查詢的索引資料。第二，備份不能只複製其中一邊；若要保留完整狀態，應先確認 workspace 內哪些資料夾共同構成記憶庫。

這和備份個人 Agent 身分檔的觀念相近：應先列出真正的資料來源，再決定備份與還原範圍。可搭配 OpenClaw 身分與記憶備份指南 建立自己的盤點表，但實際路徑仍以 OpenHuman 當前版本的 workspace 為準。

安裝前先選執行路徑#

官方安裝文件優先列出各平台的原生套件：macOS 使用 Homebrew cask，Debian／Ubuntu 使用 .deb，Windows 使用簽署的 .msi。文件也提供安裝腳本與 Linux AppImage，但明確提醒安裝腳本沒有額外的簽章或完整性驗證，因此原生套件是較容易檢查的起點。

OpenHuman 目前仍標示為 Early Beta。這不代表不能使用，而是升級前應先看 release note，並保留 workspace 備份。v0.63.9 release 就以發行可靠度與 Linux 啟動修正為主，顯示安裝與更新路徑仍在快速調整。

為什麼本機記憶仍要檢查雲端邊界#

OpenHuman 的架構文件把本機與後端邊界列得相對清楚：Memory Tree、Markdown vault 與部分音訊／模型狀態留在裝置；訂閱方案下的 LLM 呼叫、網頁搜尋代理、OAuth 工具代理與 TTS 串流可能經過 OpenHuman 後端。

因此，連接私人帳號前至少要確認四件事：

1. 模型路由：目前對話、摘要與 embedding 各自使用哪個 provider？切換成 Ollama 是否涵蓋所有工作負載，還是只有其中一部分？
2. OAuth scope：整合要求讀取、建立、修改或刪除哪些資料？是否能只開放任務需要的最小權限？
3. 工具代理：外部工具由本機直接呼叫，還是透過後端代理？日誌與錯誤訊息會保留哪些輸入內容？
4. 停用與撤銷：斷開整合後，第三方 token、已匯入內容與本機索引要如何個別處理？

OpenHuman 過去也有 GitHub issue 討論登入、OAuth 與 local-first 用詞。這些討論適合用來建立檢查清單，但不能取代當前文件與實際設定畫面；專案更新速度快，舊 issue 描述的流程可能已經改變。

如果要接 MCP 或其他工具，原則也相同：先確認 Agent 原本缺少什麼能力，再縮小權限，而不是看到整合數量就全部啟用。可參考接 MCP 前的能力盤點，把每條外部連線視為獨立的資料與操作邊界。

怎麼判斷 OpenHuman 是否適合你#

OpenHuman 比較適合想把個人知識、研究與 Agent 工作流放在同一套桌面介面，而且願意管理資料路由的人。安裝前可以用下面這組問題做決策：

• 我需要的是可長期保存的個人記憶，還是偶爾使用的聊天介面？
• 我是否接受部分模型、搜尋或整合流量經過託管服務？
• 若要求本機模型，我能否逐項確認對話、摘要、embedding 與工具呼叫的 provider？
• 我準備連接哪些私人帳號？每個整合的最小 OAuth scope 是什麼？
• workspace 是否納入備份？備份是否包含 SQLite、Markdown 與必要設定？
• Early Beta 的更新頻率與可能的相容性變動，是否符合使用情境？

如果這些問題沒有答案，先不要連主要信箱、雲端硬碟或正式工作帳號。可以先建立獨立 workspace，只匯入可替換的資料，再逐項增加模型與整合。這樣即使設定不符合預期，也能清楚知道是哪一條資料路徑造成問題。

OpenHuman 和 OpenClaw 怎麼選？#

兩者不是單純的功能數量比較。OpenHuman 的產品重心是桌面介面、Memory Tree、個人知識與視覺化工作流；OpenClaw 更接近以檔案、設定與可組合工具為中心的 Agent 工作區。

如果你想直接檢視 Markdown 記憶、用圖形介面安排研究與任務，OpenHuman 的整合方式較接近這個需求。若你已習慣在終端機、repository 與設定檔中控制 Agent，並希望每個工具都能自行替換，OpenClaw 類型的流程可能更順手。

真正的選擇標準仍是可驗證性：記憶放在哪裡、模型送去哪裡、工具能做什麼，以及中斷服務時能否帶走資料。產品名稱和「local-first」標籤都不能替你回答這四個問題。

這篇真正要記住的事#

OpenHuman 值得注意的地方，是它把本機可讀的記憶、Agent 編排與外部能力做成一個完整產品，而不是只增加另一個聊天視窗。但 local-first 主要描述資料與體驗的起點，不代表所有模型、搜尋、OAuth 與語音處理都自動留在本機。

使用前先畫出資料流：哪些內容寫進 SQLite 與 Markdown、哪些請求送往模型或搜尋供應商、哪些帳號透過 OAuth 開放了什麼權限。只要這張圖能回答清楚，你才是在選擇架構，而不是只相信標籤。

常見問題#