首页 >发现

MCP 与 API 网关：二者不可互换

深入解析 MCP 与 API 网关的核心区别，了解为何专用的 MCP 网关对于现代应用的安全与性能至关重要。

作者: 几米宋
分类:产品深度
2 次阅读

MCP 与 API 网关在架构和协议层面存在本质差异，企业应采用专为 MCP 设计的网关方案以保障安全性与可扩展性，而非简单复用传统 API 网关。

我服务的许多组织正在快速采用 模型上下文协议（MCP），以便通过 AI 智能体将服务和数据连接到 AI 模型。但他们也遇到了熟悉的挑战：既要保护 MCP 服务器和工具的访问安全，又要实现路由、限流、可观测性和开发者门户等能力。

API 早期的普及让我们深刻体会到：如果没有合适的网关控制，服务暴露会带来安全漏洞、性能灾难和运维混乱。

如果你正在企业内部构建并暴露 MCP 服务器，你很可能会问我经常被问到的问题：“我们能不能直接用现有的 API 网关来做 MCP？”

简短的答案是“也许可以”，但真正的问题是“你应该这样做吗？”API 网关并不是为 MCP 场景设计的。事实上，大多数 API 网关厂商最终都会推出专用的 MCP 网关。

让我们深入探讨 API 与 MCP 的根本范式差异，以及为何现有基础设施（API 网关）必须进化。

API 是无状态的，MCP 是有状态的

在讨论基础设施应如何演进前，首先要理解这两种方式的本质区别。API 是“无状态”服务，每个请求都是独立处理的。REST API 严重依赖底层传输协议（HTTP）来表达协议语义。实际上，这意味着 API 网关所需的所有路由、鉴权和策略信息都包含在 HTTP 头和 URL 结构中。

API 网关可以通过以下方式做出智能决策：

• 方法（如 GET、POST、PUT、DELETE）

• 路径（如 /users/123/orders）

• 头部（如 Authorization: Bearer xyz、Content-Type）

• 查询参数（如 ?limit=10&offset=50）

API 网关很少处理请求体内容。如果需要，也只是做些简单转换，或将部分内容提取到头部或元数据中用于路由。请求体通常遵循可预测的结构（如 Open API 规范），可通过简单的映射规则进行校验和转换。最重要的是，每个请求都是独立的，无需维护会话状态。

而远程 MCP 服务器则完全颠覆了这一模式。首先，MCP 客户端会通过“initialize”消息与 MCP 服务器建立连接，并协商协议参数。随后，服务器分配一个会话 ID（如 Mcp-Session-Id），用于协调该客户端后续所有交互。这个会话会维护关键上下文/状态，包括：

• 客户端与服务器协商的协议能力（可用的可选特性）。

• 前序工具调用及响应的结果/上下文。

• 异步工具调用状态、流式更新/通知。

• 服务器向客户端请求的信息状态。

与 REST API 不同，MCP 请求在 HTTP 层只包含极少的路由信息，协议内容全部在 HTTP 请求体中。典型的 MCP 请求如下：

POST /mcp
Mcp-Session-Id: session_abc123
Content-Type: application/json
{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "database_query",
    "arguments": { /* 复杂嵌套结构 */ }
  },
  "id": "call_456"
}

所有有意义的信息都在 JSON-RPC 请求体中：方法类型、具体调用的工具及参数。HTTP 层只是“哑巴”传输通道。

更具挑战性的是，MCP 服务器还可以通过 Server-Sent Events（SSE）主动向客户端推送进度更新、流式结果，甚至发起新请求（如引导、采样等）。这种双向、会话感知的通信模式与 API 网关设计时的请求 - 响应模型截然不同。

能否用 API 网关替代 MCP 网关？

如上所述，两者有本质区别。但也有相似之处：都基于 HTTP，可以应用 JWT/Token/OAuth 等安全机制，API 网关也能操作请求体。那么，能否用 API 网关治理 MCP 服务？

