AI Agent 最怕权限失控：NemoClaw 把 OpenClaw 关进沙箱后，终于敢持续跑任务了

很多人不是不想把 AI Agent 用起来，而是不敢真的让它长期跑任务。

原因很现实：一旦 Agent 开始自己查资料、自己调工具、自己连外网，你最担心的往往不是它笨，而是它 权限太大、边界不清、出了问题很难控。尤其是你想让 OpenClaw 这类常驻助手接进真实工作流时，问题会立刻变成：它能访问哪些网站？能读哪些目录？模型请求到底发到哪里？

NVIDIA 新开源的 NemoClaw，我觉得最值得看的地方就在这里。它不是又做了一个“更聪明的 AI 助手”，而是把 OpenClaw + OpenShell + sandbox + inference policy 串成一套更可控的运行方式。简单说，就是：先把 Agent 关进沙箱，再谈让它持续干活。

这篇文章不讲空泛概念，直接讲 4 件事：NemoClaw 解决什么问题、怎么安装、怎么跑起来、适合哪些人现在就上手。

---

为什么很多 AI Agent 一到真实场景就不敢放权？

如果你只是把 AI 当聊天工具，权限问题并不明显。

但只要你开始让它做下面这些事，风险就会立刻出现：

• 自动联网检索资料
• 读取项目目录或本地文件
• 运行命令、调用外部工具
• 长期常驻，持续处理任务
• 把推理请求发到云端模型服务

这时候你最怕的往往不是“回答错”，而是下面这几类问题：

1. 网络边界不清：Agent 想访问什么站点都能试，出了问题很难知道它连过哪里。
2. 文件权限过宽：不小心读到不该读的目录，或者把临时产物和工作目录混在一起。
3. 进程能力不可控：如果底层执行环境过于宽松，安全和稳定性都不好保证。
4. 模型出口不透明：你以为只是本地跑一个助手，实际推理请求可能已经被发到外部服务。

NemoClaw 的价值，正是把这些原本散落的问题统一收口。

它的做法不是“提醒你注意安全”，而是直接在运行时层面加了一道约束：

• Network：限制未授权外连
• Filesystem：把访问范围收进 /sandbox 和 /tmp
• Process：限制提权和危险 syscall
• Inference：把模型调用重定向到受控后端

这就不是“写规范”了，而是把规范变成默认行为。

---

NemoClaw 到底是什么？

按官方 README 的说法，NemoClaw 是一套用于运行 OpenClaw always-on assistants 的开源方案。

它会安装 NVIDIA OpenShell runtime，再通过 nemoclaw 这个 CLI 去编排下面几层能力：

• OpenShell gateway
• sandbox
• inference provider
• network policy

你可以把它理解成一层“Agent 运行控制面”。

OpenClaw 负责助手本身，OpenShell 负责受控运行环境，NemoClaw 负责把安装、连接、策略和推理配置统一串起来。它最实用的一点，是你不用自己手工拼安全边界，而是通过 nemoclaw 直接拉起一套更像样的沙箱环境。

官方目前明确写着这是 Alpha software。这点一定要记住：它更适合用来搭实验环境、验证工作流、做受控测试，而不是不看边界就直接上生产。

---

安装前先看清楚：它不是零门槛玩具

NemoClaw 的安装要求并不离谱，但也不是随便一台机器就能愉快开跑。

硬件要求

最低配置：

• 4 vCPU
• 8 GB RAM
• 20 GB 可用磁盘

推荐配置：

• 4+ vCPU
• 16 GB RAM
• 40 GB 可用磁盘

官方还特别提到，sandbox 镜像压缩后大约也有 2.4 GB。如果你机器内存偏小，镜像推送阶段有可能直接 OOM。实在不能加内存，至少考虑配 8 GB swap，但速度会明显变慢。

软件要求

• Ubuntu 22.04 LTS 或更高
• Node.js 20+
• npm 10+
• 已安装并运行容器运行时
• 已安装 OpenShell

