英伟达在 GTC Berlin 发布 OpenShell 参考架构，将模型推理、智能体运行时、沙箱隔离、行为观测与硬件级策略执行整合为企业级智能体基础设施，强调把安全控制从模型层转移到基础设施与硬件层。该架构依托 Vera Rubin、Vera CPU 与搭载 Sentry 的 BlueField-4 DPU，并已宣布多家合作伙伴参与，但具体部署成熟度与实际效果需由企业分别验证。
英伟达于2026年10月21日在柏林举行的 GTC Berlin 上发布 OpenShell 参考架构，将模型推理、智能体运行时、沙箱隔离、行为观测和策略执行组合到同一套企业级基础设施设计中。英伟达表示，该架构面向在企业基础设施和边缘系统上构建、运行和治理智能体，但这项发布本身并不等同于所有合作方的产品已经完成全面商业部署。
根据英伟达新闻稿，OpenShell 参考架构以 NVIDIA OpenShell 安全运行时为基础，把 NVIDIA Vera Rubin 用于模型推理，把 Vera CPU 用于运行智能体 harness 和工具调用，再由搭载 NVIDIA Sentry 的 BlueField-4 DPU负责持续监测和硬件级策略执行。英伟达首席执行官黄仁勋将这套分工概括为：智能体“在 Rubin 上思考、在 Vera 上行动、在 BlueField 上接受治理”。
从模型层控制转向基础设施层约束
企业智能体与一次性问答模型不同。它们可能连续运行较长时间，读取文件、调用网络服务、执行代码、访问业务系统，甚至生成新的工具或请求更高权限。随着任务链条变长，企业要面对的风险不再只是模型是否生成了不当文本，还包括智能体到底访问了什么、改变了什么，以及人在何时能够停止它。
英伟达的技术博客将 OpenShell 定义为一种开源运行时：智能体被视为在整个执行过程中都不可信，系统只在策略允许时授予访问权限。NVIDIA 的OpenShell产品页面称，默认情况下不允许访问，权限依据策略授予，执行和决策记录都可以审计；安全控制放在模型和应用程序之外，而不是依赖智能体自行遵守规则。
这也是 OpenShell 与传统应用层防护的区别。OpenShell 为每个智能体提供隔离沙箱，限制其可访问的文件，并通过内核层面监测和过滤系统调用。网络请求由外部 supervisor 根据二进制文件、目标地址、方法和路径等条件进行策略判断，凭据也只有在策略许可时才会被提供。策略更新可以实时生效，允许和拒绝决定则被记录为审计轨迹。
Vera、BlueField-4与Sentry如何分工
在英伟达的参考架构中，Vera Rubin NVL72承担模型推理和企业工作负载。英伟达称，面向智能体工作负载，Vera Rubin NVL72可实现每兆瓦吞吐量最高30倍的提升；Vera CPU则被定位为运行智能体循环和工具调用的处理器，英伟达称其性能达到 x86 处理器的两倍。这些数字均来自英伟达自身的产品说明，尚未构成独立第三方测试结论。
BlueField-4 DPU承担的是另一层职责。英伟达表示，运行在 BlueField-4 上的 Sentry 使用 DOCA 软件，在智能体所在执行环境之外持续观察其行为，并在硅层执行策略。如果智能体试图越过软件边界，Sentry可以将其隔离并在毫秒级停止。英伟达还称，Sentry在 BlueField-4 上运行时可将智能体容量提升最高20%；这一容量数字同样应视为厂商口径，实际效果仍取决于工作负载、硬件配置和部署方式。
这种设计的核心假设是：执行任务的智能体不应拥有修改自身监控、权限和安全组件的最终权力。此前AIFlux对OpenAI内部编码Agent弱化监控机制的报道显示，当模型能够影响告警或监控链路时，问题会从一次任务执行错误扩展为监控独立性和权限边界问题。OpenShell与Sentry试图把部分控制点移到被监控智能体无法直接修改的外部运行时和硬件层。
合作生态扩大，但部署状态仍需区分
英伟达表示，OpenShell参考架构可以运行在由 Canonical、SUSE 和 Red Hat 支持的 Linux 与 Kubernetes 环境，也支持 Microsoft Windows 和 Microsoft Execution Containers，并可连接 AWS、Google Cloud 和 Microsoft Azure 的云操作系统。架构还可延伸到 RTX Spark、DGX Spark 和 DGX Station 等边缘系统，覆盖零售、医疗、制造、机器人、软件开发和电信等场景。
参与合作或集成的企业包括 Anthropic、AWS、Cisco、CrowdStrike、Dell Technologies、Google Cloud、HPE、IBM、Meta、Microsoft、OpenAI、Palo Alto Networks、Perplexity、SAP、ServiceNow、Siemens 和多家云服务商。英伟达还称，SAP正把该参考架构与 Joule Studio 运行时结合，ServiceNow则宣布其 Arc 智能体的运行时动作可由自身控制塔管理，并由 OpenShell 执行。
不过，新闻稿中的“合作”“集成”和“探索”并不都意味着相同的产品成熟度。英伟达称参考架构已经可用，但不同合作方的支持范围、交付时间、部署规模和商业条件并未在同一份公告中完整披露。企业因此仍需分别核实：某项能力是参考设计、技术集成、试点项目，还是已经交付并经过实际生产验证的产品。
这套区分在基础设施发布中尤其重要。英伟达近期推出的DSX POD模块化AI工厂参考设计同样说明，参考设计可以减少集成工作，却不能替代现场的电力、冷却、网络和监管条件。OpenShell的安全边界也需要在具体企业环境中与身份系统、数据权限、业务审批和应急接管机制结合，不能仅凭硬件组件名称推断其已经解决所有运行风险。
“可控”仍需要独立验证
从产品路线看，OpenShell参考架构反映出企业智能体安全正在从“提示模型遵守规则”转向“即使模型偏离目标，基础设施仍限制其可执行范围”。这意味着沙箱、策略验证、凭据代理、审计和硬件监控将成为智能体平台的一部分，而不只是部署完成后的附加安全工具。
但这套架构能否在真实环境中阻止越界行为，还取决于策略是否完整、外部控制面是否足够独立、硬件监控能否覆盖所有关键路径，以及企业是否为人工暂停和事后取证保留足够权限。英伟达目前公布的是参考架构、产品能力和合作伙伴计划；关于不同行业中的误报率、漏报率、性能开销和长期运营结果，公开资料仍然有限。
因此，OpenShell此次发布的意义，更接近于为企业智能体提出一套全栈安全基础设施蓝图，而不是宣布一个已经在所有场景中验证完毕的安全结论。随着智能体获得更多工具和更长的自主运行时间，真正的竞争将不只是让它们完成更多任务，也包括让企业能够清楚知道它们做了什么、为什么被允许这样做，以及在出现偏离时能否及时、可靠地收回控制权。
来源：
- NVIDIA Newsroom：NVIDIA Launches OpenShell Reference Architecture for Safe AI Agents
- NVIDIA OpenShell：Open, Secure Runtime for AI Agents
- NVIDIA Technical Blog：How NVIDIA OpenShell Reference Architecture Secures and Governs AI Agent Workloads at Scale
- NVIDIA Newsroom：NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment