Google Cloud 为 Agent Runtime 提供了不可变版本和基于百分比的路由

Why it matters

Agent deployments need the same rollback and canary-release controls as other production software. Google is building those controls into its managed runtime, with Preview-stage limits and added capacity costs.

Google Cloud 在 7 月 6 日前为 [Agent Runtime] 增加了不可变修订和基于百分比的流量拆分，给开发者提供了一种在不替换正在运行的引擎、资源名称或端点的情况下发布新代理代码的方式。

该功能在周一通过一篇 Google Cloud Tech 在 X 上的帖子 再次浮出水面，距离 Dani Zamora 发布一篇 技术演练 已接近一个月。时机很重要，因为 Google 正在将其托管代理基础设施定位于那些需要在传统云应用中已成为标准的发布控制的工作负载。

Google 的实现会在开发者更改有版本字段时创建一个不可变快照。这些字段包括打包代码、依赖项、Python 版本、环境变量、伸缩限制、容器并发、身份配置和 agent cards。旧的修订在被弃用或删除之前保持可用。

端点保持固定，而流量在其后面的修订之间移动。开发者可以将所有请求指向最新版本，或配置手动的百分比拆分，前提是分配之和为 100%。团队可以将 10% 的请求发送到新代码，将其行为与现有发布进行比较，逐步增加占比，并在不创建另一次部署的情况下回滚流量。

这一机制把代理更新变成了可量化的生产实验。当团队更换模型、重写指令、添加工具或更改编排代码时，代理行为可能会发生重大变化。稳定的端点和并发修订允许开发者在实时流量上比较延迟、任务完成情况、工具失败和用户偏好，而不是立即进行全车队替换。

围绕代理状态构建的发布系统

Agent Runtime（先前称为 Agent Engine）将代理代码打包进容器，而 Google Cloud 处理包括托管会话、内存、伸缩、代码执行、身份、可观测性和私有网络在内的基础设施。修订将该托管层扩展到软件交付领域。

Zamora 的示例在同一个引擎上部署了两个版本的研究代理。第一个使用 Google Search 生成快速简报。第二个启动了一个更慢的 Deep Research 作业并返回一个用于检索报告的句柄。Zamora 随后在保持单一 URL 的同时对两者进行了流量拆分。

在使用 50/50 配置的十几次测试请求中，有七次命中更快的版本，五次启动了更深入的研究流程。小样本并不能确立性能，但它展示了路由模型：不同的代理实现可以在同一个生产资源后端同时运行。

Google 在一个 开源演示仓库 中发布了配套代码，包括用于创建引擎、用修订更新它、列出修订以及通过 Vertex AI SDK 更改流量分配的脚本。

该演练也暴露了开发者需要预算的一项容量限制。手动流量拆分会保持每个目标修订处于“热”状态。Zamora 的第一次尝试失败是因为部署只允许一个实例，留不出第二个修订的容量。增加实例范围解决了该失败。这意味着更安全的逐步发布在测试期间可能需要额外的运行容量。

流量设置本身并不具版本化。更改拆分会在不下发代码或生成另一个快照的情况下将请求重新路由到现有修订。Google 还警告开发者弃用或删除旧修订，以免它们消耗配额或以过时代码和潜在的安全问题继续可访问。

Google 仍在测试界面

Google 将 [revisions and traffic splitting] 标记为受其 GA 前条款约束的 Preview 功能。这些控制通过 v1beta1 API 提供，这意味着字段名称、行为和支持承诺仍可能发生变化。Zamora 还指出命令行部署工具尚未直接暴露流量拆分，演示需要使用 Vertex AI SDK。

这一补充使 Google 在云平台竞争中更进一步，竞争点在于在开发者完成原型后谁来运营生产代理。[Amazon Bedrock AgentCore] 提供带有隔离用户会话的托管运行时，而 [Microsoft Foundry Agent Service] 则运行容器化代理代码并提供托管伸缩、会话持久性、身份和可观测性。

修订控制的可见度低于新模型发布，但它们解决了决定代理能否在生产中存活的运营工作。Google Cloud 正在为团队提供一条受控路径，以修补代理代码、测试竞争行为并在保留端点和围绕工作负载的有状态基础设施的同时回滚失败的发布。