Google Agent Compute Engine 拆解：给每个 Agent 一台「没有钥匙」的 microVM，凭据全在出口换掉

admin@yesmiracle.net (万戈) — Wed, 04 Nov 2026 00:00:00 +0000

Google 在 10 月 22 日的 AGNTCon + MCPCon 上发布了 Agent Compute Engine，定位是一句话：每个 AI agent 会话一台硬件隔离的 microVM，容器级速度，外加沙箱里零凭据。它已经在 Google 内部跑 Gemini、Gemini platform、Antigravity 以及模型评估和强化学习管线，对外开放的 preview 在「未来几个月」。两位署名作者都是 Distinguished Engineer。

先说一件必须说清楚的事，否则这篇会变成另一篇文章的重复。「凭据不进沙箱、只在出口换回来」这个结论已经不新了。 站内 10 月 27 日那篇拆 Anthropic srt 的稿子，标题级卖点就是这个命题，正文里还专门写了「改了 HTTP_PROXY 也没用，墙在操作系统里」。如果这篇再把这个结论讲一遍，那就是逐字复用同一批结论。

所以我保留原题，但把这篇的问题换掉：Google 为了在它自己说的「行星规模」上做到零凭据，被迫额外解决了哪些别的工程问题。答案有三块，都是前面几篇没有覆盖的：身份得拆成四种、内存得压成共享物理页、闲置得变成零成本。最后还有一块是我在核对源码时挖出来的，放在第八节。

它要解决的其实是三件工程问题，安全只占其中一件

Google 自己把动机总结成三句话（deep dive 结尾），我直接引原文：

模型会犯错；犯错的时候，沙箱里不该有任何能被拿来对付它的东西。
agent 大部分时间在等待。闲着的 agent 应该几乎不花钱，而且醒来要快到人察觉不到。
agent 记得越多越有用。它的工作区应该能跨轮次、跨天、跨操作系统版本活下来。

三句话里只有第一句是安全。第二句是成本，第三句是持久化。这个配比本身就说明一件事：零凭据只是入场券，真正难的是让这台「什么钥匙都没有」的机器在行星规模上跑得便宜。

「没有钥匙」到底是怎么做到的

先讲结论再讲机制，机制里有几处是我觉得最值得抄的。

沙箱侧的网络路径：microVM 没有标准虚拟网卡、没有默认 IP 网关、也没有直接的 VPC 访问。所有进出流量走一条隔离的点对点 IPC 边界（virtio-vsock），这条边界终止在一个本地的、无特权的中介代理上，再由它转发到外部代理，最后由网关校验请求范围、执行策略化出网。

出口侧的身份来源，我在开源孪生实现的包注释里找到了最精确的一句：

Identity comes from the actor certificate presented in the mTLS handshake, never from a request header.

身份来自 mTLS 握手里呈现的证书，永远不来自请求头。这句话是整个设计的地基：如果身份可以从请求头里来，那沙箱就能伪装成别人。

凭据注入这一步比「在出口换掉」要细。开源实现里的注释写着，它只替换请求本身携带的 header：

Only a header the request carries is replaced; a request without it goes out unchanged, and its credential is not fetched.

一个没带这个 header 的请求会原样出去，凭据根本不会被取。为什么要这么设计？因为这样可以保证「取凭据」这个动作永远由放行策略触发，而不是由沙箱的任意请求触发。

接下来是一条我读到时觉得写得很狠的注释。替换时它强制覆盖 actor 自己设的同名 header：

Overwrite any header the actor set itself, so a client cannot pre-seed a value that survives injection.

覆盖 actor 自己设的值，这样客户端无法预埋一个能存活过注入的值。配上一句文档里的话就完整了：actor 从不持有密钥，它只发一个占位值，网关把这个占位值丢掉。

那密钥到底在哪？答案是连网关自己也不驻留。网关向一个叫 credential provider 的独立组件拉取，请求里带的字段是「已经过出口网关验证的、该 actor 的 SPIFFE ID」。文档里这句话是全链路最关键的一句：

The provider is the only component in the path with access to secret storage. The gateway never reads secrets at rest.

provider 是这条链路上唯一能读密文存储的组件，网关从不读取静态存储里的密钥。也就是说一次请求的路径上，密钥只在一个瞬间存在于 provider 返回的那一小段字节里。

还有一条最容易被忘掉的路：实例元数据。所有云上跑过代码的人都知道，SSRF 打到元数据服务是拿云凭据的经典路径。这里它在 actor 的网络命名空间里用 nftables 直接拒绝 169.254.0.0/16 和 fe80::/10，也就是链路本地整段封掉。威胁模型文档里有一条编号项专门写这件事。

