2万星开源项目，把AI agent关进内核级隔离间

英伟达把一个叫 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 干活，而是让你敢放它多干一点，因为你知道它只能碰到你允许的那部分。