01 / 15
↑ ↓ / Space / Swipe / Click dots
OpenClaw Deployment Briefing
01

從零開始部署龍蝦 OpenClaw

用 Windows 11 + WSL2 先把主線跑通，再接 Telegram、常駐 gateway、多供應商模型入口，以及免費與高 CP 值的雲端模型來源。

Windows 11 WSL2 + Ubuntu Telegram Bot Multi-provider Launcher Google / NVIDIA / Codex / Ollama
兩個常見誤解
02

先把「不敢開始」的理由拆掉

這篇文章的核心不是炫技，而是把 OpenClaw 拉回一般 Windows 使用者也能落地的範圍。

迷思 1

一定要先有很猛的本地硬體

如果主力是雲端 LLM，本機主要負責把 agent 架構跑起來、接工具、維持流程。對多數人來說，重點不是先買大機器，而是先把 provider strategy 想清楚。

本地硬體 ≠ 起手門檻 雲端入口先跑通
迷思 2

OpenClaw 一定很燒 token、一定很貴

成本是否失控，關鍵不在「有沒有裝 OpenClaw」，而在你接了哪些 provider、用了哪些模型、把它拿來做什麼。先用免費與高 CP 的雲端來源，就能把主線壓得很穩。

先配入口 再談成本曲線
真正該先決定的事： 你是先用雲端模型把 agent 跑起來，還是要一開始就走本地模型路線？
內容定位
03

文章不是取代 repo，而是帶你看懂 repo

Blog Post

帶路解說

補上背景、踩坑、取捨與「為什麼這樣做」，讓一般讀者比較敢動手。

GitHub Repo

施工圖

README、docs、模板、`.env.example`、`openclaw.json`、Windows launcher，都是真正實作時要對照的 source of truth。

This Deck

速讀導覽

把文章重組成適合分享的簡報節奏，讓你在十分鐘內抓到主線與關鍵風險。

一句話總結： repo 像施工圖，文章像帶路的人，簡報像高速導覽地圖。
架構圖
04

一眼看懂整體關係：Windows 操作 + WSL 執行

Left Side

Windows 11 使用者

PowerShell 安裝、批次檔切模型、桌機瀏覽器開 dashboard。

PowerShell`.bat` Launcher
Center

WSL2 Ubuntu + OpenClaw Gateway

Linux 工具鏈、`nvm`、Node 22、gateway、`systemd --user`、log 與 service 都放在這一層處理。

nvmNode 22systemd
Right Side

Dashboard / Telegram

桌面看 dashboard、手機走 Telegram，讓 OpenClaw 真的變成日常入口。

DashboardTelegram Bot
Windows→WSL→Gateway→Providers
Ollama Cloudqwen3.5:cloud
Googlegemini-3.1-pro-preview
NVIDIAqwen/qwen3.5-397b-a17b
OpenAI Codex OAuthopenai-codex/gpt-5.4
選路線之前
05

為什麼目前更建議 Windows 使用者先走 WSL

Reason 01

Linux 工具鏈比較順

OpenClaw 相關工具脈絡仍偏 Linux。用 Ubuntu 直接接 `bash`、`curl`、`git`、`systemd`，排錯一致性更高。

Reason 02

後面做常駐與看 log 比較自然

`systemd --user`、`journalctl` 這些概念在 WSL 裡的操作脈絡明確，做 Telegram 與 service 時會省很多力氣。

Reason 03

保留 Windows 的舒服操作感

你仍然可以用 Windows 編輯器、瀏覽器、批次檔入口，只把執行層交給 WSL，形成很實用的混合工作流。

簡單說： 不是說 Windows 原生不能做，而是如果你的目標是先成功、先穩定、先少踩坑，WSL 是更實際的起手式。
Deployment Mainline
06

主線步驟 I：先把環境底座搭起來

1
Windows

安裝 WSL2 與 Ubuntu

用 PowerShell 跑 `wsl --install`、`wsl --update`、`wsl --status`。

2
Ubuntu

初始化系統

先 `apt update && apt upgrade`，再補 `curl git ca-certificates build-essential`。

3
Optional but Recommended

視需要啟用 systemd

不是基本啟動的硬性條件，但若要做 Telegram、常駐 service、Windows launcher，建議先打開。

4
Repo

clone guide repo

放在 `~/openclaw-windows-wsl-guide`，後續模板、docs、launcher 都從這裡對照。

Deployment Mainline
07

主線步驟 II：把 OpenClaw 跑起來

5
Runtime

安裝 nvm

把 Node.js 管理放在使用者家目錄，避免 `sudo npm -g` 類型的路徑混亂。

6
Node.js

用 nvm 裝 Node 22

先照 repo 主線走，不要一開始就發明太多變形做法。

7
OpenClaw CLI

安裝 `openclaw@latest`

確認 `openclaw --version` 正常，代表 CLI 已經可用。

8
Optional

`openclaw onboard` 可跑可不跑

這次 repo 採模板化路線。想熟悉官方精靈可以跑，但不是唯一正確流程。

Deployment Mainline
08

主線步驟 III：從可用走向可維護

9
Template First

套用公開模板

複製 `.env.example`、`openclaw.json`、service 檔，讓設定結構可對照、可重現。