身份的形状也值得抄一眼：actor 拿到的是 spiffe://substrate-actor.local/actor/<命名空间>/<名字>，而代表 actor 行事的 worker 证书是 .../worker-for-actor/...。出口侧校验时会拒绝 CA 证书、要求客户端认证用途、并强制 URI SAN 必须是 worker-for-actor 那种形式。证书有效期一小时。

边界也要说清楚，两处。第一处，出口那段读证书的代码里挂着一个 TODO，写的是要审计「这个值不能被 actor 自己发的 header 顶掉」。也就是说「身份来自证书而非请求头」在文档和设计上是成立的，但代码里有一处输入通道仍待审计。第二处，actor 的 JWT 是按 actor 名字缓存的，文档自己承认：同名重建的 actor 有可能短暂拿到前任的 token，其 UID claim 指向的是上一个实例。这两处都不影响主设计，但它们说明这套东西在细节上还在打磨。

四种身份：增量在这一块

零凭据解决的是「偷不到东西」，解决不了下一个问题。Google 把这个问题的场景写得很具体：一个 agent 在云端打开了某份文档。用户没有点任何东西去打开它，harness 也没有写代码去打开它，是沙箱把它跑起来的。那么它是以谁的名义在请求？

传统云身份系统只认两种调用者：人，和服务。agent 两种都不是。它是一个自主行动、并且经常是代表某个用户行动（on-behalf-of）的动态软件实体。

Google 的答案是创建四种身份，并且永远不让沙箱持有那个「开门的」身份：

用户身份：发起请求或拥有该 agent 工作流的那个人的已认证身份。它只用来认证整个任务，不用于任何 agent 操作。
受委托的 on-behalf-of 身份：一份密码学上受限的授权，证明用户已授权 harness 代表他做特定的工作。这种长期授权只存在于中心授权服务里，永远不在计算节点上。
Agent 工作负载身份：microVM 启动时，平台给它一个短时的、经过密码学证明的身份，基于开放的 SPIFFE 标准。这是沙箱流量唯一使用的身份。 Google 明说：这个身份即使被带出机器，也无法直接用来调后端 API；它唯一的用途是以密码学方式标识「这个出向数据包来自哪个沙箱」。
Agent 劳动力身份：agent 也可以作为你的助手，拥有自己的身份、自己的账号和资源。

Google 的原话是：在主机上我们只用第三个身份，然后在 off-node 之后再把它翻译成其它身份，前提是验证过主机、用户、沙箱、会话和相关策略。

一次请求出去之后是这样走的：沙箱里的代码发出请求，节点的本地代理拦截它，绑定节点与 Titanium 支持的证明，转发给 off-node 的 Agent Gateway。网关校验完整的三角，用户委托、agent 身份、节点身份，然后评估细粒度的出网策略和数据防泄漏策略，最后做一次在途 token 替换，在请求离开网关的那一刻把后端所需凭据插到线上。

结果是：下游后端看到的是一个干净的、标准的、可加密验证的身份，并带有完整的审计记录，说明一个 agent 曾代表某个特定用户行动。而那个不可信的沙箱从来看不到任何凭据。

我认为这一步的分量比零凭据更大。零凭据把「agent 能不能被偷」解决了，四种身份把「agent 做的事能不能被归因」解决了。而且注意身份 2 的位置：长期授权待在中心授权服务里，节点上没有，沙箱里更没有。这三层位置的设计，让「拿到一台被攻破的机器」和「拿到一个能代表用户行动的权限」变成两件必须分别攻破的事。

行星规模的另一半：闲置经济学

这一段是我认为全网最少被讲到的部分，也是「为什么这事只有云厂商做得出来」的答案。

Google 的测量结论是：agent 大部分时间在等待。等模型返回下一步，等用户回复。任意时刻，只有一小部分打开着的会话在跑代码。原文有一句很直接的话：这个数字改变了我们对成本的看法：如果为每个打开的会话预留 CPU 和内存，我们要为 agent 实际做的工作付多得多的钱。

他们的做法分三层。

第一层，应用感知的闲置检测。传统虚拟机服务里，hypervisor 不知道 guest 是在干有用的事还是在空转等下一个提示。Google 的优势在于沙箱命令运行时和主机执行器是协同设计的，所以基础设施天生懂应用：agent 一执行完工具调用、进入 agentic 循环的「思考」阶段，沙箱就上报「没有活跃命令或后台任务在飞」。主机立刻把沙箱从活跃切成闲置，走的是快速 checkpoint 与恢复模型。闲置状态下保留状态、消耗零活跃资源。原文的说法是这让一台物理节点能承载比传统虚拟机多几个数量级的活着的 microVM。

同一套机制还顺带给了 agent 需要的东西：克隆、快照与分叉、回退与回滚。

