01 · 為什麼 AI 需要一個家

你開啟一個聊天 AI，讓它幫你寫程式碼。它寫得不錯，你複製結果，關掉瀏覽器。

現在問一個更底層的問題：那個 AI 還在嗎？

不是模型服務還在不在。模型當然還在雲端。這裡問的是：剛才幫你理解專案、修程式碼、做判斷的那個“助手”還在不在工作。它會不會繼續盯伺服器日誌？會不會在凌晨三點發現故障？會不會主動從 Telegram 或 Slack 找你？

答案很簡單：不會。

大多數聊天 AI 是一次請求、一次回覆、一次結束。它可以很聰明，但它不是一個常駐工作實體。OpenClaw 要解決的，就是從“會聊天的模型”到“能常駐工作的 AI 助手”之間缺失的基礎設施。

1. 先分清模型、聊天視窗和助手

新手最容易把三個東西混在一起：模型是生成文本、推理和呼叫工具的大腦，不是長期存在的員工；聊天視窗是你和模型互動的介面，不是執行時，也不是記憶系統；AI 助手是能長期工作、記住背景、被多個入口觸達的實體，不能只靠一次對話成立。

這三個東西的差異，決定了 OpenClaw 為什麼不是另一個聊天 UI。

flowchart TD
    User[使用者] --> Chat[聊天視窗]
    Chat --> Model[模型]
    Model --> Reply[回覆]
    Reply --> End[對話結束]
    End --> Gone[助手狀態消失]

這張圖裡沒有後臺程序、沒有長期記憶、沒有外部渠道入口。它能回答問題，但很難成為助手。

2. 無狀態不是小問題

LLM 本身是無狀態的。每次請求帶著一段上下文進去，模型生成結果出來，呼叫結束。下一次請求如果沒有把舊資訊重新塞進去，模型就不知道之前發生過什麼。

很多產品會做“記憶”功能，但它通常只是把部分偏好或摘要重新注入到新會話。它能減少重複解釋，卻不能直接變成一個 24 小時工作的實體。

所以問題不是“模型夠不夠聰明”。模型再聰明，如果沒有執行時和狀態層，也只能在每次對話裡臨時出現。

3. 真正的助手需要三件基礎設施

做一個思想實驗：你想讓 AI 在凌晨巡檢伺服器，異常時先按規則處理，再從 Telegram 通知你。這個場景至少需要三個能力。

flowchart LR
    Process[24 小時程序] --> Assistant[AI 助手]
    Memory[持久記憶] --> Assistant
    Channel[多渠道入口] --> Assistant
    Assistant --> Action[發現問題 / 執行動作 / 彙報結果]

3.1 沒有 24 小時程序，就只能被動響應

如果 AI 只在你開啟網頁時存在，它就不能等你不線上時做事。

• 定時任務沒人觸發。
• 突發事件沒人響應。
• 外部訊息沒人接收。
• 長任務沒有穩定執行位置。

這就是 Gateway 出現的原因。OpenClaw 官方文件把它定義為一個 self-hosted gateway：你在自己的機器或伺服器上執行一個 Gateway 程序，它連線聊天渠道、控制端、節點和 Agent runtime。

3.2 沒有持久記憶，每次都像新人上班

你告訴 AI 專案背景、部署規則、溝通偏好。如果這些只留在聊天記錄裡，長會話壓縮或新會話開始後就可能消失。

OpenClaw 的記憶不是神秘黑箱。官方記憶文件的核心很明確：模型只“記得”寫到磁碟上的東西。預設 workspace 裡有 MEMORY.md 和 memory/YYYY-MM-DD.md 這類 Markdown 檔案，長期事實、日常觀察和回憶線索都可以落到檔案。

這就是“檔案即真相”的價值：你能開啟、檢查、修改、版本控制。

3.3 沒有多渠道入口，助手很難融入工作流

如果 AI 只能在一個網頁裡聊天，你每次都要專門開啟它。OpenClaw 的 Channel 讓同一個 Gateway 連線 Telegram、Discord、Slack、WhatsApp、Matrix、WebChat 等入口。

渠道不是“多幾個聊天 App”這麼簡單。它還帶來幾個系統能力：

• 不同入口可以路由到不同 Agent。
• 私信、群組、執行緒可以有不同 session。
• 入口可以做 pairing、allowlist 和 mention gating。
• Agent 可以在你真實使用的地方出現，而不是留在單獨工具裡。

4. Gateway、Memory、Channel、Agent 的關係

把這幾個概念合起來看，OpenClaw 的基本形狀就清楚了。

flowchart TD
    subgraph Host[你的機器或伺服器]
      Gateway[Gateway 常駐程序]
      AgentA[Agent A]
      AgentB[Agent B]
      Workspace[Agent workspace]
      Memory[MEMORY.md / memory 日誌]
    end

    Telegram[Telegram] --> Gateway
    Slack[Slack] --> Gateway
    WebChat[WebChat / Control UI] --> Gateway
    Gateway --> AgentA
    Gateway --> AgentB
    AgentA --> Workspace
    Workspace --> Memory

一句話：Gateway 讓 AI 活著，Memory 讓 AI 記得，Channel 讓你找得到它，Agent 負責真正做事。

5. OpenClaw 不是另一個 ChatGPT

把 OpenClaw 當成“自建 ChatGPT”會誤解它。