容器运行时支持

• Linux：Docker
• macOS（Apple Silicon）：Colima、Docker Desktop
• Windows WSL：Docker Desktop（WSL backend）
• macOS + Podman：当前文档里明确写了暂不支持

如果你现在就在 Mac 上折腾本地 AI 工具，这一点尤其重要：不是所有容器栈都能直接用。

---

真正能跑起来的最短路径

如果你今天就想试，不要先研究半天架构图，直接先走官方给的 Quick Start。

第一步：执行安装脚本

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

这个脚本会做几件事：

• 如有需要安装 Node.js
• 启动 guided onboard wizard
• 创建 sandbox
• 配置 inference
• 应用 security policies

这意味着你不是“下一个包就结束”，而是在第一次安装时就把运行环境、推理通路和安全策略一并搭起来。

如果装完后终端里找不到 nemoclaw，官方给的处理方式很直接：

source ~/.bashrc

或者：

source ~/.zshrc

第二步：连接到你的 assistant sandbox

nemoclaw my-assistant connect

这一步的意义，不只是“进去看一眼”，而是确认你的 Agent 不是跑在随手开的普通终端里，而是在 NemoClaw 帮你准备好的受控环境中。

第三步：在沙箱里打开 OpenClaw TUI

openclaw tui

如果你平时更习惯交互式操作，这个入口最直观。它会让你直接在受控环境里和 OpenClaw 对话、测试工具调用、观察行为边界。

第四步：用 CLI 丢一个最小任务

openclaw agent --agent main --local -m "hello" --session-id test

这条命令很适合做冒烟测试。先别急着给它一大堆复杂工作流，先确认最基本的会话、调用链和输出是通的。

---

它最值钱的不是“能跑”，而是“能控”

我觉得 NemoClaw 最适合写成实战文的地方，不是它有多少功能，而是它把“可持续运行 Agent”里最麻烦的那部分提前做好了。

1. 网络访问不是默认放开

官方说明里提到，如果 Agent 访问了未列入允许名单的主机，OpenShell 会拦截，并在 TUI 中等待人工批准。

这个体验非常关键。

因为很多 AI Agent 真正让人不放心的地方，不是它会不会犯错，而是它一旦联网，你根本不知道它会试哪些目标。NemoClaw 相当于把“先斩后奏”改成了“先申请再放行”。

2. 文件系统边界更清晰

默认访问范围被压缩到 /sandbox 和 /tmp，这对长期跑任务很重要。

原因很简单：

• 你更容易知道哪些内容是工作产物
• 不容易误碰宿主机上不该读的目录
• 调试问题时，范围更清晰

很多人一开始觉得这只是安全细节，但真跑自动化以后就会发现，这其实也是 可维护性问题。

3. 推理出口是可治理的

当前文档里主推的 provider 是 NVIDIA cloud，示例模型是：

nvidia/nemotron-3-super-120b-a12b

你需要从 build.nvidia.com 获取 NVIDIA API key，并在 nemoclaw onboard 时填写。

这件事的重点不在于你是不是一定要用这个模型，而在于：推理请求被明确收进了一条受控链路里。

如果你在团队环境里想做成本、审计、出口统一管理，这比“随便塞一个模型 key 跑起来”靠谱得多。

4. Blueprint 让沙箱环境更像“可复用工件”

README 里提到它通过版本化 blueprint 去创建和应用沙箱资源，生命周期包括：

• resolve artifact
• verify digest
• plan resources
• apply via OpenShell CLI

这意味着它不是一次性手搓环境，而是在往“可重复部署、可验证、可演进”的方向靠。

对想把 Agent 运行环境标准化的人来说，这一点非常重要。

---

一个最小可执行工作流：先别追求复杂，先验证边界

如果你今天就想把 NemoClaw 用起来，我建议你先跑一个很小但非常真实的工作流。

