把 OpenClaw 塞进笼子:NVIDIA NemoClaw 架构解析

1. 和 OpenClaw 的关系2. NemoClaw 安装3. NemoClaw 体系4. NemoClaw 安全机制5. NemoClaw 的限制6. 对比 IronClaw参考资料

“NVIDIA 皮衣教主” 黄仁勋 在 2026 年 GTC 大会上宣布了项目 NemoClaw^[1]，该项目在 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^[2] - 另一个由 NVIDIA 发起的开源项目，提供底层的沙箱隔离能力

满足依赖后，执行下面的命令即可安装 NemoClaw，简单直接：

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

安装过程主要完成 3 个步骤：

1. Node.js

• 检测系统是否已有 Node.js >= 22.16 和 npm >= 10
• 如果没有或版本不够，通过 nvm 安装

2. NemoClaw CLI

• 修复 npm 全局安装权限
• Github 克隆 NemoClaw 源码到 ~/.nemoclaw/source
• 安装依赖、构建 CLI 模块和 TypeScript 插件
• 通过 npm link 注册全局 nemoclaw 命令

3. 配置引导

• 运行 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 里实现，做了两件事：

1. URL 合法性检查 — 只允许 http:// 和 https:// 协议，拒绝 file://、ftp:// 等协议
2. DNS 解析后的 IP 检查 - 拿到实际 IP 地址后检查是否落在私有网段里，只要解析出的任何一个 IP 在私有网段里，直接拒绝

• 网络策略引擎 - 分层的出口控制系统，遵循最小化原则：“默认全部拒绝，按需逐条放行”

• 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 对硬件配置也有一定的要求：

其中，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 安全机制解析^[3] 的文章，分析了 IronClaw 的安全机制。既然 NemoClaw 也瞄准了 OpenClaw 的安全问题，那么这里做一个简单的对比——面对类似的安全问题，它们采取了两种典型的安全机制：

• IronClaw - 基于 WASM 沙箱隔离，轻量，资源占用少
• NemoClaw - 基于容器和进程的隔离，资源占用高，却能很方便的与企业现有的基础设施集成

对此，你有什么看法，不妨在留言区聊聊。

参考资料

不一样的 OpenClaw^[4]

NemoClaw on Github^[5]

NemoClaw Overview^[6]

How NemoClaw Works^[7]

NemoClaw Architecture^[8]

引用链接