Agent Compute Engine：代理的「计算机」抬到硬件隔离 microVM

代理要的不只是更大的上下文窗口，而是一台能开机、暂停、带浏览器和工具、并且尽可能不把密钥漏进沙箱的计算机。2026 年 10 月 22 日，Google Cloud 在 AGNTCon + MCPCon 上把这件事产品化：Agent Compute Engine（目的计算服务，即将 preview，未 GA），以及开源的 Agent Substrate（跑在 GKE 上）。叙事主语是 Gemini 代理工作负载的基础设施经验；卖点里最硬的一句，是凭据在 microVM 外注入。

TL;DR：据 Google Cloud 博文（10-22），ACE 为 Gemini 代理自建的硬件隔离运行时：Titanium IPU、Cloud Hypervisor、每代理自有 guest kernel/root、短时凭据、service credentials 在 egress 侧于 microVM 外注入；idle 时 checkpoint/restore；每 VM 自有 Hyperdisk。Agent Substrate（开源，GKE）：自称可达约 10× 密度；20 万代理基准下约 500 激活/秒、suspend/resume <500ms；可选 microVM 或 gVisor。治理面扩展 Agent Gateway / Registry / SPIFFE 身份 / OTel，覆盖 ACE、Cloud Run 等，并预告本地 Claude Code / Antigravity 治理。判断点在隔离与凭据拓扑，而非又一次「我们有沙箱」营销。

一、从容器叙事到「每代理一台机」

博文把动机写得很直接：从单轮提示转到交互代理之后，执行与控制都变成基础设施问题；传统计算原语不适合「高频启动—工具调用—思考—暂停」的 churn。ACE 的回答是 microVM：快速启动，用 copy-on-write 共享模板以提高密度，在工具调用结束、进入「思考」或等人时把 microVM 检到 idle，再从快照恢复。

安全段落点名 Titanium（Google 的 IPU 卸载）与 Cloud Hypervisor 硬件边界：每只 microVM 自带 guest kernel 与 root；代理身份短时；每只 microVM 还有密码学可验证 ID；与 Agent Gateway 集成做策略与可观测。持久化靠每 VM 的 Hyperdisk，把工作区与上下文留在会话之间。企业数据「用不搬迁」的说法，绑定的是同一套云身份与审计模型——宣传语气浓，但结构上说的是：沙箱内外的身份不要两套互相打架的故事。

同日开源的 Agent Substrate 把类似设计放到 Kubernetes：闲置时快照内存、机器回池；安全默认写 zero-trust，egress 代理在代理够不着的地方注入凭据；可选 microVM 或 gVisor。基准数字（200k agents、500 activations/s、<500ms suspend/resume、约 10× 密度）全部是厂商自测，正文只作「他们如何量化代理密度」的引用，不外推你的集群也能同样。

Nous Research 等客户引言强调的是：多租户代理进既有客户基础设施时，隔离与可扩展访问控制若能沉到平台层，应用侧就少造一套。这与「模型公司卖权重」是不同交付物——这里卖的是代理怎么被关进可计费、可暂停、可审计的盒子。

二、凭据在沙箱外：一句硬判断

多数沙箱营销停在「不信任的代码跑在隔离里」。ACE / Substrate 反复写的那句更窄：凭证注入发生在 egress、在 microVM 外。含义是：就算代理在 guest 里拿到 root、就算提示注入让它「想」偷密钥，设计目标仍是让长期密钥根本不进可被模型直接读的地址空间。短时凭据、SPIFFE 身份、Gateway 策略，是同一拓扑的配套零件。

这和站内两条线对得上：

OpenAI 前沿训练断网与代理红队：训练侧 microVM 逃逸链、残留出口服务、侧信道——说明「隔离」在能力足够的红队面前是工程问题，不是开关；
Apple 收紧 Full Disk Access、本站谈过的本机代理权限：操作系统与云厂商同时在收「代理默认可碰什么」。

产品侧把硬件隔离做成计费 SKU，训练侧把逃逸写进 safety case——两边用的词都是 microVM，约束不同。读者要问的不是「Google 有没有沙箱」，而是：密钥生命周期是否真的不经过 guest、idle 快照里留下什么、Gateway 策略失败时默认拒绝还是默认放行。preview 未 GA，这些问题应以正式文档与第三方测评为准，本文只标出设计宣称。

