NVIDIA 在 GTC 2026 上发布的 NemoClaw，不是又一个 AI 框架，而是 Agent 时代缺失的那块“操作系统级安全基座”。本文将从源码出发，拆解它的本质、架构与设计哲学。

引言：Agent 越强，企业越怕

2026 年，AI Agent 彻底出圈。从技术大佬到创业玩家，从美国硅谷到深圳龙岗，人人都在拥抱 Agent 浪潮。OpenClaw 以超过 33万 GitHub 星标的速度成为有史以来增长最快的开源项目，NVIDIA CEO 黄仁勋在 GTC 2026 上直言：

Mac 和 Windows 是个人电脑的操作系统；而 OpenClaw 则是个人 AI 的操作系统。

但这句话的背后藏着一个巨大的隐患 —— 操作系统意味着 Agent 拥有和人类一样的系统控制权。

正如《网心技术 | AI Agent 上岗，从能用 → 敢用》一文提到： OpenClaw 能根据你的需求自行搭建环境、写代码、做测试、交付结果。从这个视角理解，Agent 至少具备了以下核心能力：

但能力越强，边界越模糊，权限越大，风险也就越显性。正是在这样的背景下，NVIDIA 在 GTC 2026 上发布了 NemoClaw —— 一个给 AI Agent 的企业级运行时。

本文将从源码级别，深度拆解 NemoClaw 到底是什么、解决什么问题、如何解决，以及它的未来走向。

NemoClaw 到底是什么？

NemoClaw 是 NVIDIA 开源的、企业级 OpenClaw 安全运行环境参考方案（Reference Stack）。用更通俗的话说：NemoClaw = OpenShell 安全沙箱运行时 + Nemotron 开源模型 + 声明式安全策略 + 一条命令搞定一切的 CLI。

它不是一个 AI 框架，不是一个模型，更不是 Agent 的替代品。它是 Agent 的运行环境（Runtime Environment），就像 Docker 是应用的运行环境、JVM 是 Java 的运行环境一样。

从 NemoClaw 项目的 README.md 的第一行就能看出它的定位：NVIDIA NemoClaw: Reference Stack for Running OpenClaw in OpenShell

这里有三个关键词需要拆解：

1、Reference Stack

NemoClaw 不是一个最终产品，而是一个参考实现。它展示了"如何正确地、安全地运行 AI Agent"的最佳实践。企业可以直接使用它，也可以基于它二次开发自己的 Agent 运行环境。这个定位非常重要 —— 它意味着 NemoClaw 的价值不在于代码本身，而在于它定义了一种模式和标准。

2、OpenClaw

OpenClaw 是当前最流行的开源 AI Agent 平台，由 Peter Steinberger 创建。它本质上是一个"会用电脑的 AI 助手"，拥有技能系统（Skills）、通道系统（Channels）、工作流（Workflows）等完整的 Agent 基础设施。但它本身没有安全沙箱，而是直接运行在操作系统上，拥有和你一样的全部权限。

3、OpenShell

OpenShell 是 NVIDIA Agent Toolkit 的一部分，是一个安全运行时。它利用 Linux 内核的 Landlock LSM、seccomp BPF 和网络命名空间（namespace）等技术，在操作系统层面为 Agent 提供沙箱隔离。OpenShell 才是 NemoClaw 的核心引擎，NemoClaw 是 OpenShell 在 OpenClaw 场景下的"开箱即用"封装。

我们用一张图来表达它们的关系：

为什么需要 NemoClaw？

要理解 NemoClaw 为何诞生，必须先回顾 2026 年初 AI 安全领域的几起标志性事件。

1、ClawHavoc

2026 年 1 月底至 2 月，安全公司 Koi Security 在 ClawHub（OpenClaw 的官方技能市场）中发现了一场名为 ClawHavoc 的大规模供应链攻击：1,184 个恶意 Skills 被注入 ClawHub；单个攻击者 "hightower6eu" 上传了 354 个恶意包，另一个 "sakaen736jih" 提交了 199 个，频率高达每分钟一个 —— 明显是自动化操作；所有恶意 Skill 使用同一套手法：伪装成前置安装步骤，静默部署 Atomic macOS Stealer (AMOS)，窃取密码、浏览器 Cookie、加密钱包和 macOS 钥匙串数据。

