MCP 與 API 網(wǎng)關在架構和協(xié)議層面存在本質差異，企業(yè)應采用專為 MCP 設計的網(wǎng)關方案以保障安全性與可擴展性，而非簡單復用傳統(tǒng) API 網(wǎng)關。

我服務的許多組織正在快速采用 模型上下文協(xié)議（MCP），以便通過 AI 智能體將服務和數(shù)據(jù)連接到 AI 模型。但他們也遇到了熟悉的挑戰(zhàn)：既要保護 MCP 服務器和工具的訪問安全，又要實現(xiàn)路由、限流、可觀測性和開發(fā)者門戶等能力。

API 早期的普及讓我們深刻體會到：如果沒有合適的網(wǎng)關控制，服務暴露會帶來安全漏洞、性能災難和運維混亂。

如果你正在企業(yè)內(nèi)部構建并暴露 MCP 服務器，你很可能會問我經(jīng)常被問到的問題：“我們能不能直接用現(xiàn)有的 API 網(wǎng)關來做 MCP？”

簡短的答案是“也許可以”，但真正的問題是“你應該這樣做嗎？”API 網(wǎng)關并不是為 MCP 場景設計的。事實上，大多數(shù) API 網(wǎng)關廠商最終都會推出專用的 MCP 網(wǎng)關。

讓我們深入探討 API 與 MCP 的根本范式差異，以及為何現(xiàn)有基礎設施（API 網(wǎng)關）必須進化。

API 是無狀態(tài)的，MCP 是有狀態(tài)的

在討論基礎設施應如何演進前，首先要理解這兩種方式的本質區(qū)別。API 是“無狀態(tài)”服務，每個請求都是獨立處理的。REST API 嚴重依賴底層傳輸協(xié)議（HTTP）來表達協(xié)議語義。實際上，這意味著 API 網(wǎng)關所需的所有路由、鑒權和策略信息都包含在 HTTP 頭和 URL 結構中。

API 網(wǎng)關可以通過以下方式做出智能決策：

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

? 路徑（如 /users/123/orders）

? 頭部（如 Authorization: Bearer xyz、Content-Type）

? 查詢參數(shù)（如 ?limit=10&offset=50）

API 網(wǎng)關很少處理請求體內(nèi)容。如果需要，也只是做些簡單轉換，或將部分內(nèi)容提取到頭部或元數(shù)據(jù)中用于路由。請求體通常遵循可預測的結構（如 Open API 規(guī)范），可通過簡單的映射規(guī)則進行校驗和轉換。最重要的是，每個請求都是獨立的，無需維護會話狀態(tài)。

而遠程 MCP 服務器則完全顛覆了這一模式。首先，MCP 客戶端會通過“initialize”消息與 MCP 服務器建立連接，并協(xié)商協(xié)議參數(shù)。隨后，服務器分配一個會話 ID（如 Mcp-Session-Id），用于協(xié)調(diào)該客戶端后續(xù)所有交互。這個會話會維護關鍵上下文/狀態(tài)，包括：

? 客戶端與服務器協(xié)商的協(xié)議能力（可用的可選特性）。

? 前序工具調(diào)用及響應的結果/上下文。

? 異步工具調(diào)用狀態(tài)、流式更新/通知。

? 服務器向客戶端請求的信息狀態(tài)。

與 REST API 不同，MCP 請求在 HTTP 層只包含極少的路由信息，協(xié)議內(nèi)容全部在 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 請求體中：方法類型、具體調(diào)用的工具及參數(shù)。HTTP 層只是“啞巴”傳輸通道。

更具挑戰(zhàn)性的是，MCP 服務器還可以通過 Server-Sent Events（SSE）主動向客戶端推送進度更新、流式結果，甚至發(fā)起新請求（如引導、采樣等）。這種雙向、會話感知的通信模式與 API 網(wǎng)關設計時的請求 - 響應模型截然不同。

能否用 API 網(wǎng)關替代 MCP 網(wǎng)關？

如上所述，兩者有本質區(qū)別。但也有相似之處：都基于 HTTP，可以應用 JWT/Token/OAuth 等安全機制，API 網(wǎng)關也能操作請求體。那么，能否用 API 網(wǎng)關治理 MCP 服務？

API 網(wǎng)關與 MCP 網(wǎng)關對比示意圖

以下是你可能希望 API 網(wǎng)關實現(xiàn)的部分功能（非詳盡列表）：

? 解析請求體和響應（JSON-RPC），實現(xiàn)協(xié)議語義。

