用 OpenClaw 做本地 AI Agent

把 AI Agent 跑在自己硬體上，感覺真的不一樣。NVIDIA 這套教學，模型下載就要約 87 GB。前期安裝還要 20 到 30 分鐘。

講白了，這不是玩票。NVIDIA 推出一套本地優先的 Agent 堆疊，叫 NemoClaw。它把 OpenClaw 和 OpenShell 綁在一起。你可以在沙箱裡跑長時間運作的助理，不用把提示詞和檔案全丟給雲端服務。

如果你做過 API 串接，就知道差別在哪。雲端聊天機器人很方便。可是一旦要讀檔、跑工具、保留狀態，風險就上來了。這時候，本地模型和隔離執行環境，就不是加分題，而是基本配備。

NemoClaw 到底在做什麼

NemoClaw 的核心概念很直白。模型推論留在本機。Agent 也留在受控執行環境裡。外面再接 Telegram 這類訊息工具，讓使用者可以直接對話。

這套設計裡，OpenShell 負責安全邊界。OpenClaw 負責 Agent 框架。它處理記憶、工具、聊天整合。NVIDIA Build 則提供模型來源。教學裡用的是 Nemotron 3 Super 120B，再透過 Ollama 來服務。

這種架構很像把一個大型工具箱拆開。模型是一塊。沙箱是一塊。介面又是一塊。這樣做的好處很務實。你知道資料流向哪裡。你也知道權限卡在哪裡。對開發者來說，這比一坨黑箱 SaaS 好懂多了。

而且，Agent 已經不是單次回覆的聊天機器人。它會讀檔。它會呼叫 API。它會保留上下文。只要能碰到網路或執行程式，安全模型就要重寫。NVIDIA 的做法，就是先把預設路徑放進隔離環境。

• 模型下載量約 87 GB
• 前期安裝約 20 到 30 分鐘
• 初次 warm-up 約 15 到 30 分鐘
• 120B 模型回覆時間約 30 到 90 秒

硬體目標是 NVIDIA DGX Spark。它跑 Ubuntu 24.04 LTS，也搭配 NVIDIA 最新驅動。官方也提到，其他部署方式不是不行，只是要看你的裝置支不支援對應 API 或 vLLM 類能力。

為什麼安全模型很重要

OpenShell 最有價值的地方，在於它把 Agent 的活動範圍縮小。它會隔離檔案系統。它也會管網路存取。憑證也能集中處理。白話一點，就是讓助理待在小房間，不要直接碰整台機器。

這種做法很合理。因為 Agent 一旦接上工具，攻擊面就變大。你不能只看它會不會聊天。你要看它會不會亂讀檔。會不會亂打外部 API。會不會被惡意輸入帶偏。這些都是真問題，不是資安簡報上的裝飾字。

NVIDIA 在教學裡也直接講了限制。沙箱不是萬能盾牌。這句話很重要。因為很多人看到「本地」兩個字，就以為安全自動升級。其實沒有。你還是得管工具權限。你還是得管輸入來源。你還是得做測試。

“It is important to note that no sandbox offers complete protection against advanced prompt injection.”

這句引述很直白，也很誠實。它提醒你，安全不是靠口號。是靠邊界。靠預設值。靠最小權限。靠你願不願意把測試環境跟正式環境分開。

教學裡還包含導引式安裝、生命週期管理、映像硬化、版本化 blueprint。這些都不花俏。可是真正能讓系統跑久的，通常就是這些 boring 的部分。做過自架服務的人都懂，demo 很簡單，長期維運才是地獄。

本地堆疊跟雲端方案怎麼比

這套流程不是空談。它包含 Docker 設定、Ollama 安裝、模型下載、沙箱安裝，還有 Telegram 串接。步驟很明確。因為每一步都會影響網路、容器和權限設定。

你可能會想問，值不值得。我的看法是，這要看你在交換什麼。雲端方案省事。你開 API 就能用。可是提示詞和資料會離開你的機器。本地方案麻煩很多。可是模型、資料、執行環境都在你手上。

如果你做內部工具，這個差異很實際。尤其是碰到原始碼、內部文件、憑證或法規資料時。很多團隊不是不能用雲端，而是不想把資料流出去。NemoClaw 就是把這條路補起來。

• 雲端 Agent：設定快，但資料會離機器
• 本地 NemoClaw：設定較多，但模型留在裝置內
• 雲端 coding assistant：回應快，但沙箱規則常由供應商決定
• DGX Spark + Ollama + NemoClaw：首輪回應慢，但你能管 runtime、儲存和存取路徑

效能也要老實看。官方預期 120B 模型每次回覆約 30 到 90 秒。這不快。真的不快。可是如果你要的是本地控制權，這個代價算合理。小模型會快很多，但能力和記憶容量也會掉。

教學還提到先做一次測試執行，讓模型權重留在記憶體裡。這種小動作很重要。做過大型模型的人都知道，第一次冷啟動最煩。使用者都已經開始滑手機了，你的模型還在慢慢醒。

Telegram 讓它真的能用

這套東西最實用的地方，反而不是模型本身，而是 Telegram 整合。透過 @BotFather 建 bot 之後，助理就能在 Telegram 裡回話。這樣一來，DGX Spark 就不只是實驗機，而是像一個私人服務。

這很重要。因為長時間運作的 Agent，如果每次都要開終端機，根本沒幾個人會用。Telegram 給了一個簡單入口。你還是把推論和 Agent 邏輯留在本地。只是使用介面變順手了。

教學也提到可以用 SSH tunnel 或 port forwarding 連到 web UI。這種做法我覺得很正派。你不用把管理介面直接開到公網。你只要把瀏覽器流量導進去就好。這比亂開一個公開埠口安全太多。

• Telegram Bot 透過 Telegram Bot API 建立
• 本地 dashboard 使用 127.0.0.1:18789
• 遠端操作可走 SSH tunnel
• 連線驗證可用 nemoclaw my-assistant connect

這種設計很有層次。使用者看到的是簡單介面。系統底下卻把權限切得很細。這比把 Agent 丟進 Slack、Discord、Email 和公開網路來得穩。

如果拿來跟常見雲端 Agent 比，差別很直接。雲端方案通常是供應商管模型端點、執行邊界和大部分運維假設。NemoClaw 則是你自己管機器、管模型、管政策，也管從 Telegram 訊息到推論的整條路。

這對現在做 Agent 的人有什麼意思

NemoClaw 比較像模板，不像炫技。它給開發者一條可重複的路。你可以用本地推論。你可以限制工具存取。你也可以用大家熟悉的訊息介面去包裝它。

我覺得它最適合的場景，是內部工程助理、私有文件查詢、敏感程式碼輔助，還有受管制資料流程。它不需要取代所有雲端助理。真的不用。它只要把「資料留在本機」這件事做扎實，就很有價值。

更大的問題其實不是能不能做，而是團隊願不願意付出設定成本。當你看到 87 GB 下載量、30 到 90 秒回應時間、還有一堆容器與權限設定，你會先皺眉。可是一旦資料敏感度上來，這些成本就變得合理。

我的判斷很直接。像 NemoClaw 這類堆疊，會很適合需要碰原始碼、金鑰或法規資料的內部 AI 工具。尤其是在像 DGX Spark 這種本地硬體上。如果你這季要評估，先問自己一個問題：哪些資料一定要留在裝置內，哪些工具可以放出沙箱？

我會再補一個更實際的建議。先拿一個最小工作流試跑。像是 Telegram 收訊息、讀一個本地檔案、回一段摘要。不要一開始就接滿所有工具。先把邊界定好，再來談擴充，會省很多事。