NVIDIA OpenShell：为 AI 智能体划定可执行的权限边界

NVIDIA OpenShell 到底能做什么？

OpenShell 是一个开源运行时，负责运行智能体并控制其访问权限。它位于智能体底层，不替代智能体的推理能力或工具。

可以把它想象成在楼内施工的承包商：你给他一间工坊，允许他进入指定房间、联系指定供应商，而不会因为工作说明里写着“务必小心”，就把万能钥匙交给他。OpenShell 为软件智能体提供的正是这类边界。

其运行时概览介绍了文件系统限制、网络控制、进程限制和服务提供方凭据保护。Landlock 是限制文件访问的 Linux 内核机制；seccomp 限制系统调用，也就是程序向操作系统发出的底层请求。这些限制的执行独立于智能体的推理过程。

网关负责管理沙箱和访问。沙箱外的监督程序根据策略检查出站请求，并在获得许可时提供凭据。策略证明器则检查建模后的权限是否符合已定义的边界。这些机制约束的是智能体可以做什么，并不保证它在权限范围内做的事就是正确的。

NVIDIA 列出了 Claude Code、Codex、GitHub Copilot CLI、Hermes、LangChain Deep Agents、OpenClaw 和 OpenCode 的使用路径，也支持自定义智能体和镜像。“支持”不代表每个工具都已预装：当前默认工作负载是精简的 Ubuntu 镜像，不包含智能体 CLI，也就是用于启动智能体的命令行程序。

对业务而言，变化在于权限可以复用。没有可复用的边界，每增加一个智能体工作流，团队都可能需要重新讨论该开放哪些文件、密钥和服务。有了边界，就能把这些决定与工作负载一起打包，并审核后续变更。评估收益时，应记录工程师在访问配置和处理中断上花费的工时；目前没有经过验证、可直接套用的通用节时数据。

目前支持在哪些平台运行？

选择宿主机时，以当前支持矩阵为准。本文流程依据标注为 v0.1.7 的文档，核对日期为 2026 年 11 月 8 日。

WSL 2 在 Windows 上运行 Linux 环境。MXC 则是另一条原生 Windows 隔离路径。不能把“支持 Windows”理解为同一套可以互换的安装方案。

Windows 合作公告介绍了通过 MXC 将 OpenShell 引入 Windows 的方向。但这不代表原生路径现在就有常规的稳定版安装程序。当前安装文档明确指出，标准发布渠道不提供原生 Windows 二进制文件。

首次评估建议选择受支持的 Linux 或 Apple Silicon 环境。支持矩阵也规定了内核和运行时要求：Linux 6.2 引入了所需的 Landlock ABI，但仅满足内核版本要求还不够，运行时还必须通过相应检查。在 macOS 的 Docker Desktop 路径下，这些 Linux 能力运行在其 Linux 虚拟机内。无需使用 NVIDIA Vera CPU。

如何安装 OpenShell CLI 并运行第一个智能体？

先从 NVIDIA 文档中的 OpenCode 示例入手。它清楚展示了三个组成部分：负责服务访问的 provider、包含智能体的镜像，以及运行智能体的沙箱。以下步骤来自文档，不代表已在本地实测。

1. 准备宿主机并安装 OpenShell。 采用 Docker 路径时，需要先运行 Docker Desktop，或使用 Docker Engine 28.0 及以上版本。在受支持的 Linux 或 macOS 上，安装指南使用 curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh。执行前应先审阅安装脚本。它会安装 CLI、策略证明器和本地网关。运行 openshell status，确认 CLI 能连接网关。

2. 配置模型服务。 示例使用 OpenRouter。创建 provider 前，先在宿主机环境中设置 OPENROUTER_API_KEY。provider 配置档描述允许的服务端点和可执行文件路径，provider 本身负责存储凭据。NVIDIA 的示例配置档允许 /usr/local/bin/opencode 访问 openrouter.ai。

3. 导入配置档、创建 provider 并启动镜像。 在宿主机上依次运行：

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

镜像提供 OpenCode；-- 后的命令将其作为主进程启动。首个智能体操作指南使用这一免费模型，无需 OpenRouter 额度。这只是该示例的模型选择，不代表任意模型调用都免费。

4. 在宿主机上审核访问请求。 智能体尝试访问未经批准的目标时，OpenShell 会拒绝请求，并起草一条范围收敛的规则提案。运行 openshell rule get my-agent --status pending 查看。如果提案符合任务预期的访问范围，就用 openshell rule approve my-agent --chunk-id <chunk-id> 批准该条提案，并将占位符替换为实际 ID。规则重新加载后，智能体即可重试。

5. 检查实际授予的权限。 先运行 openshell policy get my-agent --base，再运行 openshell policy get my-agent --full。前者显示基础策略，后者还包含 provider 添加的规则。在接入真实项目或敏感服务之前，先审核最终生效的权限。

一次性评估结束后，可用 openshell sandbox delete my-agent 删除沙箱。

哪些策略可以在运行中修改？

网络访问权限可以在任务执行期间调整。文件系统和进程边界则需要新建沙箱才能改变。

“运行中生效”也有代价。新网络规则会关闭按旧规则建立的连接，客户端必须重新连接。注册新的外部中间件服务需要修改网关配置并重启网关。把文件系统路径加入已保存的策略，并不会让运行中的工作负载获得该路径的访问权；启动后删除路径或修改启动设置则会被拒绝。策略管理指南详细说明了这些区别。

