Windows支持OpenClaw6.1,切换安装方式评估(下)安全篇-夜雨聆风

Windows支持OpenClaw6.1,切换安装方式评估(下)安全篇

当 LLM Agent （OpenClaw、Hermes等）从聊天助手进化为可以读写文件、执行命令、安装插件的生产力工具时，安全问题就不再是”以后再说”的事了。本文重点围绕 Docker、微软 MXC（Microsoft Execution Containers）和 NVIDIA OpenShell 三种隔离与安全方案进行对比理解。

什么情况下要考虑安全问题？

如果你只是让 AI 帮你写邮件、翻译文档，安全不是首要问题。

但一旦 Agent 获得了以下能力：通过 exec 工具执行系统命令通过 read/write/edit 读写文件系统通过安装第三方 Skills（插件）扩展功能……那么就等于你把一个陌生人请进了自己的电脑。

这个陌生人可能来自：你自己写的 Prompt从社区下载的第三方 Skill模型输出的代码片段被自动执行

其中第三方 Skills 是最危险的面——你无法预知上游开发者是否写了安全的代码。一个看似无害的”网页摘要”Skill，可能在背后读取你的 SSH 密钥或向外部服务器发送数据。

SSH 私钥 = 你远程管服务器的唯一凭证。谁拿到它，谁就能以你的身份登录你的服务器。所以隔离不可信代码时，第一件事就是拦住它读 ~/.ssh/。

本次Build大会上发布的两款Agent安全产品引起了我的注意：

-微软：微软在 2025 Build 大会上正式展示了 MXC（Microsoft Execution Containers）——一个面向 AI Agent 场景的内核级沙箱方案，让 Windows 上的 Agent 安全有了系统底层的支持。

-NVIDIA OpenShell：大会上，NVIDIA 发布了 OpenShell——一个从头为 Agent 设计的”安全运行时”，集文件保护、网络管控、甚至 AI 模型调用路由于一体。虽然还只是 Alpha 版，但方向感很强。

这些事件传递的信号很一致：Agent 安全已经不是实验室议题，而是进入了产品化阶段。

那么，问题来了，

怎么给 AI Agent 选一个安全的家：Docker、微软 MXC 还是 OpenShell？

一、先简要概括三个产品

这三个工具设计目标完全不同，不是竞品，是不同层的工具：

工具	一句话定位
Docker	应用的标准化打包工具——到哪都能跑得一样
MXC	代码的”电子镣铐”——执行不可信代码时管住它能碰什么
OpenShell	Agent 的”管制工作间”——AI Agent工作时的行为、钥匙、路线管控

聪明的我预测到聪明的你可能又不想读了，建议跳转至：五、核心差异速览

二、Docker

解决什么问题：使得应用在开发、测试、生产环境跑起来一样。

跟安全的关系：Docker 天然有基础的进程隔离（容器默认看不到宿主机文件、进程、网络），但这是容器技术的副产品，不是 Docker 的设计目标。

问题是——你要让容器做点事，就必须开门（挂载目录、开网络、传环境变量），一开门就管不住了：

挂载目录（授权工作区） = 容器能读整个目录的所有文件，包括混进来的 .env / credentials
默认有网络 = 容器内的进程可以主动向外发数据
传环境变量 = API Key 明文存在进程里，谁都能读

Docker 管不了的事：

A 文件能读、B 文件不能读；
只能 GET 不能 POST；
Key 不能给进程看见明文。

三、微软 MXC（Microsoft Execution Containers）

当你的产品需要执行一段”不是你写的、你不完全信任的代码”（AI 生成的脚本、第三方插件、用户自定义逻辑）时，MXC 提供一个可嵌入的沙箱，让你精确控制这段代码能碰什么、不能碰什么。

它解决什么业务问题：

很多产品都在往”可扩展”和”AI 驱动”的方向走——用户自己写脚本、AI 生成代码、第三方开发插件。但执行不可信代码有风险：它能偷你的 SSH 私钥、能把你数据库内容偷偷发到外部网站。MXC 让你在接入这些能力的同时，不用赌”这段代码没有恶意”。

怎么管住代码：三个维度

管什么	业务语言	举例
文件系统	它能偷看你电脑上的哪些文件？	允许读 /data/，禁止读 ~/.ssh/ 和 ~/.aws/
网络	它能把你数据传到外面去吗？	允许访问 api.github.com，禁止访问其他一切外网地址
界面	它能偷看你屏幕或剪贴板吗？	禁止截图、禁止读剪贴板

怎么用：嵌入到产品代码里（TypeScript SDK），不是让用户手动操作。适合桌面应用、插件系统、AI 代码一键执行等场景。

