11 月 10 日，盐湖城，KubeCon 北美站。英伟达把 OpenShell 捐给了 CNCF 沙箱——一个给智能体用的隔离运行时，Apache 2.0 许可。五天前，谷歌把三个项目一起捐了：Agent Substrate、gVisor、OpenRL。
四件东西，没有一件是模型。三件是笼子，一件是训练场——都不生产智能，只管智能在哪跑、能碰什么。
谷歌云负责 AI 智能体与基础设施的产品经理 Brandon Royal 在台上讲得很直：任何智能体都需要被完全隔离，不管是访问工具、操作电脑还是开浏览器，「没有例外」。他把这件事讲成了一个账单问题——智能体 90% 到 95% 的时间什么都不干，在等模型回话，或者在等人点那一下批准。等的时候占着的 CPU 和内存，都是钱。
把这两件事放在一起，能看出企业 AI 今年真正换的那块地基：治理的落点，从应用里的一个审批按钮，挪到了集群里的一个沙箱。
一、一周两笔捐赠，笼子成了公共设施
谷歌的三个项目是 11 月 5 日宣布捐给 CNCF 沙箱的，一个月前已被接纳。Agent Substrate 的 1.0 版本已经在 GKE 上正式可用，谷歌自家的 Gemini Managed Agents 就跑在它上面。
英伟达的 OpenShell 晚五天，11 月 10 日在 KubeCon 现场宣布。它做的是内核隔离沙箱，策略用声明式 YAML 写，管文件系统、网络、进程和模型供应商凭据四类访问；凭据只在发往已批准端点的请求里注入；策略变更在批准之前，先跑一遍形式化验证，看会不会给出高风险的新权限。
英伟达给的口径是：数百家组织用过，不到一年收到数万条贡献。项目正在迁往 ai-openshell 组织，迁移期间代码和 issue 还留在 NVIDIA 名下。
| 项目 | 捐赠方与时间 | 许可 | 解决什么 | 当前状态 |
|---|---|---|---|---|
| Agent Substrate | Google，11-05 | 开源 | 有状态运行时：会话与算力解耦 | 1.0 已在 GKE GA |
| gVisor | Google，11-05 | 开源 | 用户态内核沙箱 | 已入 CNCF 沙箱 |
| OpenRL | Google，11-05 | 开源 | 在 K8s 上做强化学习后训练 | 2 月起预览 |
| OpenShell | NVIDIA，11-10 | Apache 2.0 | 内核隔离＋策略＋凭据控制 | 迁往 ai-openshell |
这两笔捐赠的共同点，是把「智能体怎么被关住」从一家公司的产品特性，变成了基金会托管的公共件。对采购的意义很直接：过去你只能在 ERP 的审批流里加一道「确认」，现在你可以要求供应商说明它的智能体跑在哪个运行时、隔离做到哪一层、策略谁改。
二、95% 的时间在等，等的就是钱
传统容器的假设是「开机就一直干活」。为网站后台设计的调度器，碰到智能体这种负载会很难受：它可能只花半秒执行一条命令，接下来九成以上的时间在等模型回话、等人批准、等下一个工具返回，而手里还攥着改了一半的状态，不能随便关。
不关，资源就一直占着；关，状态就丢，下次要重来。多数团队的做法是留余量，余量就是账单。
Agent Substrate 的解法不复杂：把「智能体会话」和「干活的计算」拆开。集群里维持一小池热的工作节点，智能体空闲时，把它连同内存和文件系统状态快照出去、落盘、释放节点；需要继续时再恢复回来。
空闲会话恢复时间（Google 自述，GKE 生产环境）；同一套机制下容器密度提升 10 倍
这里有个容易被忽略的因果：隔离做得越彻底，冷启动越贵；冷启动越贵，越没人敢做隔离。所以「隔离」和「账单」从来不是两个问题，是同一个架构决定的两面。谷歌云近期还推出了 Agent Compute Engine，把智能体托管单独做成一个产品位——这说明智能体正在被当成一种新的工作负载类型，而不是「带了个 API 的应用」。
三、凭据不进沙箱：四层防线，四个问题
谷歌的高级工程师 Benjamin Elder 讲得更具体：所有流量都经过一个执行策略、识别身份的网络层，智能体碰不到任何没有被明确授权的东西；凭据不给沙箱，「不要把凭据暴露给沙箱，不要让智能体碰到凭据」，要做决定就在沙箱外面做，凭据在链路上注入。
这句话值得抄下来贴在架构评审的墙上。提示注入之所以危险，不是因为模型会「被骗」，而是因为被骗之后它手里有凭据、有网络、有写权限。把凭据从沙箱里拿走，攻击面就从「一把能开门的钥匙」降级成「一个只能在指定门缝里递东西的窗口」。
| 防线 | 这道防线防什么 | 这批项目怎么做 | CIO 要问供应商什么 |
|---|---|---|---|
| 身份 | 谁在调用 | 网络层识别身份、执行策略 | 智能体有没有独立身份，能不能被单独停用 |
| 凭据 | 密钥被读走、被带出 | 凭据不进沙箱，在链路注入 | 它能拿到哪些凭据，注入点在哪，谁能改 |
| 策略 | 越权动作、策略被悄悄放宽 | 声明式 YAML，变更前形式化验证 | 谁能改策略，改完谁批，有没有验证记录 |
| 会话 | 状态残留、跨环境漂移 | 空闲快照落盘，按需恢复 | 会话存在哪、存多久、跨不跨境、怎么清除 |
为什么要强调「变更前验证」？因为智能体给自己做的检查基本不管用。「开源之道」11 月 5 日的日刊引用过两项研究，里面有两个数字：让智能体预判自己引入的缺陷，漏网率在 6.13% 到 24.53% 之间；让它判断自己是否做对，正确率只有 53%。该日刊的结论很克制——自检帮助很小，核验的价值来自「不是它自己」。
别把预览当可用。OpenRL 今年 2 月才进入 research preview；Agent Substrate 的 API 仍在变动，GPU 支持正在围绕 Kubernetes 动态资源分配重建，部分 Dynamo 集成还是实验状态；英伟达同期公开的 NVKE / NVKR 明确标注 public preview、不建议用于生产。用它们做架构验证可以，写进 SLA 还早。
这一段对 CIO 的意义是：你审的不是「智能体聪不聪明」，而是「策略谁能改、改完谁验证」。这和 ERP 里写操作必须人工确认是同一个问题的两个层——应用层管「这一笔要不要人点头」，运行时层管「它根本能不能碰到这个接口」。
四、为什么是捐，不是卖
谷歌给出的捐赠理由，比技术细节更值得读。gVisor 要让 I/O 接近原生 Linux，需要一串宿主机内核补丁；但在「项目由单一厂商拥有」期间，上游 Linux 维护者拒绝合并这些补丁。捐给基金会之后，蚂蚁集团、Modal、Tines 加入成为维护者。
「开源之道」在 11 月 7 日的日刊里把这件事点得很透：这不是因为「相信开放」，而是因为「所有权挡住了合并」——同一份代码，产权归属一换，协作成本就下来了。
这段话对国内做信创和开源选型的团队同样成立：一个项目挂着开源许可证，不等于它的关键能力能被生态共用。许可证解决「能不能用」，治理结构解决「能不能一起改」。
同期披露的两个性能数字也值得记一下，但要看清楚是谁测的：OpenRL 在 Harvey 的法律智能体基准（24 个执业领域）上，把 Gemma 4 的准确率从监督微调的约 50% 提到 70%；llm-d 1.0 用前缀缓存感知的路由，把 KV 缓存命中率从 35% 提到 70%，多轮智能体负载的中位首字延迟下降 70% 到 85%。两个数字都来自谷歌自家生产负载，属于厂商口径，不能直接当你的基线。
三个别搞混：开源不等于免费（运维、升级、合规验证都是钱）；预览不等于可用（API 会变）；厂商跑分不等于你的负载（你的提示词长度、工具数量、并发形态都不一样）。
给 CIO 的三条
第一，把运行时写进采购与验收清单。不要只问「支持哪些模型、能做哪些场景」，要问四件事：隔离在哪一层、凭据进不进沙箱、策略谁能改、会话状态存哪。四个问题里有一个答不上来，这套东西就还停在演示阶段。
第二，把「策略变更」当变更管理，不当配置修改。谁能改、谁批、改完怎么验证、回滚要多久——这四项进 CAB 流程。运行时策略的一次放宽，风险和 ERP 里放开一个权限组是同一量级，但它通常不会走同样的审批。
第三，用外部核验，不用自检。智能体给自己补的测试几乎不改变漏网率。真正有效的核验来自另一套权限、另一个人、另一条流水线。
回到开头那个比喻。笼子这周被开源了，材料、图纸、锁芯都摆在了台面上，谁都能拿去用。但钥匙不在图纸里——它在你的策略变更流程、你的凭据管理和你的审计日志里。
资料来源：Google Cloud Blog《Open infrastructure for autonomous agents comes to CNCF》与 Google Open Source Blog《Sandboxing untrusted AI agents at scale》（2026-11-05，含 Agent Substrate 1.0 GA on GKE、gVisor 与 OpenRL 捐赠、Gemini Managed Agents 运行其上）；CNCF 沙箱接纳（2026-10，早于捐赠公告一个月）；NVIDIA 于 KubeCon + CloudNativeCon North America（盐湖城，2026-11-09 至 12）宣布向 CNCF Sandbox 捐赠 OpenShell（2026-11-10，Apache 2.0，声明式 YAML 策略、凭据仅注入已批准端点、策略变更形式化验证、迁移至 ai-openshell）；Unite.AI《NVIDIA Donates OpenShell to CNCF and Adds Open-Source AI Factory Tools》（2026-11-10）；AI Frontier Post《Google Cloud's open AI-native Kubernetes stack》（2026-11-10，含 llm-d 1.0 与 OpenRL 基准数据）；「开源之道」日刊（2026-11-07，含捐赠动因、维护者名单与 Foresight-SWE、BOBA 数据）；KubeCon 现场发言经网易号技术报道（2026-11-11）转述。
数据口径说明：500 毫秒恢复、10 倍容器密度、KV 缓存命中率与首字延迟、Gemma 4 基准提升均为 Google 自述、在其自有生产负载测得，非第三方审计；OpenShell 的「数百家组织、数万条贡献」为 NVIDIA 自述；OpenRL 仍为 research preview，NVKE / NVKR 为 public preview 且厂商不建议生产使用。
众谛信息（Zodioo）· 企业数字化观察 · 2026-11-12
