当 Agent 从演示走向生产，算力隔离与凭证管理正在成为比模型能力更现实的瓶颈。Google Cloud 给出的答案是：一个 Agent，一台虚拟机。
发生了什么
Google Cloud 宣布推出 Agent Compute Engine，这是一项为 AI Agent 设计的计算服务。其核心设计是：每个 Agent 运行在独立的、硬件级隔离的 microVM 中，并且虚拟机内部不保存任何凭证。据 MarkTechPost 报道，该服务目前已在内部运行 Gemini 系列 Agent，并计划在未来数月进入预览阶段。
官方披露的信息相当克制，没有给出实例规格、计费方式或具体可用区域，因此现阶段更适合把它理解为一种架构主张，而非可直接评估的产品。
为什么重要
过去一年，Agent 的落地路径基本是“在容器里跑一个带工具调用的循环”。问题在于，容器共享内核，隔离强度有限；而 Agent 恰恰是最不该被信任的执行体——它会读外部网页、调用第三方 API、执行模型生成的代码，攻击面远大于传统服务。一旦某个 Agent 被提示注入攻破，横向移动的成本取决于它和邻居共享了多少东西。
microVM 的思路是把隔离边界下沉到硬件虚拟化层，用接近容器的启动速度换取接近虚拟机的安全边界。这在云厂商中并非全新概念，但把它明确绑定到“每个 Agent 一个实例”的产品形态上，是第一次。
更值得注意的细节是“内部无凭证”。Agent 需要访问数据库、调用云 API，传统做法是把密钥塞进环境变量，这也正是 Agent 泄露事故最常见的来源。把凭证从执行环境中彻底移除，意味着鉴权必须由外部代理完成——这是一次对 Agent 安全模型的重新划分：执行环境被默认为不可信。
影响与看点
对开发者而言，短期影响有限，因为服务尚未开放；但方向性信号很明确——Agent 的运行时会逐渐从“你自己搭的容器编排”转向云厂商托管的安全沙箱。如果这一模式成立，Agent 框架的竞争焦点会从编排能力转向与云上身份体系的耦合深度。
对行业而言，这实际上是在为 Agent 建立一套类似“函数计算”的抽象：无状态、短生命周期、强隔离、外部鉴权。区别在于，函数计算的触发者是请求，而 Agent 的触发者是模型决策，后者对运行时长和状态保持的要求更高，这也是 microVM 而非纯函数方案的原因。
需要观察的点有三个：一是冷启动与并发密度能否支撑 Agent 频繁的工具调用；二是外部凭证代理的延迟会不会成为新瓶颈；三是这套模型是否会与 Google 自身的 Agent 开发框架形成事实绑定，从而影响跨云可移植性。
一个独立判断：Agent 安全正在从“提示词层面的防护”转向“基础设施层面的默认不信任”，而后者才可能真正推动企业把 Agent 放进生产环境。
