Google Cloud 发布 Agent Compute Engine：每个 AI Agent 独占一个硬件隔离 microVM，沙箱内零凭证
来源MarkTechPost查看原文
速览
- 每个 Agent 独占一个硬件隔离 microVM，沙箱内不存任何凭证
- Agent 拆为沙箱外的 harness 与沙箱内的 sandbox，指令显式下发
- 出网走 vsock 到本地代理再到 Agent Gateway，凭证在途中替换
- 4 种身份分离，只有短期 SPIFFE 身份进入沙箱
- 空闲即 checkpoint 到零资源，靠 CoW 共享内存提升密度
- Agent Substrate 已达 500 次激活/秒、恢复低于 500 ms
- ACE 自身性能、定价、预览日期全部未公开
- 治理能力扩展到 Cloud Run、GKE、Agent Sandboxes 等
Google Cloud 在 AGNTCon + MCPCon 上发布 Agent Compute Engine（ACE），为每个 AI Agent 会话分配一个硬件隔离的 microVM，各自拥有独立 guest kernel、root 权限和 Hyperdisk。该服务已用于支撑 Gemini、Antigravity 以及内部的评测与强化学习流水线，客户预览计划在未来几个月开放。核心设计是把 Agent 拆成「大脑」（harness，在沙箱外调用模型）和「双手」（sandbox，执行代码、shell 命令和浏览器操作），沙箱内不存放任何凭证：microVM 没有标准网卡、没有默认网关、不能直连 VPC，所有流量经 virtio-vsock 到本地代理再出网关，由 Agent Gateway 在策略校验后于传输途中替换成真实后端凭证。空闲 Agent 会被 checkpoint 到零活跃资源，下次调用时从快照恢复；密度靠 copy-on-write 内存共享实现。开源同源项目 Agent Substrate 已在 2026 年 9 月 15 日上线 GKE，Google 给出的数据是最高 10 倍计算密度、20 万 Agent 基准下 500 次激活/秒且挂起恢复低于 500 ms、单机超过 1000 个休眠 Agent。但 ACE 本身的启动时间、密度、定价和预览日期均未公布。
关键事实
- Agent Compute Engine 为每个 Agent 会话分配一个单租户 microVM，基于 Cloud Hypervisor 边界，宿主机为无状态设备，根文件系统只读并由 dm-verity 强制
- 沙箱内零凭证：microVM 无标准网络接口、无默认网关、无 VPC 直连，仅持有会话级 SPIFFE 证书和短期身份令牌
- Google 为每个 Agent 工作负载定义 4 种身份：用户身份、委托的 on-behalf-of 身份、Agent Workload Identity（短期 SPIFFE）、Agent Workforce Identity
- 空闲 Agent 被 checkpoint 到零活跃资源，下次工具调用时从快照恢复；密度来自 DAX 映射的预热快照镜像与 copy-on-write 内存共享
- ACE 已支撑 Gemini、Antigravity 及内部评测与 RL 流水线，客户预览计划在未来几个月开放
- 开源同源项目 Agent Substrate 自 2026 年 9 月 15 日起在 GKE 提供，支持 Cloud Hypervisor microVM 或 gVisor 沙箱，兼容 Claude Code、OpenClaw、Hermes 等 harness
本站视角
最直接的影响对象是两类人。第一类是在做企业 Agent 平台的技术团队：Google 这套「沙箱零凭证 + 网关换 token + 四身份分离」的设计，实际上给 prompt injection 划了一条明确的防线——假设攻击者完全控制沙箱内部，也偷不到可用的密钥。这个假设比多数自建方案激进，值得借鉴；如果你们的 Agent 现在把 API key 直接塞进容器环境变量，这就是反面教材。第二类是依赖 E2B、自建 Firecracker 或 K8s 沙箱的中小团队：Agent Substrate 开源且能在任意 K8s 集群跑，等于把 Google 的沙箱调度层免费放出来了，短期内的迁移成本值得评估。 我们的判断是：这是一次架构层面的实质推进，但发布本身是半成品。ACE 的启动时间、单机密度、定价、预览日期一个都没给，唯一可验证的性能数字全部来自 Agent Substrate，且是 Google 自报、无第三方复现。把开源兄弟项目的数字放在 ACE 的发布稿里，容易让读者误以为 ACE 也有同样表现——原文自己也承认「这些数字属于 Agent Substrate，不属于 ACE」。另一个需要观察的点是凭证换发架构的代价：所有流量绕经 Agent Gateway 做策略检查，多一跳带来的延迟和网关本身的可用性风险，Google 没有披露。对延迟敏感的 Agent 场景（比如实时浏览器操作），这可能成为瓶颈。 竞争格局上，AWS AgentCore 已经可用、Azure 覆盖 38 个区域、E2B 已商用，Google 的 ACE 还在「未来几个月预览」。真正的差异化要等定价出来才能判断——如果 checkpoint 到零资源真能把空闲 Agent 的成本压到接近零，那对长时运行、低频触发的 Agent 是结构性优势；如果定价仍按 VM 时长算，这套精巧的挂起恢复就只是技术演示。
背景与影响
Agent 沙箱赛道今年明显升温：AWS 有 AgentCore Runtime（每会话专用 microVM，最长 8 小时，14 天 Instances），Azure 有基于 Hyper-V 的动态会话（已覆盖 38 个区域），E2B 用 Firecracker microVM、恢复约 1 秒。Google 的差异化不在隔离本身——microVM 已是共识——而在两处：一是「沙箱内零凭证 + 网关途中换 token」的凭证架构，二是把空闲 Agent checkpoint 到零资源以压低成本。这针对的是 Agent 负载的真实特征：大部分时间在等模型或等人，按传统 VM 计费会极其浪费。同时 Google 把治理层（Agent Gateway、Agent Registry、Agent Identity、OpenTelemetry 可观测性）铺到 Agent Runtime、Cloud Run、Agent Sandboxes、GKE 和 ACE 上，并计划本季度预览 token 管理、模型路由，以及与 Ping Identity、SailPoint、Saviynt 的委托授权集成。这意味着 Google 想把 Agent 的算力、身份、策略打包成一套企业级基础设施，而不只是卖沙箱。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。
