昨天我們已經用 Python Supervisor 跑完:
Research
↓
Writer
↓
Reviewer
所以現在其實已經有一套能完成任務的 Multi-Agent Baseline。
那為什麼還要再看 OpenClaw?
因為:
能把任務跑完一次,和有一個能長期管理 Agent、Session、Workspace 與工具的執行環境,是兩件事。
接下來七天會依序處理:
OpenClaw 定位
↓
建置與 Onboarding
↓
Tools / Skills / MCP
↓
Session / Workspace / Memory
↓
Multi-Agent
↓
安全與評估
↓
本機 GPU 資源調度
今天先不安裝。
先把 OpenClaw 放回整個架構裡,搞清楚它到底負責哪一層。
前面一路做到現在,其實已經碰過很多不同層次:
Ollama
MCP
Agent
LangGraph
Google ADK
Supervisor
OpenClaw 又多了一個:
Gateway
先不要全部混在一起。
在這個系列裡,可以先這樣理解:
| 元件 | 主要責任 |
|---|---|
| Ollama | 執行本機模型推論 |
| MCP Server | 提供工具與資料能力 |
| Agent | 定義角色、模型與可使用能力 |
| Session | 保存一段互動的狀態與事件 |
| Workspace | Agent 工作時使用的檔案空間 |
| Gateway | 管理 Agent 執行、Session 與外部入口 |
如果之後接 Telegram、Discord 或其他訊息來源,還會再多一層 Channel。
但這個系列先不接外部聊天平台。
只從本機 CLI 進入。
少一層外部整合,也避免測試過程不小心真的送出訊息。
整體先畫成:

