Key Findings
  • OpenClaw 在 Windows 11 原生環境（非 WSL2）可透過 PowerShell 一行指令完成安裝，安裝程式會自動偵測系統已有的 Node.js 並直接以 npm 全域安裝 openclaw 套件
  • 安裝完成後執行 openclaw onboard 進入互動式設定精靈，可在本機終端環境中一步完成 Telegram 串接、Gateway 模式選擇與基礎配置
  • Dashboard 無法開啟的根因並非瀏覽器問題，而是 Gateway 服務未啟動——openclaw dashboard 僅負責開啟瀏覽器連線至本地 WebSocket 伺服器，若 Gateway 未運行則無任何可連線的端點
  • Windows 原生環境下 Gateway 持久化需以系統管理員權限執行 openclaw gateway install（底層依賴 schtasks），或以前台模式 openclaw gateway 快速驗證

一、為什麼選擇 Windows 原生安裝

OpenClaw 的官方文件與社群教學幾乎一面倒地聚焦在 macOS、Linux 與 WSL2 環境[1]。這很合理——OpenClaw 的核心架構源自 Unix 生態，Gateway 的 Daemon 管理依賴 systemd，Node.js 與 Shell 工具鏈在 POSIX 系統上的運作更為成熟。

但現實情況是：大量企業用戶的日常工作環境就是 Windows。根據 StatCounter 2026 年 1 月數據，全球桌面作業系統市占率中 Windows 仍穩居 72%。對於需要快速驗證 OpenClaw 能力的技術決策者而言，要求他們先安裝 WSL2、設定 Ubuntu 子系統、處理跨系統檔案存取與網路橋接問題，這道額外的技術門檻往往足以延遲甚至阻止評估進程。

本文記錄了我們在 Windows 11 Pro（Build 26100）上，完全不使用 WSL2，以原生 PowerShell 環境完成 OpenClaw 安裝、設定、障礙排除到 Dashboard 成功連線的完整歷程。這不是一篇理想化的教學文件——而是一份真實的安裝日誌，包含我們遇到的每一個卡點與對應的解法。

二、安裝流程：從 PowerShell 一行指令到 Doctor 診斷

2.1 一行指令安裝

以系統管理員身份開啟 PowerShell，執行官方安裝腳本[1]：

iwr -useb https://openclaw.ai/install.ps1 | iex

安裝程式的行為如下：

  1. 偵測作業系統：識別為 Windows 環境
  2. 檢查 Node.js：發現系統已安裝 Node.js v24.13.1，跳過 Node.js 安裝步驟
  3. 安裝 OpenClaw：透過 npm install -g openclaw@latest 全域安裝，版本為 2026.2.23
  4. 自動執行 Doctor：安裝完成後自動執行 openclaw doctor 進行環境診斷

整個安裝過程約耗時 30 秒，無需任何手動介入。

2.2 Doctor 診斷報告解讀

安裝程式自動觸發的 Doctor 報告顯示了以下狀態：

openclaw doctor

[PASS] Node.js version: v24.13.1 (>= 22 required)
[PASS] openclaw version: 2026.2.23
[FAIL] Gateway not configured
[FAIL] Gateway not running
[FAIL] Gateway service not installed
[FAIL] OAuth directory missing
[FAIL] Session store directory missing
[WARN] Memory search needs embedding provider

六項 FAIL、一項 WARN。對於首次安裝而言，這些結果完全正常——Gateway 尚未設定、服務尚未註冊、OAuth 與 Session 目錄尚未建立。這些都是 openclaw onboard 互動式設定精靈要處理的事項。值得注意的是 Memory search 的 WARN：這表示語義搜尋功能需要額外的 embedding provider（如 OpenAI 或本地模型），屬於進階功能，不影響基礎運作。

三、Onboard 互動設定

Doctor 確認基礎環境就緒後，執行互動式設定精靈：

openclaw onboard

openclaw onboard 是一個需要 TTY 終端的互動式程序（這也是為什麼它在 SSH 或 headless 環境下會失敗——參見我們先前的部署全指南中的踩坑紀錄 #1）。在 Windows 原生 PowerShell 中，互動式精靈正常運作，依序引導完成以下設定：

3.1 通訊渠道設定——Telegram Bot

Onboard 精靈詢問要串接的通訊渠道。我們選擇 Telegram，並輸入預先從 @BotFather 取得的 Bot Token[6]。精靈自動將 Token 寫入 %USERPROFILE%\.openclaw\openclaw.json 的 channels.telegram 區塊，並啟用 Telegram 外掛。

3.2 Gateway 模式選擇

精靈詢問 Gateway 運行模式。我們選擇 local——Gateway 運行在本機，不經過雲端中繼[2]。這是最適合本機測試的模式，所有資料傳輸都不離開本機網路。

? Gateway mode: local
Setting gateway.mode to local...

Onboard 完成後，設定檔已就緒。但接下來的步驟——啟動 Dashboard 進行驗證——是我們遇到第一個重大障礙的地方。

四、Dashboard 無法開啟：Gateway 啟動問題的根因分析

