跳轉到主要內容
這個單元解決什麼問題NemoClaw 是 NVIDIA 在 2026-03 開源的 reference stack，把「總是開著」的 AI 代理（OpenClaw、Hermes）放進 OpenShell 沙箱內運行。它不重新發明 agent 框架，而是提供 CLI 引導、YAML 藍圖、SSRF 驗證、網路政策、managed inference 等強化層，把既有 agent 變成「可被企業環境信任的常駐服務」。本單元從由來、核心技術、系統結構、自訂檔案、安全性、該學什麼六個面向深度解析，並對位到 05-1、05-2 與 05-4。

​
學習目標

  • 能說清 NemoClaw 在堆疊中的位置（不是另一個 agent 框架，是 OpenClaw/Hermes 上層的硬化層）
  • 能描述三層架構：OpenShell 沙箱 → NemoClaw CLI/Blueprint → OpenClaw 或 Hermes 代理
  • 能說出 blueprint.yaml、policies/、model-specific-setup/ 三類自訂檔案的職責
  • 能列出 NemoClaw 的四道安全護欄（網路政策、憑證淨化、SSRF 驗證、Docker capability drops）對應的攻擊面
  • 能評估「要不要把自家 agent 跑進 NemoClaw」的取捨代價

​
1. 由來與定位

  • 發布時點：2026-03-16，NVIDIA 於 GTC 2026 開源，Apache 2.0 授權（截至 2026-06）
  • 為何做：always-on agent（持續連線、可被訊息喚醒）對企業環境帶來新攻擊面：提示注入誘導 agent 打外網、依賴套件升級夾帶後門、容器逃逸、憑證透過錯誤訊息外洩。NemoClaw 給出「不丟失 agentic 能力但能被 ops 團隊接受」的硬化範本
  • 與 05-1（OpenClaw）、05-2（Hermes-Agent）的關係：包覆兩者，不是取代。沒有 agent 跑在裡面，NemoClaw 沒有意義
  • 選型理由：OpenShell（NVIDIA 自家沙箱引擎）+ Claude Code 風格 sub-agent + OpenClaw 預設相容 + 雙 CLI alias 支援 Hermes
  • 與 OpenClaw 既有機制相容：透過 nemoclaw/ Commander 插件注入命令，OpenClaw 的 heartbeat、SOUL.md、skills 機制不需修改

​
2. 核心技術

  • 雙語言堆疊（依官方 AGENTS.md）：
    • TypeScript：CLI 核心（src/lib/）與 OpenClaw plugin（nemoclaw/src/）
    • YAML：藍圖（nemoclaw-blueprint/blueprint.yaml）與政策（nemoclaw-blueprint/policies/）
    • Bash/Python：scripts、E2E 工具
    • CommonJS（bin/）：stable entry point launcher，與 TypeScript 編譯產物分開管理版本
  • OpenShell 沙箱：每個 agent 跑在隔離 runtime 內，工具集與網路存取受限（沙箱細節見 05-4 對 sandbox 章節的討論）
  • Managed Inference：@aws-sdk/client-bedrock-runtime + 路由層 + model-specific-setup registry 處理「同一 agent 不同模型供應商」的相容性
  • 四道安全護欄：network policies、credential sanitization、SSRF validation、Docker capability drops（細節見第 5 節）
  • 多 agent 支援：原生支援 OpenClaw（預設）與 Hermes（透過 NEMOCLAW_AGENT=hermes 環境變數切換，CLI alias nemohermes）
  • 執行環境需求：Node.js >= 22.16.0（engines 欄宣告，意味著採用較新 V8 與 ESM 特性）

​
3. 系統結構：三層堆疊如何組合

