昨天先把 OpenClaw 放回整個架構裡：

CLI
↓
Gateway
↓
Agent / Session / Workspace
├── Ollama
└── MCP

但昨天只有設定，Gateway 根本還沒啟動。

今天才真的把它跑起來。

不過這台 GPU 主機上本來就有其他服務，所以第一件事不是：

npm install -g ...

而是先把這次實驗和整台機器隔離開。

這篇使用：

OpenClaw 2026.9.4
Node 24.21.0

版本會變，之後重跑時要先核對官方安裝需求，不要直接照著舊文章複製指令。

一、先做一個不碰全域環境的 Lab

今天新增 OpenClawLab。

目標很簡單：

OpenClaw 套件
設定
Workspace
Session
Gateway Log

全部放在這次實驗自己的目錄裡。

例如：

.runtime/
└── openclaw/
    ├── ...
    └── lab/

不覆蓋原本的 OpenClaw Profile，也不安裝常駐背景服務。

入口程式：

import json

from ironman.openclaw_lab import OpenClawLab


def main() -> None:
    lab = OpenClawLab()

    lab.setup()

    print(
        lab.cli(
            "config",
            "validate",
        ).stdout.strip()
    )

    with lab.gateway():
        print("Gateway endpoint: HTTP 200")

        reply = lab.ask(
            "請用一句繁體中文介紹這個本機開發工具箱。"
        )

        print(
            json.dumps(
                {"answer": reply["answer"]},
                ensure_ascii=False,
            )
        )


if __name__ == "__main__":
    main()

這裡的：

with lab.gateway():

也很重要。

這次實驗啟動哪一個 Gateway，就只負責關掉那一個。

不會為了清理測試環境，順手把：

Ollama
其他 OpenClaw instance
主機原本的服務

一起停掉。

二、Onboarding 不一定只能靠互動式精靈

一般第一次使用 OpenClaw，可以直接走官方 Onboarding：

選模型
設定 Provider
設定 Gateway
建立 Agent
選擇入口

這對人工操作很方便。

但教學系列還有另一個需求：

同一份範例下次能不能重現？

所以這次沒有依賴每次都手動點相同選項。

而是由：

OpenClawLab.setup()

產生這次 Lab 所需的設定，包括：

Agent
Model Provider
Gateway
Authentication
Workspace

它完成的是這次實驗需要的等價配置。

不是在文章裡宣稱：

我已經人工跑完所有互動式 Onboarding

也沒有綁定：

Telegram
Discord
其他外部 Channel

目前入口仍然只有本機 CLI。

三、先驗證設定，再啟動服務

設定產生完後，不直接開 Gateway。

先跑：

openclaw config validate

順序刻意是：

產生 Config
↓
Validate
↓
啟動 Gateway
↓
Health Check
↓
真的送訊息

原因很單純。

如果 Config 本身就不合法，沒必要先把整個 Runtime 啟動起來再猜錯誤。

今天實測至少留下兩種不同的證據。

第一個：

Gateway endpoint: HTTP 200

只能證明：

Gateway 已經啟動，而且目前可以接受連線。

它不能證明模型能用。

接著真的送：

請用一句繁體中文介紹這個本機開發工具箱。

有收到模型答案，才能再證明：

CLI
↓
Gateway
↓
Agent
↓
Ollama Provider
↓
本機 Ollama

這條路也正常。

所以：

HTTP 200
≠
Agent 已經可以推論

兩個要分開驗證。

四、這次真的碰到版本差異

安裝 Agent Framework 最容易遇到的問題之一，就是：

網路上的範例和自己裝的版本不是同一版。

這次就碰到了。

舊設定範例使用：

agents.list

但本篇實際使用的版本，角色設定已經改成：

agents.entries

而且是以 Agent ID 作為 key。

這種問題如果只看：

程式還能不能勉強跑

很容易錯過 Migration Warning。

所以我的處理順序是：

確認本機版本
↓
看這個版本的 CLI / Schema
↓
再修改 Config Generator

而不是看到網路上的設定就直接照抄。

這也是為什麼這個系列會把：

版本
設定驗證
實測結果

一起留下來。

五、Ollama Provider 不要和 OpenAI-Compatible 混在一起

這次 OpenClaw 使用的是原生 Ollama Provider。

設定會明確指定：

api: "ollama"

而 Base URL 指向 Ollama 本身。

這種模式下，不需要刻意補：

/v1

因為那是另一套 OpenAI-compatible API 的使用方式。

兩種介面都可能連到 Ollama，但不能把設定混在一起：

原生 Ollama Provider
→ 使用 Ollama 的介面

OpenAI-Compatible
→ 使用相容 OpenAI API 的介面

如果 Provider 選的是一套，URL 和欄位卻照另一套寫，問題通常會發生在模型請求那一層。

所以今天特別把：

Gateway 活著

和：

Provider 真的能呼叫模型

分開驗證。

六、安裝成功不能只看 npm 沒報錯

npm 安裝過程有時候會出現：

某些 package 的 install script 沒有被允許執行

這類訊息不能一律理解成：

一定沒事

也不應該看到 Warning 就直接：

全部 allow

比較合理的是先確認：

是哪一個套件
哪個 lifecycle script
本次功能到底需不需要它

今天最後採用的成功條件不是：

npm install 跑完了

而是：

CLI 能執行
↓
版本正確
↓
Config Validate 通過
↓
Gateway 啟動
↓
真的收到 Ollama 回答

這些才是這次實驗真正需要的證據。

七、Control UI 今天先不碰

OpenClaw 還有 Control UI。

但今天的實測入口只有：

CLI

如果之後真的要開 UI，也會繼續遵守昨天的原則：

Gateway 不公開監聽

需要遠端操作時，優先使用受保護的本機連線或 SSH Tunnel。

不要為了少打一條 SSH 指令，就把：

0.0.0.0

直接暴露出去。

尤其：

Gateway Token
API Credential
Session 資訊

也不應該出現在文章截圖裡。

今天的目標只是確認最小路徑：

本機 CLI
↓
Gateway
↓
Agent
↓
Ollama

真的能動。

昨天我們只有：

OpenClaw Config

今天第一次把 Runtime 啟動起來：

隔離安裝
↓
產生設定
↓
Config Validate
↓
Gateway
↓
Agent
↓
Ollama
↓
第一個真實回答

到這裡，OpenClaw 已經不只是流程圖上的 Gateway。

它真的開始管理一個可以收到訊息、呼叫本機模型並保留 Runtime 狀態的 Agent。

但目前它還只會聊天。

前面 Day 10 做好的 devbench MCP Server 還沒接回來。

所以下一篇要驗證的標準也會更嚴格：

不能只看 Agent 回答：

「我已經讀過檔案。」

而是要真的看到：

Agent 發出 Tool Call
↓
MCP Server 收到
↓
檔案真的被讀取
↓
Observation 被留下
↓
答案能對回來源

Day 25：

讓 OpenClaw 不只會聊天：Tools、Skills 與 MCP。

參考資料

OpenClaw 安裝文件
https://docs.openclaw.ai/install

OpenClaw Ollama Provider
https://docs.openclaw.ai/providers/ollama