傳統(tǒng)API網(wǎng)關(guān)難以處理有狀態(tài)的MCP協(xié)議，其會話、流式和多路復(fù)用等特性需要Agentgateway等專用網(wǎng)關(guān)來解決。

譯自：MCP vs. API Gateways: They’re Not Interchangeable^[1]

作者：Christian Posta

我合作的組織正在迅速采用模型上下文協(xié)議 (MCP)^[2]，通過AI 代理^[3]將其服務(wù)和數(shù)據(jù)連接到 AI 模型，但它們遇到了熟悉的挑戰(zhàn)：如何在提供路由、速率限制、可觀測性和開發(fā)者門戶的同時，保障對 MCP 服務(wù)器和工具的訪問安全。

API 早期采用的經(jīng)驗教訓(xùn)讓我們痛苦地認(rèn)識到，當(dāng)服務(wù)在沒有適當(dāng)網(wǎng)關(guān)控制的情況下暴露時，會導(dǎo)致安全漏洞、性能災(zāi)難和運(yùn)營混亂。

如果你正在企業(yè)中構(gòu)建和暴露 MCP 服務(wù)器，你可能會問我經(jīng)常聽到的那個問題：“我們能直接使用現(xiàn)有的API 網(wǎng)關(guān)^[4]來處理 MCP 嗎？”

簡短的回答是“也許可以”，但真正的問題是：你“應(yīng)該”這樣做嗎？API 網(wǎng)關(guān)并非為 MCP 用例而構(gòu)建。事實上，大多數(shù) API 網(wǎng)關(guān)供應(yīng)商最終都會構(gòu)建專用的 MCP 網(wǎng)關(guān)。

讓我們探討一下 API 和 MCP 之間根本的范式差異，以及為什么現(xiàn)有基礎(chǔ)設(shè)施（API 網(wǎng)關(guān)）必須演進(jìn)。

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

在我們深入探討基礎(chǔ)設(shè)施應(yīng)該做什么之前，我們需要了解這兩種方法之間明顯的區(qū)別。API 是“無狀態(tài)”服務(wù)，它們獨(dú)立地處理每個請求。REST API 大量使用底層傳輸協(xié)議 (HTTP) 來實現(xiàn)協(xié)議語義。實際上，這意味著在 API 網(wǎng)關(guān)中進(jìn)行路由、授權(quán)和實施策略所需的所有信息都存在于 HTTP 請求頭和 URL 結(jié)構(gòu)中。

你的 API 網(wǎng)關(guān)可以通過檢查以下內(nèi)容來做出智能決策：

? 方法 (GET, POST, PUT, DELETE)

? 路徑 (/users/123/orders)

? 請求頭 (Authorization: Bearer xyz, Content-Type)

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

API 網(wǎng)關(guān)很少對請求體進(jìn)行操作。如果進(jìn)行操作，通常是為了進(jìn)行一些次要轉(zhuǎn)換，或?qū)⒉糠謨?nèi)容提取到請求頭或元數(shù)據(jù)中以用于路由。請求體通常遵循可預(yù)測的模式（例如 Open API Spec），可以在需要時使用簡單的映射規(guī)則進(jìn)行驗證和轉(zhuǎn)換。最重要的是，每個請求都是獨(dú)立的，調(diào)用之間無需維護(hù)任何會話狀態(tài)。

遠(yuǎn)程 MCP 服務(wù)器則完全顛覆了這種模型。首先，MCP 客戶端會通過“初始化”消息連接到 MCP 服務(wù)器^[5]并協(xié)商各種協(xié)議設(shè)置。其次，服務(wù)器會分配一個會話 ID（例如 Mcp-Session-Id），用于協(xié)調(diào)該客戶端的所有后續(xù)交互。此會話維護(hù)關(guān)鍵上下文/狀態(tài)，包括：

? 客戶端和服務(wù)器之間協(xié)商的協(xié)議能力（哪些可選功能可用）。

? 之前工具調(diào)用和響應(yīng)的工具結(jié)果/上下文。

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

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

