2026 年 Agent 圈有個梗：「龍蝦在前，流程當道」——你花大量時間配 Skill、寫 Prompt、拉工作流，AI 才會「像工程師」；關掉工作階段，跨週的決策理由仍要重講一遍。緊接著 OpenHuman 又在 GitHub Trending 上刷屏：口號變成「不用你教，每 20 分鐘一輪同步，把你的一切寫進本機知識庫」。
這不是又一篇 Star 數科普。本文聚焦「連 — 抓 — 記」三步：如何在 Early Beta 前提下，用最小權限接 Gmail、GitHub、日曆等來源，讓記憶樹（SQLite + 可匯出 Obsidian Markdown）真的服務於「懂你」，而不是多一個吃 Token 的黑箱。若你還沒讀過專案定位，可先對照本站《GitHub 爆火的 OpenHuman，到底是什麼？》。
1. 龍蝦時代解決了什麼，又留下了什麼？
台灣與華語開發圈常把 OpenClaw 生態戲稱「龍蝦」，並與仍靠你「教」模型的流程型工具對照——這不是商標，而是 Agent 1.5 代的縮影：
- 龍蝦側（整合型）：像 OpenClaw 閘道 + ClawHub 技能——強項是 Webhook、Cron、多通道訊息，但要自己裝技能、跑 doctor、守權限。
- 流程側（紀律型）：像 mattpocock/skills——用
/grill-me、/tdd把工程紀律寫進對話，但 CONTEXT.md 與倉庫規則仍要你維護。
共同點：跨 Gmail、GitHub、Notion、日曆的個人脈絡不會自動匯聚；關掉 IDE，上週的「為什麼選方案 B」仍要靠人複述。Andrej Karpathy 在 2026 年強調的「個人知識庫」——把筆記、郵件、程式決策沉澱成可檢索 Markdown——在龍蝦／流程體系裡往往仍是手工活。
OpenHuman 的敘事則是：把 Karpathy 式知識庫做成背景流水線。官方與社群評測描述的核心迴圈是：OAuth 連接 → 約每 20 分鐘增量同步 → 清洗壓進「記憶樹」→ 對話時按任務路由模型並檢索片段。Star 數請以 GitHub 即時為準；倉庫標註 Early Beta，下文步驟以 官方 GitBook 目前版本為準。
2. 技術背景：記憶樹與「Karpathy 式」知識庫
OpenHuman 不是簡單 RAG 套殼。公開材料裡，長期記憶大致分三層（名稱以文件為準）：
- 來源樹：按連接器（Gmail、GitHub 等）歸檔原始增量。
- 主題樹：按專案、人物、時間軸做摘要與關聯。
- 全域樹：跨主題的高層索引，供 Agent 規劃「該查哪條枝」。
儲存上，權威資料在本機 SQLite；同時匯出相容 Obsidian 的 .md 片段（社群稱單段約 ≤3000 Token），便於你用雙向連結筆記人工糾偏。對話前，TokenJuice 一類壓縮會把相關片段壓進上下文，減輕「把整庫聊天記錄塞進 Prompt」的成本——具體比例隨任務變化，勿當成固定 80% 承諾。
模型側，Model Routing 按任務選推理／快速／視覺模型；也可接 本機 Ollama / MLX 做離線推理。這與龍蝦層只解決編排與紀律、不解決個人級全源記憶形成清晰分工。
3. 對照：龍蝦路線 vs OpenHuman「連—抓—記」
| 維度 | 龍蝦（Skill / 閘道 / Rules） | OpenHuman |
|---|---|---|
| 誰在維護「懂我」 | 你寫 Prompt、Skill、CONTEXT.md | 背景同步 + 記憶樹索引（你可審 Obsidian 匯出） |
| 接第三方服務 | 逐平台配 Key / Webhook | 文件稱 118+ 服務 OAuth（以控制台列表為準） |
| 更新節奏 | 手動或自建 Cron | 預設約 20 分鐘輪詢已連接帳戶 |
| 跨週協作 | 依賴倉庫文件與持久記憶設計 | 強調跨工作階段檢索個人脈絡 |
| 典型代價 | 維運閘道、技能版本、權限 | Beta 穩定性、GPL-3.0、連接器權限稽核 |
一句話：龍蝦讓你當教練；OpenHuman 試圖當「持續讀你工作日誌的助教」——助教仍可能記錯，所以 SQLite + Markdown 雙份落地是為了讓你能查、能改、能刪。
4. 工作流：20 分鐘週期內你能做完什麼
「20 分鐘」指同步週期，不是「安裝後 1200 秒立刻全知」。下面是一條可重現的首次上手路徑（UI 文案隨版本變，邏輯不變）：
4.1 連：最小連接器集
從 Releases 安裝桌面端後，不要一次 OAuth 118 個。建議首批只接：
- 一個信箱（工作 Gmail 或別名信箱二選一）；
- 一個程式碼源（GitHub 個人帳號或單一 Org）；
- 一個日程（Google / Outlook 其一）；
- 可選：Notion 或 Drive 之一，避免重複文件源。
每接一個源，在紙上記：唯讀還是可寫、能否撤銷、是否含客戶 PII。企業信箱請先過資安評審。
4.2 抓：等待至少 1～2 個同步週期
連接成功後，背景會按預設間隔（社群與評測多寫約 20 分鐘）拉取增量：新郵件主題、提交記錄、日程變更等。此階段你應做：
- 在應用內查看「上次同步時間」與失敗連接器；
- 確認磁碟占用成長是否符合預期（索引 + 匯出 md）；
- 勿用「它怎麼還不知道我昨天會議說了啥」來評判——第一輪只驗證管道是否通。
4.3 記：驗收記憶樹與 Obsidian 匯出
打開 Obsidian 庫路徑（安裝精靈或設定裡查看），抽查 3～5 個自動產生的 md：
- 標題是否對應真實事件（例如某次 PR、某封郵件串）；
- 是否誤把促銷郵件當成「專案決策」；
- 敏感 token、金鑰是否被寫進正文——若有，立即斷開該連接器並提 Issue。
然後在 OpenHuman 裡問一個需要跨源推理的問題，例如：「本週我在倉庫 X 的提交，和日曆裡與 Y 的會議是否相關？」對照回答裡的引用片段是否來自正確 md。
4.4 與龍蝦元件並聯（建議拓撲）
[Gmail/GitHub/日曆 …] --OAuth--> OpenHuman 記憶樹 (SQLite + .md)
|
v
模型路由 (雲端 / Ollama / MLX)
^
[Cursor + mattpocock/skills] ----寫程式----+
[OpenClaw 閘道] ----IM/Webhook/Cron--------+避免讓 Skills 的 CONTEXT.md 與 OpenHuman 匯出目錄各寫一套「專案真相」而不同步。實務上：個人生活與跨工具脈絡交給 OpenHuman；倉庫內工程決策仍以 Git 追蹤的 CONTEXT.md / ADR 為準。
4.5 何時停手或回退
- 檢索經常「張冠李戴」，且 Obsidian 裡摘要品質差——先減連接器，而非加模型。
- 你需要 GPL 之外的商業閉源分發——法務不通過則不要深度整合。
- 只想 24×7 跑 Telegram 機器人——優先 OpenClaw 遠端 Mac 部署實操，不是 OpenHuman 主場景。
5. 常見問題
「20 分鐘封神」是不是行銷誇張？
更準確的說法是：20 分鐘一輪自動同步。真正「懂你」取決於連接源數量、歷史資料量與你是否願意審閱匯出筆記。把它當「可稽核的個人 ETL」，比當「讀心術」更不容易失望。
和 Karpathy 手工知識庫衝突嗎？
不衝突。OpenHuman 自動化的是「從 SaaS 拉事實」；你仍應在 Obsidian 裡寫判斷、優先順序與 ADR 式結論。機器記「發生了什麼」，人記「我們選擇了什麼」。
Token 帳單會爆嗎？
路由 + 壓縮旨在只送相關片段；但若你接太多高頻源（群聊、監控告警），索引體積與檢索次數都會漲。先用最小連接器跑一週，再看帳單與磁碟。
6. 算力放哪：筆電、桌機與遠端 Mac
記憶樹與索引主要在本機磁碟；大模型推理可留在本機 Apple Silicon，也可把 Ollama/MLX 指到高記憶體遠端 Mac，讓筆電只跑 OpenHuman UI。24×7 同步 + 閘道場景下，獨占 macOS 節點能減少合蓋休眠導致的同步中斷——這與 Macstripe 讀者常用的「Agent 在雲上、資料出口可控」拓撲一致。
若你下一步要評估獨享 M4 Mac Mini 承載 OpenHuman 與 OpenClaw，可到Macstripe 首頁查看節點與開通方式。
7. 結論
龍蝦時代證明了：工程師願意教 AI，但不想重複教同一件事。OpenHuman 的「封神」敘事，實質是把 Karpathy 式個人知識庫從手工筆記變成可輪詢、可壓縮、可匯出審閱的本機流水線——「連—抓—記」三步，20 分鐘是節奏，不是魔法。
- 先最小 OAuth，等 1～2 個週期再測檢索品質。
- 用 Obsidian 匯出當「記憶體檢表」，錯了就刪源或改權限。
- 與 Skills / OpenClaw 分工：個人脈絡 vs 倉庫紀律 vs 訊息閘道。
Early Beta 務必當稽核專案，而非正式秘書。更多 OpenHuman 架構解讀見《GitHub 爆火的 OpenHuman，到底是什麼？》；跨週記憶方法論見《Cursor 為什麼總「失憶」？》。