組件對照表（依官方 AGENTS.md）：
路徑語言職責
bin/JavaScript (CJS)CLI launcher（nemoclaw.js / nemohermes.js）與相容性 helper
src/lib/TypeScript核心 CLI：onboard、credentials、inference、policies、preflight、runner
nemoclaw/TypeScriptOpenClaw plugin（Commander 擴充）
nemoclaw/src/blueprint/TypeScriptrunner、snapshot、SSRF 驗證、state 管理
nemoclaw/src/commands/TypeScriptslash 命令、migration 狀態
nemoclaw/src/onboard/TypeScriptonboarding config
nemoclaw-blueprint/YAMLblueprint 定義與網路政策
nemoclaw-blueprint/policies/YAML網路 egress 規則
nemoclaw-blueprint/model-specific-setup/JSON代理-模型相容性 registry
agents/openclaw/、agents/hermes/資產代理部署資產
.agents/skills/Markdown11 個 user skill 與 maintainer / contributor 三層
看倉庫最快的方式：先讀 AGENTS.mdNemoClaw 自己的 AGENTS.md 就是給 agent 讀的「這專案怎麼運作」摘要，比 README 更結構化，比源碼更快掌握。讀陌生開源專案時先找它的 AGENTS.md / CLAUDE.md / CONTRIBUTING.md 三件套，是省時間的捷徑。

​
4. 自訂檔案：四類設定面

YAML 為主，TypeScript 為輔，分四層：

​
4.1 Blueprint：整個堆疊的單一事實來源

  • nemoclaw-blueprint/blueprint.yaml：宣告 sandbox 結構、預設政策、推論路由
  • 與「agent 工作區的 openclaw.json」的差異：blueprint 是「ops 想要的狀態」，工作區設定是「agent 自己的偏好」；兩者分離避免使用者改壞企業政策
  • 改 blueprint 需重啟 sandbox；改工作區設定是 hot-reload

​
4.2 Network Policies：egress 控管

  • 位置：nemoclaw-blueprint/policies/
  • 行為：白名單外網目標、阻擋 SSRF、限制連線埠與 protocol
  • 設計理由：always-on agent 最大的攻擊面是「agent 被 prompt injection 誘導去呼叫外網 API 拉資料或上傳 token」；網路政策是最後一道離開主機的關卡
  • 客製化：透過 nemoclaw manage policy 指令或直接編輯 YAML

