Announcing MCP support in Apigee hybrid: agentic tools that run in your own cluster

宣布 Apigee 混合版支持 MCP：在您自己的集群中运行的智能代理工具 - Google 开发者博客

Google Tag Manager (noscript)

结束 Google Tag Manager (noscript)

HTML

宣布 Apigee 混合版支持 MCP：在您自己的集群中运行的智能代理工具

2026 年 10 月 14 日

Ayo Salawu

软件工程师

Sundar Ramamoorthy

分享

• Facebook

• Twitter

• LinkedIn

• 邮件

去年 12 月，我们宣布了 Apigee 中 MCP 支持的预览版：通过该功能，您可以将已有的 API（这些 API 已经经过安全防护、治理和分类）转化为 AI 代理可以发现并调用的工具，无需编写代码或部署自己的 MCP 服务器。客户对此的反馈非常迅速，他们立即提出了第一个问题：“我能否在运行环境实际所在的环境中使用这个功能？”

对于许多 Apigee 客户来说，运行环境并不偶然地部署在 Google 管理的基础设施上。它们可能位于客户自己的数据中心、共置设施或其他公共云中，原因可能是监管要求、核心系统距离较远，或者多云架构本身就是业务的现实需求。这些客户并不是在询问是否需要通过智能代理访问 API，而是在询问是否可以在不迁移运行环境的情况下实现这一目标。

现在，他们可以实现了。随着 Apigee 混合版 1.17.0 于 2026 年 9 月 14 日发布，Model Context Protocol（MCP）支持现已在 Apigee 混合版中提供，MCP 数据平面将运行在您自己的 Kubernetes 集群中。

相同的模型，不同的位置

概念模型与我们在 Apigee 上提供的保持一致，没有任何变化。您使用 OpenAPI 3.0.x 规范描述 API，并从中创建 MCP 发现代理。该规范中的每个操作都会变成一个 MCP 工具。代理通过 JSON-RPC 与端点通信，使用 tools/list 发现可用工具，使用 tools/call 调用工具，Apigee 负责处理协议和转码。您无需编写 MCP 服务器代码，也不需要将 MCP 服务器作为独立软件组件运行，拥有自己的生命周期。

混合版中的变化在于工作执行的位置。在 Apigee 混合版中，MCP 数据平面运行在您自己的 Kubernetes 集群内部。Apigee 控制平面从您的 OpenAPI 规范生成 MCP 工具配置，您的集群会定期获取该配置，MCP 请求流量永远不会离开集群。下图展示了 MCP 数据平面在每种部署模型中的运行位置。

该架构的两个特性需要明确说明，因为它们将是您的安全审查团队关注的重点。

MCP 请求流量保留在您的集群内部。代理的 tools/call 请求在您的基础设施内部接收、授权并代理到后端系统。请求时，没有任何 MCP 请求或响应会跨越到 Google Cloud。

配置是拉取而非推送。MCP 数据平面旁的边车组件（从您的集群内部）会主动获取从您的规范派生的工具配置。Apigee 控制平面（位于 Google Cloud）永远不会主动连接到您的集群，这意味着 MCP 不需要从 Google 进入您网络的入站路径。

对多云和本地部署的影响

• Agentic endpoints 运行在您的 API 已经运行的环境中。Apigee hybrid 已经支持您在任意 Kubernetes 平台上部署运行时，MCP 继承了这一能力。MCP sidecar 重用现有的 apigee-watcher 身份。无需创建新的 Google 服务账号，也无需授予新的 IAM 角色。每个组织只需一次控制平面授权，您已有的身份即可完成其余操作。

• 数据驻留和主权立场保持不变。Apigee hybrid 中的 MCP 支持订阅版和评估版组织，包括已启用数据驻留功能的组织（在组织设置时配置）。在混合部署模式下，配置从您的控制平面位置获取，运行时请求路径通过架构设计始终保留在集群内。对于需要“请求不得离开此司法管辖区、此设施或此 VPC”的团队，该约束由架构本身而非特定设置来保障。

• 您已编写的治理规则同样适用于代理。MCP 端点作为 Apigee 代理，继承平台能力：OAuth 2.0 和 OpenID Connect 认证、API 密钥验证以及 Apigee 内置的策略库。工具级控制基于您已熟悉的 API 产品概念。您可以列出客户端有权访问的具体工具操作，可选地为每个工具设置配额，Apigee 会强制执行该规则。系统还会自动过滤发现结果。当客户端调用 tools/list 时，响应内容仅包含该客户端 API 产品中的工具。如果某个工具从未被允许访问，代理无法调用其对应的删除账户操作。

