在 Google Cloud Next '26 上，Google 随 Gemini Enterprise Agent Platform 一同推出了 Agent Gateway（预览版）——第一个来自主流云厂商的「协议原生」agent 网关。它和传统 API 网关的本质区别只有一句话：网络层不再只是搬运流量，而是理解流量想干什么。

从「看 IP 和 Header」到「看工具调用」

传统 API 网关工作在 HTTP 层：看 IP、Header、路径，最多做限流和鉴权。但当企业里的智能体开始通过 MCP 调用工具、通过 A2A 互发消息时，真正需要管控的粒度是「哪个 agent 可以调用哪个工具」——这层信息藏在协议报文里。

Agent Gateway 基于 Envoy 和 Kubernetes 构建，遵循标准 K8s Gateway API，保持开放可扩展。它原生解析两种协议：

• MCP：解析工具调用的具体方法名和工具名；
• A2A：解析 agent 之间的消息语义。

解析出工具名、模型 ID、agent 身份后，就可以在协议层做细粒度 RBAC。官方给出的例子：通过 SPIFFE 身份 + mTLS 握手验证 agent 身份，经 deframing filter 拆解 MCP 报文，提取请求的 method 与 tool name，然后强制执行策略——某个 agent 只允许调用被批准的那几个 GitHub MCP 工具，其余一律拒绝。

配套的安全底座

单点网关解决不了全部问题，Google 把它嵌进了一整套治理体系：

• Model Armor：统一防御 prompt 注入、工具投毒、敏感数据外泄；
• Agent Identity：给非人类实体发放密码学身份 ID，agent 的每个动作都有可审计的痕迹；
• Security Command Center：自动发现未纳管的 agent 工作负载——包括跑在 Cloud Run 和 GKE 上的 agent 与 MCP 服务器，先把「影子智能体」找出来；
• Wiz 集成：扩展多云发现能力，覆盖 AWS AgentCore、Gemini Enterprise、Azure Copilot Studio、Salesforce Agentforce；
• 三个新的安全智能体（威胁狩猎、检测工程已在预览，第三方上下文即将推出），加上已投产的 Triage and Investigation agent——后者过去一年处理了超过 500 万条告警，把平均 30 分钟的人工分析压到 60 秒。

协议生态的节点时刻

两个背景数据让这个发布更有分量：A2A v1.0 已在 150 家组织投入生产，并归入 Linux Foundation 旗下的 Agentic AI Foundation；Google 自己的全线服务已默认 MCP 化，BigQuery、Compute Engine、GKE、Security Operations 的托管远程 MCP 服务器均已 GA。

为什么值得关注

这是对本周 MCP 安全议题的直接回应。 前几天刚有研究披露 MCP 协议级的信任漏洞——恶意提示词可以借 agent 之间的信任链路传播（详见 #514）；而上周还有对 Top 20 MCP 服务器的扫描发现，近半数在工具描述里夹带「指挥性文本」。协议层的治理缺口是真实的，Agent Gateway 给出的答案是：把安全策略下沉到协议解析层，而不是在网络层装看不见协议内容的防火墙。

企业 agent 架构有了「空中管制」的雏形。 当智能体从玩具走向生产，困扰企业的第一件事不是模型不够聪明，而是不知道哪些 agent 在跑、能做什么、做了什么。协议原生网关 + agent 身份 + 自动发现，本质上是在为 agentic 流量建立类似 K8s 时代的编排与管控标准。

对自建 agent 平台的团队，这是个架构信号。 MCP 和 A2A 的治理正在从「每个应用自己搞定」变成「基础设施层统一提供」。如果你的平台还在用裸 Nginx 转发 MCP 流量，值得评估一下协议层网关这条路——Google 先做了，其他云大概率会跟上。