image.pngAPI 网关与 MCP 网关对比示意图

以下是你可能希望 API 网关实现的部分功能（非详尽列表）：

• 解析请求体和响应（JSON-RPC），实现协议语义。

• 对请求体中的部分内容（如工具列表、工具调用、资源请求等）注入策略决策（允许/拒绝）。

• MCP 客户端的单个 HTTP POST 可能对应多个响应，并以流式（SSE）返回。

• 需要在流中注入策略执行。

• 建立流后，将 MCP 服务器的请求代理到 MCP 客户端。

• 协调 MCP 客户端与 MCP 服务器之间的差异。

• 向 MCP 客户端呈现单一逻辑 MCP 服务器（虚拟 MCP 服务器），后端可能有多个 MCP 服务器。

API 网关能实现部分功能，下面按复杂度递增梳理常见的 MCP 网关模式：

• 简单透传代理

• 部分协议理解

• MCP 协调代理（Brokering）

• MCP 多路复用（Multiplexing）

简单透传代理

最基础的做法是让 API 网关作为 MCP 流量的透传代理。在这种场景下，网关将 MCP 请求视为普通的 HTTP POST + JSON 负载，不理解 JSON-RPC 结构或 MCP 语义，但仍能提供一定价值：

优势

• HTTP 层认证（API Key、OAuth Token）

• 按客户端或 IP 的基础限流

• 传输层安全（TLS）终止与证书管理

• 请求/响应日志与基础指标采集

image.pngMCP 透传代理示意图

例如，你可以校验 HTTP Authorization 头中的 JWT，并通过可信 IdP 验证 JWT。这是基础的 HTTP 处理，任何 API 网关都能胜任。如果响应为 SSE 流？幸运的是，大多数现代 API 网关也能返回事件流。如果你想对响应实施策略（如限制客户端可见的工具），则需要理解 SSE 事件。简单透传代理无法实现这一点。

SSE 下的网关局限

• 无法流式策略执行：网关无法检查或过滤单独的 SSE 事件。

• 可观测性有限：无法跟踪进度、检测错误或统计每个事件的延迟。

• 无中途授权能力：无法在流式过程中撤销访问或动态应用策略。

• 会话上下文丢失：多个 SSE 事件属于同一 MCP 操作，但网关视为独立片段。

这就像在数据库前面加了个通用反向代理：你能获得连接池和基础监控，但无法实现查询级洞察或策略。一旦需要理解代理流量内容，这种方式就不够用了。

部分协议支持

这里开始变得有趣且复杂。通过自定义开发，你可以让 API 网关解析 MCP 的 JSON-RPC 负载，并提取有意义的信息用于策略决策。大多数 API 网关支持通过 JavaScript/Lua/模板策略等机制自定义请求体解析。例如，在 Apigee中，可以调用 JavaScript 扩展策略实现自定义解析与策略。

能力提升

• 更好地理解 JSON-RPC 请求。

• 实现工具级授权（如“市场部用户不能调用 database_query”）。

• 基础请求转换与校验。

image.png部分协议支持示意图

痛点在于：这种方式很快变得脆弱且维护成本高：

• 动态解析复杂：MCP 工具列表长度不定，JSONPath 表达式越来越复杂且易碎。

• 性能开销大：JavaScript 策略比原生网关策略慢。

• 维护负担重：每新增 MCP 工具都可能需要更新网关策略，基础设施团队与 MCP 服务器开发强耦合。

• 流式支持有限：部分网关支持 SSE，但流中策略执行复杂度指数级上升。

实际情况是，你最终会在现有网关之上再造一个网关，不断为新特性和性能优化而挣扎。

MCP 协调代理（Brokering）

