Apigee 支持在自有集群运行 MCP 工具

去年 12 月，我们宣布推出 Apigee MCP 支持的预览版：将你已经完成安全防护、治理并纳入目录的 API 转化为 AI Agent 可以发现和调用的工具，无须编写代码，也无须自行搭建 MCP server。客户很快就给出了反馈，而他们问的第一个问题也随之而来：“能不能在我的 runtime 实际运行的地方使用它？”

对许多 Apigee 客户来说，runtime 没有部署在 Google 托管的基础设施上，是有意为之。它可能运行在客户自己的数据中心、托管机房，或另一家公有云上：可能是监管要求如此，可能是核心业务系统就在三个机架之外，也可能是多云环境本来就是企业的现实。这些客户问的不是要不要让 Agent 访问自己的 API，而是能不能在不迁移 runtime 的前提下做到这一点。

现在可以了。随着 Apigee hybrid 1.17.0 于 2026 年 9 月 14 日发布，Apigee hybrid 已支持 Model Context Protocol，MCP 数据平面运行在你自己的 Kubernetes 集群中。

模型相同，运行位置不同

概念模型与我们此前在 Apigee 上推出的完全一致。你使用 OpenAPI 3.0.x 规范描述 API，再根据规范创建一个 MCP Discovery Proxy。规范中的每个 operation 都会成为一个 MCP 工具。Agent 通过 JSON-RPC 与 endpoint 通信，使用 tools/list 发现可用工具，使用 tools/call 调用工具，协议处理和转码由 Apigee 完成。你无须编写 MCP server 代码，也无须将 MCP server 作为一套拥有独立生命周期的软件来运维。

hybrid 改变的是这些工作发生的位置。在 Apigee hybrid 中，MCP 数据平面运行在你自己的 Kubernetes 集群内。Apigee 控制平面根据你的 OpenAPI Specification 生成 MCP 工具配置，集群定期拉取这些配置，MCP 请求流量始终留在集群内。下图展示了不同部署模式下 MCP 数据平面的运行位置。

这种架构有两个特性需要明确说明，因为它们正是安全审查团队会问到的问题。

MCP 请求流量始终留在你的集群内。Agent 的 tools/call 请求，从接收、授权到代理转发至后端，全部在你自己的基础设施中完成。处理请求时，没有任何 MCP 请求或响应会跨越边界进入 Google Cloud。

配置采用拉取方式。与 MCP 数据平面一同运行的 sidecar 会从集群内部主动发起连接，拉取根据规范生成的工具配置。位于 Google Cloud 的 Apigee 控制平面从不会主动连接你的集群，因此 MCP 不需要任何从 Google 进入你网络的入站通道。

这对多云和本地部署意味着什么

Agent 使用的 endpoint 会运行在 API 已经运行的地方。Apigee hybrid 原本就允许你在自行选择的 Kubernetes 平台上托管 runtime，MCP 也沿用了这一能力。MCP sidecar 复用现有的 apigee-watcher 身份。你无须创建新的 Google service account，也无须授予新的 IAM role。每个 organization 只需完成一次控制平面授权，剩下的工作由现有身份完成。

现有的数据驻留和数据主权保障也得以延续。Apigee hybrid 中的 MCP 适用于 Subscription 和 Evaluation organization，包括已启用 Data Residency 的 organization，这项配置在 organization 初始化时完成。在 hybrid 模式下，配置从控制平面所在位置拉取，而 runtime 请求路径在架构上就被限定在集群内。对于要求“请求不得离开指定司法辖区、指定设施或指定 VPC”的团队，这项约束由架构本身保障。

你已经编写的治理规则同样适用于 Agent。MCP endpoint 本身就是 Apigee proxy，因此继承了平台的能力：OAuth 2.0、OpenID Connect、API key 验证，以及 Apigee 内置的 policy 库。工具级别的控制来自你已经熟悉的概念：API product。你在其中列出客户端有权使用的具体工具操作，也可以为每个工具设置 quota，由 Apigee 强制执行。它还会自动过滤工具发现结果。当客户端调用 tools/list 时，响应只包含该客户端 API product 中的工具。如果 Agent 从未获准发现 delete_account，它就无法调用这个工具。

