谷歌给每个 agent 发一台硬件隔离的 microVM：凭据不进沙箱，空闲就挂起

谷歌把「agent 该在什么里跑」这件事的答案摊开了。跟我们自己搭沙箱时的取舍比一比，有几个地方值得直接抄。

ACE 的几个设计

每台 agent 一台 microVM，独立 guest 内核 + root 权限，隔离边界是硬件隔离的 Cloud Hypervisor，底层跑 Titanium（谷歌的 IPU）
凭据在 microVM 外部的出口注入。原文是 service credentials are injected in egress outside the microVM——沙箱内一份凭据都不存，每个 microVM 用短期凭据 + 加密验证过的 ID
空闲即挂起。agent 跑完一次工具调用进入「思考」阶段，或者等人工、等外部系统时，microVM 主动发出空闲信号，主机用快速检查点把它挪到闲置态；需要时从快照恢复
写时复制内存共享，多个 agent 跑在同一份操作系统模板上，省一台物理机能塞多少
每个 microVM 一块自己的 Hyperdisk，跨多次长会话持久化工作区和上下文
目前支撑 Gemini、Antigravity 与谷歌内部的模型评估、强化学习流程；公开 preview 还在「未来几个月」

今天能用的是另一个东西

同一篇博客里还放了个开源项目：Agent Substrate on GKE。它是 Kubernetes 原生的开源执行运行时，零信任架构，把 agent 执行与机器管理解耦。官方给的数字：

仓库地址官方写的是 http://ate.dev/ 。

对我有什么用

一人公司跑 agent，通常是在自己机器上开个 Docker 容器，把 API key 用环境变量塞进去，跑完手动清。这套做法有两个具体代价：

凭据在沙箱里。 容器里 env 一下、或者 agent 误读一个 .env，你的密钥就进了它的上下文、进了日志、进了它写的那行样例代码。谷歌的解法是把注入点挪到出口——沙箱内部根本没有可偷的东西。
空闲的 agent 白占资源。 agent 大部分时间在等模型返回、等你确认。谷歌让 microVM 主动声明空闲然后挂起，一台机器上能塞的 agent 数量就是这么翻上去的。

第 1 条今天就能抄，不需要 GKE。做法就一句话：把密钥从容器的环境变量里拿出来，改到出口代理那一层注入。

泼冷水

ACE 现在用不上。 官方明说 preview 在「未来几个月」，而且它最初只服务谷歌自己的产品。看到「硬件隔离 microVM」很兴奋之前，先记住这条。
Agent Substrate 要 GKE。 对一个人来说，为了跑几个 agent 去维护一套 Kubernetes 集群，大概率是亏的。它适合的场景是「你已经有一套 K8s，并且 agent 数量上到了几百」。
20 万 agent / 500 毫秒是谷歌自己的基准。 没有第三方复现，也没有说清硬件配置。当方向看，别当 SLA。
10 倍密度来自写时复制内存共享 + 快照，这招的前提是你的 agent 共享同一份系统模板。如果你的每个 agent 都要不同的依赖环境，这个倍数会掉得很快。
「凭据不进沙箱」换来的代价是复杂度。 出口代理要自己维护、策略要自己写。规模小的时候，一套干净的环境变量管理可能反而更省事——前提是你真的管得住。
Hyperdisk 持久化是双刃剑。 工作区跨会话保留很方便，但也意味着上一次会话留下的脏东西会跟着到下一次。沙箱「干净」这件事要自己保证。

具体建议

今天就能做的一件事：把 agent 容器的密钥从环境变量挪到出口层注入。哪怕只是在宿主机上跑一个代理，让容器拿不到明文 key。
给 agent 加一条「空闲即挂起」的规则：模型返回后超过 N 分钟没有新动作就停掉容器，状态存快照。N 设多少取决于你自己的等待习惯。
盘一遍你现在的 agent 能碰到什么：SSH key、云凭据、生产库连接串，凡是它用不到的都拿掉。谷歌那份清单里最该抄的不是 microVM，是「默认不给」。
已经在用 K8s 的，去 ate.dev 看一眼 Agent Substrate，重点看它的出口代理怎么实现——那部分即使不整体采用也能单独抄。
别因为谷歌发了 ACE 就把自建沙箱推翻。你现在那套容器方案如果跑得稳、凭据管得住，继续用；换架构的成本远高于它带来的收益，除非你的 agent 数量真的上到了三位数。