4.1 症狀描述

Onboard 完成後，我們執行：

openclaw dashboard

系統預設瀏覽器開啟了一個 URL：

http://127.0.0.1:18789/#token=eyJhbGci...

但瀏覽器頁面幾乎立即關閉，或顯示連線失敗。反覆嘗試數次，結果相同。

4.2 根因追溯

這個現象的根因並非瀏覽器相容性問題，也不是 Token 過期。問題在於 Gateway 服務根本沒有在運行。

理解 OpenClaw 的架構至關重要[2]：openclaw dashboard 這個指令本身不啟動任何服務——它僅僅是打開瀏覽器，將 URL 指向本地的 WebSocket 伺服器（ws://127.0.0.1:18789）。Dashboard 的前端是一個靜態頁面，透過 WebSocket 與 Gateway 通訊。如果 Gateway 沒有在監聽 18789 埠，瀏覽器自然無法建立連線，頁面即刻失敗。

這是一個容易被忽略的隱含前提：Gateway 是 Dashboard 的必要前置服務，但 openclaw dashboard 的指令輸出中並未明確提示這一點。

4.3 嘗試啟動 Gateway 服務

我們依序嘗試了以下指令：

# 嘗試 1：啟動 Gateway 服務
openclaw gateway start
# 輸出：Gateway service missing

# 嘗試 2：安裝 Gateway 服務
openclaw gateway install
# 輸出：Access is denied

第一個指令失敗，因為 Gateway 服務尚未被註冊。第二個指令失敗，因為 openclaw gateway install 底層呼叫 Windows 的 schtasks 工具來建立排程任務[3]，而 schtasks 需要系統管理員權限。我們當時的 PowerShell 並非以管理員身份執行。

這裡揭示了 Windows 原生環境與 Linux 的一個關鍵差異：Linux 上 OpenClaw 使用 systemd 管理 Daemon 服務，使用者可透過 systemctl --user 在非 root 模式下註冊服務；但 Windows 上 OpenClaw 依賴 schtasks，而 schtasks /Create 在非管理員 PowerShell 中一律會被拒絕。

五、Gateway 啟動的三條路徑

釐清根因後，我們整理出三條可行的 Gateway 啟動路徑，適用於不同情境：

路徑 A：前台模式（最簡單，適合測試驗證）

直接在終端中以前台模式啟動 Gateway：

openclaw gateway

Gateway 會開始在前台運行，監聽 ws://127.0.0.1:18789。終端會持續輸出日誌，關閉終端視窗即停止服務。這是最快的驗證方式——無需管理員權限，立即可用。

如果希望在同一個 PowerShell 中繼續操作，可以將 Gateway 放到背景執行：

# PowerShell 背景執行
Start-Job -ScriptBlock { openclaw gateway }

我們在實測中選擇了這條路徑。Gateway 啟動成功後，再次執行 openclaw dashboard，瀏覽器正常開啟 Dashboard 介面，Telegram 連線狀態顯示「ok」——問題徹底解決。

路徑 B：系統排程任務（持久化，需管理員權限）

以系統管理員身份開啟 PowerShell，執行：

# 必須以管理員身份執行
openclaw gateway install

這個指令會呼叫 schtasks /Create 建立一個 Windows 排程任務[3]，設定為使用者登入時自動啟動 Gateway。安裝完成後，Gateway 會在每次 Windows 啟動時自動運行，無需手動介入。

驗證排程任務是否建立成功：

# 查看 OpenClaw 相關的排程任務
schtasks /Query /TN "OpenClaw*"

這是生產環境建議的做法，但需要注意：如果你的 Windows 帳戶沒有管理員權限（例如企業環境中的一般使用者帳戶），這條路徑將無法使用。

路徑 C：NSSM 或啟動指令碼（替代方案）

對於無法使用 schtasks 但又需要持久化的場景，可以透過第三方服務管理工具 NSSM (Non-Sucking Service Manager) 將 openclaw gateway 註冊為 Windows 服務：

# 下載 NSSM 後
nssm install OpenClawGateway "C:\Program Files\nodejs\node.exe"
nssm set OpenClawGateway AppParameters "C:\Users\%USERNAME%\AppData\Roaming\npm\node_modules\openclaw\bin\openclaw gateway"
nssm set OpenClawGateway AppDirectory "C:\Users\%USERNAME%"
nssm start OpenClawGateway

或者，最簡單的替代方案是在 Windows 的「啟動」資料夾中放入一個批次檔：

# 建立 startup.bat，放入 shell:startup 目錄
@echo off
start /min cmd /c "openclaw gateway"

將此檔案儲存至 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ 目錄，Windows 登入時即自動啟動 Gateway。

三條路徑的比較

路徑需管理員權限持久化適用情境
A. 前台模式否否（終端關閉即停止）快速測試、功能驗證
B. schtasks 排程是是（開機自啟動）長期使用、生產環境
C. NSSM / 啟動腳本NSSM 需要；腳本不需要是無管理員權限但需持久化

六、Doctor 報告解讀與後續優化