與 REST API 不同，REST API 的每個請求在請求頭中都攜帶著完整的上下文，而 MCP 請求在 HTTP 層中包含最小的路由信息。整個協(xié)議都包含在 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 請求體中：方法類型、被調(diào)用的特定工具以及參數(shù)。HTTP 層只是一個“啞”傳輸。

更具挑戰(zhàn)性的是，MCP 服務(wù)器可以通過服務(wù)器發(fā)送事件 (SSE) 主動向客戶端發(fā)起通信，發(fā)送進(jìn)度更新、流式結(jié)果，甚至新的請求（誘導(dǎo)、采樣等）。這種雙向、會話感知的通信模式與 API 網(wǎng)關(guān)圍繞設(shè)計的請求-響應(yīng)模型有著根本性的不同。

你能將 API 網(wǎng)關(guān)用作 MCP 網(wǎng)關(guān)嗎？

如我們所見，這兩種模型之間存在根本性的差異。但它們也有相似之處，對嗎？它們都通過 HTTP。我們可以應(yīng)用 JWT/令牌/OAuth 風(fēng)格的安全。而且，API 網(wǎng)關(guān)能夠?qū)φ埱篌w進(jìn)行操作也并非牽強(qiáng)。那么，你是否能使用現(xiàn)有的API 網(wǎng)關(guān)來管理 MCP 服務(wù)^[6]呢？

圖片

^[7]以下是你的 API 網(wǎng)關(guān)可能需要執(zhí)行的一些功能（非窮盡列表）：

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

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

? 來自 MCP 客戶端的單個 HTTP POST 可能會導(dǎo)致多個響應(yīng)以流式（SSE）方式返回。

? 需要一種在流中注入策略執(zhí)行的方法。

? 一旦流建立，代理從 MCP 服務(wù)器到 MCP 客戶端的請求。

? 在 MCP 客戶端和 MCP 服務(wù)器之間進(jìn)行差異協(xié)商。

? 向 MCP 客戶端呈現(xiàn)單個邏輯 MCP 服務(wù)器（虛擬 MCP 服務(wù)器），該邏輯服務(wù)器在后端可能由多個 MCP 服務(wù)器組成。

API 網(wǎng)關(guān)可以完成其中一些功能，所以讓我們從簡單到復(fù)雜，看看常見的 MCP 網(wǎng)關(guān)模式：

? 簡單直通代理

? 部分協(xié)議理解

? MCP 協(xié)商

? MCP 多路復(fù)用

簡單直通代理

在最基本的層面，你的 API 網(wǎng)關(guān)可以作為 MCP 流量的直通代理。在這種場景下，網(wǎng)關(guān)將 MCP 請求視為帶有 JSON 負(fù)載的普通 HTTP POST。它不理解 JSON-RPC 結(jié)構(gòu)或 MCP 語義，但仍然可以提供一些價值：

運(yùn)行良好的方面：

? HTTP 級別的認(rèn)證（API 密鑰、OAuth 令牌）

? 每個客戶端或 IP 的基本速率限制

? 傳輸層安全 (TLS) 終止和證書管理

? 請求/響應(yīng)日志記錄和指標(biāo)

圖片

^[8]例如，你可能需要檢查 HTTP Authorization 請求頭中是否包含 JWT，并針對可信的 IdP 驗證 JWT^[9]。這是基本的 HTTP 處理，任何 API 網(wǎng)關(guān)都可以做到。如果響應(yīng)是 SSE 流會怎樣？幸運(yùn)的是，大多數(shù)現(xiàn)代 API 網(wǎng)關(guān)也能返回事件流。如果我們想對響應(yīng)實施一些策略（例如，客戶端可以看到哪些工具），那么我們需要理解 SSE 事件。簡單的直通代理方法不允許我們這樣做。

網(wǎng)關(guān)在 SSE 方面的局限性：

? 沒有流式策略執(zhí)行： 網(wǎng)關(guān)無法檢查或過濾單個 SSE 事件。

? 可觀測性有限： 無法跟蹤進(jìn)度、檢測錯誤或衡量每個事件的延遲。

? 沒有流中授權(quán)： 無法在流進(jìn)行過程中撤銷訪問或應(yīng)用策略。

? 會話上下文丟失： 多個 SSE 事件是同一邏輯 MCP 操作的一部分，但網(wǎng)關(guān)將其視為獨(dú)立的塊。

