Apigee hybrid 1.17.0：集群内部运行 MCP，复用现有 API 管控

1. 将 API 转换为工具的方式保持不变

此次支持包含在 2026年9月14日发布的 Apigee hybrid 1.17.0 中。谷歌此前于 2025年12月宣布了 Apigee MCP 支持的预览版。MCP 是供 AI 智能体发现和调用工具的通信协议。

开发者使用 OpenAPI 3.0.x 规范描述 API 并创建 MCP Discovery Proxy 后，规范中的每项操作就会成为工具。该代理是将智能体调用转换为现有 API 请求的入口。无需另行编写 MCP 服务器代码，也无需将其作为独立软件运营。

智能体通过 tools/list 发现工具，通过 tools/call 调用工具。由 Apigee 负责通信协议处理和请求转换，这一点与现有方式相同。

2. 分离请求处理与配置传递的路径

变化的是运行位置。实际处理 MCP 请求的部分运行在用户的 Kubernetes 集群内。调用接收、权限检查及向后端转发均在自有基础设施内完成，处理请求时，MCP 请求和响应不会传到 Google Cloud。

而工具配置则在负责配置管理的 Google Cloud 控制平面中生成。集群内的辅助进程会定期拉取配置，因此无需开放供谷歌主动连接内部的入站路径。不能把请求留在内部的说法理解为配置管理也与外部隔绝。

3. 复用现有权限策略与可观测体系

MCP 端点属于 Apigee 代理，因此适用现有的身份验证和策略。在名为 API product 的权限集合中指定允许客户端使用的工具，必要时也可设置各工具的调用限额。工具列表也只显示该客户端获准使用的条目。

已部署的工具会自动注册到 API hub，供用户搜索。API insights 可区分智能体流量与普通 API 流量，并查看各工具的性能、错误和延迟。即使请求汇入同一路径，Apigee 也会标注工具名称，因此可以分别查看各工具的用量和后端处理时间。

4. 同时确认启用顺序与运维负担

该功能默认关闭，需要 1.17.0 或更高版本的集群。通过部署工具 Helm 启用。

在配置文件 overrides.yaml 的顶层设置 enableMcpServer: true。

升级 Helm 的部署包 chart 时，先升级 apigee-operator，再升级 apigee-org。如果颠倒顺序，即使升级成功，也不会创建 MCP 运行单元。

为获取配置，需按组织向现有 apigee-watcher 身份授予一次控制平面访问权限。无需创建新的 Google 服务账号或 IAM 角色。

默认运行副本数为 2，最多可自动扩缩至 10。

收益在于减少独立 MCP 服务器的运营工作，复用现有安全策略，同时在内部处理请求。相应地，集群必须容纳这些副本和辅助进程。启用和停用都会逐步替换运行进程，因此原文建议在获批的维护窗口内操作。

5. 调用追踪需要具备埋点条件

分布式追踪通过为经过多个服务的请求添加相同标记，定位产生延迟的环节。Apigee 从 MCP 消息的 _meta 中提取追踪信息，并通过普通 HTTP 头传递。已完成追踪埋点的后端无需修改代码，即可参与同一条追踪链路。

以下是原文调用示例中包含追踪信息的部分。

          "_meta": {
            "traceparent": "00-3ad8012d970b3971cb16cda653a1a370-df3047d1d0830dc0-01"
          }

原文示例的前提是在 Apigee 中启用基于 OpenTelemetry 的分布式追踪，且调用路径上的服务向同一个 Google Cloud Trace 上报。因此，仅在集群内部运行，并不会自动获得完整的调用追踪。

推动相关传递方式标准化的 SEP-2028 仍是一项公开提案。

此次支持的价值在于保留 API 运行位置与现有管控体系的同时，开放智能体访问；决定是否引入时，也应将集群资源和变更操作的负担纳入考量。