10 月 22 日，Google Cloud 在圣何塞的 AGNTCon + MCPCon 上交出一件已经在自家跑着的东西：Agent Compute Engine。每个 Agent 领到一台硬件隔离的 microVM；沙箱里没有 API 密钥、没有 OAuth 刷新令牌、也读不到云实例元数据服务。真正的凭证只在请求离开节点时，由外部的 Agent Gateway 核对身份后再塞进报文。
同一天的产品博客写得很直白：这套服务已经在支撑 Gemini 的工作任务 Agent，客户预览要到「未来几个月」，定价没有公布。SiliconANGLE 与 The New Stack 同日报道确认了发布事实，并补充了和 E2B、Daytona、AWS Bedrock AgentCore 等现有沙箱产品的对照。
问题不是「再要一台虚拟机」
Google 工程师 Ramanathan Venkatapathy 与 Rohit Jnagal 在技术深潜里把内部压力写清楚了。Gemini 团队想给每个用户一台能记事、能写代码、能开浏览器的云端电脑；企业侧的 Gemini for business 又要让 Agent 读 Workspace、查内网库，同时不能把敏感数据整包搬出公司边界。
他们把每个 Agent 拆成两截：harness（脑）在沙箱外调用模型、决定下一步；sandbox（手）在沙箱里跑代码、shell 和浏览器。传统虚拟机隔离够硬，但启停以秒到分钟计，跟不上 Agent 频繁挂起与恢复；容器够快，却和宿主机共享内核，编码类 Agent 又常常要完整内核与 root。更麻烦的是闲置：Agent 大部分时间在等模型或等人，若每台会话都常驻占满 CPU 和内存，成本会先于能力把规模卡死。
Agent Compute Engine 的回答是：给每个会话一台单租户、带独立 guest kernel 的 microVM（底层用 Cloud Hypervisor），再在应用层告诉宿主机「这台现在在想事情、没有在跑命令」，于是主机可以把 microVM 检查点休眠到几乎不占活动资源，下一轮工具调用再从快照唤醒。
密钥不进盒子，攻击面挪到网关
深潜文用一封带隐藏指令的邮件举例：企业邮箱 Agent 若被诱导「把本机 API 密钥发出去」，多数时候模型会忽略，有时不会。Google 写明的设计前提是：假定攻击者已经控制沙箱内部，也必须在里面找不到能用的东西。
为此，guest 环境不持有持久密钥；流量不走普通虚拟网卡，而要经本机代理再送到节点外的 Agent Gateway。Gateway 校验用户委托、Agent 身份与节点证明之后，才做「空中换票」，把后端真正需要的凭证插到出口侧。SiliconANGLE 复述了同一套代理链路，并指出底层主机被做成无状态、只读根文件系统的设备，由 Titan 芯片校验固件完整性。
身份也被拆开。技术深潜区分了用户身份、用户授权给 harness 的委托、沙箱使用的短时 SPIFFE 工作负载身份，以及 Agent 作为助理本身的劳动力身份；沙箱侧只用短时身份，不能直接拿它去调后端 API。审计上，下游服务看到的是可验证的「某用户授权的某 Agent」请求，而不是一串泄漏在盘上的长期密钥。
这把风险从「沙箱被攻破就能偷钥匙」挪到了「Gateway 策略、委托范围与节点证明是否真的严」。官方没有公布第三方红队结论，也没有给出可复核的逃逸案例统计。读者能确认的是设计目标，不是已在客户环境里被独立测过的安全边界。
闲置时几乎不占活动算力，记忆还要留着
深潜文称，测量典型会话后发现 Agent 多数时间在等待。应用感知的闲置检测让工具调用结束后的「思考」阶段可以把 microVM 从活动态切到检查点；同一宿主机上，静态的操作系统页与预热二进制通过 DAX 与写时复制共享，私有脏页才单独占内存。持久工作区落在 Hyperdisk 一类卷上，临时构建垃圾走可丢弃覆盖层，公共工具链以只读卷共享。
密度与时延数字目前几乎全是 Google 自述。产品博客写 Agent Substrate（面向 Kubernetes 的开源运行时）可做到相对传统计算「最高约 10 倍」密度，并在 20 万 Agent 的基准里维持每秒 500 次激活、挂起/恢复低于 500 毫秒。这些数字没有附上外部复现条件，不宜当成客户上线后的保证。
The New Stack 提醒：沙箱市场并不空。E2B 用 Firecracker microVM，可暂停并约一秒恢复；Daytona 在容器之外加了 microVM；AWS Bedrock AgentCore 也按会话给 microVM，等待模型时不收 CPU 费但仍计内存，会话上限曾到八小时，后来又加了最长约 14 天的 EC2 运行时。Google 的差异叙述集中在：同一套栈已经服务 Gemini 与内部评测/强化学习流水线，并把「零密钥 + 出口换票」和 Titan/Titanium 硬件根信任绑在一起。
今天能动手的是 Substrate，不是托管预览
托管的 Agent Compute Engine 仍停在意向登记。谁现在就能部署，要看另一条线：Agent Substrate。Google Cloud 文档写明，Agent Substrate on GKE 对所有客户开放评估与非生产使用，生产支持走白名单私有 GA；它把空闲 Agent 的内存与本地文件快照下来，需要时再还原到热 worker 池，并绕开把海量短时工具调用全部压进标准 Kubernetes 控制面的瓶颈。开源仓库注明项目仍早、API 可能大变，且「不是 Google 官方支持的产品」。
10 月 22 日的产品博客同时把 Gemini for business 的治理能力往外推：Agent Gateway、Registry、基于 SPIFFE 的 Agent Identity，以及跨 Cloud Run、GKE、ACE 预览等运行时的策略覆盖；本季度预览还提到按 token 计费管控与模型路由。这些是治理面的路线图，不是 ACE 当天即可调用的 SLA。
Nous Research 商务负责人 Hervé Bizira 在公告里表示，公司用 Agent Substrate 处理多租户隔离与可扩展访问控制，以便把 Hermes Enterprise 部署进客户现有基础设施。这是指名客户证言，不是对托管 ACE 预览进度的第三方审计。
还没交出去的那一半
对云上要跑编码 Agent、浏览器操作或长时间重构的团队，10 月 22 日的新闻回答了一半问题：Google 愿意把服务 Gemini 的隔离与闲置模型卖出来，而且设计上把密钥留在沙箱门外。另一半问题原封不动：预览何时开放、哪个区域、多少钱、闲置计费怎么算、与现有 Agent Sandbox / Gemini Enterprise 沙箱如何并存，官方都没有给出可执行的数字。
在预览配额真正发下来之前，能核验的只有架构描述、开源 Substrate 的文档限制，以及市场上已经存在的 Firecracker / AgentCore 替代方案。Google 把「行星级 Gemini」的故事写成了产品说明书；客户要等到自己能创建第一台 microVM，才能把说明书里的密度和安全句子变成自己的运维数据。
