谷歌云为每个Agent提供独立微虚拟机

Google Cloud 想把 AI agent 的执行环境做成一项独立计算服务：每个会话分配一台硬件隔离的 microVM，空闲时保存状态、释放活跃资源，访问外部服务则由网关代办凭证。

这项服务叫 Agent Compute Engine（ACE）。它值得程序员关注的地方，是把执行不可信代码、管理授权和降低等待成本放进了同一套设计。不过，原文最亮眼的性能数字来自开源的 Agent Substrate，不能直接算到 ACE 头上。

为什么 agent 有 root，仍然拿不到后端凭证

按原文介绍，ACE 已用于 Gemini、Antigravity，以及 Google 内部的评估和强化学习流水线。Google 在 AGNTCon + MCPCon 公布了它，客户预览目标是未来几个月，具体日期没有披露。

它先把 agent 拆成两部分：harness 是调用模型、安排任务的「脑」，sandbox 是运行代码、shell 命令和浏览器的「手」。harness 完全在沙箱外，只向里面下发明确命令。

每个会话独占一台 microVM，拥有自己的 guest kernel、root 权限和 Hyperdisk。隔离边界由 Cloud Hypervisor 提供。宿主机是无状态设备，根文件系统通过 dm-verity 强制只读；底层使用 Titan silicon 和 Titanium IPU，Titanium 将证明密钥保存在 guest 外。

更关键的是网络。microVM 没有标准网络接口，没有默认网关，也不能直接访问 VPC。流量必须经过 virtio-vsock、本地代理，再到外部网关。沙箱只持有会话级 SPIFFE 证书和短期身份令牌；Agent Gateway 检查策略后，才在请求途中换入真实的后端凭证。

它的安全前提，是默认攻击者已经控制了沙箱里的全部内容。

这里的「零凭证」需要读细一点：沙箱并非没有任何身份材料，而是没有可直接使用的后端凭证。原文称，工作负载身份即使被窃取，也不能直接调用目标 API，只能标识流量来自哪个沙箱。

授权还被拆成四类身份：

• User identity 只认证整体任务。
• Delegated on-behalf-of identity 表示限定范围的委托授权，保存在中央授权服务，节点不持有。
• Agent Workload Identity 是短期 SPIFFE 身份，用于沙箱流量。
• Agent Workforce Identity 是 agent 自己的账号及资源身份。

这样做的价值，是把「谁发起任务」「允许代办什么」「哪个沙箱发出请求」分开处理。拿到执行权限，不会自动等于拿到业务系统的长期访问权。

agent 大部分时间在等，为什么还要一直占着机器

Google 团队的观察是，agent 经常等待模型返回或用户输入。持续给每个会话保留 CPU 和内存，会为这些等待付出成本。

ACE 的处理方式是：工具调用结束后，沙箱主动发出信号，宿主机将空闲 microVM 做检查点保存，降到零活跃资源；下一次调用到来时，从快照恢复。

「零活跃资源」不等于总成本为零。状态还要保存，持久工作区还要存储，而 ACE 没有公开定价，暂时算不出完整账单。

它还用写时复制（copy-on-write）提高密度。预热快照通过 DAX 映射，同一宿主机上的 microVM 共享基础操作系统和库的内存页，只有各自修改过的页面需要私有内存。可以把它理解为：大家先共用同一份底稿，改到哪里，才为哪里单独留一份。

存储则分为可丢弃的临时覆盖层、共享只读卷，以及基于 Hyperdisk 的持久用户工作区。harness 还可以使用克隆、快照与分叉、回退和回滚能力。

这些机制适合有长时间等待、又需要保留执行现场的任务。但 ACE 的启动时间、恢复时间和宿主机密度都未公布。现在能确认的是设计方向，不能据此判断每次工具调用会多出多少延迟。

那组 20 万 agent 的数据，到底属于谁

原文的性能数据来自 Agent Substrate。它是开源、面向 Kubernetes 的对应方案，可运行在任意 Kubernetes 集群上，提供 Cloud Hypervisor microVM 或 gVisor 沙箱。

据原文，它自 2026 年 9 月 15 日起在 GKE 提供，Google 报告的数据包括：

• 相比传统计算，计算密度最高提高到 10 倍。
• 在 200,000 个 agent 的基准中，达到每秒 500 次激活，挂起与恢复低于 500 ms。
• 每台宿主机可以容纳超过 1,000 个休眠 agent。

这些是 Google 报告的 Agent Substrate 成绩，不是 ACE 已公开的性能承诺。

原文没有交代「传统计算」的具体基线，也没有展开硬件配置、负载构成和延迟分布。数字有参考价值，但还不足以推算普通团队的容量与成本。

Agent Substrate 可配合 Claude Code、OpenClaw 和 Hermes。所有 GKE 客户可以用于非生产用途，生产 GA 仍需进入允许名单；其持久存储选项包括 Filestore agent volumes。

Google 同时把治理能力扩展到 Agent Runtime、Cloud Run、Agent Sandboxes、GKE 和 ACE，组合包括 Agent Gateway、Agent Registry、Agent Identity，以及基于 OpenTelemetry 的可观测能力。

这些能力分阶段交付：基于 Envoy 的多云与混合环境执行点、托管设备上的 Claude Code 和 Antigravity CLI 治理，均计划近期预览；令牌管理、模型路由、Service Extensions 绑定、Cloud Run 的 Express Link，以及与 Ping Identity、SailPoint、Saviynt 的委托授权，计划在原文所说的本季度预览。它们仍是发布计划，不能当作全部已经可用。

我的判断

我认可它把执行隔离和凭证隔离一起考虑。对能运行 shell、打开浏览器的 agent，只加一道进程边界不够；让真实凭证留在沙箱外，能减少提示注入成功后的直接窃密机会。

但网关仍要判断请求是否被授权。凭证拿不走，并不自动保证 agent 不会在已有权限内做错事。原文没有给出策略误放行、提示注入防护效果或故障恢复的对照数据，安全收益需要结合具体授权规则评估。

替代方案也各有取舍。原文列出的 AWS AgentCore Runtime 使用每会话独立 microVM，microVM 会话上限为 8 小时，Instances 为 14 天；Azure dynamic sessions 使用 Hyper-V 沙箱，从预热池毫秒级分配，列出 38 个区域，冷却后销毁；E2B 使用 Firecracker microVM，暂停保存文件系统和内存，恢复约 1 秒。

这些指标口径不同：预热分配、暂停恢复和完整启动不是同一件事。ACE 尚未公开价格、启动时间、密度和确切预览日期，现在无法据此选出性价比赢家。Google 对等待模式的观察值得借鉴，收益多大仍需用自己的任务验证。

能拿来做什么

• 如果你正在做会运行代码或 shell 的 AI 编程工具，可以先拆开 harness 和执行沙箱，让模型编排留在外部，通过明确命令控制沙箱。
• 检查现有沙箱是否保存了业务 API key 或长期令牌；需要代用户访问服务时，可以参考中央授权、短期身份和网关代注入凭证的分工。
• 对执行环境持续占用资源的任务，先统计等待模型、等待用户和实际运行工具的时间，再评估快照恢复是否划算，同时记录恢复延迟和存储成本。
• 已经使用 Kubernetes 或 GKE 的团队，可以按 Agent Substrate 的非生产开放范围做验证，用真实任务测恢复、工作区持久化和授权链路，再考虑生产接入。