一个不到一秒的失效场景

F5在介绍OpenShell参考架构时描述了一个具体情形：AI工厂中的一个智能体检索到一份文档，文档里藏着一条用户从未授权的指令。智能体照做了，通过模型上下文协议调用工具，把一条本不该外发的记录发送到了未经批准的位置。本应拦截这一行为的防护机制，是部署在同一容器中的sidecar，智能体先把它关掉了。日志由智能体控制，所以这件事从未被记录。

这个场景的关键不在“智能体被攻击”，而在于控制措施和智能体处在同一个信任域里。只要监管组件和智能体共享同一个可以相互操作的边界，智能体就有能力禁用、绕过或篡改它。F5的结论很直接：智能体无法监管自己。

英伟达技术博客给出了同一判断的另一版本：安全与治理必须属于智能体运行所在的基础设施，而不是交给智能体自身。

OpenShell要解决的就是这个“监管者在哪里”的问题。

四个组件，把决策权放在沙箱外面

OpenShell在软件层的设计围绕四个组件展开，每一个都指向同一个原则：权限的执行者不能是被执行的对象。

Gateway是控制平面，管理沙箱的生命周期和策略的分配。Supervisor检查智能体的出站请求是否符合策略，并独立保管和中介凭据的访问——它完全运行在沙箱之外，智能体进程无法直接触达。Sandbox用内核级隔离（基于Landlock LSM）限制智能体可以读写的文件路径、可以到达的网络端点以及所持有的权限，声明式YAML策略把这些边界写成可审计的规则。Policy Prover则做一层形式化验证，检查策略授予的权限是否始终落在组织设定的上限之内。

这四个组件的共同逻辑是：智能体的模型输出不能直接改变执行器的行为。策略在智能体进程之外执行，Supervisor的中间件还可以检查、阻断或修改智能体通过网络发送和接收的内容，Gateway拦截器允许运营方在不修改网关的情况下加入部署特定的治理逻辑。软件层建立的边界不依赖智能体的配合。

当软件边界不够时，BlueField-4接管

软件层的隔离有一个固有的前提：它信任主机操作系统和运行环境。如果智能体突破了软件边界，或者主机本身被攻破，沙箱的约束就可能失效。OpenShell参考架构对此的处理是把监控和执行再往外推一层，推到智能体无法访问的独立硬件域。

BlueField-4 DPU在参考架构中位于Vera CPU上运行的智能体与Vera Rubin上运行的模型之间的I/O路径上。运行在其上的NVIDIA Sentry基于DOCA构建，持续观察请求与响应、网络与文件活动，验证身份与委托权限，并分析部分主机内存以检测偏离授权行为的情况，而不依赖智能体的自我报告。一旦检测到威胁或策略违规，BlueField-4在芯片层执行策略，Sentry可以在毫秒内隔离智能体。

Sentry被定位为可选的硬件保障层，而非所有部署的必备条件。但对于那些智能体接触敏感企业数据、且软件边界可能被突破的场景，这一层把“监管者”放到了一个智能体在物理上无法触及的位置。黄仁勋在演讲中的概括是：智能体在Rubin上思考，在Vera上行动，在BlueField上受到治理。

性能不是免费的，但也不是唯一的代价

把治理外置并推到硬件层，会引入新的开销。OpenShell参考架构对性能问题的回答集中在Vera CPU上。Vera配备88个Olympus核心，第二代Scalable Coherency Fabric提供最高3倍的核心间带宽和最高低50%的核心间延迟，LPDDR5X内存带宽达到1.2TB/s，PCIe Gen 6提供96条通道。

CoreWeave的实测数据提供了具体的参照：在Vera上，智能体沙箱的启动速度比x86 CPU快3倍以上，智能体循环（Terminal Bench）的完成速度快1.8倍，单机架可以支撑超过11000个并发智能体环境。每瓦性能是x86的2倍，LPDDR5X内存子系统的功耗比DDR5方案低一个数量级。

这些数字来自CoreWeave与英伟达的联合测试，测试对象是沙箱启动和智能体循环这两类具体工作负载。它们说明的是：在Vera上运行OpenShell的治理层，不会因为隔离和策略检查而牺牲智能体基础设施的密度。

但它们不直接回答另一个问题——当Sentry在BlueField-4上持续分析内存和网络活动时，端到端的推理延迟会受到多大影响。这一层的开销在目前的公开材料中没有独立的量化数据。

谁已经在用，用在了哪里

OpenShell的开源运行时（Apache 2.0）于2026年9月底先行发布，参考架构在10月21日GTC柏林大会上正式推出，现已可用。参考架构可以运行在Canonical、Red Hat、SUSE的Linux和Kubernetes上，也可以通过Microsoft Execution Containers运行在Windows上；云端覆盖AWS、Google Cloud和Azure。

合作伙伴的覆盖范围横跨模型提供方、安全厂商和基础设施制造商。模型侧包括Anthropic、OpenAI、Meta、Google、Cohere、Perplexity等；安全侧包括CrowdStrike、Palo Alto Networks、Check Point、Fortinet、Okta、Zscaler等；系统制造商包括Dell、Cisco、HPE、Lenovo和Supermicro。

更具体的部署信号来自企业软件层。SAP正在将OpenShell集成到Joule Studio运行时中；ServiceNow已将长期运行的个人智能体Arc正式上线，其操作通过OpenShell执行约束。Anthropic自9月起将Claude Managed Agents与OpenShell配对，让企业能够限制Claude智能体的行为并记录每一项操作。BBVA和Santander被描述为正在探索这一架构在智能体安全与治理方面的应用。

这些部署的成熟度并不相同：SAP和ServiceNow是产品级集成，Anthropic是服务层面的配对，银行则处于探索阶段。但它们共同指向一个方向：OpenShell试图占据的位置不是又一个安全插件，而是智能体基础设施中“谁有权决定智能体能做什么”的那一层。

治理外置的架构含义

OpenShell的核心主张可以压缩成一句话：智能体的权限判断，必须由智能体无法触及的机制做出。软件层的四组件把这个判断放在沙箱之外，硬件层的Sentry把它放在主机操作系统之外。两层叠加，形成了一个从内核策略到芯片执行的连续边界。

这套设计的代价是引入了额外的组件和硬件依赖。收益是一个可审计、可验证的治理结构：每一个出站请求都经过沙箱外的检查，每一次策略违规都有独立于智能体的监控记录，每一个越界行为都可以在毫秒级被遏制。

对于正在把智能体从演示推进到生产环境的企业而言，这个交换是否值得，取决于智能体被允许触碰的东西有多重要。当答案涉及客户数据、财务系统或物理设备时，把监管者放在智能体够不到的地方，就不再是一个架构偏好，而是一个前置条件。

（素材来自：英伟达 智算芯能前沿网综合）

本文由智算芯能前沿网编辑整理，转载请注明出处。