10
Gateway

先測試，再決定要不要常駐

第一次可以直接跑 `openclaw gateway`，後面需要 Telegram 或 launcher 再做成 service。

11
Validation

驗證 dashboard

`openclaw dashboard` 打得開，代表主線安裝大致已經過關。

12
Extension

再往下接 Telegram 與多入口

到這一步才開始加手機入口、模型切換與後續 Ollama 延伸，比較不容易亂。

Template-Based Setup
09

真正進入「可維護」狀態的關鍵：模板先行

File 01

`~/.openclaw/.env`

放 API key、gateway token、Telegram bot token 等敏感但可抽換的環境變數。

File 02

`~/.openclaw/openclaw.json`

定義 workspace、預設模型、channels 與 Telegram 啟用狀態，是整個 gateway 行為的主要骨架。

File 03

`openclaw-gateway.service`

讓 gateway 進入 `systemd --user` 管理，後續可重啟、查狀態、接 Windows launcher。

至少先處理
  • `GOOGLE_GEMINI_API_KEY`
  • `NVIDIA_API_KEY`
  • `OPENCLAW_GATEWAY_TOKEN`
  • workspace placeholder 路徑
如果還沒接 Telegram

先保留 `channels.telegram.enabled = false`，把主線跑通之後再開。

先求穩再加入口
Gateway Decision
10

`openclaw gateway` 要前景測試，還是直接做成 service？

Mode A
第一次測試很適合

前景模式：`openclaw gateway`

  • 最快知道 OpenClaw 能不能先跑起來
  • 錯誤訊息直接看得到，排錯很直觀
  • 關掉終端機就會一起停掉
Mode B
日常使用更穩

常駐模式：`systemd --user` service

  • 適合 Telegram、長時間待命、Windows 批次檔切模型
  • 可用 `openclaw gateway restart/status` 維運
  • 需要先把 systemd 路線整理好
實務大原則： 同一個 Telegram bot token，一次只保留一個 gateway instance 在輪詢，否則很容易出現 `409 Conflict`。
Telegram Workflow
11

Telegram 值得接，但先把唯一輪詢原則搞懂

啟用流程
  • 到 `@BotFather` 建 bot，拿到 bot token
  • 把 `TELEGRAM_BOT_TOKEN` 寫進 `.env`
  • 把 `channels.telegram.enabled` 改成 `true`
  • 重啟 gateway
  • 用 `openclaw channels status --json` 驗證
常見坑
409 Conflict

最常見原因不是 Telegram 壞掉，而是你同時開了兩個 gateway instance：一個來自 `systemd` service，另一個來自手動前景模式或其他 launcher。

systemctl --user status openclaw-gateway.service --no-pager -l journalctl --user -u openclaw-gateway.service -n 100 --no-pager
判斷標準： 如果 `telegram.running=true`，而且 bot 可正常回應，就代表 channel 已經載入成功。
Windows Launcher
12

多供應商入口不是花樣，而是把日常切換變簡單

公開版 `.bat`
[A] Ollama Cloud A1. qwen3.5:cloud [B] API Providers B1. Google Gemini 3.1 Pro B2. NVIDIA Qwen 3.5 397B B3. OpenAI GPT-5.4 Codex OAuth
代表模型版不是完整清單照搬
實際做的事
  • 在 Windows 上顯示選單
  • 透過 WSL 修改 `agents.defaults.model.primary`
  • 重啟已安裝的 gateway service
  • 自動打開 `openclaw dashboard`
使用前提： B 組 API 選單的前提是你已經把 gateway 裝成 service，而且各 provider 必要資訊都已先填好。
Extension, Not Prerequisite
13

Ollama 放在延伸章節，代表它重要，但不是第一階段必做

為什麼不放主線
  • 不是 OpenClaw 基本部署的必要條件
  • 一開始就加進主線，會讓第一次部署變數太多
  • 對一般 Windows 讀者來說，先讓 gateway 跑起來更重要
真的要加時
curl -fsSL https://ollama.com/install.sh | sh ollama --version ollama signin ollama pull qwen3.5:cloud ollama run qwen3.5:cloud

節奏應該是「主線先通，再補 Ollama」，而不是一開始就把自己丟進更多變數。

Agent Collaboration
14

如果流程還是有壓力，可以讓 AI agent 幫你「分段執行」

比較穩的用法
  • 先把 repo 當成主要依據，不要讓 agent 自由發揮整套流程
  • 一次只帶一個步驟，不要整包講完
  • 錯誤回貼後，先判斷卡在 WSL、Node、OpenClaw 還是 Telegram
可直接改寫使用的 prompt
請依照這個 GitHub repo 的流程， 協助我在 Windows 11 + WSL2 安裝 OpenClaw。 一次只帶我完成一個步驟。 每一步先解釋目的，再給指令。 如果出錯，先判斷問題在哪一層。
Closing Notes
15

一般 Windows 使用者，也可以把 OpenClaw 跑起來

最實際的節奏不是一步到位，而是 先求有、再求穩、最後再求多入口與延伸。

建議成功標準
  • dashboard 正常打開
  • 至少一個 provider 能工作
  • 需要時再接 Telegram
  • 最後再做多供應商入口與 Ollama 延伸