OpenHuman 背後的「Memory OS」革命

2026 年，個人 AI 的競爭焦點正在從「模型夠不夠聰明」轉向「Agent 記不記得住你」。ChatGPT 的 Memory、Claude 的專案上下文、各類 Coding Agent 的 AGENTS.md——都在試圖解決同一個痛點：大模型本質是無狀態的，系統提示裡的幾條 bullet 只是便條，不是智慧。 開源專案 OpenHuman（TinyHumans AI，GPL-3.0）則走得更遠：它把「記憶」提升為與 CPU、排程器同級的 Memory OS（記憶作業系統）——不是外掛向量庫，而是一套本機優先、可稽核、可編輯的 Memory Tree 管線。本文從架構視角拆解這場革命，並說明為何 Apple Silicon 開發者越來越多選擇在 Mac mini M4 Cloud Mac 上 7×24 執行這類個人 Agent。

為什麼需要 Memory OS，而不是更長的上下文視窗

上下文視窗從 8K 擴到 1M token，並沒有改變一個事實：每次對話結束，模型權重不會為你保留任何東西。 產品層面的「記憶」往往是：

• 把若干使用者偏好寫進 system prompt；
• 在會話內做 RAG，從向量庫撈相似片段；
• 靠外掛把 Notion / Google Drive 暫時掛載進上下文。

這些方案能緩解問題，但缺少作業系統級的抽象：統一的 ingest 規範、持久化格式、檢索作用域、生命週期管理與可人類閱讀的儲存。 OpenHuman 的 Memory OS 隱喻正在於此——Memory Tree 不是「又一個向量庫 wrapper」，而是把郵件、Slack、GitHub、會議轉錄等異構資料，經 deterministic pipeline 變成 Agent 可查詢、使用者可開啟的 Markdown 知識庫。官方文件直言：「You can't trust a memory you can't read.」

OpenHuman 是什麼

OpenHuman 是 TinyHumans 推出的本機優先個人 AI Agent 桌面應用，技術棧為 Rust + Tauri，目標是成為「你數位生活的記憶與執行者（memory and doer）」——而不只是聊天框。與 Terminal-first 的 Agent 框架不同，它強調：

• Memory Tree + Obsidian Wiki：結構化長期記憶；
• Auto-fetch：無需手動 prompt，定時從已連線 SaaS 拉取新資料；
• 完整工具鏈：Web 搜尋、程式工具、瀏覽器控制、Cron、多 Agent 協調、語音與 Google Meet Agent；
• 118+ OAuth 整合（官方對照表資料，請以最新文件為準）。

2026 年 5 月前後，專案在 GitHub 與 Product Hunt 獲得大量關注——核心差異點正在 Memory OS，而非又一個 Chat UI。

Memory OS 核心：Memory Tree 確定性管線

根據 OpenHuman Memory Tree 文件，每條新資料走同一條 hot path：

source adapters (chat / email / document)
        ↓
canonicalize    → 規範化 Markdown + 溯源元資料
        ↓
chunker         → 確定性 ID，≤3k token 分塊
        ↓
content_store   → 磁碟上的 atomic .md 檔案
        ↓
store           → chunks.db（SQLite）
        ↓
score           → 訊號 + embedding + 實體抽取
        ↓
source / topic / global trees  → 各作用域摘要樹
        ↓
retrieval       → search / drill_down / topic / global / fetch

Ingest 的三條設計原則

• Deterministic（確定性）：分塊 ID 由內容尋址，重複 ingest 不會產生重複列。
• Fast（快速）：熱路徑不做 LLM 呼叫，只用廉價啟發式打分。
• Bounded write（有界寫入）：單交易持久化，避免半吊子 ingest 污染資料庫。

重量級工作——embedding、實體抽取、seal 摘要、每日 digest——進入背景 job queue，由預設 3 個 worker 消費，並透過 semaphore 限制併發 LLM 呼叫，避免 Auto-fetch 洪峰打滿 API 配額。

三層樹：Source、Topic、Global

Memory OS 的「檔案系統」不是扁平 key-value，而是三棵獨立生長的摘要樹：

向量相似度仍在底層發揮作用，但樹結構提供壓縮與導覽——這是 Memory OS 與「純 RAG 向量袋」的分水嶺。Leaf 生命週期為 pending_extraction → admitted → buffered → sealed（或 dropped），檢索時可回溯 provenance 而無需重跑整條 pipeline。

Obsidian Wiki：記憶必須可讀、可改、可刪

Memory Tree 的雙寫設計極具工程誠實感：同一份 chunk 既進入 memory_tree/chunks.db，也落地為 wiki/ 下的 .md 檔案——相容 Obsidian vault，靈感來自 Karpathy 推廣的 obsidian-wiki 工作流。桌面應用 Intelligence 頁提供「在 Obsidian 中開啟」深鏈，搜尋命中可跳回源 Markdown。

對開發者這意味著：

• 可以用 Git 版本管理 wiki/（注意脫敏）；
• Agent「記錯」時，人類可直接編輯 md 修正；
• 合規稽核時，記憶不是黑箱 embedding，而是明文 + 分數 + 溯源。

Auto-fetch：讓 Memory OS 主動「記帳」

多數 Agent 的記憶是被動的——你 @ 檔案、貼上連結、手動 export。OpenHuman 的 Auto-fetch 每約 20 分鐘遍歷活躍連線，把新郵件、新訊息、新 PR 寫入 Memory Tree，無需你開口。Scheduler 還在 UTC 0:00 觸發 global daily digest 與 stale buffer flush。

這改變了產品心智：早上開啟 Agent，它已擁有「昨天的上下文」——類似作業系統的 page cache，而不是每次 cold boot 從雲端 mount 文件。