截至 2 月 16 日，恶意 Skill 数量已增长到 824 个，占整个生态约 20%。更触目惊心的是：安全研究人员发现超过 135,000 个暴露在公网上的 OpenClaw 实例使用了不安全的默认配置，其中超过 12,800 个可直接被远程代码执行漏洞利用，大量 API 密钥、聊天记录和账户凭证在裸奔。

2、CVE 漏洞群

除了供应链攻击，OpenClaw 本身也暴露出一系列严重漏洞：

工信部 NVDB 发布的安全预警更是直接指出：ClawHub 中 36.8% 的 Skill 至少存在一项安全漏洞。

3、MCP 协议的安全困境

MCP（Model Context Protocol）本是 AI Agent 的"USB-C 标准接口"，但安全设计的缺失使其成为新的攻击面。数据显示：部署 10 个 MCP 插件的被利用概率达 92%；3 个互连服务器的风险即超 50%；数百个 MCP 服务器在公网裸奔且无认证。

这些事件揭示了一个根本性的矛盾：Agent 的核心价值（自主执行能力）恰恰是安全风险的根源。引用微软在 2026 年 2 月 19 日发布的安全指南：OpenClaw 应被视为不可信代码执行环境，且拥有持久化凭证。建议完全隔离 —— 专用虚拟机、非特权凭证、仅访问非敏感数据。但“专用虚拟机”的方案在企业大规模部署时成本极高，操作复杂。企业需要的是一种既能保持 Agent 生产力、又能系统性控制风险的解决方案 —— 这就是 NemoClaw 诞生的直接原因。

NemoClaw 的核心架构

从源码分析，NemoClaw 的架构可以清晰地分为四个层次：

第一层：CLI Plugin（命令行插件层）

目录结构

来自 docs/reference/architecture.md ：

这一层使用 TypeScript 编写，是用户与 NemoClaw 交互的入口。设计原则是 "Thin Plugin"（轻量插件） —— 它只负责用户交互和命令分发，不包含核心编排逻辑。

从 index.ts 中可以看到，插件启动时做三件事：

1、注册 /nemoclaw 命令（支持 status、eject、onboard 子命令）

2、注册 NVIDIA 推理提供者（Inference Provider）

3、打印配置 Banner（显示当前 Endpoint、Provider 和 Model）

第二层：Blueprint（蓝图编排层）

Blueprint 是 NemoClaw 架构中最精妙的设计之一。它包含所有沙箱创建、策略应用和推理配置的逻辑。

目录结构：

blueprint.yaml 定义了整个部署的元数据：

Blueprint 生命周期遵循五个阶段：Resolve（解析） → Verify（验证摘要） → Plan（规划） → Apply（应用） → Status（报告）

这种设计模式借鉴了 Plan/Apply 模型 —— 先声明目标状态，再计算差异，最后执行变更。这确保了部署的可预测性和可重复性。

从 runner.py 的 action_apply 函数可以看到实际执行步骤：

为什么要把 Plugin 和 Blueprint 分开？源码中的设计原则写得很清楚："Plugin 保持轻量和稳定。编排逻辑存在于 Blueprint 中，可以独立发布和演进。"这样就可以保证安全策略的更新不需要升级整个 NemoClaw，只需要更新 Blueprint 即可 —— 对于企业安全运维来说，这个设计很关键。

第三层：OpenShell Sandbox（安全沙箱层）

这是 NemoClaw 的安全核心。OpenShell 是一个独立的开源项目，它提供了操作系统级别的 Agent 隔离能力。

从 Dockerfile 中可以看到沙箱镜像的构建过程：

OpenShell 沙箱提供了四层保护：

从默认安全策略文件 openclaw-sandbox.yaml 中可以看到具体的安全规则：

注意 binaries 字段 —— 这意味着即使网络白名单放行了某个域名，也只有指定的二进制文件才能访问。比如 integrate.api.nvidia.com 只允许 openclaw 进程访问，沙箱内的其他进程无法连接。这种细粒度的控制提供了强有力的安全保障。

第四层：Inference Routing（推理路由层）

推理路由是 NemoClaw 解决"隐私与推理能力矛盾"的关键设计。核心原则：Agent 的推理请求永远不会直接离开沙箱。