第二层，内存去重。一台主机上几百个 agent 跑的是同一个基础镜像、同一个 Python 运行时、同一个浏览器，如果每个 VM 都留一份自己的副本，内存会被白白吃掉。它的做法是构建预热好的快照镜像，二进制完全初始化；在主机上用 DAX 直接映射进物理内存，再用写时复制做内存克隆。因为 DAX 绕过了重复的 guest page cache，同一主机上每台 microVM 共享的是同一批物理内存页，物理内存只为每台机器私有修改的那一小块增量分配。再加上活跃内存回收和压缩，把释放的页还给主机池。

第三层，需求曲线不重合。这一层是经济学。Google 把三条需求画出来发现峰值不同：Gemini 的消费端 agent 在早晚高峰，企业端在各时区的工作时段，而评估和强化学习的任务根本没有峰值，有闲置容量就跑。加上相当大一部分 agent 计算不是实时人在环（每日摘要、深度后台研究、异步代码迁移、过夜测试、大规模 RL），于是三件事成立：全球策略感知调度把会话导向最优容量池，同时强制地理边界与合规要求；时间上灵活的工作被排进低谷；一个统一的、可互换的硬件池把这三类负载跑在一起。交互需求上来时，低优先级的批量评估会主动让出物理槽位。

存储也被拆成了三类，因为 Google 发现自己「看了 agent 到底写了什么」之后才想明白：临时草稿数据（OS 日志、构建产物、容器层 churn）进可丢弃的 overlay；只读与共享卷（基础镜像、语言工具链、共享包缓存）以只读方式跨沙箱挂载，团队还能通过 GCS 上的高速 FUSE 挂共享卷协作，凭据由主机侧管理而不进沙箱；只有用户真的工作状态和产物作为持久数据留存。存储那句推导也值得抄：绝大多数 agent 的盘实际上是空的，而且最先耗尽的资源往往是挂盘槽位，轮不到 CPU。

开源实现这一侧的对应机制我核过了，几个结果值得记：microVM 走的是 Cloud Hypervisor 的 VM 快照（暂停、写快照、拆掉 VMM），恢复用 userfaultfd 做按需换页；gVisor 走的是原生 runsc 的 checkpoint/restore；而两处都没有 CRIU，我 grep 过非测试代码里零命中。状态保留分三级，从只保卷、到加 rootfs、到加内存态，逐级累积。另外有一条诚实的代价写在文档里：异步挂起如果在后台上传完成之前节点挂了，有丢状态的窗口。

硬件那一半：Google 一笔带过，我从开源侧补齐

ACE 的安全清单里，有一层是它讲得很快但我认为分量最重的。

密钥不放在 guest 里，也不放在主机 OS 里，而是放在 Titanium IPU 里。Google 的原话是：用于节点与工作负载证明的密码学私钥，只存在于 IPU、主机或远端，唯独不在 guest 环境里。同时块存储的挂载由 IPU 用实例绑定的密码学授权来中介，效果是：一个被攻破的沙箱，加一个被攻破的主机 OS，仍然不足以跨节点或跨租户去挂载、读取或覆写卷。

主机侧还有一层：物理主机是一个无状态、不可变的家电，根文件系统只读，靠 dm-verity 强制，零持久本地状态；Titan 校验硬件与固件完整性，在任何工作负载被调度之前完成密码学验证的启动完整性。

为什么我把这层看得比前面那些策略更重？因为 nftables 规则、代理、身份校验都是软件层的东西，理论上都可以被上层攻破或绕过。把凭据的信任根放进 IPU，等于把「翻墙」的成本从改配置提高到了攻破硬件信任根。这也是为什么这套组合里，最不像 AI 的部分反而最关键。

ACE 里还有一层严格的分离值得提一句：编排 harness（大脑）完全跑在执行沙箱（手）之外，沙箱只执行 harness 显式派发的命令并把输出流回去。这个边界建立起一条确定性的审计链，把每一次 harness 发起的工具调用和沙箱内预期的计算活动对应起来。

开源兄弟：能跑的那一半

ACE 本身没有代码可读，但 Google 把它的 Kubernetes 版本开源了，叫 Agent Substrate，仓库 agent-substrate/substrate，6,053 星、676 fork、Go、Apache-2.0，2026 年 5 月建仓。有意思的是它的 v0.6.0 发布于 10 月 22 日，跟 ACE 发布同一天。

仓库形状我先量了一遍（排除 vendor 和生成代码）：手写源码 151,328 行，手写测试 232,673 行，测试比源码多出 54%，另有 59,441 行生成代码，694 个测试文件。

架构上有个简洁得值得说的选择：它有两个 worker 二进制，一个跑 gVisor、一个跑 microVM，但两者实现的是同一个 gRPC 服务，契约写在 proto 里，只有五个方法（跑工作负载、检查点、恢复、查统计、终止）。也就是说这个仓库里没有那种「平台适配器大接口」，它把两条运行时路径的共识压缩成了一份 proto 契约。

CRD 只有三个。e2e 套件二十个。