? 對請求體中的部分內(nèi)容（如工具列表、工具調(diào)用、資源請求等）注入策略決策（允許/拒絕）。

? MCP 客戶端的單個 HTTP POST 可能對應多個響應，并以流式（SSE）返回。

? 需要在流中注入策略執(zhí)行。

? 建立流后，將 MCP 服務器的請求代理到 MCP 客戶端。

? 協(xié)調(diào) MCP 客戶端與 MCP 服務器之間的差異。

? 向 MCP 客戶端呈現(xiàn)單一邏輯 MCP 服務器（虛擬 MCP 服務器），后端可能有多個 MCP 服務器。

API 網(wǎng)關能實現(xiàn)部分功能，下面按復雜度遞增梳理常見的 MCP 網(wǎng)關模式：

? 簡單透傳代理

? 部分協(xié)議理解

? MCP 協(xié)調(diào)代理（Brokering）

? MCP 多路復用（Multiplexing）

簡單透傳代理

最基礎的做法是讓 API 網(wǎng)關作為 MCP 流量的透傳代理。在這種場景下，網(wǎng)關將 MCP 請求視為普通的 HTTP POST + JSON 負載，不理解 JSON-RPC 結構或 MCP 語義，但仍能提供一定價值：

優(yōu)勢

? HTTP 層認證（API Key、OAuth Token）

? 按客戶端或 IP 的基礎限流

? 傳輸層安全（TLS）終止與證書管理

? 請求/響應日志與基礎指標采集

MCP 透傳代理示意圖

例如，你可以校驗 HTTP Authorization 頭中的 JWT，并通過可信 IdP 驗證 JWT。這是基礎的 HTTP 處理，任何 API 網(wǎng)關都能勝任。如果響應為 SSE 流？幸運的是，大多數(shù)現(xiàn)代 API 網(wǎng)關也能返回事件流。如果你想對響應實施策略（如限制客戶端可見的工具），則需要理解 SSE 事件。簡單透傳代理無法實現(xiàn)這一點。

SSE 下的網(wǎng)關局限

? 無法流式策略執(zhí)行：網(wǎng)關無法檢查或過濾單獨的 SSE 事件。

? 可觀測性有限：無法跟蹤進度、檢測錯誤或統(tǒng)計每個事件的延遲。

? 無中途授權能力：無法在流式過程中撤銷訪問或動態(tài)應用策略。

? 會話上下文丟失：多個 SSE 事件屬于同一 MCP 操作，但網(wǎng)關視為獨立片段。

這就像在數(shù)據(jù)庫前面加了個通用反向代理：你能獲得連接池和基礎監(jiān)控，但無法實現(xiàn)查詢級洞察或策略。一旦需要理解代理流量內(nèi)容，這種方式就不夠用了。

部分協(xié)議支持

這里開始變得有趣且復雜。通過自定義開發(fā)，你可以讓 API 網(wǎng)關解析 MCP 的 JSON-RPC 負載，并提取有意義的信息用于策略決策。大多數(shù) API 網(wǎng)關支持通過 JavaScript/Lua/模板策略等機制自定義請求體解析。例如，在 Apigee中，可以調(diào)用 JavaScript 擴展策略實現(xiàn)自定義解析與策略。

能力提升

? 更好地理解 JSON-RPC 請求。

? 實現(xiàn)工具級授權（如“市場部用戶不能調(diào)用 database_query”）。

? 基礎請求轉換與校驗。

部分協(xié)議支持示意圖

痛點在于：這種方式很快變得脆弱且維護成本高：

? 動態(tài)解析復雜：MCP 工具列表長度不定，JSONPath 表達式越來越復雜且易碎。

? 性能開銷大：JavaScript 策略比原生網(wǎng)關策略慢。

? 維護負擔重：每新增 MCP 工具都可能需要更新網(wǎng)關策略，基礎設施團隊與 MCP 服務器開發(fā)強耦合。

? 流式支持有限：部分網(wǎng)關支持 SSE，但流中策略執(zhí)行復雜度指數(shù)級上升。

實際情況是，你最終會在現(xiàn)有網(wǎng)關之上再造一個網(wǎng)關，不斷為新特性和性能優(yōu)化而掙扎。

MCP 協(xié)調(diào)代理（Brokering）

MCP 協(xié)調(diào)代理要求網(wǎng)關主動參與 MCP 協(xié)議對話，不僅僅是代理請求，還能根據(jù)策略修改、過濾或增強請求。例如，MCP 客戶端可用一個協(xié)議版本連接 MCP 網(wǎng)關，網(wǎng)關再與后端 MCP 服務器協(xié)商不同版本。這在企業(yè)環(huán)境中尤為關鍵——當 MCP 服務器升級協(xié)議版本時，不可能讓所有客戶端同步升級。