Agent (沙箱内)  →  OpenShell Gateway  →  NVIDIA Endpoint (build.nvidia.com)

当 Agent 需要调用大模型时，它以为自己在调用 https://inference.local/v1 — — 这实际上是沙箱内的一个虚拟域名。OpenShell Gateway 拦截这个请求，在沙箱外部将其路由到真正的推理后端（NVIDIA API、本地 vLLM、Ollama 等）。

从 Dockerfile 中的配置生成逻辑可以看到这一机制：

这个设计有三个关键好处：

1、API Key 不进沙箱：推理服务的真实 API Key 存储在 OpenShell Gateway 层，沙箱内的 Agent 无法获取

2、模型可热切换：运维可以在不重启沙箱的情况下切换推理后端

3、隐私路由器：Gateway 可以在将请求转发到外部 API 之前，对敏感字段进行脱敏处理

NemoClaw 当前支持多种推理配置档案：

源码深度走读：从 nemoclaw onboard 到沙箱运行

让我们沿着一条完整的用户旅程，从源码层面跟踪 NemoClaw 的全部工作流程。

一、安装阶段

用户执行：curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

install.sh 执行以下步骤：

1、检测环境：确认 Node.js 20+、容器运行时（Docker/Colima/Docker Desktop）

2、安装 OpenShell：调用 scripts/install-openshell.sh 安装 openshell CLI

3、安装 NemoClaw：通过 npm install -g nemoclaw 全局安装

安装完成后，运行 nemoclaw onboard 进入引导式向导。

二、Onboard 阶段

nemoclaw onboard 触发 Blueprint 生命周期：

Step 1: Resolve（解析）

Plugin从OCI注册表(ghcr.io/nvidia/nemoclaw-blueprint)下载 Blueprint，检查版本兼容性：

min_openshell_version: "0.1.0"、min_openclaw_version: "2026.3.0"

Step 2: Verify（验证）

校验 Blueprint 工件的摘要（digest），确保供应链安全 —— 防止下载到被篡改的 Blueprint。

Step 3: Plan（规划）

runner.py 的 action_plan 函数分析当前环境，生成部署计划：

值得注意的是 validate_endpoint_url 函数实现了 SSRF 防护：

这个细节体现了 NemoClaw 团队的安全意识 —— 即使是在内部工具中，也防范了 SSRF（服务端请求伪造）攻击。攻击者无法通过提供一个解析到内网 IP 的域名来访问内部服务。

Step 4: Apply（应用）

执行实际部署操作：创建沙箱、配置推理提供者、设置推理路由。

Step 5: Status（报告）

确认部署状态，生成总结信息。

三、Docker 镜像构建

nemoclaw onboard 使用 Dockerfile 构建沙箱镜像。这个过程包含几个安全关键步骤：

多阶段构建：Stage 1 编译 TypeScript 插件，Stage 2 只包含运行时依赖

安全敏感环境变量处理：

不可变配置：openclaw.json 在构建时生成，运行时通过 DAC（自主访问控制）锁定为 root 所有 + 只读

每次构建唯一认证令牌：secrets.token_hex(32) 确保每个镜像有唯一令牌

四、沙箱启动

scripts/nemoclaw-start.sh 是沙箱的入口脚本：

1、写入认证配置（auth-profiles.json）

2、启动 OpenClaw Gateway（openclaw gateway run）

3、启动自动配对 Watcher（监听浏览器连接请求并自动批准）

4、打印 Dashboard URL（包含 auth token）

五、运行时连接

用户执行 nemoclaw my-assistant connect 进入沙箱交互式 Shell，然后：

openclaw tui：启动交互式聊天界面

openclaw agent --agent main --local -m "hello"：发送消息给 Agent

此时，Agent 运行在沙箱内部，所有操作都受安全策略约束。

安全设计哲学：为什么是"进程外强制执行"？

NemoClaw / OpenShell 的安全设计遵循一个核心原则，这也是它与其他方案最本质的区别：

1、进程外强制执行

传统的 Agent 安全方案通常采用"进程内"方式 —— 在 Agent 代码中嵌入安全检查、权限控制、审计日志等。但这种方式有一个致命缺陷：如果攻击者获得了 Agent 进程内的任意代码执行权，所有安全控制都形同虚设。ClawHavoc 事件完美证明了这一点 —— 恶意 Skill 在 Agent 进程内执行，拥有和 Agent 一样的全部权限。

