NVIDIA 最近发布了一篇教程，演示如何在 DGX Spark 上部署基于 OpenClaw 和 NemoClaw 的本地 AI 代理：模型自托管、支持 Telegram 接入、可以常驻运行，还试图把安全控制补进去。原作者的态度很鲜明：这套方案认真、工程化，但它暴露了一个更大的行业问题——很多 AI agent 还停留在“先把能力接上，再想办法从外面套安全壳”的阶段。

这件事重要，不是因为又多了一个本地代理教程，而是因为 AI agent 正从 demo 走向常驻服务。它一旦接 shell、文件系统、网络连接和聊天渠道，风险就不再是“模型答错一句话”，而是“模型替你执行了一串你不该放权的动作”。真正的分界线，是权限设计，而不是 UI 做得多顺手。

NVIDIA 的教程很认真，但它解决的是“补救式安全”

按原文拆解，NemoClaw 这套做法有几个关键动作：把 Ollama 绑定到 0.0.0.0，让容器里的代理能跨网络命名空间访问推理服务；Telegram 通过聊天内配对码完成首次绑定；出站网络连接在宿主机侧 TUI 中单独审批；整个代理放进容器里运行。这不是胡来，相反，它说明 NVIDIA 已经意识到 agent 默认形态并不安全。

问题也恰恰在这里。你会发现，这些步骤更像是在给“整套代理拥有较大权限”打补丁，而不是从一开始就把能力拆细。原作者拿自家项目 Wirken 做对照：代理主进程直接跑在宿主机，本地推理仍留在 127.0.0.1；不同通道是独立进程，各有 Ed25519 身份；敏感命令按工具层审批，而不是等网络层拦截；真正执行 shell 时，再临时拉起一个去权限的 Docker 容器，cap_drop ALL、只读根文件系统、/tmp 仅 64MB tmpfs、默认无网络。

两种设计思路的区别很实际。前者是“把一个强能力代理关进大沙箱”，后者是“别先给它整块权力，按动作发证”。对开发者来说，后者更麻烦，产品体验也未必更丝滑，但日志、审计和责任边界会清楚很多。

争议不在 OpenClaw，而在行业还没摆脱“MS-DOS 思维”

原文用了一个很冲的历史类比：今天一些 agent gateway，像极了早年的 MS-DOS——单进程、单口令、权限混杂。这个比喻有情绪成分，但方向没错。Unix 在 1970 年代就把进程隔离、用户隔离、文件权限做成默认前提；到了 2024 年后再做 agent，如果还把“一个 token 走天下”当成常态，确实是在重复老问题。

行业里已有类似分化。Anthropic 推 MCP，强调工具调用协议标准化；OpenAI 的 Operators、Computer Use 一类能力则更关注“能不能替用户把事办完”；大量创业项目和开源 agent 框架则先追求接入速度，把浏览器、终端、SaaS API 一股脑串起来。好用往往来得更快，安全设计却最容易被推迟。读者单看教程不一定会注意到一个现实限制：很多团队不是不懂最小权限原则，而是做了之后，接入成本、授权弹窗、跨工具身份管理都会立刻拖慢产品迭代。

所以，这事不重要的地方也要说清楚：它并不意味着 OpenClaw 或 NemoClaw “不安全”，更不意味着容器隔离没有价值。容器、网络命名空间、手工审批都比裸奔强得多。真正该被质疑的是，行业会不会把这些补丁当成终点，而不是过渡方案。

对谁影响最大：准备把 AI 代理接进内网的团队

最该认真看这类文章的，不是普通消费者，而是两类人。第一类是内部工具团队：想把本地模型接进 IM、工单系统、知识库、终端执行链路的人。你现在做的每一个“为了方便先共用一个 bot token”“先把 Ollama 暴露到局域网”的决定，半年后都可能变成审计问题。第二类是企业安全和平台团队：他们接下来要面对的，不是要不要上 agent，而是怎么给 agent 分权，怎么留痕，怎么撤权。

原文展示了一个很有价值的细节：Wirken 把拒绝执行 curl、以及只读根文件系统拦下写入尝试，都记进了哈希链式审计日志，还能回放验证。这个设计未必决定产品成败，却决定它能不能进真实组织环境。原因很简单，企业采购代理系统时，最难回答的从来不是“它会不会做 PPT”，而是“它昨天到底执行了什么、谁批的、事后能不能查”。

接下来最值得盯的变量，不是哪个 agent UI 更像聊天工具，而是谁先把“身份、授权、执行、审计”拆成四件独立可控的事。能跑起来的 agent 已经很多，能长期挂在生产环境里不惹祸的，还不多。