什么是 MCP 网关？架构、应用场景与工作原理（2026 指南）

引言

**Model Context Protocol（MCP）**是一项开放标准，让 AI Agent 和基于 LLM 的应用能够通过结构化接口，与后端工具、数据源和服务交互。随着组织在生产环境部署 MCP Server，一项新的基础设施需求随之出现：需要一个网关来管理、保护和扩展 MCP 流量。

本文介绍什么是 MCP 网关、它与传统 API 网关及 AI 网关有何区别、具备哪些核心能力，以及如何为 AI 基础设施评估 MCP 网关。

什么是 MCP 网关？

MCP 网关是位于 AI Agent（或 LLM 应用）与一个或多个 MCP Server 之间的反向代理。它验证协议元数据，将请求路由到正确的后端，执行安全策略并提供可观测性，避免每个 Agent 和 Server 都重复实现这些能力。

什么是 Model Context Protocol？

在了解网关前，先认识 MCP 本身：

MCP 允许 AI Agent 调用工具、检索上下文，并与后端服务交换结构化消息
当前 2026-07-28 协议核心是无状态的：每个请求都在 _meta 中携带协议版本、客户端身份和客户端能力
MCP 通过 Streamable HTTP 进行网络通信，或使用 stdio 与本地进程通信；HTTP 响应可以是 JSON，也可以是请求范围内的 Server-Sent Events（SSE）流
MCP Server 暴露工具（Agent 可调用的函数）、资源（Agent 可读取的数据）和提示词（Agent 可使用的模板）

官方 2026-07-28 变更日志记录了 initialize 握手、协议层会话和 Mcp-Session-Id 请求头的移除。旧客户端和 Server 仍可能协商旧版协议，因此网关必须明确处理版本兼容性。

当多个 AI Agent 通过网络连接多个 MCP Server 时，如果组织需要集中管理路由、安全策略、兼容性或可观测性，MCP 网关就很有用。小型或隔离部署未必需要增加代理层。

MCP 网关与 MCP Server 的区别

组件	职责	示例
MCP Server	执行工具调用、按需管理应用状态、返回结果	查询数据库、调用内部 API 或访问文件系统的服务
MCP 网关	在 Agent 与 Server 之间路由流量、执行策略并提供可观测性	位于 MCP Server 前，类似于 API 网关位于 REST 服务前

MCP Server 负责业务逻辑，MCP 网关负责流量管理、安全和运维问题。

MCP 网关如何工作？

MCP 网关作为第 7 层代理运行在请求路径中：

1┌──────────────┐     ┌──────────────┐     ┌──────────────┐
2│  AI Agent 1  │     │              │     │ MCP Server A │
3│  AI Agent 2  │────▶│    MCP 网关   │────▶│ MCP Server B │
4│  AI Agent 3  │     │              │     │ MCP Server C │
5│  LLM 应用     │◀────│    （策略）    │◀────│  （工具/数据） │
6└──────────────┘     └──────────────┘     └──────────────┘

请求流程

Agent 发送自描述请求——2026-07-28 客户端可以先调用可选的 server/discover，也可以直接向网关 MCP 端点发送操作。
协议验证——网关验证 MCP-Protocol-Version、必需场景中的 Mcp-Method 与 Mcp-Name，以及对应的 _meta 字段。
认证与授权——网关验证 Agent 凭证，并检查它是否有权访问请求的 MCP Server、工具或资源。
操作感知路由——网关根据可信请求元数据选择后端；现代请求可以到达任一兼容实例，无需协议层粘性会话。
代理工具或资源调用——网关转发 JSON-RPC 请求，执行速率与并发策略，并记录交互。
交付响应——Server 返回 JSON 或请求范围的 SSE 流，网关以有界缓冲和明确取消行为进行代理。
完成与观测——请求或订阅结束时，网关释放资源并记录请求级指标。

协议转换

MCP 网关的一项关键能力是协议转换：