OpenShell 采用了完全不同的思路：安全层运行在完全独立的进程中，在操作系统层面强制执行。即使 Agent 进程被完全攻陷 —— 攻击者在沙箱内拥有任意代码执行能力 —— 也无法修改约束自己的策略，因为策略引擎位于不同的信任边界。

用一个类比来理解：

2、默认拒绝

从安全策略文件可以看到，NemoClaw 遵循"默认拒绝一切，显式允许所需"的原则：

网络：默认拒绝所有出站连接，只允许白名单中的域名和端口

文件系统：默认只读，只有 /sandbox 和 /tmp

进程：默认非 root，禁止提权

当 Agent 试图访问未在白名单中的网络时，请求被阻止，并在 TUI 中通知运维人员进行实时审批。这实现了一种Human-in-the-Loop的安全模式。

3、不可变基础设施

NemoClaw 沙箱采用了不可变基础设施的理念：

核心配置文件（openclaw.json）构建时生成，运行时只读

Agent 的可写状态与不可变配置通过符号链接分离

每次部署从相同的 Blueprint 重新创建沙箱，确保可重复性

4、对应前文博客的安全四层框架

如果将 NemoClaw 的安全能力映射到企业 Agent 安全的四层框架：

可以说，NemoClaw 是前文博客所描述的"Agent 安全运行环境"理念的一个具体工程实现。它把"应该怎么做"变成了"一条命令就能做到"。

与现有方案的对比：Docker Sandboxes、VM 隔离等

NemoClaw 并非唯一的 Agent 安全方案。让我们对比几种主流选择：

一、原生 Docker 隔离

Docker 提供了容器级别的隔离，但：

1、Docker 的网络隔离是全有或全无 —— 要么能访问网络，要么不能。缺乏细粒度的域名级白名单

2、没有内置的"推理路由" —— API Key 必须传入容器

3、没有"运维实时审批"机制

4、容器逃逸仍是已知攻击面

二、Docker Desktop 的 NanoClaw 沙箱

Docker 为 NanoClaw（OpenClaw 的某精简版）提供了沙箱支持，使用 microVM 隔离：

1、microVM 比容器更安全（硬件级隔离）

2、但只支持 NanoClaw，不支持完整的 OpenClaw

3、缺乏声明式策略系统

4、没有推理路由和隐私保护

三、虚拟机（VM）隔离

微软建议的方案 —— 专用 VM：

1、隔离最彻底

2、成本高、部署复杂、不适合大规模

3、没有标准化的策略管理

4、缺乏 Agent 专属的安全原语（推理路由、网络审批等）

四、NemoClaw 与其他方案的差异化

NemoClaw 的核心差异在于：它不只是"隔离"Agent，而是理解 Agent 的行为模式，针对 Agent 的特定需求（推理调用、工具执行、网络访问）设计了专属的安全原语。

NemoClaw 的未来：从 OpenClaw 专属到通用 Agent 安全层

一、当前状态

NemoClaw 于 2026 年 3 月 16 日在 GTC 上发布，目前处于 Alpha 早期预览 阶段，官方明确标注："此软件尚未达到生产就绪状态。接口、API 和行为可能在没有通知的情况下发生变化。"从源码版本号 0.1.0 也能看出这一点。NemoClaw 的核心代码库并不庞大 —— 几千行 TypeScript + Python，主要工作由底层的 OpenShell 承担。

二、已知局限

1、未经独立安全审计：对于一个以安全为核心价值的产品，缺乏第三方审计是最大的风险

2、Linux 优先：macOS 上的 Podman 尚不支持；Windows 依赖 WSL

3、可观测性不足：行业分析师指出，生产环境还需要更完善的可观测性、回滚和审计追踪能力

4、仅支持 OpenClaw：当前版本针对 OpenClaw 设计，不支持其他 Agent 框架

三、OpenShell 的 Agent 无关性

NemoClaw 背后的 OpenShell 运行时本身是 Agent 无关的。OpenShell 的文档明确指出，它可以运行任何 Agent —— Claude Code、Codex、LangChain 自定义 Agent 等。NemoClaw 只是 OpenShell 在 OpenClaw 场景下的第一个参考实现。