还有一个容易踩的坑：没有策略文件，不等于没有访问权限。策略可能来自镜像、环境设置或网关级策略。绑定的 provider 也可能添加网络规则。策略选择规则还明确指出，全局策略会替换沙箱自身的策略，而非简单叠加一层更严格的限制。

如何为编程智能体写出清晰可审查的策略？

让修复 bug 的智能体先获得可写的项目目录和只读 API 访问，再考虑授予发布变更的权限。

下面的示例适用于预先准备好的编程镜像：项目位于 /workspace，且已在 /usr/bin/curl 安装 curl。将其保存为 policy.yaml，创建新沙箱时传入 --policy ./policy.yaml。它是针对这一镜像布局的模板，不能直接套用于所有智能体镜像：

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

智能体可以编辑项目和临时文件。网络规则允许指定可执行文件向 GitHub API 发出 GET、HEAD 和 OPTIONS 请求。它并不允许任意程序访问互联网，也不授权软件包下载或 Git 推送。模型 provider 需要另行配置。

镜像需要哪些可写的智能体状态目录，应提前准备并逐一明确加入。这些路径指向沙箱内的文件系统，不能因为宿主机上有同名目录，就认为它会自动可用。此外，具备网络能力的工作负载还会加入基础文件系统路径，因此这份简短的 YAML 并不意味着最终生效的边界只包含其中列出的路径。

有两项设置需要特别留意。若用户定义的文件系统规则无法强制执行，hard_requirement 会阻止启动，但个别缺失或无法访问的路径仍可能被跳过。enforcement: enforce 会阻止检查中发现的不合规请求；而模式定义中的默认 audit 模式只记录违规，仍会放行请求。修改模板前，请查阅策略模式定义参考。

测试既要验证允许，也要验证拒绝。NVIDIA 的网络策略教程先检查只读规则下 curl -s https://api.github.com/zen 能否成功，再确认 POST 请求会被拒绝。在宿主机上用 openshell logs my-agent --since 5m --source sandbox 检查日志。针对自己的项目，还应测试一次预期内的文件写入，以及一次超出范围的文件访问。智能体成功启动，并不等于安全策略通过了验收。

最值得先试的五类工作流

最适合早期尝试的场景，任务边界清晰，也有人能够判断输出质量。按可能带来的运维价值排序如下：

这些做法都不能保证生成的代码正确，或故障诊断可靠。它们的价值是收窄智能体工作时可能产生的影响。若要比较更多工具，可参阅 2026 年最佳 AI 沙箱安全工具；若要选择执行平台，可参阅 2026 年最佳 AI 智能体代码沙箱。

围绕 OpenShell，有哪两个值得做的产品方向？

最值得优先尝试的是团队编程智能体接入套件。 目标买家是希望开发者在获批环境中高效工作的平台负责人。本次查询返回的市场中，DataForSEO 估算 “claude code sandbox”每月有 1,300 次搜索。这说明有人关心环境搭建，不代表有 1,300 名潜在客户；其中部分搜索者寻找的也是智能体自身的沙箱，而非 OpenShell。

最小可售版本可以只支持一种智能体和一种获批的宿主配置，交付预制镜像、审核过的策略、provider 配置清单，以及可重复执行的放行与拒绝测试。卖点是能实际运行的团队部署方案，同时明确谁负责更新。难点在维护：镜像路径、智能体行为和实验性接口都可能变化。在开发托管产品前，先访谈平台负责人，了解他们承担这些维护工作的负担。

第二个方向是策略审核工作台。 安全团队可以用它查看实际生效的策略允许什么、比较变更并记录审批。DataForSEO 估算 “ai agent security”每月有 480 次搜索，“ai agent security tools”则有 70 次。这些独立查询反映的是宽泛的需求信号，不能相加后视为独立买家数。

MVP 可以导入基础策略与实际生效的策略，突出显示新增的目标地址和请求权限，并将测试结果附到审核记录中。难点在差异化：OpenShell 已经提供策略分析、提案和日志。产品需要改善团队的审核流程，而不只是给现有命令套一个仪表盘。建议先做接入套件，因为买家和交付物都更容易界定。

OpenShell 解决不了哪些问题？

OpenShell 限制访问，但不会判断某项获准操作是否符合业务利益。被允许写入项目文件的智能体，仍可能写出有问题的补丁。获批的外部目标，也仍可能收到策略允许发送的数据。文件访问与端点审批必须准确反映你真正打算开放的内容。

它也不能取代身份系统、密钥存储、监控或治理。NVIDIA 的运行时控制公告强调在智能体工作负载之外执行约束。应将它视为周边系统的一部分，而非舍弃其余机制的理由。

项目现在已有面向支持矩阵内生产环境的稳定版本，因此把整个 OpenShell 都称为实验演示并不准确。真正的限制更具体：实验性接口可能在补丁版本中发生变化，原生 Windows 路径仍在开发，NVIDIA 也说明当前的验证范围未覆盖整套发布验证政策。部署时应固定版本，并验证实际使用的工作负载与宿主机组合。

周一就能做的事： 请平台负责人选一个不含敏感信息的代码仓库和一个智能体。在受支持的宿主机上安装 OpenShell，准备镜像，定义文件与网络访问，然后分别测试一项允许的操作和一项被阻止的操作。记录首周的配置耗时，以及工程师处理中断所花的工时。只有当团队能解释每一项已授予的权限时，再扩大使用范围。

如果你希望将这套机制融入团队工作流，我们可以协助落地生产环境控制措施。