stdio → Streamable HTTP：当进程与安全模型允许时，适配器可以通过网络端点暴露本地进程中的 MCP Server
Streamable HTTP：网关验证标准请求头，并以有界缓冲和明确取消行为代理 JSON 响应或请求范围的 SSE 响应

协议适配可以减少 Server 改动，但生产部署前仍需验证进程隔离、凭证、并发和兼容性。

MCP 网关的核心能力

1. 协议感知路由

2026-07-28 协议让请求具备自描述能力，因此网关无需协议层会话亲和性即可路由：

版本感知路由——根据 MCP-Protocol-Version 与后端兼容性拒绝或路由请求
请求头感知路由——使用经过验证的 Mcp-Method 和 Mcp-Name，无需每个中间层都解析完整 JSON-RPC 正文
无状态负载分配——任一兼容副本都能处理请求；普通轮询负载均衡无需协议会话存储
显式应用状态——需要跨调用保存状态的 Server 可以签发句柄，并要求后续工具调用把它作为普通参数传回
多 Server 路由——根据能力把不同工具调用路由到不同 MCP Server，例如数据库工具发往数据库 MCP Server，文件工具发往文件系统 MCP Server

2. SSE 流式传输支持

当一个响应需要传输多条消息时，Streamable HTTP 可以返回 Server-Sent Events：

请求范围 SSE 代理——网关透明代理与单个 HTTP 请求关联的 SSE 响应
连接管理——为长时间响应和订阅实施合适的超时、取消与保活
背压——防止慢速消费者压垮 MCP Server
流检查——可选地检查流式事件，满足安全或日志需求

3. 认证与访问控制

生产环境的 MCP 部署需要超出 MCP 协议本身的安全能力：

Agent 认证——允许 MCP 连接前，使用 API Key、JWT 或 mTLS 验证 Agent 身份
工具级授权——控制不同 Agent 可以访问的工具，例如 Agent A 可以调用 query_database，但不能调用 delete_records
凭证注入——网关注入上游 MCP Server 凭证（如 Bearer Token 或 API Key），让 Agent 永远无法直接看到它们
每请求权限——根据已认证身份、请求的操作、资源和工具派生权限，而不是依赖已废弃的协议会话

4. 限流与配额

MCP 网关根据 MCP 流量模式实施限流：

工具调用限流——限制每个 Agent 每分钟可以进行的工具调用次数
并发限制——限制每个 Agent 或 MCP Server 的并发请求和长期订阅数
Token 感知限制——如果 MCP Server 代理 LLM 调用，则实施基于 Token 的限流
成本控制——按 Agent 设置预算上限，防止高成本工具调用导致费用失控

5. 可观测性

MCP 网关提供了在应用层难以获得的可见性：

请求与订阅指标——跟踪操作时长、工具调用数、活跃订阅和错误率
工具调用追踪——实现 Agent → 网关 → MCP Server → 后端的分布式追踪
成本归因——按 Agent、工具、请求，以及适用的应用状态句柄跟踪资源用量
审计日志——记录身份、操作、策略决策、状态和耗时等元数据；只有用途明确并配套脱敏、访问控制、加密和保留限制时，才采集请求或响应正文
集成——导出到 Prometheus、Grafana、OpenTelemetry 和 ClickHouse

6. 高可用与扩展

生产 MCP 部署需要与其他关键基础设施相同的韧性：

健康检查——监控 MCP Server 健康状态，并从服务池移除不健康实例
负载均衡——在兼容 MCP Server 实例之间分配自包含请求
故障处理——Server 在请求期间失效时，仅对可以安全重放的操作重试；否则向 Agent 返回有界错误
水平扩展——在负载均衡器后增加网关实例，以支持高吞吐量部署

MCP 网关、API 网关与 AI 网关的区别

这三类网关都采用反向代理架构，但面向不同流量模式：