场景：让 OpenClaw 在沙箱里做资料整理

目标不是让它替你做所有事，而是先验证 3 个核心点：

1. 能否正常在沙箱中启动和回复
2. 网络访问限制是否按预期工作
3. 输出产物是否稳定落在可控目录

你可以按这个顺序来：

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
nemoclaw my-assistant connect
openclaw tui

进入后，先给一个低风险任务，例如：

• 总结一份公开文档
• 整理一段项目说明
• 输出一份结构化结论到工作目录

然后重点观察这几件事：

• 它有没有试图访问额外域名
• 被拦截时是否能在 TUI 中看到审批提示
• 输出文件是否只落在你预期的范围内

只要这一步稳定，你再考虑把更复杂的 Agent 工作流往里迁。

这比一开始就让它接消息渠道、接数据库、接自动化脚本靠谱得多。

---

适合谁现在就上手？

不是所有人都适合马上用 NemoClaw。

我更推荐下面几类人优先关注：

适合人群	典型需求	NemoClaw 的价值
想长期跑 OpenClaw 的独立开发者	希望助手常驻，但不想权限失控	给 Agent 加上网络、文件、进程边界
做内部工具或工作流验证的团队	想让 AI 自动化先在受控环境里试运行	方便观察、审批、限制外联
需要统一推理出口的人	想把模型调用纳入统一治理	inference 请求走受控后端
想搭实验环境的人	先做原型和策略测试	Alpha 阶段更适合实验而非生产

反过来说，如果你现在只是想找一个“最省事的 AI 聊天工具”，那 NemoClaw 并不是最优先的选择。它解决的是 可控运行，不是“开箱即聊”。

---

现在上手前，先记住 4 个限制

任何教程如果只讲好处，不讲边界，最后都会把人带坑里。NemoClaw 当前至少有 4 个你必须提前知道的限制。

1. 它还是 Alpha

官方已经写明是 Alpha software。这代表接口、行为、安装体验都可能继续变化。你应该把它当成“值得试的方向”，而不是“已经完全稳定的生产基础设施”。

2. 当前主推荐入口是 nemoclaw host CLI

README 里也提到 openclaw nemoclaw 这组插件命令还在活跃开发中。所以你现在最稳的入口，依然是主机侧的：

nemoclaw onboard
nemoclaw <name> connect
nemoclaw <name> status
nemoclaw <name> logs --follow

3. 本地推理还不是主路线

文档里虽然提到 Ollama、vLLM，但也明确说这些本地推理选项还属于实验性能力。至少从当前资料看，主推路径依然是 NVIDIA cloud。

4. 不是所有平台组合都成熟

尤其是 macOS + Podman，目前 README 直接写了不支持。别看见“容器运行时”这几个字就默认什么都能配。

---

我为什么觉得这个项目值得关注

过去很多 AI Agent 项目，问题不在“模型能力不够”，而在一旦要接近真实环境，就没人能把权限边界讲清楚。

NemoClaw 的可取之处，是它至少在尝试把这件事产品化：

• 不靠口头提醒，而是靠策略约束
• 不让环境散着长，而是统一进 sandbox
• 不让模型出口失控，而是放进受管通路
• 不只解决“能不能跑”，还解决“出了问题怎么查”

如果你接下来想做的是：

• 让 OpenClaw 持续跑任务
• 让 Agent 接近真实工作流
• 但又不想一步走进权限黑箱

那 NemoClaw 很值得你现在就抽一点时间试一次。

它最有价值的地方，不是把 Agent 变得更花哨，而是让你第一次有机会比较安心地回答这个问题：

这个 AI 助手，能不能在我机器上持续干活，同时还留在我能管得住的边界里？

如果你也正卡在这里，那最小行动就是下面这 3 步：

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
nemoclaw my-assistant connect
openclaw tui

先把它跑起来，再看你要不要把下一条 Agent 工作流放进去。