agentmemory 後端：與 Cursor、Codex 共享記憶

若你已在 Cursor 或 Claude Code 側自託管 agentmemory（npx -y @agentmemory/agentmemory），OpenHuman 提供可選 backend：在 config.toml 設定 memory.backend = "agentmemory" 後，OpenHuman 成為 REST 薄客戶端，儲存 / embedding / 混合檢索（BM25 + vector + graph）由 agentmemory 統一承擔。

典型映射（摘自官方文件）：

• store → POST /agentmemory/remember
• recall → POST /agentmemory/smart-search
• 生命週期能力：consolidation、retention scoring、auto-forget、graph extraction

注意：Memory Tree 的 chunking / sealing pipeline 與 trait backend 正交——切換 agentmemory 不影響 Obsidian wiki 的文件 ingest，但 Agent 側 recall 會走共享庫。遷移路徑為 export SQLite → POST 至 agentmemory → 改設定重啟（暫無原地熱遷移）。

Memory OS vs 向量庫 vs 聊天上下文

與 OpenClaw 等 Agent 的記憶差異

OpenClaw（本部落格多次實踐的 Gateway 編排層）擅長多通道路由、Daemon 健康檢查、SSH 隧道 vs WSS——見 OpenClaw 與雲端 Mac 自動化。其記憶通常依賴外掛或外部 DB，而非內建 Memory Tree。OpenHuman 則把記憶產品化為 Intelligence 頁：儲存指標、實體關係圖、ingest 熱力圖、Obsidian 入口。

工程上二者可並存於同一臺 Cloud Mac：OpenHuman 負責長期個人知識 OS，OpenClaw 負責 Telegram / Webhook 觸發的任務編排——但務必劃分 OPENHUMAN_WORKSPACE 與 OpenClaw 設定目錄，並用 launchd 或 tmux 隔離 CPU / 記憶體峰值（大模型 embedding 與 Gateway 高峰勿重疊）。

在 Mac mini M4 Cloud Mac 上執行 OpenHuman

OpenHuman 是桌面 Agent，為何還要 Cloud Mac？對三類使用者，答案很具體：

• Windows / Linux 主力機開發者：需要 macOS 跑 Tauri 版 OpenHuman + Ollama Metal embedding，又不想買 Mac——與 Windows 遠端 Xcode 同一邏輯。
• 7×24 Auto-fetch：筆電休眠會中斷定時 sync；獨享 M4 節點可 SSH + VNC 常駐，Memory Tree 持續生長。
• 大容量 wiki：chunks.db + Obsidian + Hugging Face / Ollama 模型快取成長快——1TB/2TB 擴充見 M4 儲存 FAQ。

硬體檔位：16GB vs 24GB 與 Ollama

Memory Tree 的 fast-score 路徑不吃 GPU，但背景 embedding 與摘要會呼叫 LLM——開啟 Local AI（Ollama）時，M4 統一記憶體與 MLX / Ollama 實驗 同類：16GB 適合輕量 sync + 小 embed 模型；24GB 更適合併發 worker、較大 embed 模型與同時開 IDE。磁碟建議 AI + Memory OS 場景1TB 起。

部署步驟摘要

1. 租用 Vuncloud Mac mini M4，SSH 登入，將 workspace 放在持久卷。
2. 安裝 OpenHuman release，設定 OAuth 整合。
3. 首次手動 Run ingest，確認 wiki/ 與 Intelligence 指標成長。
4. （可選）安裝 Ollama，開啟 Local AI 做 on-device embedding。
5. （可選）對接 agentmemory，與 Cursor 工作流共享 recall。

買 Mac 還是租 Cloud Mac 跑 Memory OS？

若 Memory Tree 是你的生產級第二大腦，且 Auto-fetch 連線了工作信箱與程式儲存庫，本機 Mac mini 的隱私與零月租更誘人——直到你需要第二地備份、或團隊共享唯讀 wiki 鏡像。短期驗證 OpenHuman + agentmemory 組合，按週租用獨享節點更靈活；長期高利用率可參考 本機 vs 遠端租賃 TCO。CI 團隊若還要同機跑 GitHub Actions macOS runner，並行租期拆分更常見。

常見問題 (FAQ)

Memory OS 是什麼？ OpenHuman 對本機 Memory Tree + Obsidian wiki + Auto-fetch 的整體隱喻——記憶像 OS 一樣有 ingest、儲存、索引、排程與檢索介面。

資料存在哪？ 預設 ~/.openhuman/memory_tree/chunks.db 與 wiki/，本機 SQLite + Markdown。

能和 Cursor 共用 agentmemory 嗎？ 能，設定 memory.backend = "agentmemory" 並指向本機 REST 服務。

和 RAG 向量庫有何不同？ 多了 Source/Topic/Global 樹形摘要、時間 digest 與可編輯 wiki，而不只做 similarity search。

必須用 Mac 嗎？ 桌面版面向 macOS；24/7 場景常用 Cloud Mac。

和 OpenClaw 衝突嗎？ 不必然；注意目錄與資源隔離。

beta 穩定嗎？ 專案活躍但仍在快速迭代，生產環境請自行備份 chunks.db 與 wiki/。

結論

OpenHuman 代表的 Memory OS 路線，把個人 AI 從「聊天 + 臨時 RAG」推向「本機優先、可稽核、可同步的知識作業系統」。 Memory Tree 的確定性 ingest、三層摘要樹與 Obsidian 雙寫，回答了「Agent 憑什麼記得住我」——不是靠更大 context，而是靠結構化記憶層。對 Apple Silicon 開發者，在 Mac mini M4 上配合 Ollama 與 agentmemory，再按需擴展到 Cloud Mac 常駐 sync，是一條可落地的 2026 個人 AI 工程路徑。