OpenClaw 初體驗：在 NVIDIA Jetson Thor 上跑 Local Agent 的踩坑紀錄
最近嘗試了 OpenClaw——一個開源的本地 AI Agent 框架，想體驗看看「24 小時自動幫你做事」的感覺。硬體選擇了 NVIDIA Jetson Thor 開發板，搭配 OpenAI 開源的 gpt-oss-120b 模型。過程中踩了不少坑，在這邊記錄一下。
工具簡介
OpenClaw
OpenClaw 是一個開源的 AI Agent 平台，前身為 Clawdbot / Moltbot，由 Peter Steinberger 開發。它的定位不只是聊天機器人，而是一個能自主執行任務的 AI 代理——可以瀏覽網頁、操作檔案、執行終端指令、排程任務，甚至整合 Telegram、Signal、Discord 等通訊平台。
最吸引人的是它支援本地部署，所有資料都留在自己的機器上，也支持外部 LLM（Claude、GPT）和本地模型（Ollama、vLLM）。
NVIDIA Jetson Thor
NVIDIA Jetson Thor™ 是 NVIDIA 最新一代的邊緣 AI 超級模組，核心規格：
- GPU：基於 NVIDIA Blackwell 架構，2560-core GPU + 第五代 Tensor Core
- AI 算力：最高 2,070 FP4 TFLOPS
- 比 Jetson AGX Orin 快 7.5 倍，電源效率提升 3.5 倍
- 主打人形機器人、自動駕駛、智慧影像分析等場景
簡單來說，它是目前 Jetson 系列中最強的邊緣運算平台。
gpt-oss-120b
gpt-oss-120b 是 OpenAI 釋出的開源 LLM，基於 Mixture-of-Experts（MoE） 架構：
- 總參數量：117B（1,170 億）
- 活躍參數量：5.1B（51 億）
- 支援 MXFP4 量化，可在單張 H100 上運行
- Apache 2.0 授權，支援 function calling、結構化輸出
- 可透過 NVIDIA NIM 快速部署
選擇它的原因很單純——開源、夠大、而且 Jetson Thor 的 Blackwell 架構原生支援 FP4。
踩坑紀錄
以下是實際運行過程中遇到的各種問題，依序記錄。
1. Jetson Thor GPU 太新，vLLM 容器不認 FP4
Jetson Thor 使用 Blackwell 架構（sm_110），算是相當新的 GPU。我一開始使用 nvcr.io/nvidia/vllm:26.01-py3 這個 NVIDIA 官方容器來跑模型，結果發現容器認不得這張 GPU，直接拒絕使用 FP4 模式運行。
這是個版本支援的問題——早期的 vLLM 容器還沒加入對 Blackwell 架構（Thor）的完整支援，需要等更新版本的容器或自行編譯 vLLM 並設定 TORCH_CUDA_ARCH_LIST="11.0;11.1;12.0"。
2. contextWindow 設太小會無聲無息地失敗
OpenClaw 在配置模型時有一個 contextWindow 參數。如果這個值設太小，OpenClaw 不會在 UI 上告訴你原因，只是默默地跑不起來。你必須自己去翻 log 才會發現是 context window 不足的問題，且在設定模型的流程上也不會設定該值。
這個 UX 上的小缺陷讓我花了不少時間 debug。
3. 模型設定必須填 apiKey，即使是本地模型
即使你用的是本地 vLLM，OpenClaw 的模型設定中 apiKey 欄位是必填的。如果留空，OpenClaw 自己會無法送出 request。
解法很簡單——隨便填一個假的就好，例如 sk-dummy。但這個行為確實不直覺，本地模型根本不需要 key。
4. 透過 Tailscale 遠端存取 Dashboard 需要額外設定
如果你像我一樣透過 Tailscale 來遠端存取 OpenClaw 的 Dashboard，記得在 OpenClaw 所在的裝置上允許來自 Tailscale 的連線。不然你看得到設備在線，卻怎麼都連不到 Dashboard。
5. Telegram 整合需要在 OpenClaw 內完成配對
想用 Telegram 跟你的 Agent 互動？除了設定 bot token 之外，還需要在 OpenClaw 的設定介面中完成配對（pairing）流程。這一步在文件裡不太顯眼，容易被忽略。
6. ARM64 上的 Snap 版 Chrome 不支援 CDP
Jetson Thor 是 ARM64 架構，Linux 上預設的 Chrome 是透過 Snap 安裝的。問題是 Snap 版的 Chrome 在使用 CDP（Chrome DevTools Protocol） 控制時有諸多限制和問題，OpenClaw 要用瀏覽器自動化時完全跑不動。
7. Docker 跑 Browserless 會讓 CDP 連線中斷
既然系統的 Chrome 不行，我轉而嘗試用 Docker 跑 Browserless 來提供可被 CDP 控制的瀏覽器環境。結果發現操作流程中，例如第一步透過 CDP 開啟網頁後，連線就會斷掉、網頁直接關閉，導致後續的操作（如查看 tabs）自然也跟著失敗。整個瀏覽器自動化流程根本無法串接下去。
8. Docker Chrome 可以跑但 OpenClaw 堅持用預設 Profile
再試了 zenika/alpine-chrome:with-puppeteer 這個 Docker image，倒是成功啟動了一般瀏覽器。但 OpenClaw 本身會一直嘗試用預設的 Chrome profile 去操作，而不是連接到 Docker 裡的瀏覽器實體。
設定 defaultProfile 也沒有效果。也有可能是模型能力不夠，在 Agent 的決策過程中無法正確判斷該走哪條路徑。
9. 300B 以下的模型有強烈建議使用沙盒模式
OpenClaw 在偵測到使用的模型參數量低於 300B 時，會跳出警告建議你開啟沙盒（sandbox）模式運行。言下之意就是模型太小，它信不過模型的判斷能力，怕它做出危險操作。
gpt-oss-120b 的 117B 參數量自然觸發了這個警告。實際體驗下來，模型確實在複雜的 Agent 任務上表現得力不從心。
結語
「一個 AI Agent 24 小時幫你服務」的概念確實很吸引人，但以目前的狀況來看，要在本地端順暢跑起來還有一段距離。
回顧這次的經歷，問題大致可以歸納為：
- 硬體相容性：新架構的 GPU 需要等軟體跟上
- 軟體成熟度：OpenClaw 的設定體驗還有許多可以改善的地方
- 模型能力：Agent 任務對模型的推理能力要求很高，中小型模型力有未逮
- 瀏覽器整合：ARM64 環境下的瀏覽器控制仍是個大坑
網路上看到能順暢運行 OpenClaw 的案例，基本上都是有砸錢下去的——用 Claude 或 GPT-4 等級的雲端模型。
我的結論是：等過段時間 local agent 生態更成熟，或者有更新的技術突破再來嘗試看看吧 Orz 現階段，這類工具更適合搭配強大的雲端模型使用，純靠本地模型要達到可用的程度，還需要一些時間。
相關連結：