OpenShell
给 AI agent 干活，最难的不是让它能干，而是让它只能干你允许它干的事。NVIDIA 的 OpenShell 就是冲着这个来的：一个给成群自主 agent 用的、安全又私有的运行时。你在策略里声明每个 agent 能碰什么，它负责在运行时强制执行，而不是事后看日志追悔。
这篇文章不复述 README，重点说它跟普通沙箱到底差在哪、适合谁、以及你第一次上手最容易踩的坑。
一、为什么值得关注：它把“信任”从口头变成强制
很多 agent 沙箱的逻辑是“先给权限，出事再收”。OpenShell 反过来：每个 agent 都跑在隔离沙箱里，内核层控制它能访问哪些文件、能做哪些系统调用，每一次联网都要先过策略检查才放行。这不是应用层的过滤，而是在更底层卡住，agent 绕不过去。
更关键的是第二层：策略改动不是改完就生效。改动前，它会用形式化验证先算一遍这个改动会新放开什么，比如能不能带着密钥去一个新主机、能不能调一个新 API 方法，算出高风险就先留给人审批。这一步很对安全团队的胃口，因为 agent 时代最大的风险往往不是 agent 本身，而是某次“顺手放宽一点”的策略改动。
二、它怎么跑：网关、监管器、沙箱三件套
架构上可以理解成三件套：网关是控制面，管沙箱、策略和访问；监管器盯着运行时的 agent；沙箱是 agent 真正干活的地方。默认沙箱镜像是一个最小的 Ubuntu，里面根本没装 agent，这一点第一次用的人很容易懵：装完以为就能跑 agent，其实还要按“跑第一个 agent”的指引去接一个真实 agent，比如用 OpenCode 配一个免费的 OpenRouter 模型。
安装本身是一条命令加一个建沙箱的命令，但前提要先满足：Linux、苹果芯片的 Mac，或者 Windows 加 WSL 2（还是实验性的），外加 Docker、Podman 或者主机虚拟化。没有这些，装完也跑不起来。
三、适合谁，不适合谁
适合三类人。第一类，已经在跑不止一个 agent、而且要给 agent 文件、装包、调 API、用密钥权限的团队和个人，越是 agent 多、权限杂，这个工具的价值越大。第二类，对数据和密钥外泄特别敏感的人：agent 在这里永远看不到真密钥，密钥只由 OpenShell 加到发往已批准 endpoint 的请求上。第三类，想把 agent 接进自己应用的开发者：它有 Python、TypeScript、Go、Rust 的 SDK，接网关用，但要注意 SDK 和网关尽量用同一个版本。
不适合两类人。一类是只想跟单个 agent 聊聊天、写写代码的人，这个工具的策略、网关、审批流程对他来说太重了。另一类是希望 agent 完全自主、不要人审批的人：OpenShell 的设计就是要在高风险改动前停下来等人看，追求“全自动不打扰”和追求“不出事”在这里是冲突的。
四、上手体验和坑：先把这四条看完再装
第一，别用 curl 管道直接装完就信。README 给的是一条 curl 安装脚本，先看一眼脚本里到底装了什么、装到哪，再跑，这是装任何这类工具都该有的习惯。
第二，策略要从小写起。先给 agent 最小的权限，跑起来、看它在哪些地方被拦、再按需放开，而不是一开始就给一个宽策略图省事。放宽策略的每一次改动都会先被验证器标出来，这正是这个工具想让你慢下来的地方。
第三，遥测默认是开着的。它说只收集匿名的运行类别和数量，不收集沙箱名、主机名、文件路径、提示词、密钥、模型名和用户内容，但如果你在意，还是要在网关上把 OPENSHELL_TELEMETRY_ENABLED 设为 false，或者 Helm 安装里把 server.telemetryEnabled 设为 false，也可以直接编译掉。
第四，版本还早。0.1.x 刚进入稳定发布节奏，改动和升级指引要跟上，别把生产 agent 群直接绑在一个还在快速演进的版本上，先在测试沙箱里跑通你的策略和审批流程。
五、怎么试，第一次这样试最划算
先在 Linux 或苹果芯片 Mac 上装好，建一个叫 demo 的沙箱，然后按官方指引跑第一个 agent，重点不是看 agent 能写出什么代码，而是看三件事：它第一次想访问没批准的东西时是不是真的被拦住；你放宽策略时，验证器是不是真的标出了新风险；密钥是不是真的没有出现在 agent 能看到的地方。
这三件事都通过了，这个工具在你手里才算立住了。我的判断是：它值得关注，不是因为 NVIDIA 背书，而是因为它把 agent 安全里最难的一步——“给 agent 能力，但不给它失控的自由”——做成了可强制执行的运行时，而不是一份使用规范。
