Google云推出Agent计算引擎：每个AI代理一个微VM

Google Cloud 发布 Agent Compute Engine，把「一个 AI 代理一台隔离虚拟机」做成了云服务的基础抽象。这不只是产品更新，更是对代理运行安全模型的一次重新设计。

核心设计：代理不持有凭证，每台 microVM 硬件隔离

据 MarkTechPost 报道，Agent Compute Engine 为每个 AI 代理分配一台硬件隔离的 microVM，且虚拟机内部不存放任何凭证。这两点组合在一起，意味着代理即使被提示注入攻破，攻击者拿到的也只是一台「空壳」机器，而不是一把通往企业数据与 API 的钥匙。

传统代理部署往往把长期凭证直接塞进运行时，代理越能干，凭证权限就越大，风险也越集中。Agent Compute Engine 的思路是把凭证从执行环境中剥离出去，让代理的执行面与授权面分离。

microVM 与容器隔离的本质区别

microVM（如 AWS Firecracker、Google gVisor 的同层方案）是一种基于硬件虚拟化（通常是 KVM）的轻量级虚拟机，它在独立内核上运行 guest 操作系统，因此与宿主机和其他实例之间不存在共享内核。容器则依赖 namespaces 与 cgroups 做逻辑隔离，仍共享宿主内核，一旦内核出现提权漏洞，攻击者可能跨越容器边界。这正是「硬件隔离」在代理场景中的价值所在：提示注入被攻破后，攻击者最多控制自己那台 microVM，无法借共享内核横向移动到其他代理或宿主服务。代价是 microVM 需要独立的内存与内核镜像，启动与调度开销高于容器，所以业界才用 Firecracker 这类极简设备模型把冷启动压到百毫秒级。

提示注入与「执行面 / 授权面分离」

提示注入指攻击者把恶意指令混入代理读取的内容（网页、邮件、工具返回值）中，诱导代理偏离原任务、执行攻击者意图的操作。传统部署把长期 API 密钥或 OAuth 令牌写进代理运行时，代理一旦被注入控制，攻击者就顺带拿到了这些凭证的全部权限，这是提示注入危害被放大的主因。所谓执行面与授权面分离，是指代理的推理与工具调用（执行面）运行在不含秘密的环境里，而真正的鉴权（授权面）由外部可信组件完成，例如按需签发短时效、最小权限的令牌，或由网关代为调用下游 API。这样即使执行面失守，攻击者也无法直接复用长期凭证，暴露面被压缩为单次、受限、可审计的调用。

已经跑在 Gemini 代理上，预览版即将开放

Google 表示该服务已经在内部支撑 Gemini 代理的运行，并计划在接下来的几个月进入预览阶段。换句话说，这不是一个实验室概念，而是先内部 dogfooding、再对外开放的路径。

对企业来说，这种节奏释放的信号很明确：Google 自己在代理基础设施上已经踩过坑，现在把踩坑后的架构拿出来售卖。

为什么「一代理一 VM」可能成为代理云的默认形态

多代理系统在 2026 年的落地速度超过了身份与隔离体系的建设速度。当几十上百个代理并发执行任务时，共享运行时带来的横向移动风险会被放大。microVM 的粒度恰好卡在「足够轻量、可以批量启停」与「足够强隔离、不共享内核」之间。

这条路并不便宜：每个代理一台虚拟机，调度和冷启动开销都是真金白银。Google 显然押注的是，企业愿意为代理的失控风险付这笔账。

横向移动风险

横向移动是安全领域的术语，指攻击者攻破一个入口后，借内网信任关系、共享凭证或同宿主资源，逐步渗透到其他系统。放到多代理系统里，风险会被显著放大：几十上百个代理常共享同一个运行时、同一套环境变量或同一个服务账号，一个代理被提示注入攻破，攻击者就能读取同进程内的其他代理状态、复用它们的凭证、向同宿主的代理发送恶意任务，形成连锁失守。隔离粒度越粗，单点失守的影响面越大；microVM 把每个代理关进独立内核的盒子，正是为了切断这条横向路径，把故障与入侵控制在单台实例之内。

值得关注的几个开放问题

目前公开信息还比较有限：microVM 的启动延迟、计费粒度、与现有 IAM 体系如何对接、以及代理之间的通信是否也走隔离通道，都还没有明确答案。没有凭证的代理如何完成需要授权的操作——是通过短期令牌注入、还是由外部服务代理鉴权——将是判断这套架构成熟度的关键。

对于正在搭建代理平台的企业，Agent Compute Engine 提供了一个值得对标的参考架构：先隔离，再授权，最后才谈能力。