“NVIDIA 皮衣教主” 黄仁勋 在 2026 年 GTC 大会上宣布了项目 NemoClaw,该项目在 Github 开源,目前有 2.2K fork,18.3 stars。
NemoClaw也是带Claw的,这个项目和“巨星”OpenClaw有什么关系,是远房亲戚还是碰瓷的?接下来,我们一起了解这个项目。

1. 和 OpenClaw 的关系
OpenClaw 被黄仁勋称赞为“人类历史上最受欢迎的开源项目”,不过其安全问题常被人诟病:
- Meta 禁止员工在公司设备上运行它
- 漏洞
CVE-2026–25253,CVSS 8.8允许通过恶意网页执行远程代码 - 攻击者会通过在文档或者邮件中嵌入命令诱导 agent 遵循外部指令
由 NVIDIA 与 OpenClaw 创始人 Peter Steinberger 合作开发的 NemoClaw,它的出现不是为了取代 OpenClaw,而是打算解决 OpenClaw 的痛点问题,尝试将 OpenClaw 转变为一款安全、适于企业的 AI agent,即提供一个安全、可信且易于部署的运行时环境来运行 OpenClaw。
NemoClaw 的核心价值在于安全隔离和运维便利性。
截至目前,2026 年 4 月初, NemoClaw 还处在 Alpha 阶段,尚未达到生产环境就绪状态。
2. NemoClaw 安装
安装 NemoClaw 需要满足下面这些软件依赖:
- Linux - NemoClaw 依赖于 Linux 内核提供的安全特性
- Container runtime - NemoClaw 提供基于容器的运行时隔离环境
- OpenShell - 另一个由 NVIDIA 发起的开源项目,提供底层的沙箱隔离能力
满足依赖后,执行下面的命令即可安装 NemoClaw,简单直接:
curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
安装过程主要完成 3 个步骤:
Node.js
- 检测系统是否已有
Node.js >= 22.16和npm >= 10 - 如果没有或版本不够,通过 nvm 安装
- 检测系统是否已有
NemoClaw CLI
- 修复 npm 全局安装权限
- Github 克隆 NemoClaw 源码到
~/.nemoclaw/source - 安装依赖、构建 CLI 模块和 TypeScript 插件
- 通过
npm link注册全局 nemoclaw 命令
配置引导
- 运行
nemoclaw onboard向导 - 通过向导创建沙箱、配置 LLM Provider、应用安全策略
- 运行
安装完成后你会得到:Node.js 运行时 + NemoClaw CLI 工具链 + 一个已配置好的 OpenClaw 沙箱环境。
3. NemoClaw 体系
从软件依赖和安装过程来看,NemoClaw 像是一个“胶水”项目,它把几个已有的组件串在一起:
- OpenShell - 提供沙箱运行时
- OpenClaw - AI Agent 本身
- LLM - 大模型推理服务
- Container runtime - 容器运行时,例如 Docker,containerd 等
- Linux - 提供内核安全特性(Landlock + seccomp + netns)
不过,NemoClaw 本身也贡献了很多特性:
Blueprint 系统 - 类似 Terraform 之于 AWS,Blueprint 扮演沙箱生命周期编排器的角色,它把一个声明式的 YAML 配置(blueprint.yaml)变成一个运行中的、安全隔离的 AI agent 环境
SSRF 防护 - SSRF(
Server-Side Request Forgery,服务端请求伪造)是一种攻击方式:攻击者诱导服务端向内部网络发起请求,从而访问本不该暴露的内部服务。NemoClaw 的 SSRF 防护在ssrf.ts里实现,做了两件事:- URL 合法性检查 — 只允许
http://和https://协议,拒绝file://、ftp://等协议 - DNS 解析后的 IP 检查 - 拿到实际 IP 地址后检查是否落在私有网段里,只要解析出的任何一个 IP 在私有网段里,直接拒绝
- URL 合法性检查 — 只允许
网络策略引擎 - 分层的出口控制系统,遵循最小化原则:“默认全部拒绝,按需逐条放行”
LLM 路由 - 配置编排 OpenShell 提供的 LLM 代理层,让沙箱内的 AI agent 不直接连接外部 LLM API,统一通过一个本地虚拟端点
https://inference.local/v1来访问消息桥接 - 在宿主机侧运行 Node.js 长轮询进程,充当 Telegram 和沙箱内 OpenClaw 之间的中间人(目前主要实现了 Telegram 桥接)
交互式向导 - 提供运维便利性,把所有组件串起来
NemoClaw 更像是一个集成框架,在实践层面定义了“怎样安全地运行 AI Agent”。
NemoClaw 通过 OpenShell 操作沙箱,而 OpenShell 底层依赖 Docker(或 Colima、Docker Desktop)来实际运行容器。整体上形成下面这样的层次关系:
NemoClaw CLI
└── OpenShell(沙箱编排 + 安全策略执行 + LLM 网关)
└── 容器运行时(Docker / Colima / Docker Desktop)
└── Linux 内核安全机制(Landlock / seccomp / netns)
4. NemoClaw 安全机制
OpenShell 提供沙箱运行时的隔离基座,NemoClaw 在其上构建应用层的安全纵深——两者共同构成了 NemoClaw 的安全机制。
OpenShell 提供的主要安全能力:
- Landlock 文件系统访问控制 / seccomp 系统调用过滤 / netns 网络隔离机制
- 网络代理和出口策略执行(
openshell policy set) - LLM 网关(凭证不进沙箱)
- 沙箱容器生命周期管理
NemoClaw 实现的安全特性主要有:
- SSRF 防护 - DNS 解析 + 私有 IP 检测
- 镜像加固 - 通过
Dockerfile和nemoclaw-start.sh对容器镜像进行加固 - 配置完整性校验 - 构建时执行 SHA256 哈希,启动时验证,防配置篡改
- 文件系统分区 - 拆分
.openclaw(不可变)和.openclaw-data(可写) + 符号链接验证 + chattr 不可变标志 - 权限分离 — gateway/sandbox 双用户模型,DAC 文件权限控制
- 网络策略引擎 — 策略预设的加载、合并、去重
- 凭证清洗 — API key 不通过环境变量传入沙箱
- 聊天白名单 —
ALLOWED_CHAT_IDS访问控制
5. NemoClaw 的限制
除了软件依赖,NemoClaw 对硬件配置也有一定的要求:
| Resource | Minimum | Recommended |
|---|---|---|
| CPU | 4 vCPU | 4+ vCPU |
| RAM | 8 GB | 16 GB |
| Disk | 20 GB free | 40 GB free |
其中,8GB 内存的要求主要来自沙箱镜像推送阶段的内存峰值:沙箱镜像压缩后约 2.4GB,在 image push 阶段,Docker daemon、k3s、OpenShell gateway 和导出管道同时运行,导出管道还会在内存中缓冲解压后的镜像层。这些进程叠加起来的内存占用很容易超过 8GB,低于这个值可能触发 Linux 的 OOM。
上面提到了 k3s,NemoClaw 面向企业场景解决 OpenClaw 安全问题,一个典型企业基础设施就是 k8s。从代码来看,NemoClaw 本身并不直接依赖 k3s 或者 k8s:NemoClaw 的所有沙箱操作都是通过 OpenShell 完成的,它不关心 OpenShell 底层用什么容器编排设施。k3s 是 OpenShell 实现细节,当前版本的 OpenShell 需要借助 k3s 或者 k8s 的功能来完成沙箱生命周期的管理、容器编排调度、网络策略 NetworkPolicy 等功能。
因此,对于个人而言,NemoClaw 稍显笨重;但对于企业而言,NemoClaw 值得关注。
6. 对比 IronClaw
我之前写过一篇名为 “钢铁版 OpenClaw” - IronClaw 安全机制解析 的文章,分析了 IronClaw 的安全机制。既然 NemoClaw 也瞄准了 OpenClaw 的安全问题,那么这里做一个简单的对比——面对类似的安全问题,它们采取了两种典型的安全机制:
- IronClaw - 基于 WASM 沙箱隔离,轻量,资源占用少
- NemoClaw - 基于容器和进程的隔离,资源占用高,却能很方便的与企业现有的基础设施集成
对此,你有什么看法,不妨在留言区聊聊。
参考资料
NVIDIA NemoClaw Explained: How It Secures OpenClaw AI Agents for Enterprise Use