想象一下，這就像在數(shù)據(jù)庫前面放置一個通用反向代理。你可以獲得連接池和基本監(jiān)控，但沒有查詢級別的洞察或策略。一旦你需要理解流經(jīng)代理的內(nèi)容，這種方法就已經(jīng)無法滿足需求了。

部分協(xié)議理解

這就是事情變得有趣（和復(fù)雜）^[10]的地方。通過足夠的定制開發(fā)，你可以讓你的 API 網(wǎng)關(guān)解析 MCP JSON-RPC 有效負(fù)載，并提取有意義的信息用于策略決策。大多數(shù) API 網(wǎng)關(guān)通過 JavaScript/Lua/模板策略或類似的腳本機(jī)制支持自定義請求體解析。例如，在 Apigee 中^[11]，你可以調(diào)用 JavaScript 擴(kuò)展策略來實現(xiàn)自定義解析和策略。

可能實現(xiàn)的功能：

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

? 應(yīng)用工具級別的授權(quán)（“市場營銷用戶不能調(diào)用 database_query”）。

? 基本的請求轉(zhuǎn)換和驗證。

^[12]痛苦的現(xiàn)實是： 這種方法很快變得脆弱且維護(hù)成本高昂：

? 動態(tài)解析復(fù)雜性： MCP 工具列表的工具長度是任意的。你的 JSONPath 表達(dá)式會變得越來越復(fù)雜和脆弱。

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

? 維護(hù)負(fù)擔(dān)： 每個新的 MCP 工具都可能需要更新網(wǎng)關(guān)策略。你的基礎(chǔ)設(shè)施團(tuán)隊將與你的 MCP 服務(wù)器開發(fā)緊密耦合。

? 有限的流式支持： 盡管某些網(wǎng)關(guān)支持 SSE，但在流中應(yīng)用策略的復(fù)雜性呈指數(shù)級增長。

實際情況是，你最終會在現(xiàn)有網(wǎng)關(guān)之上再構(gòu)建一個網(wǎng)關(guān)，并努力實現(xiàn)新功能或榨取性能提升。

MCP 協(xié)商

MCP 協(xié)商涉及網(wǎng)關(guān)積極參與 MCP 協(xié)議會話，不僅僅是代理請求，還可能根據(jù)策略決策修改、過濾或增強(qiáng)請求。例如，一個 MCP 客戶端可以用某個版本的 MCP 協(xié)議連接到 MCP 網(wǎng)關(guān)，而 MCP 網(wǎng)關(guān)可以協(xié)商/代理到另一個不同的版本。當(dāng) MCP 服務(wù)器更新到新版協(xié)議時，不可能一次性更新所有 MCP 客戶端，因此這種能力在企業(yè)環(huán)境中至關(guān)重要。

其他協(xié)商用例則建立在先前的模式之上：

? 版本屏蔽： 在執(zhí)行 MCP 服務(wù)器升級時，保護(hù) MCP 客戶端免受破壞性更改的影響。

? 請求過濾： 根據(jù)向后兼容性要求從發(fā)現(xiàn)響應(yīng)中移除工具。

? 響應(yīng)凈化： 根據(jù)用戶權(quán)限級別從工具響應(yīng)中去除敏感數(shù)據(jù)。

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

? 錯誤處理： 將 MCP 協(xié)議錯誤轉(zhuǎn)換為符合企業(yè)審計要求的事件。

傳統(tǒng)的 API 網(wǎng)關(guān)在這方面舉步維艱，因為它們?nèi)狈υ?JSON-RPC 理解和會話感知策略引擎。

MCP 多路復(fù)用

這就是傳統(tǒng) API 網(wǎng)關(guān)舉步維艱的地方。MCP 多路復(fù)用涉及將多個后端 MCP 服務(wù)器聚合成一個單一的邏輯端點，我們稱之為“虛擬 MCP”。

例如，客戶端連接到一個 MCP 端點，但實際上可以訪問來自多個后端服務(wù)器的工具：

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

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

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

