智能体最危险的时刻，不是它开始执行代码的时候，而是它拿到凭证的那一刻。
10 月 22 日，谷歌在 AGNTCon + MCPCon 上正式发布 Agent Compute Engine（ACE），一个专为 AI 智能体打造的计算引擎。官方口径很克制：为智能体提供硬件隔离的 microVM 运行环境，已在内部为 Gemini 的 agent 任务提供动力，并将在未来几个月面向开发者开放 preview。但把这件事放进更大的图景里看，谷歌真正想说的是另一件事，智能体战争已经打到基础设施层了。
过去两年，行业把注意力几乎全部押在模型上。更大的参数、更低的推理成本、更长的上下文。但谷歌用 ACE 告诉我们，当智能体开始写代码、调用工具、驱动浏览器、编排企业工作流时，真正的瓶颈不再是模型本身，而是承载智能体生死的计算底座。
现象：谷歌把智能体关进了硬件笼子
ACE 的核心动作并不复杂：给每个智能体分配一台独立的微型虚拟机（microVM），用 Cloud Hypervisor 划出一道硬件级隔离边界。每个 microVM 有自己的 guest kernel、自己的 root 权限、自己经过加密验证的身份，还有一块独立的 Hyperdisk，用来持久化执行工作区和智能体上下文。
这套设计的杀伤力落在两个数字上。在 20 万智能体的基准验证中，ACE 实现了每秒 500 次激活，暂停与恢复延迟低于 500 毫秒。也就是说，当一个智能体完成一次工具调用、进入“思考”阶段等待人类或外部系统响应时，宿主机可以立刻把它从活跃态切到空闲态，释放算力；等它被再次唤醒，不到半秒就能回到现场。
这正是智能体与传统工作负载最本质的区别。传统云服务器追求“常开”，智能体追求的是“高频启停”。一个智能体在一次任务中可能触发几十次工具调用，每次调用之间都是等待。如果每次等待都要占用一整台虚拟机，成本会失控；如果为了省成本把智能体塞进普通容器，一旦智能体执行了不受信的代码，整个宿主就可能沦陷。
谷歌的选择是都要。用 copy-on-write 内存共享让多个智能体跑在同一个操作系统模板上，压低密度成本；同时用硬件隔离保证任何一个智能体被攻破，都逃不出自己的 microVM。谷歌云基础设施团队在官方博客中写道，当智能体完成工具调用进入“思考”阶段，microVM 会发出空闲信号，宿主机随即通过快速 checkpoint-and-restore 把它切走，空闲状态下的智能体在宿主机上不消耗任何活跃资源。
凭证，比代码更致命
ACE 最容易被忽略、也最值得玩味的设计，是凭证的注入位置。
谷歌明确写道：每个 microVM 使用短期凭证，而服务凭证是在 microVM 之外的 egress 路径注入的（service credentials are injected in egress outside the microVM）。这句话翻译成人话就是，智能体自己拿不到云服务的长期密钥，它要访问企业数据时，请求先走出沙箱，由外部的身份代理替它完成认证。
这不是过度设计。智能体安全领域已经反复证明，真正的风险从来不是智能体“想作恶”，而是它被提示注入攻击诱导后，在不知情的情况下把宿主环境里的凭证交出去。谷歌在技术深潜文章中进一步披露了这套边界的细节：microVM 没有标准的虚拟网卡、默认网关或直接访问 VPC 的能力，所有进出流量必须经过一条隔离的点对点 IPC 边界（virtio-vsock），终点是一个本地的无特权调解代理，再转发到外部网关；外部网关会校验请求的作用域，并执行严格的策略驱动外发代理。控制面命令和智能体的外发连接全部包裹在双向认证的 mTLS 隧道里，私钥签名被安全地保留在 guest microVM 之外。
把凭证从沙箱内部挪到 egress 代理，等于在智能体和企业的核心资产之间加了一道不会说谎的门卫。门卫掌握密钥，智能体只掌握“我要做什么”的意图。这道设计，比任何模型层的内容过滤都更接近问题的根源。
谷歌在下一盘什么棋
ACE 不只是一个新产品。它是谷歌把 Gemini 的内部实践产品化的一次摊牌。
官方博客写得直白：ACE 已经为 Gemini 的 agent for work 任务提供动力。这意味着谷歌在把 Gemini 扩展到“星球级规模”（planet scale）的过程中，先被智能体的高并发、高 churn 会话逼出了这套架构，现在把它打包成云服务卖给企业。Gemini 副总裁兼 Google Fellow Gautham Thambidorai 在博客中评价：“把 Gemini 智能体扩展到星球级规模，需要能够快速启动、以极高效率运行的计算。Agent Compute Engine 的 microVM 给了我们所需的响应速度、硬件隔离和工作负载密度，才能把交互式智能体沙箱交付给全球用户。”
更值得注意的是一明一暗两条线。明线是 Agent Compute Engine，托管在谷歌云上，适合那些不想操心底层、只想快速上线的企业；暗线是 Agent Substrate，一个开源、Kubernetes 原生的执行运行时，已经登陆 GKE，可选 microVM 或 gVisor 两种隔离方式，官方宣称相比传统计算密度高达 10 倍。
这一明一暗的组合拳，暴露了谷歌的真实意图：既要吃托管服务的钱，也要抢开发者的心。对于已经标准化在 Kubernetes 上的平台团队，Agent Substrate 给你定制化和多云可移植性；对于追求开箱即用的企业，ACE 给你硬件隔离和统一的身份治理。无论客户怎么选，谷歌都在智能体执行的必经之路上设了收费站。
基础设施层的竞争才刚刚开始
把视线拉远，智能体基础设施正在成为新的兵家必争之地。
AWS 早在 Lambda 时代就用 Firecracker microVM 证明了轻量隔离的可行性；Kata Containers 把 Firecracker、Cloud Hypervisor、QEMU 等多种 VMM 整合进 Kubernetes 生态；gVisor 则在容器和虚拟机之间走出第三条路。谷歌 ACE 的技术选型并不意外，Cloud Hypervisor、microVM、Hyperdisk，都是谷歌云已有的成熟积木。真正的新意在于，谷歌是第一个把这套积木按智能体的生命周期重新组装，并公开性能标尺的主流云厂商。每秒 500 次激活、500 毫秒内恢复、10 倍密度，这些数字给整个行业立了一个可被比较的基准。
接下来，AWS、Azure 以及国内云厂商会怎么应？它们会不会跟进 microVM 路线，还是押注容器沙箱？这会是 2027 年云计算市场最值得关注的答案之一。
也要看到 ACE 的局限。它目前仍处于即将开放 preview 的阶段，真实企业负载下的表现、定价模型、与现有云服务的集成深度，都还是未知数。更重要的是，隔离做得再好，也只是解决了“智能体不乱跑”的问题；智能体“做对事”的问题，任务规划、工具选择、错误恢复，仍然取决于模型本身的能力。基础设施是必要条件，不是充分条件。
谁会被改变
ACE 的发布，标志着 AI 竞争的焦点正在从模型层下沉到执行层。
短期看，受益最明显的是两类公司：一类是需要大规模运行智能体、又对安全合规敏感的企业，它们终于有了硬件隔离的托管选项；另一类是已经在智能体沙箱、凭证代理、执行观测等细分赛道布局的创业公司，谷歌的入局会教育市场，也会带来合作与收购的机会。
危险的是那些还停留在“调个 API 就上线智能体”的团队。当智能体开始进入企业核心流程，安全、审计、身份治理会成为硬门槛，草台班子会被迅速淘汰。
长期看，谁掌握了智能体的执行底座，谁就掌握了智能体经济的过路费。模型可以开源，权重可以蒸馏，但承载智能体生死的计算环境，企业不敢交给陌生人。
智能体时代的护城河，可能不在模型参数里，而在每一次暂停与恢复的 500 毫秒之间。谷歌已经率先把智能体关进了硬件笼子，接下来要回答的问题是，当笼子足够安全，智能体是否还愿意在里面跳舞。
快报