发生了什么
Google Cloud 在 10 月 22 日的 AGNTCon + MCPCon 上发布 Agent Compute Engine（ACE）：一个专为智能体设计的计算服务，每个智能体独占一台硬件隔离的 microVM，自带 guest 内核与 root 权限，边界由硬件隔离的 Cloud Hypervisor 守住，底层再叠 Titanium 卸载芯片。该服务已在支撑 Gemini 的工作型智能体、Antigravity 以及谷歌内部的模型评估与强化学习流水线；客户预览将在未来数月开放，定价与 SLA 尚未公布。
四件关键设计
- 单租户 microVM，不是容器：容器共享宿主内核，对需要内核级与 root 权限的编码智能体不合适；传统虚拟机隔离足够但启停要秒级到分钟级
- 零凭据沙箱：microVM 没有标准网络接口，也访问不到云元数据服务器，只持一张短期 SPIFFE 证书与可加密验证的会话身份
- 出网换票：所有外发流量经 Agent Gateway，校验用户委托链、智能体身份与节点身份，通过后再把真实凭据注入，后端只看到一次正常调用
- 持久工作区：每台 microVM 配独立 Hyperdisk，文件系统与上下文可跨轮次、跨天留存；空闲时 checkpoint 挂起，多台智能体写时复制共享同一份预热镜像
为什么密度成了核心指标
智能体的时间大多花在等待：等模型出下一个 token、等工具返回、等人审批。ACE 把这部分时间当作可回收资源，智能体进入思考阶段就发空闲信号，宿主机快照并转入闲置，下一条指令到达再从快照恢复。谷歌给出的数字是：20 万个智能体的基准中，暂停与恢复低于 500 毫秒，每秒可完成 500 次激活；同一套思路开源为 Agent Substrate 跑在 GKE 上，宣称密度最高可达传统方式的 10 倍。上述数据均为厂商自报，尚无第三方复现。
治理侧同步补齐
ACE 不是单独一个沙箱服务，而是与四个治理组件一起交付，这一点对企业架构决策比 microVM 本身更重要。
- Agent Gateway：按策略做模型路由，并对 token 与成本做管控
- Agent Registry：组织内已批准的智能体、工具、MCP 服务器、技能与端点的中央目录，未登记者不能运行，直指影子 AI
- Agent Identity：创建即签发 SPIFFE 身份，随每次模型调用、工具调用与智能体交接流转，审计可回溯到具体实例与授权用户
- Agent Observability：按 OpenTelemetry 的智能体语义约定输出遥测；并接入 Ping Identity、SailPoint 等第三方身份提供方
不确定之处与可借鉴点
待观察的有三处：一是「沙箱内没有任何可窃取之物」是设计目标，实际效果取决于 Agent Gateway 的策略是否覆盖了全部出网路径；二是跨云、本地机房与员工终端上的编码智能体仍在路线图上，落地时间未知；三是预览阶段没有价格，密度优势能否转成账单优势无法核算。
对国内企业，短期最值得借鉴的不是这套服务本身，而是它背后的威胁模型假设：先认定沙箱已被攻陷，再确保里面没有任何东西可被拿走。把「凭据不进执行环境、出网处统一换票」这两条落到自建的智能体平台上，成本远低于重建一套运行时。