英伟达（NVIDIA）的 OpenShell 0.1.x 推出稳定发布节奏、新隔离原语、更大的扩展面和新 API，建议阅读 0.1.0 升级指南。作为面向自主 AI 智能体集群的安全私有运行时，OpenShell 让智能体读取文件、安装软件包、调用 API 和使用凭证，却不放开对数据、密钥和网络的无限制访问；用户在策略中声明智能体可接触的范围，OpenShell 负责强制执行。它用内核在运行时执行策略，并以形式化验证检查策略变更。
正文
OpenShell 0.1.x 中的重要更新：稳定的发布节奏、新的隔离原语、更丰富的扩展接口以及新的 API。请阅读 0.1.0 升级指南。
OpenShell 是面向自主 AI 智能体集群的安全、私有运行时。当智能体能够读取文件、安装软件包、调用 API 并使用凭证时，它们才最有用。OpenShell 赋予它们这种能力，同时不会让它们无限制地访问你的数据、机密或网络。你在策略中声明每个智能体可以接触哪些资源，OpenShell 则负责执行该策略。
工作原理
OpenShell 通过两种方式管理智能体的行为：在运行时检测内核，对每次文件访问、系统调用和网络连接强制执行策略；并在应用策略变更前，使用形式化验证来检查该变更会允许哪些操作。
内核级强制执行。每个智能体都在独立的沙箱中运行。内核控制限制它可以访问哪些文件、可以进行哪些系统调用，并且每个网络连接在离开沙箱前都要经过策略检查。智能体永远看不到真实的凭证；OpenShell 只会将凭证添加到发往已批准端点的请求中。
形式化验证的策略变更。在批准策略变更之前，OpenShell 会使用形式化验证来标记该变更将授予的风险新访问权限，例如携带凭证访问新主机或调用新 API 方法，因此这些变更需要等待人工审核。
有关网关、supervisor 和沙箱如何组合在一起的内容，请参阅 Architecture。
快速开始
你需要 Linux、搭载 Apple Silicon 的 macOS，或带有 WSL 2 的 Windows（实验性），以及 Docker、Podman 或主机虚拟化。详情请参阅 Support Matrix。
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh openshell sandbox create --name demo
安装程序会设置 CLI 和一个本地网关。默认的沙箱镜像是极简 Ubuntu，其中没有安装任何智能体。要运行真正的智能体，请按照“Run Your First Agent”操作：它会让 OpenCode 配合一个免费的 OpenRouter 模型运行，并展示如何在智能体需要时批准新的访问权限。
进一步探索
沙箱：镜像、运行时、GPU 和生命周期。
策略：文件系统、网络和进程规则，并配有 advisor 和 prover 用于审查变更。
提供商：仅在已批准端点生效的凭证，包括推理（inference）。
网关：用于沙箱、策略和访问的控制平面。
Kubernetes：使用 Helm 部署网关。你的 CNI 必须强制执行 NetworkPolicy。
可扩展性：中间件、拦截器和计算驱动。
教程：逐步讲解策略和智能体的操作演练。
预发布和开发版本：试用即将发布的版本，或 main 分支上的最新提交。
智能体技能
为你的编码智能体安装公开的 OpenShell 技能：
npx skills add NVIDIA/OpenShell
这些技能会教你的智能体如何操作 OpenShell CLI、编写沙箱策略，以及调试网关和推理路由。它们位于 skills/ 目录下，无需签出 OpenShell 源代码即可使用。
SDK
SDK 用于将应用程序连接到 OpenShell 网关。它们不会安装 CLI。请尽可能让 SDK 和网关使用相同的 OpenShell 版本。
Python：uv add openshell（文档：README）
TypeScript：npm install @nvidia/openshell-sdk（GitHub Packages）（文档：README）
Go：go get github.com/NVIDIA/OpenShell/sdk/go@latest（文档：README）
Rust：cargo add openshell-sdk --git https://github.com/NVIDIA/OpenShell --tag
社区
OpenShell 是以智能体优先（agent-first）的方式构建的：它使用自己所支持的智能体驱动工作流进行开发。开发设置和贡献流程请参阅 CONTRIBUTING.md，仓库编码规范请参阅 AGENTS.md。
遥测
OpenShell 会收集匿名遥测数据，这些数据仅限于运维类别和计数，用于帮助改进项目。它不会收集沙箱名称、主机名、文件路径、提示词、凭证、提供商或模型名称，也不会收集用户内容。如需禁用，请在网关上设置 OPENSHELLTELEMETRYENABLED=false，或在 Helm 安装中设置 server.telemetryEnabled=false。你也可以在编译时完全移除遥测功能。详情请参阅 Telemetry，已发布的使用趋势请查看社区遥测报告。
声明与免责声明
本软件会自动检索、访问外部材料或与之交互。这些被检索的材料并不随本软件分发，仅受单独的条款、条件和许可约束。你全权负责查找、审查并遵守所有适用的条款、条件和许可，并负责验证任何被检索材料针对你的特定用例的安全性、完整性和适用性。本软件按“原样”提供，不附带任何种类的担保。作者不对任何被检索材料作出任何陈述或担保，也不对因你使用或无法使用本软件或任何被检索材料而导致的任何损失、损害、责任或法律后果承担任何责任。使用本软件及被检索材料的风险由你自行承担。
许可证
本项目基于 Apache License 2.0 授权。
评论
讨论气氛以审慎和调侃为主：不少人认可 OpenShell 把 Agent 运行时、权限控制和容器管理打包在一起的思路，但质疑声集中在默认开启遥测、命名与营销话术，以及相对直接用容器或更轻量的沙箱是否过度设计。分歧主轴是 Agent 能力与安全边界的权衡——给的权限越多 Agent 越强，但“既全能又安全”被很多人认为不可能，或至少被宣传夸大。
认为 OpenShell 把 Agent 运行时与细粒度权限管理打包得很有价值
- 现场反馈和早期用户都提到，GTC Europe 不少演示已经用到它，功能集中、对 Agent 安全加固很有吸引力；有人已在生产中使用，并在其上补充团队策略、安全 Git 使用与 SCA/SAST。细粒度的权限控制虽然繁琐到近乎迂腐，但对权限需求微妙的大型企业可能正中靶心，业界整体却在远离把 k8s 作为部署平台。（较多人） > 很高兴看到 Nvidia 加速支持，功能一站式打包得很棒，之前还担心竞品出现后项目会被砍掉。（@agentdev001）
认为默认开启遥测不可接受，甚至等同于间谍软件
- 项目默认收集匿名遥测（仅限运维类别和计数），可通过环境变量或 Helm 配置关闭；但在批评者看来默认开启就不可接受，被直接斥为间谍软件，这种反感在讨论中相当普遍，是主要信任障碍。（较多人） > 收集匿名遥测，等同间谍软件。（@sscaryterry）
认为名字、营销话术与“开放”宣称令人反感或不可信
- 名字里的 Open、Shell，以及“开箱即私有、安全”的描述让一些人本能反感，认为它大概率会在这些宣称上翻车；“Open”和 Nvidia 放在一起也被嘲为矛盾修辞，还有人提醒别和经典开始菜单项目 Open-Shell-Menu 混淆。讨论里也有人玩梗，把 OpenShell 读成“Nvidia 开启地狱”的谐音（纯玩笑）。（少数人） > 刚看到名字和“安全、私有运行时”的描述就本能反感，觉得它大概率会在这些宣称上失败。（@jrm4）
认为 Agent 能力与安全不可兼得，细粒度沙箱不等于能防住所有泄露
- 核心反直觉点是：Agent 越能读文件、装包、调 API 和用凭据就越有用，但能力越大风险也越大；宣传语读起来像“全能且安全”，被批评为掩盖了这种取舍，最多只能折中，不可能真正两全。（较多人） > 给 Agent 的权限越多它越强，所谓既能放开能力又不失控，鱼与熊掌不可兼得，宣传让人觉得过度承诺。（@smallnix）
认为直接用容器或更轻量的沙箱更简单，OpenShell 可能过度设计或难维护
- 不少人反问“为什么不直接用容器”：既然大家本来就该把 Agent 跑在容器里，OpenShell 的价值更多在于管理这些容器；基于 Docker 的白名单模式被认为更简单，有人因此看不懂 OpenShell 的用例，觉得它可能只对有遗留系统和复杂工具权限的大型组织才有意义。相比之下，Anthropic 的 sandbox-runtime 被举例为在安全与便利间更平衡、配置更简单的替代，只是遇到 xcode/swift、Docker 等常见工作流时限制会让人恼火。（较多人） > 看着 OpenShell 的复杂度，不如直接在 Docker 上做白名单模式，我不太理解它的用例。（@smashed）
- 维护前景也被质疑：有人担心 Nvidia 并非软件公司，项目会维护不良，或像过去一些大厂项目那样在竞品出现后被放弃。（少数人）
有价值的补充
- 术语上，@ivanjermakov 认为 agent runtime 其实比现在流行的 coding agent 或 agent harness 更贴切。
- 实际防御上，即便把网络限制到受信任域名并做凭据替换，数据外泄仍是未解难题：被提示注入的 Agent 可能把数据拆成字符级，慢慢发到已允许的域名；因此 GitHub 等工具的访问也需要代理和额外审计。有人想自己实现进程执行审计，却被 Claude 的安全分类器拦住，既不允许自定义内核钩子，也不允许直接调用现成审计软件。（@fennecbutt、@crypt1d）
- 有开发者在自建 Docker 沙箱时，以监控 Lethal Trifecta、确保每个 Agent 之间正确隔离为长期目标，但承认目前还没做到。（@smashed）
- 有用户已在 OpenShell 之上构建团队策略、安全 Git 使用与 SCA/SAST 等能力，说明它常被当作可扩展底座，而不是开箱即用的完整答案。（@razuba）
- 关于如何让 Agent 在沙箱内使用 xcode/swift、Docker 等常见工具，目前仍缺少既便利又安全的方案，是替代型沙箱同样要解决的问题。（@thehours）