Agent 大部分时间在等待：谷歌的 Agent Compute Engine 怎么调度
谷歌云介绍 Agent Compute Engine（ACE）与开源的 Agent Substrate：让空闲的 Agent 挂起、把机器让给别人；ACE 对外预览要等“未来几个月”。
一、Agent 一天里有多少时间在干活？
先问大家一个问题。
一个 AI Agent 一天里，真正在占用 CPU 干活的时间有多少？
大家猜猜看。
答案可能出乎意料：大部分时间，它都在等。
等模型想好下一步（也就是"思考"阶段）。
等工具调用返回结果。
等人类点一下"批准"。
等某个外部系统回复。
真正需要算力的，只是夹在这些等待中间的一小段。
如果给每个 Agent 都配一台一直开着的虚拟机，大部分时间这台机器都空转着。
Agent 少的时候，这不是问题。
一旦 Agent 多到成千上万，空转的机器就变成了一笔大开销。
10 月 22 日，谷歌云发了一篇博客（Introducing Agent Compute Engine and expanded agent governance），介绍了两样东西：Agent Compute Engine（简称 ACE）和 Agent Substrate。
两者想解决的就是这个问题：让 Agent 不干活的时候，不占着机器。
本文只谈调度和密度。
ACE 在隔离方面也做了不少设计，官方列了 Titanium IPU、Cloud Hypervisor、独立内核、每个 microVM 一个身份、在出口处注入的短期凭证等。本文不展开，有兴趣的读者可以看原文。
二、ACE：会"打盹"的 microVM
先说 ACE。
据谷歌官方介绍，ACE 目前只用在谷歌自己的产品上，承载 Gemini 的办公类 Agent，客户还不能拿来跑自己的 Agent。对外的预览版要等"未来几个月"。
也就是说，它现在还不能直接用。
它的核心是 microVM，也就是一种启动很快的轻量虚拟机。
ACE 在 microVM 上做了几件事。
（1）共享模板，写时复制
成千上万个 Agent，跑的操作系统几乎一模一样。
如果每个 Agent 都把整套系统完整地装进自己的内存，就太浪费了。
ACE 的做法是写时复制（copy-on-write）：所有 Agent 共享同一个操作系统模板的内存，只有某个 Agent 要改动其中某一块时，才给它单独复制一份。
打个比方，这就像全班同学共用一本教科书，谁想在哪一页上写笔记，就只复印那一页，其他页照旧大家一起看。
（2）想的时候，先睡一会
一个 Agent 调完工具，进入"思考"阶段，等模型给出下一步。
这时，microVM 会主动向宿主机发信号：我现在闲着。
宿主机收到信号，就可以把它暂停。
等待人类审批、等待外部系统回复的时候，也是同样的处理。
等到需要它继续干活，再从快照迅速恢复。
这有点像电脑的"睡眠"和"唤醒"：合上盖子不等于关机，打开盖子，刚才的窗口都还在。
（3）工作区跟着 Agent 走
暂停和恢复的前提是，Agent 的东西不能丢。
ACE 给每个 microVM 配了一块独立的 Hyperdisk 持久化工作区，用来保存它的文件和上下文。
所以，机器可以睡，Agent 的"记忆"不会断。
三、Agent Substrate：在 Kubernetes 上做同样的事
ACE 是谷歌云自己的服务。
如果你不在谷歌云上，或者想自己掌控，怎么办呢？
谷歌这次还开源了 Agent Substrate（GitHub 仓库 agent-substrate/substrate，谷歌博客里的开源链接指向这里）。它可以跑在 GKE 上，也可以跑在任意 Kubernetes 上。
它的思路和 ACE 一脉相承。
（1）闲了就归还机器
Agent 空闲时，Substrate 会把它的内存做成快照，然后把机器还回资源池，让给别的 Agent。
需要的时候，再从快照恢复。
这就像图书馆的座位：人走了，书包收进储物柜，座位让给下一位，回来再取书包，找个空位继续读。
（2）密度和基准
官方称，这样做能把密度提高到最多约 10 倍。
官方还给了一个基准测试：20 万个 Agent 的规模下，持续每秒 500 次激活，挂起和恢复都在 500 毫秒以内。
这些数字都是谷歌自己测的，属于厂商自报。
（3）隔离方式和 harness 都可以选
隔离可以用 microVM，也可以用 gVisor。
上面跑什么 Agent 框架（harness）都行，官方点名了 Claude Code、OpenClaw 和 Hermes。
多个 Agent 需要协作时，可以挂 Filestore 卷，共用一个工作区。
官方提到，Nous Research 的 Hermes Enterprise 已经用上了 Substrate。
这里值得多说一句。
调度层不挑 harness，意味着它管的是"机器怎么分"，不管"Agent 怎么想"。
这是一种很经典的分层：底下的人只负责把座位排好，至于坐上去的人看什么书，它不过问。
这样做的好处是，Agent 框架换来换去，底下的调度不用跟着重写。
四、Agent 多了，还要管得住
调度解决的是"跑得起"，治理解决的是"管得住"。
这篇博客也顺带更新了治理工具。
现有的组件包括 Agent Gateway、Registry、基于 SPIFFE 的身份，以及 OTel 可观测性。
即将推出预览的有三项：
- 跨云的 Envoy 策略执行点
- 面向托管设备上 Claude Code、Antigravity CLI 的操作系统级沙箱
- 按 Agent、按模型的 token 预算和模型路由
最后一项和本文的主题关系最近。
机器的账可以靠调度省下来，token 的账也需要有人管。按 Agent 设预算、按任务挑模型，是同一个思路在另一层的延伸。
官方提到的客户里有欧莱雅（L'Oréal）。
五、我的看法
过去我们给程序分配资源，默认它是"一直在跑"的。
Web 服务器是这样，数据库也是这样。
Agent 打破了这个默认。它更像一个上班的人：大部分时间在开会、在等回复、在想事情，真正敲键盘的时间不多。
ACE 和 Substrate 的思路，就是承认这一点，然后把等待的时间换成别人的运行时间。
这不是什么全新的发明。写时复制、快照、资源池都是很老的技术。
操作系统里，进程挂起和恢复早就是家常便饭；云计算里，虚拟机按需分配也做了很多年。
新的是把它们组合起来，专门对付"大部分时间在等"这种负载。
需要提醒的是，ACE 对外还只是"未来几个月"的预览，Substrate 的数字是厂商自报。真实效果，还要看自己的负载跑出来是什么样。
如果你正在 Kubernetes 上跑大量 Agent，苦于机器大部分时间闲着，可以试试 Agent Substrate。
（完）
来源：Google Cloud 官方博客（2026-10-22）；GKE 官方博客；Agent Substrate GitHub 仓库。ACE 目前只用于谷歌自家 Gemini 产品，对外预览要等未来几个月，尚不可用；密度最多约 10 倍、20 万 Agent、每秒 500 次激活、500 毫秒以内挂起恢复均为谷歌自测自报，未见第三方复测；比方为作者所加。