背景：智能体的安全边界正在从软件挪到硬件
智能体和聊天机器人的根本差别在于它能动手：读文件、发请求、调工具、改配置。一旦智能体持有凭证，它就同时具备了被诱导的可能性和造成实际损害的能力，这两件事叠加在一起，让「权限最小化」从一句原则变成了必须被机器强制执行的约束。
过去两年的主流做法是在软件层解决：容器隔离、网络策略、网关代理、应用层护栏、审计日志。这些手段有效，但有一个共同的结构性弱点——执行约束的软件，和被约束的智能体，跑在同一台机器的同一个信任域里。智能体一旦拿到提权路径，它同时也就拿到了修改护栏的路径。
OpenShell 参考架构提出的答案是把这个约束往外挪一层：让监控与强制执行的组件运行在 DPU 上，也就是一块智能体自己的软件够不到的网卡上。这是整套设计里真正新的那部分，其余两层的价值更多在于把性能与容量讲清楚。
参考架构（Reference Architecture）这个词需要按字面理解：NVIDIA 发布的是一份「怎么搭」的设计说明与配套组件清单，而不是一个装好就能跑的盒子。新闻稿中明确写道，其中描述的许多产品与特性仍处于不同阶段，将按「可用时提供」的方式供应，且不构成承诺或法律义务。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
它是什么：参考架构、运行时与两条时间线
需要先把两件事分开，因为不少转述把它们混在了一起。OpenShell 运行时是一个开源软件项目，早在 2026 年 2 月就已公开在 GitHub 上，采用 Apache 2.0 许可，10 月 20 日发布了 v0.1.5 版本。它的 README 用一句话讲清了自己的定位：你用策略声明每个智能体能碰什么，OpenShell 负责强制执行这句话。
OpenShell 参考架构是 10 月 21 日在 GTC Berlin 发布的那一层，它不替代运行时，而是把运行时放进一整套硬件与软件的组合里：Vera Rubin 基础设施、Vera CPU、开源 OpenShell 软件、BlueField-4 DPU 与 Sentry 安全框架，并延伸到边缘侧的 RTX Spark、DGX Spark 与 DGX Station。
| 层次 | 承担的工作 | NVIDIA 的宣称指标 | 是否开源 |
|---|---|---|---|
| Think（想） | Vera Rubin NVL72 承载闭源与开源模型推理，含 Nemotron 系列 | 智能体负载每兆瓦吞吐 30 倍 | 否，NVIDIA 产品 |
| Act（做） | Vera CPU 运行 Harness 与工具调用，外面套 OpenShell 沙箱 | x86 处理器性能的 2 倍，能效更优 | 运行时开源，CPU 为产品 |
| Govern（管） | BlueField-4 DPU 运行 Sentry（基于 DOCA），带外监控与硅内执行 | 毫秒级隔离越界智能体；智能体容量最多提升 20% | 否，NVIDIA 产品 |
| Edge（边缘） | RTX Spark、DGX Spark、DGX Station 上跑同一套设计 | 面向零售、医疗、制造、机器人、软件开发、电信 | 运行时开源，硬件为产品 |
黄仁勋在新闻稿里给出的表述是：随着企业准备部署数十亿个 AI 智能体，安全与控制必须内建进计算架构。他把智能体拆成五个部分——模型、编排其工作与记忆的 Harness、隔离 Harness 的沙箱、知识与工具，并强调因为智能体能够触达文件、网络与工具，它的权限应当是最小的且需要被监视。他还特别指出一点：每次启动一个智能体，它的权限都应该是不同的。
三层分工：想、做、管各自归位
三层分工看起来像是 marketed 出来的口号，但拆开看，它对应的是三种不同的资源瓶颈。
推理层的瓶颈是吞吐与能耗，所以放 GPU。执行层的瓶颈是通用计算与系统调用的密度——Harness 要起进程、开文件、跑脚本、做序列化，这类负载在 CPU 上的表现决定了智能体的响应速度，所以放自研 CPU。治理层的瓶颈完全不同：它需要的是「无法被绕过」，而不是快。把治理放到 DPU 上，本质是承认了在软件层做治理存在一个绕不过去的自指问题。
NVIDIA 对 BlueField-4 与 Sentry 的描述是：持续带外监控智能体行为，提供硅内安全执行；如果智能体试图越出自己的软件边界，Sentry 在毫秒内将其隔离并停止。关键在于「带外」——监控逻辑运行在 DPU 上，不在智能体所在的那台服务器的操作系统里，智能体自己的软件够不到它。
硬件层治理相对软件层治理的收益是失效模式变好了：软件层护栏与智能体共享同一信任根，攻破一个通常意味着攻破两个；硬件层的监控组件不在这个信任根里。但代价也需要说清楚——它把治理能力绑定到了特定硬件上。一个已经在 x86 加 Kubernetes 上跑了几百个智能体的团队，要享受这层能力就得换硬件，而软件层的治理方案可以渐进部署。本文据此判断：这套架构的目标客户更可能是新建 AI 工厂与云服务商，而不是存量环境改造。需要说明的是，NVIDIA 同时列出了 Canonical、SUSE、Red Hat 与 Microsoft Windows 的执行容器作为支持的操作系统层，因此它并非完全排斥存量软件栈，但治理层仍需 BlueField 硬件。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
运行时三条机制：沙箱、凭证、策略变更
真正开源、也因此真正可以被独立审查的，是运行时的三条机制。
| 机制 | 具体做法 | 解决的问题 |
|---|---|---|
| 内核级沙箱 | 每个智能体的文件与系统调用由内核机制限制；每一条网络连接在离开前都要过策略检查 | 把「能碰什么」变成内核强制的约束，而不是应用层的君子协定 |
| 凭证不落地 | 智能体永远看不到真实凭证；OpenShell 只在发往已批准端点的请求上附加凭证 | 堵住「模型把密钥写进日志或回答」这条最常见的泄露路径 |
| 策略变更先校验 | 用形式化方法标记一次策略变更会新授予哪些访问能力，例如带凭证访问一台新主机；这类变更等待人工复核 | 把权限蠕变从「改完才发现」变成「改之前就被拦下」 |
第二条值得展开。多数团队处理凭证的方式是把密钥放进环境变量或配置文件，然后祈祷模型不要把它打印出来。OpenShell 的做法是把凭证从智能体的可见世界里拿走，改由网关在判定目标端点已批准之后再附上。这样即使智能体被提示注入诱导，它也没有一个「密钥」可以交出去。这个设计和零信任里的令牌代理思路一脉相承，差别是它被下沉到了智能体运行时而不是 API 网关。
工程取舍：为什么形式化校验放在策略变更上
第三条机制里藏着一个容易被忽略的工程判断：形式化校验是一个昂贵的操作，而它没有被放在每次动作的执行路径上，只被放在策略变更上。
这个取舍是合理的。智能体每秒可能发起几十次工具调用，如果每次都要跑一遍形式化证明，延迟会直接吃掉吞吐量；而策略变更是低频事件，一天可能只有几次，值得为它付出几秒甚至几分钟的验证时间。换句话说，设计者把昂贵的正确性检查放在了低频高影响的环节，把高频环节留给便宜的查表式策略匹配。
这套分层对不打算买任何 NVIDIA 硬件的团队同样有参考价值。常见的错误做法是要么完全不做权限校验，要么给每一次工具调用都套上完整的审查流程，后者会把智能体的响应速度拖到不可用。可操作的做法是把检查分成三档：高频动作只做策略查表；中频的资源访问做凭证代理与端点白名单；低频的权限与策略变更走人工复核加自动化差异分析。OpenShell 把第二档和第三档做进了运行时，第三档还加了形式化方法，这是它的增量，但分层的骨架是通用的。
生态名单：谁在集成，谁只是被点名
参考架构这种发布形式，生态名单本身就是产品的一部分。NVIDIA 列出的名单很长，但名单里的位置并不等价，需要按「已经做了什么」而不是「被提到」来读。
| 类别 | 名单 | 被描述的动作 |
|---|---|---|
| 操作系统与云 | Canonical、SUSE、Red Hat、Microsoft Windows 经 Microsoft Execution Containers；AWS、Google Cloud、Azure | 架构可运行在其上 |
| 模型厂商 | Anthropic、Cohere、Google、Meta、OpenAI、Perplexity、Reflection、SpaceX Super Intelligence | 企业可在 OpenShell 基础设施上运行其智能体 |
| 安全厂商 | 1Password、Check Point、CrowdStrike、Cisco、F5、Fortinet、Microsoft、Okta、Palo Alto Networks、TrendAI、Zscaler | 正在把支持集成进各自的智能体安全方案 |
| 企业软件 | Cadence、Dassault Systèmes、IBM、SAP、Siemens、Synopsys、Palantir | 用 OpenShell 构建智能体软件平台；SAP 具体接入 Joule Studio 运行时 |
| 服务器厂商 | Dell Technologies、Cisco、HPE、Lenovo、Supermicro | 构建基于该架构的基础设施 |
| 云服务商 | CoreWeave、Crusoe、Firebird、Firmus、GMI Cloud、IREN、Lambda、Nebius、Nscale、Oracle Cloud Infrastructure、Vultr | 部署 OpenShell 就绪的基础设施 |
| 推理与后训练服务 | Baseten、Deepinfra、Fireworks、Together AI | 把该架构集成进模型开发流水线 |
| 银行 | BBVA、Santander | 正在探索，作为强化智能体安全与治理的框架 |
其中有两个条目信息量明显高于其余。SAP 被具体描述为把该架构与 Joule Studio 运行时集成，属于有明确接入点的工程动作。ServiceNow 同日宣布 Arc 个人长时运行智能体正式可用，其动作由 ServiceNow 自己的控制塔治理、由 OpenShell 强制执行；更值得注意的是 ServiceNow 的 AI Passport 权限层，它把策略带到 OpenShell 与 Sentry，使企业能在数秒内跨软件与硬件撤销一个智能体的访问。这是少见的把软件侧策略传递到硬件侧执行的具体案例。
AI Passport 到 OpenShell 加 Sentry 这条链路的价值在于，撤销权限这个动作不再需要先找到智能体在哪台机器上、再改配置文件、再等生效，而是直接下发到硬件执行层。但本文要提醒两点：一是这条能力要求企业同时部署 ServiceNow 的权限层与 NVIDIA 的硬件栈，对绝大多数团队而言这不是一个短期可选项；二是「数秒内撤销」是新闻稿表述，没有给出测量方法与对照基准。把它当作方向性承诺而非已验证指标更稳妥。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
与三条既有路线的对照
把 OpenShell 放进坐标系里看，它和另外三条正在成型的路线并不冲突，但解决问题的层次不同。
| 路线 | 约束落在哪一层 | 典型形态 | 主要短板 |
|---|---|---|---|
| 容器与沙箱 | 操作系统与运行时 | 容器、microVM、gVisor 类隔离、文件系统只读挂载 | 与智能体共享内核信任假设，逃逸即失守 |
| 平台治理层 | 应用与编排 | AI 控制塔、网关、策略引擎、审计与身份 | 依赖于智能体主动走这条通道，绕开即失效 |
| 应用层护栏 | 提示词与工具层 | 输入过滤、输出审查、工具白名单、人在回路 | 可被提示注入绕过，且没有强制力 |
| 硬件强制（OpenShell 所在层） | DPU 与硅内 | 带外监控、硅内策略执行、凭证代理 | 需要特定硬件，存量环境改造成本高 |
本文的判断是这四层不是替代关系而是叠加关系。容器解决「别碰到邻居」，平台治理解决「谁批准了什么」，应用层护栏解决「这个具体动作合不合理」，硬件层解决「前面的都失效了怎么办」。把预算全押在任意一层都不完整，但硬件层是此前投入最少的一层，也是这次发布真正补上的位置。
开源边界与锁定边界恰好重合
这次发布有一个结构值得单独指出：开源的部分是运行时，也就是策略声明与执行逻辑；需要购买的部分是 GPU、CPU 与 DPU，也就是承载那份逻辑的硬件。
这个划分对 NVIDIA 是合理的商业设计——运行时开源能降低采纳门槛并建立标准，硬件才是收入来源。但对采用方意味着一件具体的事：你可以免费拿到并审查这套安全模型，甚至把它跑在自有硬件上做实验，但想获得「带外监控加硅内执行」这层能力，就必须进入它的硬件栈。
从 GitHub 的公开数据也能侧面看出这套组合的热度分布：截至 10 月 21 日的读数，NemoClaw（在 OpenShell 内运行 Hermes、LangChain Deep Agents、OpenClaw 等智能体的项目）约 22,787 星，OpenShell 运行时本身约 16,878 星，社区仓库约 193 星。运行时并非无人问津，但围绕它长出的是上一层的应用项目。
三条性能宣称与它们缺失的基准配置
新闻稿给出了三个量化宣称，都需要按「厂商口径、无对照基准」来读。
| 宣称 | 表述 | 本文的读数提醒 |
|---|---|---|
| 每兆瓦吞吐 30 倍 | Vera Rubin NVL72 在智能体负载上相对前代 | 未说明对照机型、负载构成与测量方法；「智能体负载」本身没有标准定义 |
| x86 性能的 2 倍 | Vera CPU 跑 Harness 与工具调用 | 未说明对照的 x86 型号、代际与测试集；Harness 负载差异极大 |
| 容量最多提升 20% | Sentry 跑在 BlueField-4 上带来的收益 | 「最多」为上限口径；未说明容量定义与基线配置 |
这三条都不应被直接用于容量规划。合理的用法是等第三方在自己的负载上重跑，或者自己在采购前做一轮概念验证，把「每兆瓦能跑多少个智能体、每个智能体多少并发工具调用」这类自己真正关心的指标测出来。NVIDIA 在新闻稿末尾也给出了标准的免责表述，指出其中许多产品与特性仍处于不同阶段，将按可用时提供。
工程清单：想用上要准备什么
如果暂时不采购硬件，本文仍建议从这套设计里取走可迁移的部分：
| 动作 | 具体做法 | 优先级 |
|---|---|---|
| 把凭证从智能体可见范围内移走 | 改为端点白名单加代理注入，日志脱敏，禁止把密钥写入上下文 | P0 |
| 给每个智能体单独的策略声明 | 按任务而非按团队授予权限，任务结束即回收 | P0 |
| 把策略变更纳入变更管理 | 任何会新授予访问能力的改动都要差异分析加人工复核 | P0 |
| 建智能体注册表 | 知道在跑多少个、各自属于谁、能碰什么，否则撤销无从谈起 | P1 |
| 分层放置检查 | 高频动作查表、中频访问做凭证代理、低频变更做完整校验 | P1 |
| 验证监控是否真的带外 | 演练一次智能体提权，看监控组件是否仍然可见并能够叫停 | P1 |
冷静判断：它改变了什么，没改变什么
它改变的是讨论的层次。在此之前，关于智能体安全的工程讨论基本停留在「用不用容器、要不要人在回路、提示词怎么过滤」这一层；OpenShell 参考架构把「约束应该跑在被约束者的控制域之外」这个命题摆到了主流议程上，并且给出了一个可采购的答案。对正在规划新建 AI 工厂的组织，这张蓝图有实打实的参考价值。
它没有改变的是两件事。其一，多数据中心的存量环境不会因为一份参考架构就换掉硬件，多数团队在可见的未来仍要在容器、网关与护栏这三层上做文章。其二，它没有解决智能体安全的另外半边——即使执行边界坚不可摧，智能体仍然可能被诱导去做一个「在权限范围内但业务上错误」的决定。边界能挡住越权，挡不住被误导，后者要靠评测、可观测性与业务侧的规则来兜。
还有一层不确定性需要摆在明面上：运行时的版本号仍是 0.1.x，发布说明与参考架构文档同步上线，Sentry 的隔离时延宣称尚无独立测试，模型厂商名单中除 ServiceNow 与 SAP 外多数未给出具体接入细节。把这次发布当作方向确认而不是能力到位，是更稳妥的读法。