• 您的代理流量会出现在与 API 流量相同的位置。部署的 MCP 发现代理会自动被 Apigee API hub 吸收，分配 MCP API 风格并将其操作映射到可搜索的工具目录中，开发者可通过自然语言查询，而非查看端点列表的电子表格。在 API 洞察功能中，通过 API 风格和 MCP 工具名称两个过滤条件，您可以将代理流量与普通 REST 流量隔离，并在 API 性能、错误分析、延迟和目标性能仪表板中单独查看某个工具的指标。您可以查看发现请求与执行请求的比例，并区分代理开销与后端处理时间。

你的 MCP 代理作为单一端点暴露。每个代理请求，无论调用什么工具，都会到达相同的 /mcp 路径。Apigee 会为每个请求打上所调用工具的名称标签，因此 API insights 可以按工具维度拆分该单一端点，展示代理实际使用的工具、使用频率及时间范围。下图展示了 API insights，包括对 MCP 代理（mcp）的请求，以及各个工具（如 API 代理 mcp-healthcare、mcp-petstore、mcp-statuscode）的响应时间和 TPS。有关如何使用 API insights 仪表板监控和分析 MCP 流量的公开文档，请参见此处和此处。

在 API insights 的工具性能标签页中，还可以查看被调用工具的视图。

下一步：端到端追踪代理调用

一个 MCP 工具调用会跨越 AI 客户端、Apigee 和你的后端。目前，每个组件的日志都是独立的孤岛，因此平台团队实际提出的问题“时间都去哪儿了？”没有统一的答案。

下面的代码片段是一个来自 AI 客户端的示例 mcp 工具调用请求。当 Apigee 启用分布式追踪（OTEL）时，以下 curl 请求可实现端到端追踪。

curl -X POST "https://xxx.xxx.xxx.net/mcp" \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2025-11-25" \
  -d '{
    "jsonrpc": "2.0",
    "id": 321,
    "method": "tools/call",
    "params": {
      "name": "createReward",
      "arguments": {
        "reward": "123"
      },
      "_meta": {
        "traceparent": "00-3ad8012d970b3971cb16cda653a1a370-df3047d1d0830dc0-01"
      }
    }
  }'

Shell

已复制

通过 Google CloudTrace 的分布式追踪功能发起的相同调用，可以在全局视图中完整展示该调用（假设链路中的所有服务（Apigee/非 Apigee）均上报至同一 Google CloudTrace）。

MCP 客户端在 JSON-RPC 的 _meta 字段中携带 W3C 追踪上下文，而传统 REST 后端无法识别该字段。Apigee 会提取该信息并以普通 traceparent 和 tracestate 请求头形式转发，使下游已配置的服务无需代码修改即可加入追踪。这带来三个优势：跨越 AI 客户端、Apigee 代理和后端执行的单一追踪 ID；后端无需重写代码即可参与追踪，减少噪音，因为网关可通过直通模式转发上下文，而非生成自身的基础设施追踪段，从而降低追踪数据摄入成本。

生态系统正在向统一方案靠拢。MCP 社区的开放提案 SEP-2028 目标是标准化 MCP 服务器的 _meta-to-header 转发 W3C 追踪上下文行为。

目前 Apigee 已支持承载 W3C 追踪上下文的 OpenTelemetry 路径。

下一步

Apigee 混合版 1.17.0 现已支持 MCP。从 Apigee 中的 MCP 概览开始了解架构，通过启用 Apigee 混合版中的 MCP 和 MCP 快速入门指南，即可获得第一个响应代理的工具。

发布于：

• AI

• 云服务

• 公告

• 问题解决

• 探索

• 代理

• API

• 获取灵感

• 网关

• 代理

• 资源

• MCP

• JSON-RPC

上一篇

下一篇

相关文章

列表

Gemini

AI

云服务

公告

最佳实践

使用 Gemini 4 Argon 在一夜之间优化 20 万行 Python 代码库

2026 年 10 月 13 日

案例研究

Gemini 4 Argon 在机器人领域的应用

导航点