英伟达把一个叫 OpenShell 的项目开源了。它被形容成 AI agent 的“隔离间”:agent 在里面可以放手干活,但只能碰到你允许它碰的东西。
这个比喻不算夸张。真正的问题从来不是 agent 干不了活,而是它干得太多。OpenShell 想解决的,正是这个“太多”。
它到底是什么
OpenShell 是一个专为 agent 打造的运行时。它本身不是模型,不是 agent,也不是聊天界面,而是夹在 agent 和你的机器之间的一层,agent 每次碰文件、跑命令、连网络,规则都要在这里过一遍。
项目文档开篇说得很直白:agent 最有用的时刻,是它能读文件、装依赖包、调 API、用凭证的时候。可把这些能力全给出去,等于把整台机器的钥匙交了出去。OpenShell 的选择是给能力划边界,而不是一刀切地封死。
规则在内核层生效
每个 agent 跑在独立沙箱里,能读哪些文件、能调哪些系统调用,由内核机制管着。所有网络连接在离开沙箱之前,都要先过一遍策略检查。
关键在于,它不靠 agent 自觉,也不靠一句“禁止这样做”的提示词,而是在 agent 绕不开的层面强制执行。
凭证同样不落到 agent 手里。文档写明,agent 从来看不到真实凭证,OpenShell 只会在请求发往已获批准的终点时,才把凭证填进去。这针对的是一个常见事故:agent 不小心把密钥写进代码,或者把数据发到了机器外面。
新策略生效之前,系统会用形式化证明标出潜在风险,比如访问新主机同时带上凭证、调用新的 API 方法。这些风险项会被挂起等人审核,不会自动放行。形式化证明不等于没有漏洞,它保证的是变化不会悄悄溜过去。
一个策略文件管五件事
策略文件是 YAML 格式,五个部分各管一摊:
- filesystem_policy:规定进程能读、或能读写的路径,由 Linux 内核的 Landlock 机制强制执行。
- landlock:规定系统文件规则用不了时,沙箱还启不启动。
- process:规定进程使用的用户和用户组,在创建沙箱时由 Docker 或 Podman 锁定。
- network_policies:规定每个二进制能访问哪些终点、能发哪类请求,默认拒绝一切出站连接,除非有规则放行。
- network_middlewares:对已被规则放行的流量做检查、转换或拦截,适合“能读 API 但不能写”这类需求。
架构与上手
系统里有 gateway 充当沙箱、策略和访问权限的控制中心,有 supervisor 负责监督,真正干活的则是沙箱。如果团队已经在用 Kubernetes,可以用 Helm chart 安装 gateway,前提是 CNI 能强制执行 NetworkPolicy。
仓库首页给出的安装命令是 curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh,随后执行 openshell sandbox create --name demo。默认镜像是一个精简的 Ubuntu,里面没有预装 agent。项目提供 Python、TypeScript、Go 和 Rust 的 SDK,Python 版可以通过 pip 或 uv 安装,包已经上了 PyPI。
此外还有面向 coding agent 的公开技能,教它自己用 CLI 写策略、调试 gateway,省得每次配置都等人手写 YAML。
项目现状
项目采用 Apache 2.0 协议,文档链接指向 v0.1.5 版本。查看时仓库有 20,191 颗星、1,988 次 fork。
未关闭的 issue 约 390 条,打开的 pull request 约 210 条,GitHub 页面上显示的 600 是两者之和。这个数字不代表项目出了问题,只说明它还在快速变动,远没到稳定状态。
用之前要知道的限制
机器需要 Linux、Apple Silicon 上的 macOS,或者使用 WSL 2 的 Windows,后者仍是实验状态。原生 Windows 有一条走 Microsoft MXC 的路径,支持 x64 和 ARM64,但文档写明仍在开发中,尚未达到可投入实际使用的安全标准。宿主机上还得有 Docker、Podman 或能跑起来的虚拟化系统。
遥测默认开启,收集的是匿名数据,不收集沙箱名、主机名、文件路径、提示词和凭证。可以在 gateway 设置 OPENSHELL_TELEMETRY_ENABLED=false 关闭,或在 Helm 里改。
策略文件写错也会让系统停摆:镜像里的策略不合法,工作负载就不会启动,直到改好为止。系统不会跳过错误去用默认值,这个行为安全,但新手容易卡住。
还有一点,形式化证明只覆盖证明器检查到的那部分策略,通过检查不代表策略已经最窄,也不代表对所有情况都安全。如果 agent 被骗去滥用已有权限,防线仍然要靠最小权限设计。
至于沙箱会让 agent 慢多少,文档没有给出任何数字。如果速度直接影响成本,只能在自己的任务上实测。
为什么值得关注
一个能读 .env 的 agent 是看不见的风险。把它放进项目文件夹里不加约束,它就能读到你有权限读的所有文件,包括存着 API 密钥的文件和不该离开机器的配置。
当 agent 去读别人控制的网页或文档时,陌生指令可能被埋进内容里,agent 可能不知不觉照做。限制网络终点和凭证,能把损失控制在策略允许的范围内。
如果团队在个人机器上跑 Claude Code 或 Codex,而同一台机器上还存着客户数据,那么加一层策略强制,最好赶在出事之前。代价是配置要花时间,不是每个团队都准备好了。
OpenShell 不会让 agent 变强,它做的是给损失划出边界。它真正的价值不是拦住 agent 干活,而是让你敢放它多干一点,因为你知道它只能碰到你允许的那部分。
热门跟贴