谷歌 ACE 为智能体提供可暂停计算环境

AI 智能体执行任务，需要的不只是模型接口，还需要一个能运行代码、打开浏览器、保存工作进度的计算环境。谷歌 10 月 22 日宣布的 Agent Compute Engine（ACE），就是准备把这套环境做成 Google Cloud 服务。

它最值得关注的设计是：每个智能体拥有独立的微型虚拟机，空闲时暂停，继续工作时恢复文件和内存。谷歌称，在 20 万个智能体的测试中，暂停与恢复耗时不到 500 毫秒。不过，这个数字的测试条件和服务开放细节，原文都没有展开。

为什么智能体需要一台「专属电脑」

调用一次模型接口，通常只需要提交输入、接收输出。但让智能体修改项目、执行代码、操作浏览器，再根据结果继续行动，就需要一个可以持续工作的环境。

ACE 为每个智能体提供硬件隔离的 microVM，也就是微型虚拟机。智能体可以在里面执行代码、调用工具、操控浏览器，完成多个步骤组成的任务。

它还提供独立客户内核和根权限。可以理解为，智能体对自己的工作环境有较大的控制权，而不同环境之间的隔离交给底层虚拟化设施处理。

谷歌使用 Cloud Hypervisor 的硬件隔离边界保障安全，并表示沙箱内不会保存凭据，以降低滥用和数据泄露风险。但凭据如何在实际调用工具时提供、权限如何约束，原文没有说明。

独立环境解决的是执行空间与隔离问题，不能单凭它判断整个智能体系统是否安全。

不到 500 毫秒，快的是哪一步

ACE 的关键设计是「持久且可暂停」。

智能体空闲时，计算环境自动挂起并释放资源；需要继续工作时，恢复此前的文件和内存状态。对多步骤任务来说，保存内存比只保留磁盘文件更进一步，因为恢复目标包含运行中的状态。

这让「长期拥有一个环境」和「持续占用运行资源」有了分开的可能。

谷歌称，在 20 万个智能体的测试中，暂停与恢复耗时不到 500 毫秒。同时，ACE 可以通过共享内存和快照复制，提高单台服务器承载的智能体数量。

这里需要把性能口径看准：原文说的是暂停与恢复耗时，没有分别给出两者的数据，也没有说明统计分位、内存规模或负载条件。它不能直接当成新建环境、启动浏览器，或完成一次任务的延迟。

共享内存和快照复制带来的承载量提升，原文也没有给出具体倍数、对照配置和成本数据。

开发者能控制什么，谷歌负责什么

ACE 最初用于支撑 Gemini、Gemini 平台、Antigravity，以及谷歌内部的模型评估和强化学习流程。这说明它已有内部使用场景，但原文没有提供这些场景的详细运行结果。

按照公告描述，未来开发者可以通过 Google Cloud 使用 ACE，自行控制环境镜像、身份、网络访问和生命周期，谷歌负责底层资源调度与扩容。

这个分工对需要大量执行环境的团队有吸引力：开发者决定环境里装什么、允许访问什么，以及何时启动或暂停，不必自行承担全部底层调度工作。

但原文没有给出 SDK、API、价格、区域、配额和具体开放时间。现阶段可以理解它的设计方向，还不足以据此安排生产接入。

我的判断

我认同 ACE 对智能体生命周期的判断：需要保留工作进度的执行环境，不一定需要一直运行。把暂停、恢复和资源调度放到基础设施层，确实切中了这类任务的需求。

但是否适合一般团队，取决于任务形态。如果任务只执行一段短脚本、产出结果就结束，临时容器或其他短生命周期执行环境也可能够用。需要持续保留文件和进程状态的任务，才更值得评估 ACE。

原文提供了一个性能数字，没有提供足以比较不同方案的对照数据。

不到 500 毫秒来自谷歌自述，不能据此断言 ACE 比现有容器或虚拟机方案更快、更便宜。内部用于 Gemini 等产品，也不等于开发者未来获得的服务条件已经明确。

能拿来做什么

• 做 AI 编程工具时，先确认任务是否需要保留依赖安装结果、项目文件和运行中的进程，再决定是否采用可持久恢复的执行环境。
• 做浏览器智能体时，把环境恢复耗时与任务完成耗时分开记录，避免用一个基础设施指标代表用户实际等待时间。
• 评估 ACE 时，重点补齐价格、可用区域、凭据处理和网络控制方式，再与现有容器或虚拟机方案比较。
• 如果正在自建智能体运行平台，可以参考它的生命周期设计，把环境创建、暂停、恢复和销毁作为明确的管理动作。