ARTICLE · 1273393

【AI工具推荐】19.8K星!英伟达开源Agent沙箱:AI能在你机器上随便跑,却摸不到你的密钥

发布时间：2026-10-29 11:52:47 最近访问：2026-10-29 11:52:48

19.8K星！英伟达开源Agent沙箱：AI能在你机器上随便跑，却摸不到你的密钥

英伟达开源 OpenShell，19,851 星、一周涨 3,223 星。它把 Agent 权限闸门装进内核，密钥永不落地，策略改一行都要过形式化验证。这篇把它拆开讲清楚：值不值得现在就上。

上周有条新闻没上热搜，但做基础设施的人应该看一眼：印度 CERT-In 发了一份安全通告，起因是一个 AI Agent 在"跑测试"的时候，读到了它本不该碰的真实企业系统数据。

注意，这不是被攻击。是 Agent 自己走过去的。它没有恶意，它只是"能力比约束多了一点"。

这就是 2026 年下半年最尴尬的现实：Agent 越好用，你给它的权限越多；权限给多了，它就是一台挂着你的密钥、连着你的内网、还能自己决定下一步做什么的进程。

英伟达对这个问题的回答，是一个 19,851 星的开源项目：NVIDIA/OpenShell。

一、先看数据：这不是概念稿，是已经跑起来的运行时

先摆硬指标，全部来自公开仓库数据（截至 2026-10-25）：

指标	数值
Star 总数	19,851
本周新增	+3,223
Fork	1,966
主语言	Rust
许可证	Apache-2.0
提交数	1,863
发布版本	102 个，最新 v0.1.5（2026-10-20）
创建时间	2026-02-24

一个 8 个月前创建的仓库，一周吃进 3,223 星，说明它不是靠"英伟达"三个字涨的——是靠痛点涨的。

官方定位一句话："the safe, private runtime for autonomous AI agents"（面向自主 AI Agent 的安全、私有运行时）。

拆成中文就是：让 Agent 拥有它干活必需的权限，一个都不多。

这句话听起来像营销，但它的实现方式很硬：不是给你一个 SDK 让你"记得调用"，而是在内核层插桩。

二、核心功能拆解：它到底把闸门装在哪一层

这是理解 OpenShell 的唯一关键点。位置选错了，后面全白搭。

🔹 1. 控制点在内核，不在 SDK

市面上大部分 Agent 沙箱是在应用层做包装：SDK 里加个 hook，拦一下工具调用，判断这次调用该不该放行。

这种做法的软肋非常明显——绕过 SDK 就失效。Agent 自己写段脚本调 curl，或者干脆起个子进程，包装层就成了装饰品。

OpenShell 换了个位置：对内核插桩。每一个 Agent 跑在独立沙箱里，内核负责对每一次文件访问、每一次系统调用、每一个出站网络连接执行策略检查。

这个差别的实质是：它不依赖 Agent 配合，也不依赖上层框架写得规不规范。你用的是 Claude Code、Codex、OpenCode 还是自己写的 Agent 循环，闸门都在那儿。

🔹 2. 凭据永不落地

这是我认为最值钱的一条设计。

常规做法是把 API Key 塞进环境变量，Agent 需要时自己读。问题在于：一旦 Agent 能读环境变量，它就能把 Key 打印出来、写进文件、发到某个它不该发的地方——而 prompt injection 干的正是这件事。

OpenShell 的做法是：Agent 永远看不到真实凭证。只有当请求发往已批准的端点时，运行时才在出口处把凭证注入进去。

翻译一下：Agent 知道"我要调这个 API"，但它不知道"我用什么身份调"。中间那一层，它碰不到。

🔹 3. 策略变更要过形式化验证

这一条是 OpenShell 和普通沙箱方案最大的分水岭。

绝大多数沙箱工具把策略当配置文件：改完、reload、生效。

OpenShell 把策略 diff 本身当成需要分析的对象：任何策略改动在生效之前，系统会先算一遍这次改动会新增哪些访问权限。如果这次改动会让某个 Agent 用某个凭证去访问一个新主机，或者调用一个新的 API 方法，它会被标记出来，挂起，等人来审。

为什么这个设计重要？因为它默认了一个前提：改策略的那个人，可能就是 Agent 自己，或者是在 Agent 建议下动手的人。

这个威胁模型比"防外部黑客"现实得多。你的 Agent 在帮你配环境时顺手放宽了一条策略，这种事每周都在发生。

🔹 4. 推理流量可以完全私有

OpenShell 单独做了一套 Inference Routing：把推理请求路由到本地或自建的模型后端，让推理流量不出你的网络。

对国内团队来说这条尤其实际——不管是合规要求，还是单纯的网络稳定性，能自己控制推理出口就是硬需求。

🔹 5. 现成 Agent 一行命令进沙箱

它不要求你重写 Agent。创建沙箱时直接指定你要跑的东西：

openshell sandbox create --claude openshell sandbox create --from openclaw openshell sandbox create --opencode openshell sandbox create --codex

官方口径是：Claude Code、Codex、Cursor 这类主流编码 Agent 可以不改代码跑在 OpenShell 里。

另外，如果你的编码 Agent 支持 skills，还有一条可选路径：

npx skills add NVIDIA/OpenShell

三、上手指南：两条命令起沙箱，五个坑先记住

🔹 安装

两种方式，任选其一：

# 方式一：走 Python 工具链（推荐，好升级） uv tool install -U openshell  # 方式二：官方安装脚本 curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

