智能体在 Rubin 上思考、在 Vera 上行动、在 BlueField 上被管住：英伟达把治理做进了硬件

10 月 21 日，英伟达在柏林 GTC 的主题演讲上发布了 OpenShell 参考架构。黄仁勋用一句话概括了这套东西的分工：智能体在 Rubin 上思考，在 Vera 上行动，在 BlueField 上接受治理。这句话不是修辞，而是三块硬件的职责划分。

具体来说，Vera Rubin NVL72 负责训练与推理，也就是模型「想」的部分；Vera CPU 负责运行智能体的执行框架、处理工具调用，也就是「做」的部分；BlueField-4 DPU 上跑的是英伟达的 Sentry 安全软件，负责持续监测智能体与模型之间的流量，在硬件层面执行策略，越界就隔离。

这套拆分解决的是一个很实际的问题。过去企业部署智能体，通常把推理、编排、工具执行全塞在同一台机器或同一个容器里，安全靠软件层的权限控制和日志审计。问题是，智能体本身就在那台机器上跑，它一旦拿到了执行权限，理论上有能力去碰监管它的那层软件。

把监管放到 DPU 上，是把裁判挪出了球场。DPU 有独立的处理器和内存，跟主机相互隔离，即使主机侧软件出问题，DPU 上的策略照样能执行。英伟达的说法是，智能体试图突破软件设定的运行边界时，Sentry 能在毫秒级把它隔离并停止运行。

先说清楚沙箱在智能体场景里到底防什么。它防的不是模型说错话，而是模型「做错事」——读到了不该读的文件、调用了不该调的接口、把数据发到了不该发的地址、在用户不知情的时候改了配置。这些动作都发生在工具调用阶段，也就是 Vera CPU 负责的那一段。

软件沙箱的经典难题是「同层对抗」。沙箱和被执行对象跑在同一个内核上，共享同一套系统调用，一旦出现内核漏洞或配置疏漏，逃逸就有可能发生。过去两年公开的智能体越权事件，多数不是模型主动作恶，而是权限给多了、工具描述写糊了、重试逻辑把一次误操作放大成了一串。

硬件带外监管的价值在于「不共享」。Sentry 不依赖主机上的代理，不需要在智能体进程里注入任何东西，它看的是网络流量和硬件层面的行为特征。这意味着即使智能体被诱导去关闭日志、清空审计、篡改本地策略，带外那一层依然在记录、依然能掐断。

当然，这不是万能。硬件监管能保证「越界会被发现并阻断」，不能保证「边界划得对」。边界是人划的：哪些域名可以出、哪些接口可以调、哪些文件可以读。划错了，系统会非常忠实地执行一个错误的策略——而且执行得很快。

OpenShell 的策略执行链路值得逐段看，因为它决定了「治理」到底是口号还是工程。智能体进程发起一个 TCP 或 DNS 请求，第一步不是直接连出去，而是被沙箱识别出发起程序，然后通过 Unix socket、TCP 或 vsock 组成的沙箱协议，送到可信侧的隔离后端。

隔离后端先核验进程身份——这个请求到底是哪个进程发的，是不是它声称的那个。身份对得上，才进入策略执行模块。策略执行模块逐项检查四件事：目标地址是否在白名单内、发起请求的二进制是否被允许、七层应用规则是否匹配、这次调用携带的凭证是否有效。

五项全过，连接才能到达上游服务；其余出站流量一律拒绝。这个「默认拒绝」的顺序很关键。多数企业现有的做法是「默认放行 + 黑名单」，在智能体场景里等于没设防，因为智能体试错的次数比人多得多，撞上黑名单只是时间问题。

还有一条容易被忽略的设计：策略变更需要人工审批，审批通过后由 Supervisor 重新加载策略。也就是说，智能体不能自己给自己扩权。这条约束听起来理所当然，但在实际项目里，「让智能体自己调整工具权限以便完成任务」是一个非常有诱惑力的偷懒方案。

一套治理架构能不能用，取决于它接得上多少现有的东西。英伟达公布的适配范围包括 Linux、Kubernetes，以及通过 Microsoft Execution Containers 运行的 Windows 环境；云侧覆盖 AWS、谷歌云和微软 Azure 的云操作系统；形态上还能延伸到 RTX Spark、DGX Spark、DGX Station 这类工作站与边缘设备。

参与方名单也铺得很开。模型侧有 Anthropic、OpenAI、谷歌、Meta；安全侧有 CrowdStrike、思科、微软、Palo Alto Networks；整机侧有戴尔、HPE、联想、超微。这套组合说明它想做的不是一款产品，而是一个被 OEM 和安全厂商共同承接的标准形态。

落地案例里有两个值得注意。SAP 把 OpenShell 参考架构接进 Joule Studio 运行时，意味着企业级应用里的智能体可以在同一套约束下调用业务接口；ServiceNow 同日宣布长期运行的个人智能体 Arc 正式可用，运行时约束由 OpenShell 执行，等于把「能跑几天的智能体」放进了可监管的笼子里。

