先看证据
代理工作负载卡在执行与等待之间
Google Cloud于2026年10月22日公布Agent Compute Engine（ACE），这是一项面向AI代理的计算服务，目标是为每个代理会话提供独立执行环境。Google称它已经用于Gemini代理工作任务，也用于内部评测和强化学习流程；面向客户的预览则计划在“未来几个月”推出，尚无具体日期。
这项设计针对的不是单纯的代码运行速度，而是代理工作的间歇节奏：代理执行一次工具调用，随后等待模型或用户，再继续下一步。传统虚拟机隔离较强，但Google称启停可能耗时数秒至数分钟；容器较轻，却共享宿主机内核。若每个等待中的代理都长期占用一台完整虚拟机，隔离和资源利用率就会互相牵制。
把决策留在沙箱外，把执行关进微型虚拟机
ACE把代理拆成“brain”和“hands”：编排程序在沙箱外决定下一步，沙箱内的microVM则运行代码、命令和浏览器操作。每个会话对应一个单租户microVM，使用Cloud Hypervisor边界；这不是每个代理独占一台物理服务器，而是在Google管理的主机上提供独立的虚拟化隔离。Google称底层使用Titanium IPU和Titan硅组件。
这种拆分改变了失陷时的默认假设。系统不必相信沙箱里运行的代理代码安全，而是把它视作可能已被提示注入或恶意输入控制，再限制它能做什么。编排程序通过明确派发的操作让沙箱执行任务，因此代理的推理与代码执行不再处于同一个信任边界内。
零凭证不等于零权限
ACE的安全重点不只是“把危险代码关起来”，还包括让沙箱本身没有可直接带走的业务密钥。Google称microVM内没有持久凭证、OAuth刷新令牌或云服务账号密钥，也不能访问实例metadata server；同时没有标准网卡、默认网关或直接VPC通路。请求通过隔离的本地通道到达外部Agent Gateway，由网关检查身份和策略，再在请求离开时换入所需的后端凭证。
Google为代理工作负载区分四类身份：代表整体任务的用户身份、存放在中央授权服务中的委托身份、用于沙箱流量的短期Agent Workload Identity，以及代理自己的Agent Workforce Identity。对沙箱网络流量而言，短期工作负载身份只用于标识“哪个沙箱发出了请求”，即使泄露，也不能直接拿它调用业务API。换句话说，零凭证不是零权限：代理仍可能通过网关访问数据，实际边界取决于网关策略、授权范围和任务设计。
休眠机制是架构的一部分，不是性能证明
代理进入等待阶段后，ACE据称会检查点保存microVM状态并释放活动计算资源，下一次工具调用到来时再从快照恢复。预热快照和写时复制则用于减少重复内存占用：代理可以共享未修改的基础系统页，只有各自修改的部分才成为私有页。工作区也被拆成可丢弃的临时层、共享只读卷和持久化用户空间，避免把所有状态都塞进同一种存储生命周期。
但目前公开的效率证据主要属于开源兄弟项目Agent Substrate，而不是ACE。Google材料给出的一个结果是：在20万代理的测试中，Substrate达到每秒500次激活、暂停与恢复低于500毫秒；另一份技术简报又称超过每秒1500次激活、恢复低于400毫秒，并提到最高10倍计算密度。材料没有交代两组数据的测试口径差异，也没有公布ACE自身的启动时间、主机密度、价格或成本节省比例，因此这些数字不能直接外推到托管服务。
先验证权限边界，再等待托管服务数据
对技术负责人来说，ACE最值得借鉴的不是“每个代理一台microVM”这句口号，而是把执行环境和授权路径分开设计。若代理要运行不可信代码，同时又需要接触企业数据，团队可以先检查现有架构能否做到沙箱不持有长期凭证、网络出口经过策略网关、每次任务只获得所需范围的授权。开源Agent Substrate可运行在Kubernetes集群上，适合用来验证这类隔离、身份和休眠恢复流程，但它不能替代对ACE托管形态的性能评估。
边界也必须说清：Google描述的硬件隔离、空闲时释放资源和快速恢复，目前都缺少ACE自身公开的独立审计或性能数据。代理安全最终不会由microVM单独保证，网关策略配置错误、授权范围过宽或工作区持久化不当，仍会留下风险。合理的决策顺序是先验证权限模型与故障边界，再用真实任务测量恢复延迟和成本，最后等ACE公布价格、预览条件及服务级数据后，判断托管便利是否值得换取平台依赖。