MCP 协调代理要求网关主动参与 MCP 协议对话，不仅仅是代理请求，还能根据策略修改、过滤或增强请求。例如，MCP 客户端可用一个协议版本连接 MCP 网关，网关再与后端 MCP 服务器协商不同版本。这在企业环境中尤为关键——当 MCP 服务器升级协议版本时，不可能让所有客户端同步升级。

在前述模式基础上，协调代理还可实现：

• 版本屏蔽：MCP 服务器升级时，保护 MCP 客户端免受破坏性变更影响。

• 请求过滤：根据兼容性需求，从发现响应中移除部分工具。

• 响应脱敏：根据用户权限，从工具响应中剥离敏感数据。

• 上下文注入：为工具调用添加企业上下文（如用户 ID、租户信息）。

• 错误处理：将 MCP 协议错误转化为企业合规的审计事件。

传统 API 网关难以胜任这些场景，因为它们缺乏原生 JSON-RPC 理解和会话感知的策略引擎。

MCP 多路复用（Multiplexing）

这时，传统 API 网关彻底“撞墙”。MCP 多路复用要求将多个后端 MCP 服务器聚合为一个逻辑端点，即“虚拟 MCP”。

例如，客户端只需连接一个 MCP 端点，即可访问多个后端服务器的工具：

• 天气工具来自 weather-service.internal

• 数据库工具来自 analytics-service.internal

• 邮件工具来自 notification-service.internal

AI 智能体无需了解和连接众多 MCP 服务器，只需对接一个虚拟端点，统一访问所有企业工具。

image.pngMCP 多路复用聚合示意图

复杂度爆炸：实现这一点需要传统 API 网关不具备的能力：

1. 会话分发：客户端发起“tools/list”时，网关需查询所有后端服务器并合并结果。

2. 请求路由：工具调用需根据工具名路由到正确后端。

3. 响应多路复用：多个后端的流式响应需合并为单一 SSE 流。

4. 状态协调：会话 ID 和协议协商需在多个后端连接间管理。

5. 错误隔离：某个后端故障不应影响整个虚拟会话。

这种协议感知的聚合与虚拟化远超传统 API 网关的设计初衷。你几乎需要重写网关的核心请求/响应处理逻辑，以支持 MCP 的会话语义。

Agentgateway：为 MCP 而生的网关

Agentgateway 是 Linux 基金会开源项目，采用 Rust 编写，专为 AI 智能体协议（如 MCP）设计，吸取了 API 网关的经验教训。与为无状态 REST 交互优化的传统 API 网关不同，agentgateway 原生理解 JSON-RPC 消息结构，维护有状态的会话映射，并支持 MCP 所需的双向通信模式。

这种深度协议感知能力，使其能够正确地多路复用/解复用 MCP 会话，将客户端请求分发到多个后端 MCP 服务器，聚合工具列表，并维护服务器主动向客户端发消息时所需的关键双向会话映射。agentgateway 的架构天然契合 MCP 的会话导向、流式通信模型，无需与请求 - 响应 API 架构“对抗”。

image.pngagentgateway 工作原理动图

基于此，agentgateway 可作为原生 MCP 网关、大语言模型（LLM）网关和智能体间（A2A）代理，提供传统 API 网关无法实现的安全、可观测性和治理能力。

它支持 MCP 多路复用，将多个后端服务器的工具统一联邦，细粒度授权控制客户端可访问的工具，并无缝支持 stdio 与 HTTP Streamable 传输。

当与 CNCF 项目 kgateway 作为控制面集成时，agentgateway 具备原生 Kubernetes 能力，团队可用标准 Gateway API 资源管理 MCP 服务，协议复杂性由代理自动处理。

这种专为 MCP 设计的方案，为企业级 MCP 部署带来高性能、安全性和运维简洁性，避免了用 API 网关“硬改”带来的脆弱性、维护负担和架构妥协。


本文由公众号“几米宋”授权AI产品之家转载，原文连接： https://mp.weixin.qq.com/s/29AS1AyCAll6Zq0Gn0n5sQ