MCP與API網關：不可互換的各自定位
傳統API網關難以處理有狀態的MCP協議，其會話、流式和多路復用等特性需要Agentgateway等專用網關來解決。
譯自：MCP vs. API Gateways: They’re Not Interchangeable[1]
作者：Christian Posta
我合作的組織正在迅速采用模型上下文協議 (MCP)[2]，通過AI 代理[3]將其服務和數據連接到 AI 模型，但它們遇到了熟悉的挑戰：如何在提供路由、速率限制、可觀測性和開發者門戶的同時，保障對 MCP 服務器和工具的訪問安全。
API 早期采用的經驗教訓讓我們痛苦地認識到，當服務在沒有適當網關控制的情況下暴露時，會導致安全漏洞、性能災難和運營混亂。
如果你正在企業中構建和暴露 MCP 服務器，你可能會問我經常聽到的那個問題：“我們能直接使用現有的API 網關[4]來處理 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 Spec），可以在需要時使用簡單的映射規則進行驗證和轉換。最重要的是，每個請求都是獨立的，調用之間無需維護任何會話狀態。
遠程 MCP 服務器則完全顛覆了這種模型。首先，MCP 客戶端會通過“初始化”消息連接到 MCP 服務器[5]并協商各種協議設置。其次，服務器會分配一個會話 ID（例如 Mcp-Session-Id），用于協調該客戶端的所有后續交互。此會話維護關鍵上下文/狀態，包括：
? 客戶端和服務器之間協商的協議能力（哪些可選功能可用）。
? 之前工具調用和響應的工具結果/上下文。
? 異步工具調用狀態；流式更新/通知。
? 從服務器到客戶端的請求信息狀態。
與 REST API 不同，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": { /* complex nested structure */ }
},
"id": "call_456"
}所有有意義的信息都存在于 JSON-RPC 請求體中：方法類型、被調用的特定工具以及參數。HTTP 層只是一個“啞”傳輸。
更具挑戰性的是，MCP 服務器可以通過服務器發送事件 (SSE) 主動向客戶端發起通信，發送進度更新、流式結果，甚至新的請求（誘導、采樣等）。這種雙向、會話感知的通信模式與 API 網關圍繞設計的請求-響應模型有著根本性的不同。
你能將 API 網關用作 MCP 網關嗎？
如我們所見，這兩種模型之間存在根本性的差異。但它們也有相似之處，對嗎？它們都通過 HTTP。我們可以應用 JWT/令牌/OAuth 風格的安全。而且，API 網關能夠對請求體進行操作也并非牽強。那么，你是否能使用現有的API 網關來管理 MCP 服務[6]呢？
圖片
[7]以下是你的 API 網關可能需要執行的一些功能（非窮盡列表）：
? 解析請求體和響應 (JSON-RPC)，實現協議語義。
? 對請求體中的部分內容（工具列表、工具調用、資源請求等）注入策略決策（允許/拒絕）。
? 來自 MCP 客戶端的單個 HTTP POST 可能會導致多個響應以流式（SSE）方式返回。
? 需要一種在流中注入策略執行的方法。
? 一旦流建立，代理從 MCP 服務器到 MCP 客戶端的請求。
? 在 MCP 客戶端和 MCP 服務器之間進行差異協商。
? 向 MCP 客戶端呈現單個邏輯 MCP 服務器（虛擬 MCP 服務器），該邏輯服務器在后端可能由多個 MCP 服務器組成。
API 網關可以完成其中一些功能，所以讓我們從簡單到復雜，看看常見的 MCP 網關模式：
? 簡單直通代理
? 部分協議理解
? MCP 協商
? MCP 多路復用
簡單直通代理
在最基本的層面，你的 API 網關可以作為 MCP 流量的直通代理。在這種場景下，網關將 MCP 請求視為帶有 JSON 負載的普通 HTTP POST。它不理解 JSON-RPC 結構或 MCP 語義，但仍然可以提供一些價值：
運行良好的方面：
? HTTP 級別的認證（API 密鑰、OAuth 令牌）
? 每個客戶端或 IP 的基本速率限制
? 傳輸層安全 (TLS) 終止和證書管理
? 請求/響應日志記錄和指標
圖片
[8]例如，你可能需要檢查 HTTP Authorization 請求頭中是否包含 JWT，并針對可信的 IdP 驗證 JWT[9]。這是基本的 HTTP 處理，任何 API 網關都可以做到。如果響應是 SSE 流會怎樣？幸運的是，大多數現代 API 網關也能返回事件流。如果我們想對響應實施一些策略（例如，客戶端可以看到哪些工具），那么我們需要理解 SSE 事件。簡單的直通代理方法不允許我們這樣做。
網關在 SSE 方面的局限性：
? 沒有流式策略執行： 網關無法檢查或過濾單個 SSE 事件。
? 可觀測性有限： 無法跟蹤進度、檢測錯誤或衡量每個事件的延遲。
? 沒有流中授權： 無法在流進行過程中撤銷訪問或應用策略。
? 會話上下文丟失： 多個 SSE 事件是同一邏輯 MCP 操作的一部分，但網關將其視為獨立的塊。
想象一下，這就像在數據庫前面放置一個通用反向代理。你可以獲得連接池和基本監控，但沒有查詢級別的洞察或策略。一旦你需要理解流經代理的內容，這種方法就已經無法滿足需求了。
部分協議理解
這就是事情變得有趣（和復雜）[10]的地方。通過足夠的定制開發，你可以讓你的 API 網關解析 MCP JSON-RPC 有效負載，并提取有意義的信息用于策略決策。大多數 API 網關通過 JavaScript/Lua/模板策略或類似的腳本機制支持自定義請求體解析。例如，在 Apigee 中[11]，你可以調用 JavaScript 擴展策略來實現自定義解析和策略。
可能實現的功能：
? 更好地理解 JSON-RPC 請求。
? 應用工具級別的授權（“市場營銷用戶不能調用 database_query”）。
? 基本的請求轉換和驗證。
[12]痛苦的現實是： 這種方法很快變得脆弱且維護成本高昂：
? 動態解析復雜性： MCP 工具列表的工具長度是任意的。你的 JSONPath 表達式會變得越來越復雜和脆弱。
? 性能開銷： JavaScript 策略比原生網關策略慢。
? 維護負擔： 每個新的 MCP 工具都可能需要更新網關策略。你的基礎設施團隊將與你的 MCP 服務器開發緊密耦合。
? 有限的流式支持： 盡管某些網關支持 SSE，但在流中應用策略的復雜性呈指數級增長。
實際情況是，你最終會在現有網關之上再構建一個網關，并努力實現新功能或榨取性能提升。
MCP 協商
MCP 協商涉及網關積極參與 MCP 協議會話，不僅僅是代理請求，還可能根據策略決策修改、過濾或增強請求。例如，一個 MCP 客戶端可以用某個版本的 MCP 協議連接到 MCP 網關，而 MCP 網關可以協商/代理到另一個不同的版本。當 MCP 服務器更新到新版協議時，不可能一次性更新所有 MCP 客戶端，因此這種能力在企業環境中至關重要。
其他協商用例則建立在先前的模式之上：
? 版本屏蔽： 在執行 MCP 服務器升級時，保護 MCP 客戶端免受破壞性更改的影響。
? 請求過濾： 根據向后兼容性要求從發現響應中移除工具。
? 響應凈化： 根據用戶權限級別從工具響應中去除敏感數據。
? 上下文注入： 向工具調用添加企業上下文（用戶 ID、租戶信息）。
? 錯誤處理： 將 MCP 協議錯誤轉換為符合企業審計要求的事件。
傳統的 API 網關在這方面舉步維艱，因為它們缺乏原生的 JSON-RPC 理解和會話感知策略引擎。
MCP 多路復用
這就是傳統 API 網關舉步維艱的地方。MCP 多路復用涉及將多個后端 MCP 服務器聚合成一個單一的邏輯端點，我們稱之為“虛擬 MCP”。
例如，客戶端連接到一個 MCP 端點，但實際上可以訪問來自多個后端服務器的工具：
? 來自 weather-service.internal 的天氣工具
? 來自 analytics-service.internal 的數據庫工具
? 來自 notification-service.internal 的電子郵件工具
AI 代理不再需要了解并連接到數十個不同的 MCP 服務器，而是連接到一個虛擬化端點，該端點提供所有企業工具的統一接口。
圖片
[13]復雜性急劇增加： 實現這一點需要傳統 API 網關根本不具備的功能：
1. 會話扇出： 當客戶端發送“tools/list”時，網關必須查詢所有后端服務器并合并結果。
2. 請求路由： 工具調用必須根據工具名稱路由到正確的后端。
3. 響應多路復用： 必須將來自多個后端的流式響應合并到單個 SSE 流中。
4. 狀態協調： 必須跨多個后端連接管理會話 ID 和協議協商。
5. 錯誤處理： 單個后端中的故障不應破壞整個虛擬會話。
這種協議感知聚合和虛擬化水平超出了傳統 API 網關的設計處理范圍。你本質上需要重寫網關的核心請求/響應處理邏輯以支持 MCP 會話語義。
Agentgateway：從頭開始為 MCP 構建
Agentgateway[14] 是一個開源的 Linux 基金會項目，它吸取了構建 API 網關的經驗教訓，專門用 Rust 為 MCP 等 AI 代理協議構建。與針對無狀態 REST 交互進行優化的傳統 API 網關不同，agentgateway 原生理解 JSON-RPC 消息結構，維護有狀態會話映射，并處理 MCP 固有的雙向通信模式。
這種深入的協議感知能力使其能夠正確地多路復用和解復用 MCP 會話，將客戶端請求扇出到多個后端 MCP 服務器，聚合工具列表，并維護服務器向客戶端發起消息時所需的關鍵雙向會話映射。Agentgateway 的基礎架構與 MCP 面向會話、流式通信模型完美契合，而不是與為請求-響應 API 設計的架構抗爭。
圖片
在此基礎上，agentgateway 作為原生 MCP 網關、大語言模型 (LLM) 網關和代理到代理 (A2A) 代理，提供傳統 API 網關無法實現的安全、可觀測性和治理能力。
它支持 MCP 多路復用以聯合來自多個后端服務器的工具，應用細粒度授權策略來控制客戶端可以訪問哪些工具，并無縫處理 stdio 和 HTTP Streamable 傳輸。
當與云原生計算基金會 (CNCF)[15] 項目 kgateway[16] 集成作為控制平面時，agentgateway 變為 Kubernetes 原生，使團隊能夠使用標準網關 API 資源管理 MCP 服務，同時代理負責協議特定的復雜性。
這種專門構建的方法提供了企業在生產 MCP 部署所需的性能、安全性和操作簡便性——避免了改造 API 網關帶來的脆弱性、維護負擔和架構折衷。
引用鏈接
[1] MCP vs. API Gateways: They’re Not Interchangeable:https://thenewstack.io/mcp-vs-api-gateways-theyre-not-interchangeable/[2]模型上下文協議 (MCP):https://thenewstack.io/model-context-protocol-a-primer-for-the-developers/[3]AI 代理:https://thenewstack.io/how-ai-agents-will-change-the-web-for-users-and-developers/[4]API 網關:https://thenewstack.io/api-gateway-ingress-controller-or-service-mesh-when-to-use-what-and-why/[5]連接到 MCP 服務器:https://thenewstack.io/how-to-set-up-a-model-context-protocol-server/[6]API 網關來管理 MCP 服務:https://thenewstack.io/solocon-explore-service-mesh-api-gateways-graphql-ebpf/[7]:https://cdn.thenewstack.io/media/2025/10/60cb4d80-image1-1024x141.png[8]:https://cdn.thenewstack.io/media/2025/10/5920c6b1-image3-1024x208.png[9]驗證 JWT:https://thenewstack.io/using-jwts-to-authenticate-services-unravels-api-gateways/[10]事情變得有趣（和復雜）:https://blog.christianposta.com/building-an-mcp-gateway-on-top-of-apigee/[11]在 Apigee 中:https://blog.christianposta.com/building-an-mcp-gateway-on-top-of-apigee/[12]:https://cdn.thenewstack.io/media/2025/10/2b8f9f28-image2-1024x237.png[13]:https://cdn.thenewstack.io/media/2025/10/4fd51832-image4-1024x499.png[14]Agentgateway:https://agentgateway.dev/[15]云原生計算基金會 (CNCF):https://cncf.io/?utm_cnotallow=inline+mention[16]kgateway:https://kgateway.dev/