能力	API 网关	AI 网关	MCP 网关
主要流量	REST、GraphQL、gRPC	LLM 补全（OpenAI API）	MCP 工具、资源、提示词和订阅
协议状态	通常无状态	通常限制在请求或流范围内	`2026-07-28` 采用无状态核心；应用状态使用显式句柄
流式传输	可选（WebSocket/SSE）	使用 SSE 传输补全结果	JSON 或请求范围的 SSE
限流单位	请求	Token + 请求	工具调用 + 并发请求/订阅
安全重点	认证、WAF、DDoS	提示词注入、PII	工具级授权
计费单位	API 调用	消耗的 Token	工具调用 + 计算资源

如需深入比较，请阅读配套文章：AI Gateway、MCP Gateway 与 API Gateway 有何区别？。

统一网关方法

在实践中，大多数组织并不希望运维三套独立网关。使用一套统一网关处理 REST、LLM 和 MCP 流量，可以获得：

一套统一的运维对象
共享的认证与身份基础设施
覆盖所有流量类型的统一可观测性
一致的策略执行

Apache APISIX基于 NGINX/OpenResty 采用插件式方法，而 AISIX为 AI 工作负载提供 Rust 原生数据面。应评估计划部署的产品是否支持所需的 REST、LLM 与 MCP 能力和协议版本，不能假定两种实现完全相同。

MCP 网关的常见应用场景

1. 企业 AI Agent 部署

部署内部 AI Agent（编程助手、数据分析师、客服机器人）的组织使用 MCP 网关来：

控制每个 Agent 可以访问的工具
对数据访问执行合规策略
跟踪并审计所有 Agent 与工具的交互
独立扩展 MCP Server 基础设施

2. 多租户 MCP 平台

构建 AI 平台的 SaaS 公司使用 MCP 网关来：

隔离不同租户的身份、工具访问、应用状态句柄和流量
执行每租户限流与配额
提供租户专属工具注册表
根据工具调用量向租户计费

3. 从开发到生产的流程

团队使用 MCP 网关连接本地开发与生产环境：

开发人员在本地使用 stdio 构建 MCP Server
兼容的适配器为生产环境通过 Streamable HTTP 暴露 stdio Server
在所选适配器与传输实现兼容时复用 Server 逻辑
在网关增加认证、日志和扩展等生产能力，同时测试必要的适配器变更

如何评估 MCP 网关

标准	需要关注的能力
协议支持	明确支持 `2026-07-28`、必需请求头与 `_meta`，并记录旧版行为
流式支持	请求范围的 SSE，以及取消、背压和有界缓冲
协议转换	stdio → Streamable HTTP 适配，并记录隔离与兼容限制
认证	API Key、JWT、mTLS 支持及工具级授权
性能	实测代理开销、长响应行为、并发限制和有界资源使用
可观测性	请求与订阅指标、工具调用追踪和成本归因
开源	Apache 2.0 或同等许可证；避免在新兴协议基础设施中被锁定
统一流量	使用一套网关处理 REST + LLM + MCP 流量

开始使用

如需进一步了解如何使用 Apache APISIX 实现 MCP 网关能力：

AISIX MCP Gateway——通过统一网关端点治理 MCP 工具发现和工具调用的产品概览
API 网关如何增强 MCP Server——包含插件示例的详细集成指南
什么是 AI 网关？——了解更广义的 AI 网关类别
AISIX AI Gateway——面向 LLM、AI Agent 和 MCP 流量的网关
理解 MCP Gateway——深入介绍架构的博客文章

结论

MCP 网关弥补了本地构建 MCP Server 与大规模生产运行之间的基础设施缺口。通过提供协议感知路由、Streamable HTTP 支持、认证、限流和可观测性，它把成熟的网关控制带给 MCP 流量。

对于在生产环境部署 AI Agent 的团队，当 MCP 流量跨越信任边界或需要集中策略与运维时，就应考虑网关策略。根据规模和所有权，可以使用独立 MCP 网关，也可以与现有 API 或 AI 网关能力统一。

引言