谷歌Agent Compute Engine：每个Agent一个microVM

谷歌最近抛出了一个针对AI Agent运行时的基础设施方案——Agent Compute Engine（简称ACE），核心思路简单粗暴：每个Agent独占一个microVM，VM内部不存放任何凭证。这个设计直指当前Agent部署中最棘手的两个问题：隔离性与密钥管理。

为什么Agent需要独立的microVM？

当前多数Agent框架跑在共享的容器或进程里，工具调用、代码执行、外部API访问都在同一环境完成。一旦某个Agent被提示注入攻破，攻击者拿到的可能不只是这个Agent的控制权，还有环境里残留的token、环境变量和相邻Agent的数据。

ACE的解法是把隔离粒度推到硬件虚拟化层。microVM（如Firecracker一类轻量虚拟机）启动快、开销小，同时提供比容器更强的边界。每个Agent一个VM，意味着一个Agent的沦陷不会横向波及别的Agent。据谷歌的描述，VM内部不保存任何凭证，Agent需要访问外部服务时，凭证由外部注入或代理，而非落在Agent可读的文件系统或环境变量中。

这一组合——强隔离加零凭证驻留——把"Agent被攻破"的最坏后果从"密钥泄露"降级为"单个VM被烧毁"。

microVM 是介于容器与完整虚拟机之间的轻量级虚拟化方案。它保留硬件虚拟化（如KVM）提供的强隔离边界，但通过精简设备模型和专用启动路径，把启动时间压缩到百毫秒级、内存开销降到几十MB，从而接近容器的敏捷性。Firecracker 是其中最具代表性的实现，由 AWS 为 Lambda 和 Fargate 开发并开源，单台主机可运行数千个 microVM。与容器共享内核不同，microVM 各自拥有独立内核，因此内核漏洞或容器逃逸类攻击难以跨 VM 扩散，这正是 ACE 选择它的原因。

提示注入（prompt injection） 指攻击者把恶意指令藏在 Agent 会读取的内容里（网页、文档、工具返回结果等），诱使模型偏离原任务、执行未授权操作。与传统注入攻击不同，它利用的是模型对自然语言指令的服从性，而非代码解析漏洞，因此很难用输入过滤彻底根除。在共享运行时中，被注入的 Agent 可能读取环境变量、调用高权限 API 或访问相邻 Agent 的数据，造成横向移动。ACE 的 microVM 隔离与凭证外置，正是为了把提示注入成功后的影响面限制在单个 VM 内。

谷歌说了什么，没说什么

根据公开信息，ACE的定位是Agent的托管运行时，强调按Agent粒度分配计算资源与隔离边界。但需要如实指出：目前公开的技术细节相当有限。microVM的具体实现（是否基于Firecracker、gVisor或其他）、凭证注入的具体机制（sidecar代理、短期令牌交换还是别的方案）、网络策略的默认配置、以及定价模型，均未完整披露。

换句话说，现在能确认的是设计意图和架构方向，而不是可验证的实现细节。对打算依赖这套基础设施的团队来说，这是一个需要留意的信息缺口——架构承诺和实际SLA之间还有一段距离。

构建者今天能抄的三件事

即便ACE本身尚不可用，它的设计思路对自建Agent基础设施的团队有直接参考价值。

1. 把隔离单元从容器下沉到microVM

如果你的Agent会执行模型生成的代码或调用不受信任的工具，容器边界偏薄。用Firecracker、Cloud Hypervisor一类轻量虚拟化方案为每个会话或每个Agent分配独立VM，启动时间可以控制在百毫秒级，代价可接受。关键是让爆炸半径等于一个VM。

2. 凭证不落在Agent环境里

这是ACE最值得抄的一条。把密钥从Agent的env、文件系统和内存中移出去，改由外部代理在请求发出时注入。具体做法包括：出站流量走代理，代理侧持有凭证并做短期令牌交换；或者用工作负载身份（如SPIFFE）让Agent以身份而非密钥访问资源。这样即使Agent被完全控制，攻击者也拿不到长期凭证。

SPIFFE（Secure Production Identity Framework for Everyone） 是一套工作负载身份标准。它由 SPIFFE ID（形如 spiffe://trust-domain/path 的 URI）和 SVID（携带该身份的短期加密凭证，通常是 X.509 证书或 JWT）组成，由各节点上的 Workload API 自动签发和轮换。工作负载凭 SVID 向资源方证明身份，资源方据此授权，全程无需静态密钥。对 Agent 场景而言，这意味着即使攻击者完全控制某个 VM，也只能拿到几分钟内有效的身份凭证，且该身份可被单独吊销，无法据此长期访问其他资源。

3. 按Agent粒度做资源与生命周期管理

每个Agent有自己的VM意味着可以独立地限流、快照、销毁和审计。审计日志天然按Agent切分，出问题时能精确定位到单个运行时，而不是在一堆共享日志里捞针。

值得关注的信号

ACE释放的信号比它当前的功能更重要：主流云厂商开始把Agent当作一等公民的运行时负载来对待，而不是"跑在容器里的一个应用"。隔离粒度、凭证模型、生命周期管理这些传统上由开发者自己拼装的东西，正在被收编进平台层。

对开发者而言，短期内不必等待ACE落地——上面三条原则今天就能用开源组件实现；中期则值得盯着谷歌后续补全的实现细节，尤其是凭证注入机制和网络策略默认值，这两项决定了这套架构的安全下限。

---

资料来源说明：本文基于RSS来源的公开报道整理，谷歌官方文档中关于ACE的实现细节尚未完整公开，文中涉及具体机制的描述以公开信息为限。