OpenHuman 放在雲端 Mac 上：Memory Tree 7×24 與 OpenClaw 怎麼搭

2026 年 5 月 26 日 · Nuvcloud 技術部落格 · 約 7 分鐘閱讀

筆電工作區——OpenHuman AI 分身、Memory Tree 與雲端 Mac — OpenHuman 在桌面聚合郵件與程式上下文；常線上 cloud mac 讓 auto-fetch 不因合蓋中斷。

早上跟 ChatGPT 講完客戶背景，下午在 Slack 又得重講一次——這種「上下文碎成渣」的感覺，Agent 工具越多越明顯。OpenHuman 想解的是另一件事：把 Gmail、Notion、GitHub、行事曆等接進本機記憶庫，讓助手能引用你最近的工作脈絡，而不是每次從零開始。原始碼在 GitHub，macOS / Windows / Linux 皆可跑，文件見 OpenHuman 官方文件。

本文不複述安裝步驟，而是給已經打算認真用的人一份部署決策指南：OpenHuman 該留在筆電，還是改養在常線上的雲端 Mac mini？如何與 OpenClaw 遠端實作分工？什麼時候該用租用 cloud mac，避免 auto-fetch 因合蓋、換網路而中斷。週末試玩，本機 MacBook 就夠；若要 7×24 同步、穩定 OAuth 出口、可擴充磁碟，請繼續往下看。

1. 先釐清定位：記憶管線，不是多開一個聊天分頁

官方把 OpenHuman 定義為桌面端個人 AI 系統：Rust 核心、TypeScript 介面，以一鍵 OAuth串接第三方（公開資料稱 118+ 整合）。重點不在「模型多聰明」，而在資料管線——Memory Tree（記憶樹）把郵件、行程、文件、程式活動壓成 Markdown，寫入 SQLite 與類 Obsidian 的本機倉庫（文件稱 Obsidian 風格 wiki）。

預設約 20 分鐘一輪 auto-fetch（auto-fetch 說明）：新郵件、行事曆變更、repo 提交會被拉回主機再入庫。實務上，助手才能回答「昨天答應客戶什麼」「本週誰 merge 了卡住的 PR」——前提是主機別半夜睡眠、網路別斷、磁碟別悄悄寫滿。

和只回答當下問題的 Copilot 式工具相比，OpenHuman 更像在本機跑一條私有 ETL + Agent流水線。你選擇用本地留存換取跨 App 脈絡；這筆交易只有在「跑它的機器夠穩」時才划算。

Beta 提醒：專案仍標 Early Beta。請鎖定 Release 版本，在與主力機隔離的環境試跑一週，觀察磁碟成長後再決定是否月租常線上節點。

能力	OpenHuman 做法	對選型的影響
整合接入	OAuth 一鍵授權 Gmail / Notion / GitHub 等	少配 API Key，但背景同步更吃主機資源
記憶	Memory Tree + Markdown 倉庫	跨 App 檢索需要快碟與定期備份
同步	定時 auto-fetch（約 20 分鐘）	獎勵常線上 Mac；懲罰合蓋與不穩 Wi‑Fi
隱私敘事	資料預設落在本機庫	模型若走雲端 API，金鑰仍是獨立風險面

2. 與 OpenClaw 分工：一個管「記得」，一個管「做了」

站內不少讀者已接觸 OpenClaw（官方文件、openclaw.ai）。一句話區分：

OpenHuman：把數位生活聚成可檢索的記憶，適合「依最近郵件草擬回覆」「本週會議與 commit 有什麼衝突」。
OpenClaw：把 macOS 變成可編排的執行面，適合 Webhook 觸發建置、Gateway，以及與 GitHub Actions Runner 同機協作。

實務上常見雙機或分機：OpenHuman 在常線上 cloud mac「長記性」，OpenClaw 在另一節點跑 CI。若只有一台 16GB 機器，先選定一件事跑穩，別同時開滿整合又掛平行 Runner。

OpenHuman 不能取代建置流水線；OpenClaw 也不能取代跨郵件與文件的記憶圖。兩者並存時，請分開 OAuth 範圍與磁碟目錄，避免互相拖垮。

3. 什麼時候該把 OpenHuman 養在雲端 Mac 上

本機 MacBook 跑 OpenHuman 完全可行。以下若中兩條以上，就該認真評估獨享 cloud mac：

常出差、合蓋、家用寬頻不穩，卻希望 auto-fetch 不要停。
記憶庫一週長好幾十 GB，輕薄本 SSD 成瓶頸。
公司 OAuth 或 SaaS 白名單要求固定出口 IP，家裡線路做不到。
不想在主力機上混個人 Gmail token 與 Early Beta 軟體。

雲端節點買的是可預期的在線與磁碟：SSH 看日誌、VNC 點 OAuth 授權——流程與幫助中心的遠端 Mac 一致。代價是多一筆 OpEx，因此更建議先日租，用真實郵件與行事曆流量測一週，再改月租。