Gateway 成功啟動後，再次執行 openclaw doctor 確認系統狀態：

openclaw doctor

[PASS] Node.js version: v24.13.1
[PASS] openclaw version: 2026.2.23
[PASS] Gateway configured (mode: local)
[PASS] Gateway running on ws://127.0.0.1:18789
[PASS] Gateway service installed
[WARN] OAuth directory missing
[WARN] Session store directory missing
[WARN] Memory search needs embedding provider

三項 WARN 的解讀如下：

6.1 OAuth directory missing

OAuth 目錄用於儲存第三方服務的認證 Token（例如 Google Calendar、Notion 等整合）。如果你不需要這些第三方整合，這個警告可以安全忽略。若需要，執行 openclaw doctor --fix 會自動建立所需目錄。

6.2 Session store directory missing

Session store 用於持久化對話 Session，確保 Gateway 重啟後能恢復進行中的對話。同樣可透過 openclaw doctor --fix 自動修復。對於測試環境而言，缺少此目錄意味著 Gateway 重啟後所有進行中的對話會遺失，但不影響基礎功能。

6.3 Memory search needs embedding provider

這是功能性的提醒而非錯誤。OpenClaw 的 Memory 層支援語義搜尋——當累積足夠的對話歷史後，AI 可以透過語義相似度（而非關鍵字匹配）檢索過往對話。啟用此功能需要設定 embedding provider，例如：

# 使用 OpenAI 的 embedding 模型
openclaw config set memory.embedding.provider openai
openclaw config set memory.embedding.model text-embedding-3-small

若不設定，OpenClaw 仍可正常運作，僅語義搜尋功能不可用。對於初次安裝與功能驗證階段，建議先跳過此項。

七、原生 Windows 與 WSL2 的部署決策矩陣

經歷完整的原生 Windows 安裝流程後，我們有足夠的實測數據來比較兩條部署路徑的取捨。以下決策矩陣基於我們團隊分別在原生 Windows 與 WSL2 環境的實際部署經驗：

評估維度原生 WindowsWSL2
安裝複雜度低（一行 PowerShell）中（需先啟用 WSL2 + 安裝 Ubuntu）
Gateway 持久化schtasks（需管理員）或 NSSMsystemd（原生支援，無需 root）
檔案系統存取原生 NTFS，效能最佳跨系統存取有延遲（/mnt/c/）
瀏覽器自動化直接使用系統 Chrome/Edge需安裝 headless Chromium + Xvfb
Skills 相容性部分 Unix 工具需替代方案完整 Linux 工具鏈支援
網路設定直接使用系統網路NAT 橋接，部分埠號需轉發
Docker 整合需安裝 Docker Desktop原生 Docker 引擎支援
適合角色技術決策者快速驗證、非開發角色長期部署、需完整 Linux 工具鏈的開發者

我們的建議：如果你的目標是在 30 分鐘內完成安裝並驗證 OpenClaw 的核心能力（Dashboard 控制、Telegram 串接、基礎對話），原生 Windows 是阻力最小的路徑。如果你計劃長期運行 OpenClaw 並使用進階功能（瀏覽器自動化、Claude Code 整合、定時任務），WSL2 提供了更完整的基礎設施支援[4]。

值得注意的是，這兩條路徑並非互斥。許多用戶的實際做法是：先在原生 Windows 上快速安裝、體驗基礎功能、確認 OpenClaw 符合需求後，再遷移至 WSL2 環境進行正式部署。OpenClaw 的設定檔（openclaw.json）可以直接複製到 WSL2 環境中使用。

結語

回顧這次安裝歷程，整個過程可以濃縮為一個核心洞見：Gateway 是 OpenClaw 一切功能的隱含前提，而 Windows 原生環境下 Gateway 的啟動路徑與 Linux 存在本質差異。

安裝本身是無痛的——一行 PowerShell 指令即完成。Onboard 互動設定也相當直觀。但從 Onboard 完成到 Dashboard 成功連線之間，存在一個未被文件充分說明的斷層：Gateway 服務需要獨立啟動，而 Windows 環境下服務註冊需要管理員權限。這個看似簡單的權限問題，在缺乏明確錯誤提示的情況下，足以讓使用者在 Dashboard 反覆失敗中浪費大量時間。

OpenClaw 作為一個仍在高速迭代的開源專案[5]，其 Windows 原生支援尚處於「可用但不完善」的階段。安裝程式能正確偵測 Windows 環境並完成安裝，Onboard 精靈在 PowerShell 中正常運作，核心功能（Gateway、Dashboard、Telegram 串接）均可在原生 Windows 上執行——但圍繞這些功能的錯誤處理、提示訊息與文件覆蓋度，仍有明顯的改進空間。

對於正在評估 AI 代理工具的技術決策者而言，本文提供了一條經過實測驗證的原生 Windows 部署路徑。如果您的團隊正在考慮將 OpenClaw 納入 AI 自動化策略的評估範圍，歡迎與我們的研究團隊進一步交流——我們將持續追蹤 OpenClaw 在 Windows 平台上的支援進展與最佳實踐。