AI 代理不再需要了解并連接到數(shù)十個不同的 MCP 服務(wù)器，而是連接到一個虛擬化端點，該端點提供所有企業(yè)工具的統(tǒng)一接口。

圖片

^[13]復(fù)雜性急劇增加： 實現(xiàn)這一點需要傳統(tǒng) API 網(wǎng)關(guān)根本不具備的功能：

1. 會話扇出： 當(dāng)客戶端發(fā)送“tools/list”時，網(wǎng)關(guān)必須查詢所有后端服務(wù)器并合并結(jié)果。

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

3. 響應(yīng)多路復(fù)用： 必須將來自多個后端的流式響應(yīng)合并到單個 SSE 流中。

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

5. 錯誤處理： 單個后端中的故障不應(yīng)破壞整個虛擬會話。

這種協(xié)議感知聚合和虛擬化水平超出了傳統(tǒng) API 網(wǎng)關(guān)的設(shè)計處理范圍。你本質(zhì)上需要重寫網(wǎng)關(guān)的核心請求/響應(yīng)處理邏輯以支持 MCP 會話語義。

Agentgateway：從頭開始為 MCP 構(gòu)建

Agentgateway^[14] 是一個開源的 Linux 基金會項目，它吸取了構(gòu)建 API 網(wǎng)關(guān)的經(jīng)驗教訓(xùn)，專門用 Rust 為 MCP 等 AI 代理協(xié)議構(gòu)建。與針對無狀態(tài) REST 交互進(jìn)行優(yōu)化的傳統(tǒng) API 網(wǎng)關(guān)不同，agentgateway 原生理解 JSON-RPC 消息結(jié)構(gòu)，維護(hù)有狀態(tài)會話映射，并處理 MCP 固有的雙向通信模式。

這種深入的協(xié)議感知能力使其能夠正確地多路復(fù)用和解復(fù)用 MCP 會話，將客戶端請求扇出到多個后端 MCP 服務(wù)器，聚合工具列表，并維護(hù)服務(wù)器向客戶端發(fā)起消息時所需的關(guān)鍵雙向會話映射。Agentgateway 的基礎(chǔ)架構(gòu)與 MCP 面向會話、流式通信模型完美契合，而不是與為請求-響應(yīng) API 設(shè)計的架構(gòu)抗?fàn)帯?/span>

圖片

在此基礎(chǔ)上，agentgateway 作為原生 MCP 網(wǎng)關(guān)、大語言模型 (LLM) 網(wǎng)關(guān)和代理到代理 (A2A) 代理，提供傳統(tǒng) API 網(wǎng)關(guān)無法實現(xiàn)的安全、可觀測性和治理能力。

它支持 MCP 多路復(fù)用以聯(lián)合來自多個后端服務(wù)器的工具，應(yīng)用細(xì)粒度授權(quán)策略來控制客戶端可以訪問哪些工具，并無縫處理 stdio 和 HTTP Streamable 傳輸。

當(dāng)與云原生計算基金會 (CNCF)^[15] 項目 kgateway^[16] 集成作為控制平面時，agentgateway 變?yōu)?Kubernetes 原生，使團(tuán)隊能夠使用標(biāo)準(zhǔn)網(wǎng)關(guān) API 資源管理 MCP 服務(wù)，同時代理負(fù)責(zé)協(xié)議特定的復(fù)雜性。

這種專門構(gòu)建的方法提供了企業(yè)在生產(chǎn) MCP 部署所需的性能、安全性和操作簡便性——避免了改造 API 網(wǎng)關(guān)帶來的脆弱性、維護(hù)負(fù)擔(dān)和架構(gòu)折衷。

引用鏈接

[1] MCP vs. API Gateways: They’re Not Interchangeable:https://thenewstack.io/mcp-vs-api-gateways-theyre-not-interchangeable/
[2]模型上下文協(xié)議 (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 網(wǎng)關(guān):https://thenewstack.io/api-gateway-ingress-controller-or-service-mesh-when-to-use-what-and-why/
[5]連接到 MCP 服務(wù)器:https://thenewstack.io/how-to-set-up-a-model-context-protocol-server/
[6]API 網(wǎng)關(guān)來管理 MCP 服務(wù):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]事情變得有趣（和復(fù)雜）: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/