谷歌给每个 agent 一台微型虚拟机

一个 agent 干完活之后在干什么？多数时候是在等下一个请求，同时继续占着一台机器。

一、发生了什么

10 月 22 日，the-decoder 报道了谷歌的 Agent Compute Engine：给每个 AI agent 分配一台独立的虚拟机，每台由谷歌自研的 Titanium 芯片做硬件隔离。

报道里提到几个关键设计。agent 空闲时，它的虚拟机自动暂停，把机器让给别人；虚拟机之间共享内存，摊薄单台的开销。谷歌说，靠这套办法，一台服务器能塞下的 agent 数量是原来的十倍。

另一个数字更值得记：在一次 20 万个 agent 的测试里，暂停和恢复的耗时不到 500 毫秒。

这项服务已经在给 Gemini 供能，未来几个月开放预览。它还对应一个开源的 Kubernetes 运行时，叫 Agent Substrate。

治理侧同时补了三样：token 追踪、模型路由、接第三方身份提供商，报道点名了两家身份厂商。这些控制会延伸到 Cloud Run、GKE 和托管端点。

以上数字都来自谷歌，属于厂商口径，报道没有交代测试方法，也没有第三方复现。

二、跟你有什么关系

做 agent 平台的人。 每 agent 一台虚拟机以前是奢侈品，因为空闲成本太高。暂停回收加共享内存这两招，把它变成了一笔能算的账。

管身份的人。 agent 数量一旦上千，权限不能再靠人配。能不能接进企业现有的身份系统是必须项，不是加分项。

算成本的人。 密度提升十倍，改变的是单位任务的基础设施成本，不是模型成本。两笔账要分开算。

三、怎么判断这套东西适不适合你

1. 先问你的 agent 需不需要内核级隔离。如果它只调接口、不执行代码，一个容器甚至一个进程就够了。隔离层级越高，冷启动和内存开销越大。
2. 看恢复时间够不够。500 毫秒对后台批处理完全够，对「用户按下去要立刻有反应」的交互式 agent 就偏慢。你的场景决定这个数字是优势还是短板。
3. 盘一遍身份。列出每个 agent 要访问哪些系统、用谁的凭证、多久轮换一次。这一步做完，才知道接身份系统是省事还是添事。
4. 等预览区。预览阶段通常有地域和配额限制，先确认你要落地的区域在不在名单里，再谈迁移。

四、三个别信的说法

「每个 agent 一台虚拟机，所以更安全。」 隔离解决的是「一个 agent 被攻破后能不能横向移动」，解决不了「这个 agent 本来就拿到了过大的权限」。后者靠策略，不靠虚拟化。

「密度十倍，成本就降十倍。」 十倍是单机可容纳的 agent 数量，不等于总成本降到十分之一。控制面、存储、网络和闲置配额都会吃掉一部分。

「暂停恢复快，就适合长任务。」 反了。频繁暂停适合短任务和突发流量；长任务反复挂起恢复，状态保存本身就是风险点。

五、一句话结论

把 agent 当虚拟机管，是这类平台从演示走向生产的分界线——它承认了两件事：agent 会闲着，也会失控。

信息来源

• Google's Agent Compute Engine gives every Gemini agent its own hardware-isolated micro VM，2026 年 10 月 22 日

功能与价格以官方公告为准。本文写于 2026 年 10 月 23 日。