安装脚本会同时配好 CLI 和本地 gateway。

🔹 起第一个沙箱

openshell sandbox create --name demo

到这一步你就有一个沙箱了。但请注意下面第一个坑。

🔹 环境要求（这一节最容易浪费时间，建议先对照）

项目	要求
操作系统	Linux / Apple Silicon macOS / Windows + WSL 2（实验性）
容器后端	Docker、Podman 或主机虚拟化，三者必须有其一
Linux glibc	≥ 2.28
Python SDK	≥ 3.11
源码构建	Rust 1.94、edition 2024

🔹 五个必须知道的坑

坑 1：默认沙箱里没有 Agent。

openshell sandbox create --name demo 给你的是一个精简版 Ubuntu 镜像，里面什么都没装。很多人以为 demo 会开箱跑点 Agent 行为，结果对着空壳发呆。要跑真 Agent，去看官方 "Run Your First Agent" 文档——它会用 OpenCode 接一个免费模型，并完整走一遍"Agent 申请新权限 → 人工审批"的流程。这段流程才是这个项目的精华，别跳过。

坑 2：Intel Mac 直接出局。

支持矩阵里 macOS 只有 Apple Silicon。这不是写着好看，是真的没路径。

坑 3：没有容器或虚拟化后端，沙箱起不来。

Docker、Podman、主机虚拟化，缺一个都不行。裸机直接上会卡在第一步。

坑 4：遥测默认是开的。

OpenShell 会收集匿名遥测，官方说明范围限于运营类别与计数，不含沙箱名、主机名、文件路径、提示词、凭证。要关掉：

# gateway 上 export OPENSHELL_TELEMETRY_ENABLED=false  # Helm 安装的 # server.telemetryEnabled=false

坑 5：SDK 和 gateway 版本要对齐。

官方明确建议两者用同一个 OpenShell 版本。版本漂移不会给你干净的报错，只会给你一堆看不懂的失败。

另外提醒国内用户：安装脚本从 GitHub 拉发布产物，可能需要代理或加速通道。官方没提供镜像，翻译版仓库也没提供，只是把这个问题标出来了——省得你对着超时怀疑脚本坏了。

四、对比竞品：它站在哪一格

把 Agent 技术栈拆成五层来看会更清楚（这是今年 4 月一篇 arXiv 综述提出的 Agent BOM 框架，现在 GitHub Trending 基本能一一对应）：

层	作用	开源代表	Star
Model	推理引擎	GPT-6、Claude Opus 5.5、Kimi K3.1、DeepSeek V4.1	—
Memory	跨会话记忆	claude-mem、Mem0、Zep	103K / 45K / 28K
Skills	能力包	Cloudflare Skills、Hallmark	46K / 33K
Sandbox	隔离执行环境	NVIDIA OpenShell、E2B、Cloudflare Sandboxes	19.8K / 12K / —
Router	模型路由与容灾	FreeLLMAPI、LiteLLM、Portkey	41K / 18K / 9K

在 Sandbox 这一层，几个主要玩家的取舍差别很大：

方案	隔离粒度	凭证处理	策略变更	上手成本	适合谁
NVIDIA OpenShell	内核级（文件/系统调用/网络全覆盖）	出口注入，Agent 不可见	形式化验证 + 人工审批	中（需容器后端）	要跑自主 Agent 的团队
E2B	云端微虚拟机	需自行管理	配置即生效	低（纯云）	快速做 Agent 产品的团队
Cloudflare Sandboxes	边缘容器	平台托管	配置即生效	低	已在 Cloudflare 生态的项目
Docker + seccomp 手搓	容器级	环境变量	配置即生效	高（要自己写策略）	有专职安全的团队
Dev Container	开发环境隔离	环境变量	无	极低	只是想在隔离环境写代码

一句话总结差异：别人解决的是"把 Agent 关起来"，OpenShell 解决的是"关起来之后，它每一步到底被允许碰什么，以及谁能改这个允许"。

顺带说个细节，说明这个生态在往哪走：2026 年 9 月英伟达发布了 Open Agent Safety Platform，把 OpenShell 和 Sentry 监测层配在一起，Sentry 跑在独立的 BlueField-4 DPU 上。目前 Cisco、CrowdStrike、Google、Microsoft Security、TrendAI 都在接入。

五、谁该用，谁别碰

🔹 建议现在就用半天跑一遍的

• Agent 需要动态装包、访问外部主机、用多份凭证的场景。这是它的主场。

• 企业内网里跑 Agent 的团队。凭据不落地 + 出口策略检查，能直接消掉一整类事故。

• 要过合规/审计的。策略变更留痕 + 形式化验证，比"我们配了 seccomp"好解释得多。

• 用 Claude Code / Codex 但不敢让它碰生产环境的。改个启动参数的事。

🔹 不建议上的

• Agent 只在固定工具集里调几个内部 API。普通容器加网络策略就够了，上 OpenShell 属于过度设计，还会被审批流程拖慢节奏。

• 纯 Windows 环境。WSL 2 目前是实验性支持，别在生产上赌。

• 要求今天就能上生产的。它还在 0.1.x。

六、我的判断：方向对了，但别急着上生产

值得跑，是因为它把位置选对了。 内核层而不是应用层，这个方向我认为没有争议。凭据不落地、网络连接出沙箱前必过策略，这两条是能直接消掉事故的设计，不是加分项，是及格线。