在前述模式基礎上，協(xié)調(diào)代理還可實現(xiàn)：

? 版本屏蔽：MCP 服務器升級時，保護 MCP 客戶端免受破壞性變更影響。

? 請求過濾：根據(jù)兼容性需求，從發(fā)現(xiàn)響應中移除部分工具。

? 響應脫敏：根據(jù)用戶權限，從工具響應中剝離敏感數(shù)據(jù)。

? 上下文注入：為工具調(diào)用添加企業(yè)上下文（如用戶 ID、租戶信息）。

? 錯誤處理：將 MCP 協(xié)議錯誤轉化為企業(yè)合規(guī)的審計事件。

傳統(tǒng) API 網(wǎng)關難以勝任這些場景，因為它們?nèi)狈υ?JSON-RPC 理解和會話感知的策略引擎。

MCP 多路復用（Multiplexing）

這時，傳統(tǒng) API 網(wǎng)關徹底“撞墻”。MCP 多路復用要求將多個后端 MCP 服務器聚合為一個邏輯端點，即“虛擬 MCP”。

例如，客戶端只需連接一個 MCP 端點，即可訪問多個后端服務器的工具：

? 天氣工具來自 weather-service.internal

? 數(shù)據(jù)庫工具來自 analytics-service.internal

? 郵件工具來自 notification-service.internal

AI 智能體無需了解和連接眾多 MCP 服務器，只需對接一個虛擬端點，統(tǒng)一訪問所有企業(yè)工具。

MCP 多路復用聚合示意圖

復雜度爆炸：實現(xiàn)這一點需要傳統(tǒng) API 網(wǎng)關不具備的能力：

1. 會話分發(fā)：客戶端發(fā)起“tools/list”時，網(wǎng)關需查詢所有后端服務器并合并結果。

2. 請求路由：工具調(diào)用需根據(jù)工具名路由到正確后端。

3. 響應多路復用：多個后端的流式響應需合并為單一 SSE 流。

4. 狀態(tài)協(xié)調(diào)：會話 ID 和協(xié)議協(xié)商需在多個后端連接間管理。

5. 錯誤隔離：某個后端故障不應影響整個虛擬會話。

這種協(xié)議感知的聚合與虛擬化遠超傳統(tǒng) API 網(wǎng)關的設計初衷。你幾乎需要重寫網(wǎng)關的核心請求/響應處理邏輯，以支持 MCP 的會話語義。

Agentgateway：為 MCP 而生的網(wǎng)關

Agentgateway 是 Linux 基金會開源項目，采用 Rust 編寫，專為 AI 智能體協(xié)議（如 MCP）設計，吸取了 API 網(wǎng)關的經(jīng)驗教訓。與為無狀態(tài) REST 交互優(yōu)化的傳統(tǒng) API 網(wǎng)關不同，agentgateway 原生理解 JSON-RPC 消息結構，維護有狀態(tài)的會話映射，并支持 MCP 所需的雙向通信模式。

這種深度協(xié)議感知能力，使其能夠正確地多路復用/解復用 MCP 會話，將客戶端請求分發(fā)到多個后端 MCP 服務器，聚合工具列表，并維護服務器主動向客戶端發(fā)消息時所需的關鍵雙向會話映射。agentgateway 的架構天然契合 MCP 的會話導向、流式通信模型，無需與請求 - 響應 API 架構“對抗”。

agentgateway 工作原理動圖

基于此，agentgateway 可作為原生 MCP 網(wǎng)關、大語言模型（LLM）網(wǎng)關和智能體間（A2A）代理，提供傳統(tǒng) API 網(wǎng)關無法實現(xiàn)的安全、可觀測性和治理能力。

它支持 MCP 多路復用，將多個后端服務器的工具統(tǒng)一聯(lián)邦，細粒度授權控制客戶端可訪問的工具，并無縫支持 stdio 與 HTTP Streamable 傳輸。

當與 CNCF 項目 kgateway 作為控制面集成時，agentgateway 具備原生 Kubernetes 能力，團隊可用標準 Gateway API 資源管理 MCP 服務，協(xié)議復雜性由代理自動處理。

這種專為 MCP 設計的方案，為企業(yè)級 MCP 部署帶來高性能、安全性和運維簡潔性，避免了用 API 網(wǎng)關“硬改”帶來的脆弱性、維護負擔和架構妥協(xié)。