这意味着 NVIDIA 的长期战略很可能是：

今天：NemoClaw = OpenShell + OpenClaw（单一 Agent 参考方案）

明天：OpenShell 成为通用 Agent 安全运行时标准

未来：NemoXxx = OpenShell + 任意 Agent 框架（企业级 Agent 安全平台）

四、NVIDIA 的战略意图

黄仁勋在 GTC 上说过一句意味深长的话："NemoClaw 是免费的 —— 产品是平台。"

这句话揭示了 NVIDIA 的真实战略：NemoClaw 不是要卖软件，而是要定义 Agent 时代的基础设施标准。就像 CUDA 定义了 GPU 计算标准一样，NVIDIA 希望 OpenShell 成为 Agent 安全运行时的事实标准。从商业角度看，这个逻辑很清晰：

1、免费的 NemoClaw 推动 Agent 大规模安全部署

2、Agent 需要推理能力 → 推动 NVIDIA GPU 和 Nemotron 模型的需求

3、企业需要更强的推理性能 → 推动 DGX Spark、DGX Station 等硬件销售

4、Agent 运行时标准化 → 锁定生态位，构建护城河

五、行业影响与未来方向

NemoClaw 的出现标志着一个重要的行业趋势：Agent 安全正在从"附加功能"变成"基础设施"。就像 Web 应用需要 HTTPS、容器化应用需要 Kubernetes 一样，Agent 应用将需要专属的安全运行时。而这个运行时需要解决的核心问题包括：

1、沙箱隔离：Agent 不能无限制地访问宿主机资源

2、网络控制：Agent 的出站连接必须可审计、可控制

3、推理隐私：企业数据不能无保护地发送到外部 API

4、策略管理：安全规则必须是声明式的、可版本化的、可审计的

5、操作员控制：人类必须保留对 Agent 行为的最终控制权

NemoClaw 目前只覆盖了这些问题的基础部分，但它的架构设计为未来的扩展留下了充足的空间。未来可能的演进方向包括：

1、多 Agent 编排的安全协调：当多个 Agent 需要协作时，如何管理它们之间的信任关系和权限传递

2、策略即代码（Policy as Code）的深化：与 GitOps 工作流集成，实现安全策略的版本控制和自动化部署

3、AI 驱动的异常检测：用 AI 来监控 Agent 行为，识别异常模式

4、合规性框架集成：与 SOC 2、ISO 27001 等企业合规框架对接

5、跨 Agent 框架支持：从 OpenClaw 扩展到 Claude Code、Codex、自定义 Agent 等

实战体验：从零到安全运行的全流程

为了让读者更直观地理解 NemoClaw 的工作方式，让我们走一遍完整的实战流程。

一、环境准备

NemoClaw 的硬件要求并不苛刻：

沙箱镜像压缩后约 2.4 GB。在镜像推送过程中，Docker 守护进程、k3s 和 OpenShell 网关会同时运行，如果内存不足 8 GB，可能触发 OOM Killer。配置 8 GB 交换空间可以缓解此问题。

软件依赖：

1、Linux（Ubuntu 22.04+）或 macOS（Apple Silicon，需 Colima 或 Docker Desktop）

2、Node.js 20+

3、容器运行时（Docker、Colima 或 Docker Desktop）

4、OpenShell（由安装脚本自动安装）

对于 NVIDIA DGX Spark 用户，项目提供了专门的 spark-install.md 指南，涵盖 cgroup v2 和 Docker 配置等 Spark 特有的前置条件。

二、一键安装与引导

安装过程简化到了极致：curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

安装脚本会自动完成三个步骤：

1、检测并安装 Node.js（如未安装）

2、安装 OpenShell 运行时

3、运行引导式向导（配置沙箱名称、推理提供者、API Key 等）

安装完成后，终端会显示一个总结：

这里的 Landlock + seccomp + netns 标识直接告诉你沙箱启用了哪些内核级安全机制。

三、沙箱内的日常交互

连接到沙箱后，你进入的是一个受限的 Linux 环境。在这个环境中：

1、你可以正常使用 openclaw tui 或 CLI 与 Agent 对话