這裡還是兩條不同的能力路徑:
Agent → Ollama
負責推論。
另一條:
Agent → MCP → devbench
負責真正讀取專案資料。
OpenClaw 可以把它們組織在同一個 Agent Runtime 裡,但不會把:
MCP Server 變成模型
也不會因為接上 Ollama,就自動取得整台機器的檔案權限。
前面已經用過:
LangGraph
Google ADK
它們也能管理 Agent 流程。
所以不能簡單寫成:
LangGraph / ADK = Framework
OpenClaw = 完全不同的東西
實際能力有不少重疊。
但在這個系列裡,我會用一個比較實用的角度來區分。
LangGraph 比較著重:
State
Node
Edge
Workflow
Google ADK 提供:
Agent
Runner
Session
Tool Interface
OpenClaw 接下來則會拿來處理一個更完整、可以持續運行的環境:
Gateway
Agent Runtime
Session
Workspace
Model Provider
MCP
Tool Policy
所以我們不是因為前面的 Framework 做不到才換。
而是接下來想研究的問題開始從:
Agent Loop 怎麼寫?
變成:
多個 Agent 長期跑在同一個本機環境時,要怎麼管理?
這一點很重要。
昨天已經有:
Research
↓
Writer
↓
Reviewer
這條明確流程。
今天就算裝好 OpenClaw,也不代表它會自動知道:
Research 完成後交給 Writer
Writer 完成後送 Reviewer
Reviewer 失敗最多修一次
這些仍然是我們的 Workflow 規則。
原本的 Python Supervisor 也不會因為 OpenClaw 出現就立刻丟掉。
反而可以先保留:
Python Supervisor
→ 控制流程
OpenClaw
→ 提供 Agent Runtime / Session / Workspace
等後面真的做到 Multi-Agent,再比較哪些責任適合搬進 OpenClaw。
這樣才有 Baseline 可以對照。
今天的程式故意不啟動服務。
先把之後要用的設定組出來:
from ironman.openclaw_lab import LAB, make_config
def main() -> None:
settings = make_config(
LAB,
mcp=True,
multi=True,
)
print("Gateway: loopback only")
print(
"Agents:",
", ".join(
settings["agents"]["entries"]
),
)
print(
"MCP:",
", ".join(
settings["mcp"]["servers"]
),
)
print(
"Route: "
"Agent → Ollama or read-only MCP"
)
if __name__ == "__main__":
main()
今天只驗證幾件事:
Agent 設定能產生
MCP Server 有被註冊
Gateway 預計只監聽本機
多角色設定有明確結構
不連模型。
不啟動 Gateway。
也不真的執行 MCP Tool。
這跟前面幾天的做法一樣:
先確認靜態設定,再增加 Runtime。
不然一次把:
OpenClaw
Ollama
MCP
Multi-Agent
Gateway
全部啟動,錯誤一出現又要開始猜是哪一層壞掉。
這個系列前面一直把本機模型設定集中管理。
今天也是一樣。
設定來源仍然放在共用的:
config.py
再由產生器轉成 OpenClaw 所需要的設定。
但這裡不要誤會成:
OpenClaw 會透過我們的 Python
llm.py呼叫模型。
不是。
前面自己寫的 Agent:
Python
↓
OllamaClient
↓
Ollama
OpenClaw 則使用它自己的 Ollama provider:
OpenClaw
↓
Ollama Provider
↓
Ollama
共用的是:
模型名稱
Endpoint
我們定義的設定來源
不是同一支 Python HTTP Client。
這個差別要留下來,不然「Single Source of Truth」很容易被誤寫成:
所有 Runtime 都跑同一份程式碼
實際上不是。
前面 Day 19、20 花了兩天做安全邊界。
不能進 OpenClaw 之後全部重置。
所以這個 Lab 一開始就先限制:
Gateway
→ loopback only
Runtime 狀態
→ 使用獨立 .runtime/lab
既有 OpenClaw Profile
→ 不讀取
MCP
→ 只接唯讀 devbench
Workspace
→ 獨立管理
目前不開:
任意 Shell
寫檔
刪檔
瀏覽器自動操作
對外訊息
外部聊天 Channel
原因不是這些功能永遠不能用。
而是:
今天的任務根本不需要。
最小權限到了新的 Runtime 還是同一條原則。
不要因為 Framework 提供某個功能,就順手全部打開。
OpenClaw 的 Agent 會有自己的 Workspace。
後面會把:
Agent 設定
Bootstrap 資料
工作檔案
Memory
逐步拆開。
今天先記一件事:
Workspace 應該被當成 Agent 的工作範圍,而不是整台機器的 Home Directory。
尤其後面 Multi-Agent 時,每個角色可能有不同 Workspace。
例如:
Research Workspace
Writer Workspace
Reviewer Workspace
是否要共享、共享多少,都應該明確決定。
不能因為三個 Agent 在同一台機器,就預設:
大家都看得到所有人的檔案
這跟 Day 21 拆 Tool 權限其實是同一件事。
只是現在開始延伸到檔案與 Session。
昨天完成的是:
Python Supervisor
↓
Research
↓
Writer
↓
Reviewer
它已經能完成任務。
所以 OpenClaw 接下來不是要證明:
沒有 OpenClaw 就做不了 Agent。
而是要回答另一個問題:
當 Agent 不再只是跑一次就結束,而是開始有 Session、Workspace、多角色和持續狀態時,執行環境該怎麼管理?
今天先把位置擺好:
CLI
↓
OpenClaw Gateway
↓
Agent / Session / Workspace
├── Ollama
└── MCP
明天才真的安裝鎖定版本,建立獨立 Lab,驗證設定並啟動 Gateway。
最後送出第一個真實訊息,確認:
CLI
↓
Gateway
↓
Agent
↓
Ollama
整條路真的走得通。
Day 24:
從零建置 OpenClaw:安裝、Onboarding 與第一個本機 Agent。
OpenClaw 官方文件
https://docs.openclaw.ai/
OpenClaw Agent Runtime
https://docs.openclaw.ai/agent
OpenClaw Agent Workspace
https://docs.openclaw.ai/agent-workspace
OpenClaw MCP Tools
https://docs.openclaw.ai/tools/mcp
OpenClaw Ollama Setup
https://docs.openclaw.ai/providers/ollama/setup