---
title: "01 · 為什麼 AI 需要一個家"
description: "從無狀態聊天出發，解釋 OpenClaw 為什麼需要 Gateway、Memory、Channel 和 Agent 這幾個基礎概念。"
verifiedAt: "2026-05-06"
---

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

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

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

答案很簡單：不會。

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

> [!TIP]
> 這一篇先建立一個底層直覺：模型提供智力，Gateway 提供常駐執行，Memory 提供長期事實，Channel 提供真實入口。

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

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

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

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

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

## 2. 無狀態不是小問題

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

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

| 你期待的助手能力 | 單純聊天視窗能不能自然做到 | 缺什麼 |
| --- | --- | --- |
| 你睡覺時繼續值班 | 不能 | 常駐程序 |
| 記住專案規則和長期偏好 | 很弱 | 可檢查、可沉澱的記憶系統 |
| 從手機訊息裡隨時叫它 | 不能 | 多渠道入口 |
| 主動提醒異常或結果 | 很弱 | 心跳、定時任務、事件機制 |
| 多個身份分工協作 | 很弱 | Agent 和路由邊界 |

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

> [!IMPORTANT]
> 聰明的模型只能回答當下問題；常駐助手還需要程序、狀態、入口和許可權邊界。

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

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

```mermaid
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 的基本形狀就清楚了。

```mermaid
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 | 常駐控制面 | 管渠道連線、WebSocket 控制面、session、事件、Agent 排程 |
| Agent | 具體幹活的人 | 根據身份、規則、記憶和工具執行任務 |
| Workspace | Agent 的工作實體邊界 | 放 `AGENTS.md`、`SOUL.md`、`TOOLS.md`、`MEMORY.md` 等檔案 |
| Memory | 長期可檢查的記憶層 | 儲存事實、偏好、決策、每日觀察和可搜尋線索 |
| Channel | 外部訊息入口 | 連線聊天平臺，處理 sender、group、thread、pairing 和路由 |

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

> [!NOTE]
> 如果只記一句話：OpenClaw 不是把模型包裝成聊天框，而是給 Agent 一個能長期執行的家。

## 5. OpenClaw 不是另一個 ChatGPT

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

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

| 對比項 | ChatGPT 這類聊天產品 | OpenClaw |
| --- | --- | --- |
| 核心定位 | 對話產品 | 自託管 Agent Gateway |
| 執行位置 | 平臺託管 | 你的機器或伺服器 |
| 模型來源 | 平臺內建 | 連線你配置的 provider 或 runtime |
| 工作方式 | 開啟對話再使用 | Gateway 常駐，渠道隨時可觸達 |
| 記憶形態 | 產品內部能力 | workspace 檔案和 memory 系統 |
| 適合問題 | 直接問答、寫作、分析 | 長期助手、多入口、工具執行、個人工作流 |

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

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

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

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

| 你要做的事 | 用通用框架通常要自己處理 | OpenClaw 提供的預設層 |
| --- | --- | --- |
| 接 Telegram 或 Slack | Bot API、webhook、訊息格式、重試 | Channel 配置和 Gateway 路由 |
| 24 小時執行 | 程序管理、服務守護、日誌 | Gateway 程序和 daemon/runbook |
| 長期記憶 | 資料庫、索引、摘要策略 | workspace Markdown、memory tools、memory backends |
| 多 Agent 分工 | 路由、上下文隔離、許可權分層 | Agent 配置、binding、session key |
| 安全入口 | allowlist、pairing、group policy | Channel policy 和 Gateway 安全配置 |

這不是誰替代誰的問題。想寫自己的 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：

```text
请帮我检查本机 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. 接下來去哪

<Cards>
  <Card href="/zh-Hant/docs/openclaw/understanding/02-message-journey" title="02 · 一條訊息的旅程" description="繼續看一條 Telegram 或 Slack 訊息如何經過 Channel、binding、session、context、Agent loop。" />
  <Card href="/zh-Hant/docs/openclaw/official/00-getting-started/installation" title="官方教程：安裝" description="如果還沒安裝，先回到官方安裝流程，確認執行前置條件。" />
  <Card href="/zh-Hant/docs/openclaw/official/01-gateway-runtime/architecture" title="官方教程：Gateway 架構" description="對照官方架構頁繼續理解 Gateway、Control UI、CLI、Nodes 和 WebChat。" />
</Cards>

## 13. 官方資料

- [OpenClaw 首頁](https://docs.openclaw.ai/)
- [Gateway architecture](https://docs.openclaw.ai/concepts/architecture)
- [Memory](https://docs.openclaw.ai/concepts/memory)
- [Channels](https://docs.openclaw.ai/channels)