2、Agent 可以执行开发任务、写代码、运行测试

3、但 Agent 的所有网络访问都受策略控制

4、文件写入只能在 /sandbox 和 /tmp 目录

当 Agent 尝试访问白名单以外的网络端点时，运维人员会在 OpenShell TUI（通过 openshell term 启动）中收到实时审批请求。这种"按需审批"的模式在实际使用中非常实用 —— 你不需要预先知道 Agent 需要访问哪些服务，只需在它请求时做出判断。

四、策略定制

NemoClaw 预置了多种策略文件，覆盖常见的企业集成场景：

你可以将这些预置策略组合使用，构建适合自己企业的 Agent 安全配置。例如，一个内部开发 Agent 可能只需要 PyPI + npm + GitHub 策略；一个客服 Agent 可能需要 Slack + Jira + Outlook 策略。策略可以通过两种方式应用：

1、静态方式：编辑 openclaw-sandbox.yaml 后重新运行 nemoclaw onboard

2、动态方式：运行 openshell policy set <policy-file> 在运行中的沙箱上临时应用

五、卸载与清理

NemoClaw 提供了干净的卸载方式：curl -fsSL https://raw.githubusercontent.com/NVIDIA/NemoClaw/refs/heads/main/uninstall.sh | bash

卸载脚本会移除沙箱、NemoClaw 网关提供者、相关 Docker 镜像和容器、本地状态目录以及全局 npm 包。但不会移除 Docker、Node.js、npm 或 Ollama 等共享系统工具。

结语：Agent 时代的安全范式转移

回到最初的问题：NemoClaw 到底是什么？

从软件角度，NemoClaw 是一个轻量级的参考方案，由一个 TypeScript CLI 插件和一个 Python Blueprint 编排器组成，核心安全能力由底层的 OpenShell 运行时提供。它的代码量不大，但它定义的模式意义深远。

从问题角度，NemoClaw 解决的是 Agent 时代最根本的信任问题 —— 当 AI Agent 拥有和人类一样的系统控制权时，如何确保它"即便出错也不失控"。

从方案角度，NemoClaw 给出了一个工程上可行的答案：

1、操作系统级沙箱隔离（而非进程内安全检查）

2、声明式安全策略（而非手动配置防火墙规则）

3、推理隐私路由（而非将 API Key 暴露给 Agent）

4、操作员实时控制（而非事后审计）

5、一条命令部署（而非复杂的手动安全加固）

NemoClaw 当前还处于 Alpha 阶段，距离生产就绪还有不少路要走。但它代表了一种重要的范式转移：从"信任 Agent 不会犯错"到"假设 Agent 必然被攻陷，确保攻陷后损失可控"。

这就像 Web 安全从"信任输入"演进到"永不信任输入"的零信任范式一样，Agent 安全也需要同样的思维转变。

NVIDIA 选择在这个时间点推出 NemoClaw，并将其完全开源、芯片无关，是一步深思熟虑的战略棋。它不仅是对 ClawHavoc 事件的回应，更是在定义一个新的基础设施品类 —— Agent 安全运行时。

就像黄仁勋说的："Claude Code 和 OpenClaw 点燃了 Agent 拐点 —— 将 AI 从生成和推理延伸到行动。"而 NemoClaw，则是确保这些"行动"不会失控的那道安全闸门。

参考资料：

• https://github.com/NVIDIA/NemoClaw
• https://nvidianews.nvidia.com/news/nvidia-announces-nemoclaw
• https://www.nvidia.com/en-us/ai/nemoclaw/
• https://developer.nvidia.com/blog/run-autonomous-self-evolving-agents-more-safely-with-nvidia-openshell/
• https://github.com/NVIDIA/OpenShell
• https://docs.nvidia.com/nemoclaw/latest/reference/architecture.html
• https://cyberpress.org/clawhavoc-poisons-openclaws-clawhub-with-1184-malicious-skills/
• https://thenextweb.com/news/nvidia-nemoclaw-openclaw-enterprise-security
• https://earezki.com/ai-news/2026-03-19-nvidia-openshell-and-the-rise-of-agent-sandboxes-in-agentic-devops/
• https://www.cio.com/article/4146545/nvidia-nemoclaw-promises-to-run-openclaw-agents-securely.html