Agent 流量也会出现在你查看 API 流量的地方。部署后的 MCP Discovery Proxy 会自动纳入 Apigee API hub，API style 被设为 MCP，其中的 operation 则映射为独立工具，形成一个可搜索的目录。开发者可以用自然语言查询这个目录，无须翻查记录 endpoint 的电子表格。在 API insights 中，API style 和 MCP tool name 两个筛选条件可以将 Agent 流量与普通 REST 流量分开，并在 API 性能、错误分析、延迟和目标端性能 dashboard 中查看某个工具。你可以看到工具发现与实际执行的比例，也可以区分 proxy 开销和后端耗时。

MCP 是 Apigee hybrid 的可选功能，默认不启用。要启用它，需要在已运行 Apigee hybrid 1.17.0 或更高版本的集群上执行 Helm 操作。步骤如下。

在 overrides.yaml 中设置顶层配置项 enableMcpServer: true，然后先升级 apigee-operator chart，再升级 apigee-org chart。顺序很重要。新 MCP 资源的 schema 由 operator chart 管理；如果升级顺序错误，升级操作会显示成功，却不会出现 MCP pod。此外，每个 organization 还需要进行一次授权，将 apigee-watcher 身份加入该 organization 的控制平面访问权限，以便 sidecar 获取配置。默认配置开箱即用：运行两个 MCP 副本，自动扩缩容上限为十个。回滚时，将同一字段设为 false，再执行一次 chart 升级即可。

安排变更前，还有几件事需要提前规划。启用或禁用 MCP 都会触发 runtime pod 分阶段进行 canary 发布，因此请在已获批准的维护窗口内操作。相关公开文档介绍了如何在现有 Apigee hybrid 集群中启用 MCP。

在 Apigee 中观测 MCP 流量

你的 MCP proxy 对外提供单一 endpoint。每个 Agent 请求，无论调用哪个工具，都会到达同一个 /mcp 路径。Apigee 会为每个请求标记所调用工具的名称，因此 API insights 可以按工具拆分这个 endpoint 的流量，展示 Agent 实际使用了哪些工具、使用频率以及使用时间范围。下面的截图展示了 API insights，其中既包含对 MCP proxy（mcp）的请求，也可以查看各个工具的响应时间和 tps，这些工具以 API proxy mcp-healthcare、mcp-petstore、mcp-statuscode 的形式呈现。相关公开文档分别介绍了如何使用 Apigee API insights 监控和分析 MCP 流量，以及如何使用 API insights dashboard。

下图还展示了 API insights 中 tool performance 标签页里的工具调用情况。

下一步：端到端追踪 Agent 调用

一次 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"
      }
    }
  }'

通过 Google CloudTrace 中的分布式追踪，同一次调用的完整链路可以呈现在一个全局视图中。（前提是链路中的所有服务，无论是否属于 Apigee，都向同一个 Google CloudTrace 上报。）

MCP 客户端将 W3C trace context 放在 JSON-RPC 的 _meta 字段中，而传统 REST 后端并不知道如何读取这个字段。Apigee 会提取其中的上下文，并通过普通的 traceparent 和 tracestate header 转发，因此已接入追踪的下游服务无须修改代码，就能加入同一条 trace。这带来三个结果：同一个 trace ID 贯穿 AI 客户端、Apigee proxy 和后端执行过程；后端无须改写代码即可参与追踪；追踪噪声更少，因为 gateway 可以采用 passthrough 模式转发上下文，无须生成自身的基础设施 span，这也能降低追踪数据的摄取成本。

整个生态也在朝同一个方向发展。MCP 社区中的开放提案 SEP-2028，旨在将 W3C trace context 从 _meta 转发到 header 的机制，标准化为 MCP server 的常规行为。

Apigee 目前已经提供通过 OpenTelemetry 传递 W3C trace context 的能力。

Apigee hybrid 1.17.0 现已支持 MCP。你可以先阅读 MCP in Apigee 概览了解架构，再参考 Enable MCP in Apigee hybrid 完成 Helm 操作，最后按照 MCP quickstart，让第一个工具响应 Agent 的调用。