登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

Google Cloud Next 2026 的 Agent Platform 解决了什么治理问题

来源:17golang原创

时间:2026-09-08 01:39:32 391浏览 收藏

Google Cloud Next 2026 的 Agent Platform,重点解决的不是“再提供一个模型调用入口”,而是企业代理一多之后出现的身份不清、工具失控、运行不可追踪和质量难回归。Google 在 2026 年 4 月 22 日公布 Gemini Enterprise Agent Platform,将 Vertex AI 的模型能力与代理集成、DevOps、编排和安全能力合并到一条生产路径中。

如果团队只是试验一个聊天机器人,平台的治理能力可能显得过重;如果代理要访问 CRM、数据仓库或业务工具,并且需要长期运行、审计和多人协作,Agent Platform 的价值就在于把“能运行”推进到“可管、可查、可优化”。
要点速览
  • Agent Identity、Agent Registry、Agent Gateway 对应身份、资产和连接三个治理入口。
  • Agent Runtime、Memory Bank、Agent Sandbox 主要补齐长流程、长期上下文和隔离执行边界。
  • Simulation、Evaluation、Observability 把上线前测试、线上评分和执行追踪连成闭环。

企业代理为什么需要单独的治理层

传统应用通常能把用户、服务账号、接口权限和日志挂到明确的调用链上。代理系统却可能自主选择工具、委派子代理、保留跨会话记忆,甚至执行模型生成的代码。此时只给每个服务配置一个密钥,无法回答“哪个代理在什么授权下做了什么”,也很难在工具版本变化后重新评估整条链路。

Agent Platform 的产品定位因此发生了变化:开发者仍可在 Agent Studio 中低代码搭建,也可用升级后的 Agent Development Kit(ADK)编写图式代理逻辑;但平台同时把身份、注册、网关、运行时和安全检测纳入同一控制面。它针对的是代理车队,而非某个孤立的 Prompt。

Gemini Enterprise Agent Platform 中代理身份、注册目录、网关与安全策略连接企业工具的治理平面示意图
图1:把代理身份、批准资产和跨环境连接放到同一治理平面后,团队才有统一的审计入口。

三项治理能力分别补上什么缺口

能力解决的治理问题工程团队应关注什么
Agent Identity代理无法被稳定识别,操作难以追责身份是否唯一、授权是否能映射到动作
Agent Registry内部代理、工具和技能分散,未经批准的资产容易被复用谁能发布、发现和下线资产
Agent Gateway代理跨环境连接工具时,策略和防护不一致连接策略、Model Armor、防提示注入和数据泄漏
Agent Security异常推理、恶意连接和依赖漏洞不易集中发现异常检测、威胁检测及底层包扫描的责任边界

这张表也说明了公告的核心取舍:平台没有把治理简化成一个“允许/拒绝”开关,而是把资产管理、连接控制和风险发现拆开。团队可以据此建立职责分工:平台组维护注册和网关,安全组维护策略与告警,业务组对代理目标和人工介入点负责。

从试验走向生产,还要看运行与质量闭环

治理只是上线门槛,生产代理还要解决两个问题。第一是状态:官方介绍的 Agent Runtime 支持长时间运行的代理,Memory Bank 用于持久化长期上下文,Agent Sessions 则可用自定义会话 ID 把交互映射回内部 CRM 或业务记录。第二是执行边界:Agent Sandbox 为运行模型生成代码和浏览器操作提供隔离环境,降低直接触碰宿主系统的风险。

质量侧则由三层组成:Agent Simulation 在受控环境中用合成交互和虚拟工具做上线前测试;Agent Evaluation 对真实流量进行多轮评分;Agent Observability 提供执行追踪,帮助定位复杂代理链路。公告还提到 Agent Optimizer 会聚类线上失败并提出系统指令改进建议。这里要注意,自动建议不等于自动上线,关键流程仍应保留人工审批和回归样本。

从 Agent Studio 和 ADK 构建代理,经 Agent Runtime 运行,再由 Simulation、Evaluation 与 Observability 回流优化的生产闭环
图2:Agent Platform 的开发影响在于把构建、运行、评估和可观测性安排到连续的生产闭环中。

开发团队是否迁移,可先做这份检查

Google 表示 Vertex AI 的服务与后续路线将通过 Agent Platform 交付。对已有 Vertex AI 项目,迁移不应只看 API 名称是否相同,而要按以下顺序盘点:

  1. 列出代理、模型、工具、数据源和服务账号,先确定哪些资产需要登记和唯一身份。
  2. 为高风险工具画出网关边界,明确哪些动作必须人工确认,哪些数据不能离开既定环境。
  3. 把长流程的状态、会话 ID、记忆保留期限和恢复策略写进设计,而不是只依赖 Prompt。
  4. 准备一组真实失败样本和安全样本,分别接入模拟、评估与线上追踪,再比较迁移前后的可解释性。
  5. 先选低风险、可回滚的业务试点;价格、区域、配额和具体 GA 范围以 Google Cloud 文档与控制台实际信息为准。

因此,Agent Platform 解决的是企业代理规模化后的“控制面缺失”:谁在运行、能调用什么、出了问题如何追踪、效果如何持续改进。它并不会替团队自动完成权限设计、数据分类或业务验收,这些仍是迁移计划中必须明确的工程责任。

相关问题

Agent Platform 是 Vertex AI 的替代品吗?

官方将它描述为 Vertex AI 的演进,并表示后续 Vertex AI 服务与路线将通过 Agent Platform 提供。具体项目的兼容性仍应以对应文档和迁移说明为准。

它只适合大型企业吗?

公告面向需要构建、扩展、治理和优化代理的技术团队。小团队也能使用构建能力,但只有当代理涉及多工具、长期状态或审计要求时,治理组件的投入才更容易体现价值。

Agent Evaluation 能替代人工测试吗?

不能。它能扩大多轮样本的持续评分范围,但业务规则、危险动作和上线放量仍需要人工定义验收标准。

参考:Google Cloud Next ‘26 官方汇总Google Cloud Blog:Introducing Gemini Enterprise Agent Platform

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>