谷歌为 Gemini 代理提供独立微虚拟机

Google 想解决 Agent 落地中的一个实际问题：当大量 Agent 等待用户、模型或工具返回结果时，怎样避免它们持续占着计算资源。它公布的 Agent Compute Engine，为每个 Agent 分配独立的微型虚拟机，同时通过自动暂停和内存共享降低运行成本。

这项服务已经支撑 Gemini，计划在未来几个月开放预览。值得关注的是，它把 Agent 的隔离、资源调度和管理控制放到了一起。不过，原文中的性能数字均来自 Google，离一般团队能获得多少收益，还差一组具体条件。

每个 Agent 一台虚拟机，成本怎么控制

按照 Google 的介绍，每个 Agent 都运行在独立的微型虚拟机（microVM）中，由 Google 的 Titanium 芯片提供安全保障。

可以把 microVM 理解成体积较小、供单个 Agent 使用的运行环境。这里的隔离边界落在虚拟机层面，目标是让 Agent 各自在受保护的环境里执行任务。原文没有进一步解释 Titanium 的具体保护机制，也没有给出安全测试结果。

问题随之而来：Agent 越多，虚拟机越多，资源成本也会增长。Google 给出的处理方式有两项：

• Agent 空闲时，对应虚拟机会自动暂停，让机器资源供其他任务使用。
• 虚拟机之间共享内存，以降低每个实例的运行成本。

它试图保留每个 Agent 的独立运行环境，同时减少空闲实例带来的资源占用。

这里还不能把「共享内存」理解为 Agent 可以互相读取业务数据。原文没有说明共享的是哪些内存、如何共享，以及它与隔离机制如何配合。

10 倍密度和不足 500 毫秒，能说明什么

这套思路也用于已经开源的 Agent Substrate，一个 Kubernetes 运行时。Agent Compute Engine 是服务，Agent Substrate 则是底层运行环境相关的开源项目，两者不能直接画等号。

Google 声称，单台服务器可以容纳的 Agent 数量达到原来的 10 倍。在一项涉及 200,000 个 Agent 的测试中，暂停和恢复耗时不到 500 毫秒。

这两个数字分别回应了不同问题：前者关注服务器能装下多少 Agent，后者关注暂停之后能否较快恢复执行。对于经常等待外部结果的 Agent，暂停是否足够便宜，决定了资源回收有没有实际价值。

但原文没交代 10 倍对应的比较基线，也没有说明服务器配置、Agent 负载、活跃比例，以及不到 500 毫秒采用什么统计口径。它不能直接被解读成端到端任务延迟，更不能据此推算费用下降了多少。

此外，Google 正在增加 token 跟踪、模型路由，以及 Ping Identity、SailPoint 等第三方身份提供商支持。这些控制能力将扩展到 Cloud Run、GKE 和托管端点。它们分别涉及用量观察、模型选择和身份接入，但原文没有展开具体 API、配置方式和可用范围。

我的判断

方向有道理。Agent 的生命周期可能包含大量等待时间，持续为这些等待保留计算资源，确实是需要处理的成本问题。把隔离环境与自动暂停结合，比单纯追求更多并发实例更完整。

但资源收益取决于任务形态。若 Agent 大部分时间都在持续计算，可供暂停回收的空间就会减少；如果业务对恢复延迟敏感，也需要把暂停策略放进实际链路里测。

目前能确认的是 Google 公布了方案和测试数字，不能确认一般团队也能获得同样收益。

原文没有提供与普通容器、常驻进程等做法的对照数据。独立 microVM 是否划算，需要结合隔离需求、负载特征和调度成本判断。对只运行少量 Agent 的团队，现有方案是否已经够用，仍然是合理的问题。

能拿来做什么

• 如果正在用 Node 搭建 Agent 服务，先记录任务执行、等待工具和空闲分别耗时多少，再判断自动暂停是否有价值。
• 评估这类运行时时，把实例密度、暂停恢复延迟和完整任务延迟分开测试，避免拿基础设施指标代替用户体验。
• 关注 Agent Substrate 时，先核实项目实际提供的隔离与调度能力；计划采用 Agent Compute Engine 时，再确认预览开放时间、价格和接入方式，这些信息原文都没给全。