AIREITER一个能够修改文件、安装软件包并调用 API 的编程智能体，不能只靠系统提示词里的一句警告来约束。NVIDIA OpenShell 把这些权限从智能体本身剥离出来，放进由策略强制执行的沙箱中。但项目仍然把最棘手的工作留给了你：编写完整策略，并验证实际部署是否真的符合预期。
先说结论：OpenShell 是运行时边界，不是智能体框架
NVIDIA OpenShell 是一个面向自主智能体的开源运行时。其 0.1.x 文档介绍了 Gateway、每个沙箱对应的 Supervisor、由内核强制执行的文件系统与进程控制、经中介处理的网络访问、凭据绑定，以及策略审查工具。根据 NVIDIA 于 2026 年 9 月 28 日发布的技术博客，它可以在不改写智能体的情况下，为 Codex 和 Claude Code 等智能体提供运行时保护（NVIDIA Technical Blog）。
这里最重要的区别，是“隔离”与“智能”并不是一回事：OpenShell 可以拦截未经授权的文件写入或网络请求，却无法让一份不完整的策略自动识别所有通往同一业务操作的间接路径。我会把它用于受控的编程智能体和智能体基础设施试点，但不会因为有了沙箱，就认定生产环境中的智能体已经安全。
OpenShell 到底控制了什么
OpenShell 将整个智能体集群的管理与具体工作负载分开。Gateway 负责管理沙箱和策略，Supervisor 负责中介处理工作负载发起的外部请求，而 Sandbox 则在操作系统限制下运行智能体（NVIDIA Technical Blog）。
| 层级 | 保护对象 | 运行中能否修改？ |
|---|---|---|
| 文件系统 | 文件和目录 | 不能；需要重新创建沙箱 |
| 进程 | 权限和系统调用行为 | 不能；需要重新创建沙箱 |
| 网络 | 主机、端口、二进制文件及选定的 API 操作 | 可以 |
| 提供商凭据 | 在获准端点使用的机密信息 | 可以 |
OpenShell 在应用层以下执行策略，并将可复用的凭据保留在智能体之外，只在请求获得批准时附加这些凭据（OpenShell README）。
“OpenShell 是面向自主 AI 智能体集群的安全、私有运行时。” — NVIDIA OpenShell README（来源）
安全模型在边界处最强，真正的短板在策略设计
OpenShell 的文档化控制能力之所以有价值，是因为它能在多个基础设施边界采取默认拒绝的处理方式。但它不能替代你对智能体可组合操作进行完整建模。
把文件系统、进程和网络控制放到同一张运行图里看
最新安全指南介绍了用于文件系统访问控制的 Landlock、用于进程限制的 seccomp 和降权机制，以及结合 OPA 策略评估的 CONNECT 代理，用于控制出站流量（OpenShell Security Best Practices）。未列出的文件系统路径默认无法访问，出站流量默认被拒绝，网络规则还可以将访问权限绑定到特定二进制文件的身份。
网络规则也不只是检查主机和端口。REST 策略可以检查方法和路径；GraphQL 策略可以检查操作和根字段；WebSocket 策略可以检查握手和消息。代价同样很现实：规则写得宽泛，更容易维持正常运行；写得精细，则更容易进行安全论证。
文件系统和进程限制会在沙箱启动时固定下来。运行中的沙箱可以更新网络权限，但一次批准会成为该沙箱实例的持久策略修订。这样既方便迭代，也不意味着所有控制项都可以随时修改。
凭据是经过中介管理，不是被“自动变安全”
凭据中介机制可以减少暴露范围，却无法让权限过宽的端点变得安全。只读 API 策略可以收窄一个技术上拥有写权限的凭据，但如果策略本身已经允许破坏性操作，它就无法替你修复这个问题。
安全指南建议先以 audit 模式启动 L7 规则，观察并审查实际请求后，再切换到 enforce。审计模式会记录违规行为，但仍会转发请求，因此它是发现问题的步骤，而不是生产环境的拦截机制。
如何评估 OpenShell，避免把演示当成安全结论
NVIDIA 的官方教程使用 curl 和未经身份验证的 GitHub REST API，演示拒绝访问、只读规则以及在线替换策略；它是一条学习路径，不是独立基准测试（NVIDIA Technical Blog）。
可以先用教程回答三个部署问题：
- 你的智能体能否在完全没有网络访问权限的情况下启动，然后只获得它实际需要的端点？
- 你能否为所用 API 明确区分读操作和写操作？
- 运维团队能否在不授予智能体自行批准请求权限的前提下，审查拒绝记录和策略修订？
真正进行试点时，还应加入对抗性测试：符号链接和路径遍历尝试、软件包安装、Shell 子进程、替代二进制文件、发送到错误主机的凭据占位符，以及多个单独看似获准、组合后却可能越界的操作。公开材料没有提供延迟、启动开销或独立逃逸率数据，因此这些数字应在你自己的环境中采集，不能把产品架构方面的描述直接当成测试结果。
哪些问题可能阻止生产落地
生产决策至少要考虑三个限制：
- 成熟度与兼容性。仓库列出了 Linux、Apple Silicon macOS，以及通过实验性 WSL 2 支持的 Windows；执行方式则包括 Docker、Podman 或主机虚拟化。Kubernetes 需要使用能够强制执行
NetworkPolicy的 CNI；Kubernetes 用户命名空间还需要较新的内核、Kubernetes 和运行时版本，而在这一组合下的 GPU 兼容性尚未验证（OpenShell README；Security Best Practices）。 - 策略组合。@liyun0016 的一次真实用户测试报告称，明确的拒绝测试都通过了，但编辑代码仓库、修改 CI 并触发 CI 这几个动作组合起来后，可能形成一条未经授权的生产路径（帖子）。OpenShell 会执行你写下的规则，却不会替你定义那些被遗忘的业务层规则。
- 证据质量。NVIDIA 报告了长周期对抗性实验，称受保护仓库没有发生写入，但在引用的技术材料中没有公布模型数量、基线、误报率或独立复现结果。应把这视为厂商证据，而不是认证。
“OpenShell 显然很擅长执行你交给它的规则。但……真正的瓶颈似乎在策略层。” — @liyun0016（来源）
现在适合谁使用 NVIDIA OpenShell？
| 场景 | 建议 |
|---|---|
| 处理敏感文件的本地编程智能体 | 如果 Linux/macOS 运行时要求能够满足，并且策略从严格收窄开始，值得试点 |
| 拥有多个工作区的团队智能体集群 | 适合需要隔离工作区、统一策略审查和凭据中介的团队 |
| 重度依赖 GPU 的 Kubernetes 部署 | 谨慎试点；用户命名空间和 GPU 兼容性需要单独验证 |
| 拥有广泛业务权限的无人值守生产智能体 | 不要单独依赖 OpenShell；还需要业务审批、操作级控制、日志记录和回滚机制 |
| 只需要一个简单的 Python 代码沙箱 | 应比较专用沙箱；OpenShell 可能提供了超出需求的控制平面 |
我的建议是进行有边界的试点，而不是全面迁移：选择一个智能体、一个工作区、一套默认拒绝的网络策略，以及一小组可逆任务。重点测量被拦截请求中的噪声、启动时间、策略维护成本，以及一连串单独获准的操作能否跨越业务边界。
NVIDIA OpenShell 常见问题
NVIDIA OpenShell 是否需要 NVIDIA GPU？
README 记录了 CPU 和 GPU 执行路径，并列出了 Docker、Podman 和主机虚拟化。文档没有将 NVIDIA GPU 列为运行时的硬性要求，但你仍应验证目标驱动和部署组合是否适用。
OpenShell 已经可以用于生产环境了吗？
OpenShell 0.1.x 已有明确的版本发布线，但官方材料没有提供独立安全认证或广泛的性能基准。应把它视为需要根据自身威胁模型验证的基础设施，而不是适用于所有场景的生产保证。仓库采用 Apache License 2.0；你还需要为计算资源、Gateway 运维、策略维护和安全测试预留预算（OpenShell README）。
综合结论：通过。
OpenShell 能运行 Claude Code 或 Codex 吗？
NVIDIA 的技术博客将 Claude Code 和 Codex 列为兼容智能体。该运行时的设计目标，是为现有智能体工作负载提供封装，而不是要求重写智能体。
不重新创建沙箱，可以修改文件系统规则吗？
不能。安全指南将文件系统和进程控制归类为静态控制。网络策略和提供商分配可以在沙箱运行期间发生变化。
OpenShell 和 Docker 有什么区别？
Docker 提供容器化基础能力。OpenShell 则增加了面向智能体的策略层，用于控制文件系统、进程、网络、API 操作、凭据以及策略审查。两者也可以同时出现在同一套部署中。