HPE 的动作更直接：推出 256 颗 Vera CPU 的液冷机架，官方称可支持 22500 个沙箱，智能体相关的 CPU 性能提升 80%。这个数字背后的判断很清楚——智能体不是 GPU 负载，它大量消耗的是 CPU 密集的沙箱与工具执行。企业采购如果还按「买多少张卡」来规划，会漏掉这一整块。

同一场活动的问答环节，黄仁勋提到软件授权在英伟达业务中的占比会越来越高。他举的例子是「运行人工智能工厂里支撑智能体的全部英伟达软件」需要多少开销，但没有给出正式定价，也没有说明时间表。

英伟达目前的卖法是按每块 GPU 销售 AI Enterprise 软件套件，授权指南里列了两种：一年订阅含支持，以及五年期。公司没有说明问答里那个例子是否对应同一套软件、是否只覆盖范围更窄的智能体组件，也没有说这是不是一种未来的授权模式。因此这个信息不能被解读为降价，也不能被解读为涨价，只能被解读为一个方向。

方向本身值得采购部门留意。硬件是一次性支出，软件是经常性支出，治理能力如果被绑进软件授权，那么「智能体规模扩大」会直接变成「授权成本线性上升」。这和过去买服务器、买虚拟化授权的逻辑是一样的，只是计费单位从「颗 CPU」变成了「块 GPU」或者「个沙箱」。

所以做预算时最好把三笔钱分开列：算力硬件（一次性 + 折旧）、运行时与治理软件（按年订阅）、以及集成与运维人力（通常被低估）。把三笔混成一笔「AI 项目预算」，后面很难解释为什么第一年便宜、第二年变贵。

很多企业把智能体当成「更聪明的自动化」，交给 IT 或数字化部门推进，业务部门只在验收时出现。这套流程在 RPA 时代勉强能用，在智能体时代会出问题，因为智能体的权限边界本质上是业务边界。

举个具体的例子。一个负责对账的智能体，需要读银行流水、读订单、写差异表、发通知。这四件事对应四个系统、四种权限、四条数据边界。谁来定「它可以读哪几个账户」「它可以给谁发通知」「差异超过多少必须人工确认」？这些不是技术参数，是业务规则。技术团队只能把它们翻译成策略，不能替业务决定。

治理架构带来的一个好处是，它把这些规则变成了可配置、可审计、可回滚的对象。策略是显式的，写在配置里，变更有审批，执行有日志。这比过去「把权限开大一点，先跑起来」的做法要慢，但它让「谁批准的」这个问题有答案。

另一个变化在审计侧。过去审计问的是「谁在什么时间做了什么」，现在要多问一层「是哪个智能体、依据哪条策略、由谁授权做的」。如果企业现有的日志体系只记录人的账号，不记录智能体身份与策略版本，那么出事之后能还原的故事是残缺的。

如果你正在评估智能体平台或者一体机方案，下面五个问题比「支持多少并发」更能筛掉不合格的供应商。它们不需要技术背景，但每一个都对应一条真实的架构能力。

第一，能不能看到智能体每一步做了什么，包括它调用了哪个工具、传了什么参数、拿到什么返回？如果只能看到最终结果，出问题时你无法定位是模型判断错、工具返回错，还是策略放行错。

第二，出站白名单谁批、怎么改、改完多久生效？如果改一条策略需要提工单等两周，业务会绕开它；如果能由智能体自己改，那等于没有策略。

第三，越界之后多久停、停了之后谁收到通知？「毫秒级隔离」是能力，「五分钟内有人知道」是流程，两者缺一不可。

第四，策略变更留不留痕、能不能回滚到上一个版本？这条决定了事故复盘时你能不能证明「当时是这么配的」。

第五，换掉这家供应商，智能体、策略、日志能不能带走？治理数据如果被锁在厂商的私有格式里，迁移成本会高到让你不敢换。

英伟达自己的表述是「参考架构」，不是「成品」。参考架构的意思是，它给出了硬件组合、软件栈和接口规范，但企业要自己把它组装成可用系统，中间还有集成、调优、运维一大堆活。把它当成开箱即用的安全产品，大概率会失望。

硬件带外监管也有边界。它管得住网络出口和进程行为，管不住「策略本身写错了」，也管不住「业务规则本身有问题」。一个被允许访问客户数据库的智能体，只要在授权范围内操作，监管层不会拦它——它拦的是越界，不是错误。

还有一个现实约束：国内企业能不能用、怎么用，取决于供应链与合规要求。参考架构里涉及的芯片、DPU、云平台，在国内落地的路径和海外不同；数据出境、等保、密评这些要求，也不会因为用了带外监管就自动满足。

所以更合理的定位是：它提供了一套「把治理做成基础设施」的思路和参考实现。你可以不用它的硬件，但值得借用它的分层——推理、执行、监管分开，监管不与被监管对象共享信任根。这个思路用在国内的零信任网关、堡垒机、沙箱方案上，同样成立。