当前状态：🟡 早期预览。微软表示”别当安全边界用”。

四、OpenShell（NVIDIA）

当你的 AI Agent（比如 Claude Code、Copilot）在工作时，OpenShell 提供一个 Agent 专属的”管制环境”——不止是把它关起来，而是管它能读哪些文件、能调哪些 API、用谁的 API Key、推理走哪个后端。

它解决什么业务问题：

AI Agent 的风险在于可能误删文件、API Key 可能被泄露、Agent 可能调了不该调的接口。OpenShell 不是简单地隔离 Agent，而是精细地指导 Agent 的行为，并且是运行时动态调整的，不需要重启。

它和 Docker / MXC 的核心区别：

对比项	Docker	MXC	OpenShell
管的是	应用的运行环境	不可信代码的执行	Agent 的工作行为
特有能力	环境标准化	代码沙箱化	凭证自动注入、推理路由、热加载策略

🗝️ 凭证管理： API Key 通过 Provider 注入，Agent 进程看不见明文——只能用，不能偷

🔀 推理路由：把 Agent 的 LLM 调用自动转到私有后端，数据不出门，推理走内网

🔄 策略热加载： Agent 工作时不重启，随时追加规则即时生效

🛡️ 四层防护：文件系统 + 网络 + 进程 + 推理路由

怎么用：命令行操作（openshell sandbox create — claude），不是嵌入到产品里。

当前状态：🟡 Alpha。当前仅支持”一人一环境，在走向多租户企业部署”。

五、核心差异速览

维度	Docker	MXC	OpenShell
管的是	运行环境	不可信代码执行	Agent 的行为
文件控制	整目录挂载或空	允许读/写哪些路径	文件级+可动态改
网络控制	能上网或不能	允许访问哪些地址	按 HTTP 方法和路径
凭证管理	环境变量明文	无凭证管理	自动注入，进程不可见

Docker 沙箱 = 把 Agent 关进一个独立房间，房间里只有你给它放的东西，没办法到客厅活动。
MXC = Agent 在你的客厅活动，但所有抽屉都上了锁，只有你授权的那几个它能打开。

OpenShell = 像安全管家随着Agent的工作进行动态门禁 + 实时监控 + 钥匙不过Agent手

常见误区

“Docker 能替代 MXC”——管不到文件级和网络级精细度
“OpenShell 能替代 Docker”——它依赖 Docker，是站在肩膀上的
“MXC 和 OpenShell 差不多”——MXC 管一次执行，OpenShell 管持续工作的 Agent，多了凭证/推理/热加载
“三个是竞品”——不同层，互相补充

场景举例一：你的桌面应用需要执行自己或 AI 生成的脚本

比如一个 BI 工具，写了一段 Python 脚本做数据透视，或者从 AI 对话框直接生成的代码要一键运行。

✅ MXC 最适合。它的设计就是干这个的：npm 安装 SDK，几行代码就能拉起一个沙箱，指定”只能读这个 Excel、只能写这个输出文件、不能联网”，然后跑用户脚本。嵌入到桌面应用里很自然。
Docker 不适合。 Docker 是给”部署一个完整的应用”用的，不是给”在执行流中跑一段动态代码”用的。
OpenShell 不适合。 OpenShell 是给 Agent 住的，不是给单次脚本执行设计的。

场景举例二：团队用 Claude Code 写代码，安全团队不放心

Agent 能访问整个文件系统，能调任意 API，API Key 明文存在环境变量里。安全团队要求上线前解决。

✅ OpenShell 最适合。拉起 Claude Code 沙箱，策略声明：

只读 /workspace、禁止访问 ~/.ssh、GitHub API 只允许 GET。
API Key 通过 Provider 机制注入，Agent 进程里看不到明文。
策略可以运行时热加载，不需要重启。

Docker / MXC 做不了这件事：

Docker 不具备”懂 Agent”的能力——它能隔离进程，但管不了”Claude 在调哪个 API、用了哪个 Key”。
MXC 能隔离，但没有凭证注入和推理路由，你要自己拼一大堆胶水代码。

六、选型指南

团队用 Claude Code，安全要管控 → OpenShell
产品要做”AI 生成代码一键执行” → MXC
标准后端微服务部署 → Docker
三个都想用 → 可以叠：Docker 底层 → OpenShell 做 Agent 管控 → MXC 当沙箱后端

叠加使用的环境关系示意：

整体来讲，就像权限颗粒度不同，管理效果也不同。AI 写代码速度太快，人审也跟不上，安全工具配置是必修课。

** 化繁为简 **

深度，基于核心基础

问题，是撬起AI的支点