ChatGPT 是產品：模型、介面、賬號、託管服務都由平臺提供。OpenClaw 是 self-hosted gateway：它負責把你選擇的模型、Agent runtime、workspace、渠道和控制面組織起來。

所以 OpenClaw 的重點不是“換一個聊天介面”，而是給 AI 一個可長期工作的執行環境。

6. 為什麼不是直接用 LangChain 或 CrewAI

LangChain、CrewAI 這類框架更像開發工具箱。它們幫助開發者構建 AI 應用，但你仍要自己處理程序常駐、渠道連線、記憶儲存、許可權、session、部署和排障。

OpenClaw 的定位不同：它先給你一個能執行的個人 AI 助手容器，再讓你透過配置和 workspace 檔案去塑造 Agent。

這不是誰替代誰的問題。想寫自己的 AI 應用，用框架。想在自己機器上跑一個長期助手，用 OpenClaw 更接近目標。

7. 三個關鍵設計取捨

OpenClaw 的設計明顯偏向個人可用性和可檢查性。

7.1 單個 Gateway 優先

官方架構文件強調一個 host 上由一個長期 Gateway 擁有渠道連線和控制面。這樣做犧牲了一些企業級拆分想象，但換來更低的部署複雜度和更清楚的執行邊界。

如果一個 WhatsApp session、一個 Telegram bot、多個控制端都搶同一份狀態，個人使用者很快就會陷入排障地獄。一個 Gateway 做主，行為更可預測。

7.2 檔案可見優先

記憶和身份檔案放在 workspace 裡，意味著 Agent 的長期行為不是藏在某個看不見的產品資料庫裡。你可以開啟 SOUL.md 看它的決策框架，開啟 MEMORY.md 看長期事實，開啟每日日誌看最近發生了什麼。

這不是效能最強的方案，但它適合個人掌控。

7.3 嵌入式優先

Agent 執行在 Gateway 管理的 runtime 裡，不需要每個 Agent 都變成一套複雜服務。對個人使用者來說，少一個服務、少一個資料庫、少一個訊息佇列，就是更高的成功率。

這三個取捨可以壓成一句話：控制面選擇一個 Gateway 主控，放棄多服務自由拆分，換來部署簡單和排障集中；記憶選擇檔案和 workspace 可見，放棄完全黑箱託管，換來使用者能檢查和遷移；Agent 執行選擇 Gateway 管理 runtime，放棄每個 Agent 獨立服務，換來個人機器更容易跑起來。

8. 常見誤解

常見誤解可以按這組邊界校正：

• OpenClaw 不是模型。它連線模型和 Agent runtime，本身是 Gateway 和執行環境。
• OpenClaw 不是聊天 UI。UI 只是入口之一，核心是常駐 Gateway。
• 有記憶功能不等於有狀態助手。記憶只是狀態的一部分，還需要程序、渠道、任務和許可權。
• 多渠道不是多接幾個 App。渠道還包含 sender、group、thread、session、allowlist 和路由。
• 多 Agent 不是越多越高階。只有記憶、許可權、模型或職責需要隔離時才拆。

理解這些誤區，比記住命令更重要。命令可以查，系統邊界想錯了，後面每一步都會亂。

9. 怎麼驗證自己真的理解了

你可以用 6 個問題檢查：

1. 為什麼聊天視窗關掉後 AI 不算還在工作？合格答案要包含“沒有常駐程序和持續 session”。
2. Gateway 解決什麼問題？合格答案要包含“渠道連線、控制面、事件、Agent 排程和長期執行”。
3. Memory 為什麼要落檔案？合格答案要包含“模型無隱藏長期狀態，檔案可見、可查、可遷移”。
4. Channel 為什麼不是簡單聊天入口？合格答案要包含“sender、group、thread、routing、allowlist”。
5. Agent 和 Gateway 為什麼要分開理解？合格答案要包含“Gateway 是基礎設施，Agent 是具體工作角色”。
6. OpenClaw 和 LangChain 的差異是什麼？合格答案要包含“一個是執行環境，一個偏應用開發工具箱”。

如果你能不用背定義，把這些問題解釋給別人聽，這一篇就讀懂了。

10. 給 Agent 的實踐任務

如果你已經安裝了 OpenClaw，可以把下面這段交給 Claude Code、Codex 或其他本地 Agent：

请帮我检查本机 OpenClaw 的三个基础层：
1. Gateway 是否在运行，先看 openclaw status 和 openclaw gateway status。
2. workspace 在哪里，列出 AGENTS.md、SOUL.md、TOOLS.md、MEMORY.md 是否存在。
3. 当前配置里启用了哪些 channel，只列渠道名称和安全策略，不打印 token。
最后用三句话总结：Gateway 是否活着、Memory 是否有沉淀、Channel 是否可触达。

如果你還沒安裝，就先不要讓 Agent 猜本地狀態。改成讓它閱讀官方教程中文版的安裝和 Gateway 架構兩頁，給你列出需要準備的環境。

11. 本章自檢

1. 為什麼“模型很強”不等於“助手能長期工作”？
2. Gateway、Memory、Channel 分別解決哪一個缺口？
3. OpenClaw 為什麼不是另一個 ChatGPT？
4. 檔案即真相對個人使用者有什麼價值？
5. 什麼時候應該先讀官方教程，而不是繼續讀原理文章？

12. 接下來去哪

13. 官方資料

• OpenClaw 首頁
• Gateway architecture
• Memory
• Channels