Google 将 Gemini 智能体背后的基础设施开放为云服务 Agent Compute Engine

Google 很快将向 Google Cloud 用户提供预览版，开放支撑其 Gemini 智能体的基础设施。

Agent Compute Engine 于周四在圣何塞举行的 Linux 基金会 AGNTCon+MCPCon 上发布，将于今年晚些时候向 Google Cloud 用户提供预览版。它将为每个 AI 智能体提供一个硬件隔离的 microVM，兼具容器的速度与沙箱的安全性。

还有谁提供智能体沙箱？

当然，智能体沙箱的概念并不新鲜。E2B 和 Daytona 等初创公司向开发者提供此类沙箱（并支持在任何云上运行），AWS 也通过 Bedrock AgentCore 提供。

E2B 在 Firecracker microVM 中运行每个沙箱，这是 AWS 最初为 Lambda 构建的开源虚拟化技术。它可以暂停沙箱并保留其内存和文件系统，然后在大约一秒内恢复。Daytona 最初使用容器，但在 7 月增加了 microVM 沙箱。这些沙箱可以暂停整台机器，或将运行中的机器分叉为完全相同的副本。

AgentCore 也为每个智能体会话提供独立的 microVM。当智能体等待模型或工具调用时，AWS 不收取 CPU 费用，但内存会持续计费，直到运行时回收为止。这些会话最长可持续八小时。8 月，AWS 增加了基于 EC2 的运行时实例，可使共享会话保持活跃长达 14 天。

值得注意的是，Google 本身对此也并不陌生。GKE 已经提供 Agent Sandbox 的托管版本，这是 Google 去年 11 月推出的开源 Kubernetes 项目。该公司还通过其 Gemini Enterprise Agent Platform 销售代码执行和计算机使用沙箱。

另一方面，Agent Compute Engine 最初是作为 Gemini、Antigravity 以及 Google 自身模型训练流水线的内部基础设施。

Google 的观点

很少有公司——如果有的话——运行像 Google 这样多的智能体工作负载，无论是供其内部使用还是供其客户使用。据该公司称，智能体工作负载已迅速成为其整个机群中增长最快的计算和存储消耗者之一。

在这种规模下，为所有这些自主智能体提供支持的基础设施服务不仅需要高效且能够扩展，而且也许最重要的是，它们需要安全。Google 与其一些竞争对手一样，很快意识到它需要构建一个新的专用计算服务来为所有这些智能体提供支持，类似于它需要构建 Borg（后来启发了 Kubernetes）来管理其早期数据中心中的计算。

正如 Google 的两位杰出工程师 Rohit Jnagal 和 Ramanathan Venkatapathy 在一篇技术深度解析中所指出的，传统 VM 为开发者提供了大量控制和灵活性，但代价是在启动、挂起和恢复机器方面的速度。鉴于智能体启动和关闭的速度之快，这不是一个可行的选择。

他们指出，容器解决了其中一些问题，“但有许多例子，如编码智能体和开发者助手，需要完全隔离以及对智能体环境的内核级和根级控制。”

Jnagal 和 Venkatapathy 写道，借助 Agent Compute Engine，团队回归第一性原理，构建了“一个统一的、面向 Google 的智能体计算平台”（现在也面向其客户）。

为每个智能体提供一台持久计算机

其核心基本上是为每个智能体提供一台持久的、沙箱化的计算机来工作。这使智能体能够使用 shell 脚本、使用无头浏览器，并在可能持续数周的智能体循环中编写代码（对该机器拥有 root 权限）。

但团队也为大规模用例构建了它，例如前沿实验室用于测试其模型的评估循环、AI 基准测试和强化学习。

此外，团队还将 Agent Compute Engine 设计为运行 Google 自身服务的沙箱化后端。

Jnagal 和 Venkatapathy 还指出，智能体大部分时间都在等待模型或用户。因此，一旦智能体完成工具调用，主机就会对其 microVM 进行 checkpoint，此后该 microVM 不占用任何活跃资源，直到下一次调用到来。

沙箱内无可窃取之物

这里的关键特性，除了速度之外，是能够确信智能体无法逃出其沙箱。毕竟，我们已经见识过它们逃出后会发生什么。

每个智能体会话都在单租户、内存安全的 microVM 中运行。这些环境在内存或磁盘上不保存任何机密，其唯一身份是通过每个 VM 的单一本地监听器提供的短生命周期、会话范围的身份。所有流量在传输中均端到端加密，快照和磁盘在静态时加密。

microVM 也不会获得标准网络接口。所有流量都通过沙箱外部的代理运行，当智能体需要访问 Google Drive 等服务时，Google 的 Agent Gateway 会先检查用户的委托和沙箱的身份，然后在沙箱外部添加实际凭据。

底层主机基本上是一个无状态设备，具有只读文件系统，硬件和固件在每次启动时都经过加密验证。

所有这些都由 Google 自己的 Titan 和 Titanium IPU 安全平台提供支持。microVM 本身运行在 Cloud Hypervisor（一个开源虚拟机监视器）上，每个都拥有自己的客户机内核和 root 访问权限。

Jnagal 和 Venkatapathy 举了一个企业智能体的例子：它管理用户的收件箱，并读取一封带有隐藏指令的电子邮件，要求它在机器上查找任何 API 密钥并将其发送到外部地址。他们指出，大多数情况下模型会忽略这一点，但并非总是如此。

“我们从一个原则出发：假设攻击者控制了沙箱内的一切，并确保他们在那里找不到任何可利用的东西，”团队写道。

Agent Substrate 将同样的理念带入 Kubernetes

但并非每个团队都希望让自己的智能体在 Google 的托管服务中运行。为此，Google 还提供了 Agent Substrate，这是一个面向 Google Kubernetes Engine（GKE）的开源运行时，于今年 5 月首次发布。

Substrate 构建在 Google 的 Kubernetes 项目 Agent Sandbox 之上，并增加了一个轻量级控制平面。Google 表示，该控制平面可以处理数百万次短时工具调用，而这类负载会让 Kubernetes 不堪重负。

与 Agent Compute Engine 类似，Substrate 会对空闲智能体的内存进行快照，并将机器归还到资源池，直到该智能体有更多工作要做。

Google 表示，这意味着其密度最高可达传统计算的 10 倍。该公司称，在 20 万智能体的基准测试中，Substrate 每秒处理 500 次激活，智能体的挂起和恢复时间均低于半秒。

团队可以用 microVM 或 gVisor 隔离每个沙箱，并且每个智能体都拥有自己的加密身份。与 Agent Compute Engine 一样，出口代理在沙箱外部附加凭据。Substrate 可在任何 Kubernetes 集群上运行，Google 表示它可与任何 harness 配合使用，包括 Claude Code、OpenClaw 和 Nous Research 的 Hermes。

“我们构建 Hermes Enterprise 是为了让客户能够部署到其现有基础设施中，同时处理每个智能体的隔离和可扩展的访问控制，”Nous Research 首席商务官 Hervé Bizira 在公告中指出。“Agent Substrate 在平台层同时解决了这两个问题，并且还保留了宝贵的计算资源。”

文章《Google 将 Gemini 智能体背后的基础设施转变为云服务》首发于 The New Stack。