​
4.3 Model-Specific Setup：相容性 registry

  • 位置：nemoclaw-blueprint/model-specific-setup/*.json
  • 內容：哪個 agent 配哪個 provider、需要哪些特殊 header 或參數
  • 用場：同樣跑 OpenClaw，切到 Bedrock 與切到 vLLM 需要不同 system prompt 前綴與 token 限制；這個 registry 把這層差異收斂到一個檔
  • 啟發：把「模型/服務相容性」當作可宣告的資料，不寫死在 agent 程式碼裡

​
4.4 Skills：給 agent 自己讀的文件

  • 位置：.agents/skills/，三層分眾
    • nemoclaw-user-*（10 個，end user：overview、get-started、configure-inference、configure-security、manage-policy、manage-sandboxes、monitor-sandbox、deploy-remote、agent-skills、reference）
    • nemoclaw-maintainer-*（project maintainer）
    • nemoclaw-contributor-*（codebase contributor）
  • 載入機制：用 nemoclaw-skills-guide skill 取得完整目錄與決策樹
  • 設計觀察：把「文件分眾」當作 first-class metadata，不混在同一層

​
使用者側設定目錄：~/.nemoclaw/

上面 4.1 到 4.4 是你（或 ops）在倉庫 nemoclaw-blueprint/ 裡宣告的硬化設定，進版控、是「這個堆疊該長怎樣」的設計。另有一組不在倉庫、而在你 home 下的檔案：跑完 nemoclaw onboard 後，CLI 在你機器上生成的執行期狀態，這才是日常 CLI 直接讀寫的位置（截至 2026-06）：
~/.nemoclaw
config.json · onboarding 狀態、inference route 設定
sandboxes.json · sandbox 登錄表（含 metadata）
credentials.json · 使用者 API key（明文 JSON，file mode 600）
onboard.json · onboarding 組態快照
state
nemoclaw.json · 執行狀態追蹤
三個要點：
  • ~/.nemoclaw/ 與倉庫 blueprint 的分工：blueprint（nemoclaw-blueprint/blueprint.yaml）是宣告式藍圖、進版控；~/.nemoclaw/ 是 onboard 在這台機器上落地的執行期狀態、不進版控。前者是設計，後者是這台機器的當前實況。
  • 沙箱內另有一份 OpenClaw 設定：沙箱 container 內部有 /sandbox/.openclaw/openclaw.json（agent 設定、模型、gateway）與 .config-hash（SHA256 完整性驗證）。這份在容器內、不在 host home，對位的正是 05-1 的 openclaw.json，只是被 NemoClaw 包進沙箱代管。
  • uninstall 會整個移除 ~/.nemoclaw/：執行期狀態與設計藍圖分離，所以解除安裝清掉 home 狀態，倉庫 blueprint 不受影響。
credentials.json 是明文、不加密、不進 OS keychainNemoClaw 把使用者輸入的 API key 以明文 JSON 寫進 ~/.nemoclaw/credentials.json，僅靠 file mode 600 限制權限；官方說明它不加密、也不整合作業系統 keychain。把它排除在 cloud sync（iCloud、OneDrive、Dropbox）與廣域備份之外，否則明文金鑰會被同步上雲。對照之下，provider 的 inference token 由 OpenShell gateway 在 egress 時注入、不落地 host 磁碟，安全模型較好；落地風險集中在這個 credentials.json。

​
5. 安全性認知：四道護欄對應的攻擊面

護欄實作位置對應攻擊面你該驗證的事
Network policiesnemoclaw-blueprint/policies/agent 被誘導打外網、SSRF、token 上傳預設 deny 嗎？政策可被 plugin 繞過嗎？
Credential sanitizationsrc/lib/credentialsAPI key、token 透過日誌或錯誤訊息外洩log 會自動 redact 嗎？哪些 secret 型別被認得？
SSRF validationnemoclaw/src/blueprint/ssrf.tsagent 抓 URL 卻觸及內網 metadata 服務（169.254.169.254 等）拒絕 loopback / link-local / RFC1918 嗎？
Docker capability drops + process limitsOpenShell runtime容器逃逸、CPU/記憶體耗盡預設 drop ALL caps 嗎？有 no-new-privileges 嗎？
安全不是附加功能，而是部署前提NemoClaw 的 README 第一個 badge 就是「Security: Report a Vulnerability」，SECURITY.md 規定漏洞須走 NVIDIA PSIRT 或 PGP 信道申報，不開 public issue。這是給企業環境的訊號：硬化層不是裝飾品，是部署 always-on agent 的前提。如果你想把 OpenClaw/Hermes 放進企業環境，沒有等效硬化層就不要上 production。

​
6. 該學什麼：六個值得內化的設計

  • 外殼即策略：與其讓 agent 自己決定「能不能打外網」，由外殼宣告（YAML blueprint）並強制執行（OpenShell + policy engine）。把「安全政策」與「agent 邏輯」徹底解耦
  • Managed inference 作為橫切關注點：模型相容性不是 agent 程式碼的事，是部署層的事。model-specific-setup registry 把「同 agent 多模型」變成可宣告資料
  • 三層分眾的文件：user / maintainer / contributor 各一組 skill，避免「一個 README 服務所有人」造成的資訊過載
  • Plugin 而非 fork：nemoclaw/ 是 OpenClaw 的 plugin（Commander 擴充），不是 OpenClaw 的 fork。升級上游時不需要 rebase 大改
  • 雙 CLI alias：nemoclaw（OpenClaw）與 nemohermes（Hermes）共用同一個 package，agent 切換不需重裝
  • Sandbox 邊界即安全審計單位：OpenShell 既是 runtime，也是審計邊界。同一個 agent 跑在兩個 sandbox 就是兩個審計單位，事件可獨立追溯
對位到你自己的部署假設你想把團隊內部的 OpenClaw 部署到 staging：
1

寫 blueprint

git clone OpenClaw 後，先寫一份 nemoclaw-blueprint/blueprint.yaml 描述「這個 agent 允許打哪幾個內網 API、不能打的外部 host、推論走哪個 provider」。
2

執行 onboard

跑 npx nemoclaw onboard 引導，會自動生成 policies/ 與 model-specific-setup/。
3

部署到 staging

npx nemoclaw deploy-remote 推到 staging。
4

監控

在 staging 用 npx nemoclaw monitor-sandbox 觀察 SSRF 嘗試、policy 違規、credential 曝險。
5

切換 provider

需要切換推論 provider？編輯 model-specific-setup/ 對應 JSON，重啟 sandbox 即可，agent 程式碼不動。
這條路徑展示了「agent 邏輯不動，只改 blueprint」的好處：升級 OpenClaw 上游時不必 rebase 你的硬化層。

​
7. 該反問自己什麼

  • 你的 always-on agent 有沒有等效的四道護欄？沒有的話風險面是什麼？
  • 你的 blueprint 或政策是程式碼（可版控、可審查）還是藏在 docker run 指令或 helm values 裡？
  • 你的 agent 升級上游時，硬化層會被原樣保留還是必須 rebase？
  • 你的 skill 或文件分眾機制是固定的還是隨 agent 演進？
  • 你的 SSRF 與 credential sanitization 是「預設開啟」還是「要記得開」？

​
8. 一句生活比喻

NemoClaw 像把一個會走會跑的機器人放進強化玻璃展示間：機器人本身沒換（OpenClaw 還是 OpenClaw、Hermes 還是 Hermes），但展示間決定了它能碰什麼、不能碰什麼、看得到誰、誰看得到它。展示間的政策（YAML blueprint）是可版控的，機器人的人格（SOUL.md）也是可版控的，兩層分開管理。

​
9. 與 05-1、05-2、05-4 的對位

維度05-1 OpenClaw05-2 Hermes-Agent05-3 NemoClaw
角色agent 本體agent 本體agent 的硬化外殼
語言TypeScriptPythonTypeScript + YAML + Bash
沙箱可選（agents.defaults.sandbox）6 種 terminal 後端強制（OpenShell）
網路政策工具層級工具層級blueprint + policy engine
推論路由客戶端客戶端managed inference + registry
Skill 載入skills/skills/（progressive）.agents/skills/ 三層分眾
企業就緒否（local-first 個人）否（local-first 個人）是（policy-as-code + 漏洞揭露流程）

​
動手做

1

讀 AGENTS.md

git clone https://github.com/NVIDIA/NemoClaw 後跑 cat AGENTS.md，對照本單元的「系統結構」段；專案自己為 agent 寫的 AGENTS.md 是最權威的「這專案怎麼運作」摘要。
2

看 blueprint 形狀

閱讀 nemoclaw-blueprint/blueprint.yaml 與 nemoclaw-blueprint/policies/ 一個範例，體會 policy-as-code 的形狀。
3

觀察三層分眾

用 gh api repos/NVIDIA/NemoClaw/contents/.agents/skills --jq '.[].name' 列出所有 skill，觀察三層分眾的命名規律。

​
常見誤區

  • 以為 NemoClaw 是另一個 agent 框架：它是硬化外殼，沒有自己的 AIAgent 主迴圈。沒有 OpenClaw 或 Hermes 跑在裡面，NemoClaw 沒有意義
  • 把 blueprint 當成設定檔隨意改：blueprint 是企業政策的「期望狀態」，改完需重啟 sandbox 且通過 preflight 驗證；不要繞過 preflight 直接編輯執行中的 sandbox
  • 混用 nemoclaw 與 nemohermes 指令：兩者管的是不同 agent 的 onboarding；混用會把 OpenClaw 的設定寫到 Hermes 沙箱裡（資料夾結構不同）
  • 忽略 model-specific-setup/ 的版本相容性：升級模型 provider 後沒更新 registry，agent 會以為新模型有舊模型的相容能力，導致靜默失敗

​
自我檢核

自我檢核
  1. 能用一張堆疊圖畫出 OpenShell、NemoClaw、OpenClaw 三者關係嗎？
  2. 能說出四道安全護欄各自對應的攻擊面嗎？
  3. 能解釋為何 nemoclaw-blueprint/ 採 YAML 而非 TypeScript 或 JSON 嗎？
  4. 能評估「把你的 OpenClaw 部署搬進 NemoClaw」需要改什麼、保留什麼嗎？

​
來源與延伸閱讀

事實主張依官方文件，快變動項標註截至 2026-05。
  • 銜接：05-1 OpenClaw agent 本體、05-2 Hermes-Agent 本體、05-4 三條路線比較（含沙箱深度討論）、01-6 harness 設計六要素（NemoClaw 的安全外殼是其中安全邊界要素的完整實例）。