地域選擇會影響連 SaaS 的延遲與合規敘事：美系服務常選美東／美西；亞太團隊可看新加坡、日本、香港節點——與 OpenClaw 地域文同一套思路。重點不是追新，而是把睡眠、磁碟、IP 變動從記憶管線裡拿掉。

4. 機型與磁碟：M4 記憶體怎麼估

OpenHuman 不是裝完就靜態的 App。整合越多、索引越大、Markdown 匯出越多，資源需求就往上走。規格開太小，通常先看到 swap、auto-fetch 變慢、緊急清碟——而不是友善的錯誤訊息。

使用情境	建議 SKU	說明
個人試用	M4 16GB · 512GB–1TB	少量整合；先日租驗證磁碟增速
重度整合（郵件+Notion+GitHub+行事曆）	M4 24GB · 1TB+	並行 fetch 與本地索引更吃記憶體
與 Runner 同機	24GB · 1TB+	記憶庫與 CI 快取分目錄

定價與 SKU 以 Mac mini 定價頁為準。操作上：日租 48–72 小時，每天看一次記憶庫目錄體積；若增速與記憶體壓力都可接受，再改月租。若也在評估 OS 層級的桌面 AI，可對照 Aluminium OS 跨裝置比較文。

5. 上雲第一週：照這個順序，少踩坑

第一週當成漸進上線，不要一次開滿所有整合。OAuth token 與磁碟成長會複利式累積；分批授權較容易定位問題。

核對 macOS 與你鎖定的 GitHub Release；企業網路放行 443 與 OAuth 回呼。
只裝官方套件；整合分批授權——先郵件／行事曆，再 Notion／GitHub。
記憶庫目錄獨立分區或路徑；定期備份 SQLite + Markdown。
SSH 做日常健檢；OAuth 彈窗用 VNC／螢幕共享。
記錄哪些整合屬於正式環境、哪些只是實驗，方便單獨撤銷而不整庫重來。

SSH 快速健檢（登入 cloud mac 後）

sw_vers
df -h /
du -sh ~/Documents/* 2>/dev/null | sort -hr | head -5
# 每週比對最大目錄；記憶庫成長應可預期

上述指令不是魔法，是習慣。在還沒信任自己的整合組合前，請固定執行。若某目錄增速與郵件量不符，先關最新整合再量一次，別急著加購磁碟。

6. 安全別偷懶：令牌與記憶庫 ≈ 你的人格副本

接上 Gmail 與 Notion 後，該機上的 SQLite 與 Markdown 樹，基本上就是你的職業與個人輪廓。最低限度：FileVault、SSH 僅金鑰登入、OAuth 按 App 最小授權。公司郵件若受 DLP 管控，除非合規書面核准，別用個人 OpenHuman 去碰受管信箱。

模型若走雲端 API，金鑰與記憶庫備份分開保管、定期輪替。Beta 階段請訂閱 GitHub Releases，別在正式記憶主機上自動追 latest。升級前先快照，確認各整合仍能 fetch。

隔離本身是優點：在不當日常瀏覽機的 cloud mac 上跑 OpenHuman，可降低 connector 異常或 beta 回歸的爆炸半徑——前提是你也別把整庫複製到未加密隨身碟「先試一下」。

7. FAQ

Q1：和「把 PDF 丟進 ChatGPT」有何不同？
OpenHuman 走持續 auto-fetch，記憶會隨郵件與行事曆變動；不是一次性上傳。

Q2：能取代 OpenClaw 嗎？
不能。OpenHuman 聚合上下文，OpenClaw 執行自動化與 CI；兩者重要就分機部署。

Q3：16GB 夠不夠？
只連 3–5 個整合、同機不跑 Runner，16GB 可試；重度用法或同機 CI 請 24GB。

Q4：記憶庫會不會把硬碟撐爆？
會，而且往往比預期快。每一輪 auto-fetch 都可能把郵件內文、行程、Notion 頁面、GitHub 中繼資料寫進本機 SQLite 與 Markdown；你在雲端刪了信，本地檔案不一定會自動縮小，除非你也整理或關閉對應整合。建議每週登入雲端 Mac，在終端機對記憶庫目錄執行 du -sh，看總占用（例如 42G 代表約四十二 GB）。若開 Gmail 後突然暴增，可能是同步了過多年份——重新授權時改選「最近幾週」，或先歸檔舊 thread，再考慮擴容。不再需要的整合請關閉，別讓它無限期累積。

Q5：一定要用 cloud mac 嗎？
不必。但若你要 7×24 auto-fetch，常線上雲端節點通常比會合蓋的筆電可靠。

Q6：和系統內建 Copilot／Apple Intelligence 衝突嗎？
層級不同：OS 助手服務桌面；OpenHuman 跨 SaaS 聚記憶。系統路線對照見 Aluminium OS 一文。