flowchart LR
  subgraph guest [microVM guest]
    A[Agent + 工具 + 浏览器]
    B[短时身份]
  end
  subgraph host [宿主机 / egress]
    C[凭据注入]
    D[Agent Gateway 策略]
  end
  A --> D
  C -.->|不进 guest| A
  D --> E[企业 API / 数据]

三、治理扩到「代理在哪跑」

博文下半截是 Gemini for business 的治理能力外延：Agent Gateway（流量与策略）、Agent Registry（已批准代理/工具/MCP/模型清单）、SPIFFE 身份、OTel 语义约定。覆盖面写到 Agent Runtime、Cloud Run、GKE、ACE（preview），并预告跨云 Envoy 策略点、以及托管设备上的 Claude Code / Antigravity 本地治理（preview soon）。季度内还预告 token/成本治理、模型路由、Service Extensions。

「代理到处跑」时，治理若只挂在某一个聊天产品上，必然漏掉 Cloud Run 上的工人代理与笔记本上的编码代理。Google 的动作是承认运行时多样性，试图用同一套身份与策略语法去罩。L’Oréal 等客户引言强调的是：开发者要快，控制面要清楚每个代理能碰什么——经典平台叙事，放在 2026 年的新意在于对象从微服务换成了非确定性的代理会话。

preview 阶段还有一层采购语言要拆开：「powers Gemini as an agent for work tasks」说明 Google 已在自有代理流量上跑这套栈，不等于客户明天就能在控制台勾选 ACE。Interest form、技术深潜另文、Substrate 开源仓库，是三条不同成熟度的入口——开源基板可先试密度与快照，硬件隔离 SKU 仍要以正式配额与 SLA 为准。对安全团队，checklist 可以更短：guest 是否真有独立内核、长期密钥是否可证永不进 guest 内存与快照、idle restore 后身份是否轮换、Gateway 默认 deny 还是默认 allow、以及本地编码代理纳入治理时，OS 级沙箱失败是否会静默降级。把这些写成验收项，比争论「microVM 是否比 gVisor 更安全」更接近事故半径。

四、收束

密度数字容易盖过失败模式。checkpoint 之后，磁盘上是否残留工具缓存与临时令牌、恢复后是否重跑认证、多代理共享模板时侧信道是否在威胁模型里，这些才是「硬件隔离」四个字后面的作业。Google 同时推 ACE 与开源 Substrate，等于承认客户分层：有人要托管 SKU，有人要在自有 GKE 上复现同一套暂停/恢复语义。对读 Mythos5：评测开网出了事，产品侧却在卖「代理可以一直开着」——两边都真实，合成结论只能是：常驻代理的成本必须同时算隔离工程与对齐失败，而不是只算 GPU 利用率。

三句。第一，代理基础设施正在从「容器里跑脚本」变成「每代理一台可暂停的硬件隔离计算机」——密度与 idle 经济学是定价语言，隔离与身份是安全语言。第二，「凭据不进沙箱」是可核对的设计主张，也是唯一值得从营销稿里抠出来的硬判断；是否兑现看 preview/GA 文档与红队。第三，治理必须跟着运行时走——Gateway/Registry/SPIFFE 若只服务 Gemini 聊天框，挡不住影子代理；扩到 GKE、Cloud Run、本地 CLI，才是在承认舰队已经散开。

对读 PHP2Shell 与 Mythos5：一边是能力压低利用门槛，一边是评测开网导致供应链社工；ACE 代表的第三条线是——若代理必须跑，就把它关进更贵、更可观测、密钥更难偷的盒子。盒子不是对齐，但它决定事故半径。preview 阶段最诚实的读法是：把架构图收进采购清单，把「即将」收进日历，把「已全面可用」从标题里删掉。

另一条容易被忽略的产品细节是：治理扩展把本地 Claude Code / Antigravity 也写进「即将 preview」。这意味着云厂商承认编码代理正在个人设备上形成第二舰队——只守住 Cloud Run 与 GKE，挡不住笔记本里的影子自动化。OS 级沙箱与本地治理服务若做成可静默关闭的选项，企业策略会再次裂成「云上严格、端上放行」。ACE 的硬件故事再漂亮，也补不齐端点策略缺口；两者必须分开验收。

一句话总结采购立场：把 ACE 当「隔离承诺的预览」，把 Substrate 当「可复现的密度实验」，把 Gateway 扩展当「策略覆盖的路线图」——三件不要捆成同一张已交付工单。