它的工程规则里有几条我抄下来了：atelet 与 worker 除 proto 和 nodepath 之外互相不透明；gVisor 和 microVM 两条路径都必须过 e2e；DCO 只接受人类签署；CI 里任何跳过必须失败。

harness 怎么接这件事，答案是没有适配层。文档的原话是它「与框架和 agent harness 无关」，因为它在沙箱里跑标准 OCI 容器镜像、把安全边界放在工作负载之外，所以托管任何栈构建的 agent 都不需要改 SDK。具体接线就是三步：构建镜像、用 ActorTemplate 指向镜像、在沙箱里运行。仓库自带一个示范，把三个 Claude Code 实例注册成 actor，用一个两 pod 的 WorkerPool 承载，靠 egress policy 放行 api.anthropic.com:443 并把 TLS 直通出去。

我认为「framework agnostic」在这里是架构推导出来的结论，不只是口号：因为安全边界在 workload 之外，所以它确实不需要你改 agent 代码。但坑换了个位置：接线的难点落在 OCI bundle 那层。那个示范的 README 里明确写着「为这个示范绕过了一些上游阻塞」并列出两个 issue 编号。

那几个数字，仓库里没有可复现依据

这一节是我核对源码时挖出来的，也是我认为这篇里分量最重的一段。

README 和两份文档宣称：挂起恢复在 500 毫秒以内、每秒超过 500 次激活、10 到 30 倍超分、8 个物理 pod 承载约 250 个有状态 actor。

但我在这套文档里读到了另一处：「北极星指标」把目标写成 100ms p95 激活延迟。也就是说同一个仓库既宣称「已经做到 500ms 以内」，又列出「目标 100ms」。

然后我去仓库里找实测数据。结论是：有工具，没有结果。 benchmarking/ 目录提供了完整的测量工具链，包括一个 locust 状态机、负载脚本，而且挂起恢复的分阶段计时是代码在运行时自己写出来的（检查点计时分解、恢复计时分解），还有一份专门的 runbook 教你怎么读它们。但我找不到任何提交进仓库的结果文件：没有结果 JSON、没有 CSV、没有图表。

更能说明问题的是我 grep 500ms 的结果：命中的除了 README 和文档的宣称，就是 benchmark 里的一个假延迟参数，变量名写着 FAKE_ATELET_DELAY=500ms，那是测试注入的模拟值，不是测量值。

所以准确的写法是：这几个数字目前是厂商宣称，配着一套可复现的测量工具链，但没有可核对的事实。这不等于数字是假的，Google 内部确实在跑 Gemini 和强化学习管线，规模压力是真的。但一个把测量工具和 runbook 都开源出来的项目，如果同时把结果留在仓库外，那读者就该按「未验证」来对待它。

我的判断

第一，ACE 的定位不在沙箱产品那一层，它把 agent 的执行层做成了云的原生原语。沙箱是别人也在做的红海，Google 真正在做的是把「agent 会话」变成一种和虚拟机、容器并列的、有自己生命周期语义的计算单元，然后把这个单元接进它已有的身份与 IAM 体系。它讲的那句「统一身份模型与可审计性」就是这个意思。

第二，要盯的是治理的扩张路径，隔离强度只是入场券。跟 ACE 一起宣布的还有：跨云用轻量 Envoy 代理做策略执行点，以及在受管设备上给本地 coding agent 加一层 OS 级沙箱和本地治理服务。这两条合起来意味着 Google 想治理的不只是它自己跑的 agent。一个云厂商能管别人云上的 agent，这件事的战略含量比 microVM 高得多。

第三，和站内 10 月 18 日那篇拆 SPACE 的稿子对照着看很有意思。那篇的结论之一是「出网是最接近产品能力的一层」。Google 的做法更彻底一步：它连网卡都不给沙箱，把出网降级成一条 IPC 通道，然后在通道的另一端做全部决策。同一个判断，两种实现深度。

第四，一个方法论上的观察。 ACE 没有代码可读，所以这一轮我能做的源码级验证全是在开源兄弟上做的。这算不上打折扣：一个厂商愿意把「可被验证的那一半」开源出来，本身就使它的架构主张变得可以独立核对。反过来说，这一轮我核出来的唯一硬问题是数字缺依据，而那恰好是它没开源的那部分（真实 fleet 的实测结果）。这个分界挺说明问题。

想把最接近的另一条路先看一遍，见《Anthropic 开源 srt 沙箱：不装容器也能关住 Agent，密钥防线其实在出口代理》；想看「出网即产品能力」这个判断的完整推导，见《Perplexity 开源 SPACE：Agent 沙箱该有的样子，它一次全做进去了！》；而内核级拦截加形式化验证那条路线，见《NVIDIA 把「Agent 安全运行时」做成了官方基础设施》。

出口代理 on AI博士 万戈