MCP 與 API 網(wǎng)關(guān)：二者不可互換
MCP 與 API 網(wǎng)關(guān)在架構(gòu)和協(xié)議層面存在本質(zhì)差異，企業(yè)應(yīng)采用專(zhuān)為 MCP 設(shè)計(jì)的網(wǎng)關(guān)方案以保障安全性與可擴(kuò)展性，而非簡(jiǎn)單復(fù)用傳統(tǒng) API 網(wǎng)關(guān)。
我服務(wù)的許多組織正在快速采用 模型上下文協(xié)議（MCP），以便通過(guò) AI 智能體將服務(wù)和數(shù)據(jù)連接到 AI 模型。但他們也遇到了熟悉的挑戰(zhàn)：既要保護(hù) MCP 服務(wù)器和工具的訪問(wèn)安全，又要實(shí)現(xiàn)路由、限流、可觀測(cè)性和開(kāi)發(fā)者門(mén)戶(hù)等能力。
API 早期的普及讓我們深刻體會(huì)到：如果沒(méi)有合適的網(wǎng)關(guān)控制，服務(wù)暴露會(huì)帶來(lái)安全漏洞、性能災(zāi)難和運(yùn)維混亂。
如果你正在企業(yè)內(nèi)部構(gòu)建并暴露 MCP 服務(wù)器，你很可能會(huì)問(wèn)我經(jīng)常被問(wèn)到的問(wèn)題：“我們能不能直接用現(xiàn)有的 API 網(wǎng)關(guān)來(lái)做 MCP？”
簡(jiǎn)短的答案是“也許可以”，但真正的問(wèn)題是“你應(yīng)該這樣做嗎？”API 網(wǎng)關(guān)并不是為 MCP 場(chǎng)景設(shè)計(jì)的。事實(shí)上，大多數(shù) API 網(wǎng)關(guān)廠商最終都會(huì)推出專(zhuān)用的 MCP 網(wǎng)關(guān)。
讓我們深入探討 API 與 MCP 的根本范式差異，以及為何現(xiàn)有基礎(chǔ)設(shè)施（API 網(wǎng)關(guān)）必須進(jìn)化。
API 是無(wú)狀態(tài)的，MCP 是有狀態(tài)的
在討論基礎(chǔ)設(shè)施應(yīng)如何演進(jìn)前，首先要理解這兩種方式的本質(zhì)區(qū)別。API 是“無(wú)狀態(tài)”服務(wù)，每個(gè)請(qǐng)求都是獨(dú)立處理的。REST API 嚴(yán)重依賴(lài)底層傳輸協(xié)議（HTTP）來(lái)表達(dá)協(xié)議語(yǔ)義。實(shí)際上，這意味著 API 網(wǎng)關(guān)所需的所有路由、鑒權(quán)和策略信息都包含在 HTTP 頭和 URL 結(jié)構(gòu)中。
API 網(wǎng)關(guān)可以通過(guò)以下方式做出智能決策：
? 方法（如 GET、POST、PUT、DELETE）
? 路徑（如 /users/123/orders）
? 頭部（如 Authorization: Bearer xyz、Content-Type）
? 查詢(xún)參數(shù)（如 ?limit=10&offset=50）
API 網(wǎng)關(guān)很少處理請(qǐng)求體內(nèi)容。如果需要，也只是做些簡(jiǎn)單轉(zhuǎn)換，或?qū)⒉糠謨?nèi)容提取到頭部或元數(shù)據(jù)中用于路由。請(qǐng)求體通常遵循可預(yù)測(cè)的結(jié)構(gòu)（如 Open API 規(guī)范），可通過(guò)簡(jiǎn)單的映射規(guī)則進(jìn)行校驗(yàn)和轉(zhuǎn)換。最重要的是，每個(gè)請(qǐng)求都是獨(dú)立的，無(wú)需維護(hù)會(huì)話(huà)狀態(tài)。
而遠(yuǎn)程 MCP 服務(wù)器則完全顛覆了這一模式。首先，MCP 客戶(hù)端會(huì)通過(guò)“initialize”消息與 MCP 服務(wù)器建立連接，并協(xié)商協(xié)議參數(shù)。隨后，服務(wù)器分配一個(gè)會(huì)話(huà) ID（如 Mcp-Session-Id），用于協(xié)調(diào)該客戶(hù)端后續(xù)所有交互。這個(gè)會(huì)話(huà)會(huì)維護(hù)關(guān)鍵上下文/狀態(tài)，包括：
? 客戶(hù)端與服務(wù)器協(xié)商的協(xié)議能力（可用的可選特性）。
? 前序工具調(diào)用及響應(yīng)的結(jié)果/上下文。
? 異步工具調(diào)用狀態(tài)、流式更新/通知。
? 服務(wù)器向客戶(hù)端請(qǐng)求的信息狀態(tài)。
與 REST API 不同，MCP 請(qǐng)求在 HTTP 層只包含極少的路由信息，協(xié)議內(nèi)容全部在 HTTP 請(qǐng)求體中。典型的 MCP 請(qǐng)求如下：
POST /mcp
Mcp-Session-Id: session_abc123
Content-Type: application/json
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "database_query",
"arguments": { /* 復(fù)雜嵌套結(jié)構(gòu) */ }
},
"id": "call_456"
}所有有意義的信息都在 JSON-RPC 請(qǐng)求體中：方法類(lèi)型、具體調(diào)用的工具及參數(shù)。HTTP 層只是“啞巴”傳輸通道。
更具挑戰(zhàn)性的是，MCP 服務(wù)器還可以通過(guò) Server-Sent Events（SSE）主動(dòng)向客戶(hù)端推送進(jìn)度更新、流式結(jié)果，甚至發(fā)起新請(qǐng)求（如引導(dǎo)、采樣等）。這種雙向、會(huì)話(huà)感知的通信模式與 API 網(wǎng)關(guān)設(shè)計(jì)時(shí)的請(qǐng)求 - 響應(yīng)模型截然不同。
能否用 API 網(wǎng)關(guān)替代 MCP 網(wǎng)關(guān)？
如上所述，兩者有本質(zhì)區(qū)別。但也有相似之處：都基于 HTTP，可以應(yīng)用 JWT/Token/OAuth 等安全機(jī)制，API 網(wǎng)關(guān)也能操作請(qǐng)求體。那么，能否用 API 網(wǎng)關(guān)治理 MCP 服務(wù)？
API 網(wǎng)關(guān)與 MCP 網(wǎng)關(guān)對(duì)比示意圖
以下是你可能希望 API 網(wǎng)關(guān)實(shí)現(xiàn)的部分功能（非詳盡列表）：
? 解析請(qǐng)求體和響應(yīng)（JSON-RPC），實(shí)現(xiàn)協(xié)議語(yǔ)義。
? 對(duì)請(qǐng)求體中的部分內(nèi)容（如工具列表、工具調(diào)用、資源請(qǐng)求等）注入策略決策（允許/拒絕）。
? MCP 客戶(hù)端的單個(gè) HTTP POST 可能對(duì)應(yīng)多個(gè)響應(yīng)，并以流式（SSE）返回。
? 需要在流中注入策略執(zhí)行。
? 建立流后，將 MCP 服務(wù)器的請(qǐng)求代理到 MCP 客戶(hù)端。
? 協(xié)調(diào) MCP 客戶(hù)端與 MCP 服務(wù)器之間的差異。
? 向 MCP 客戶(hù)端呈現(xiàn)單一邏輯 MCP 服務(wù)器（虛擬 MCP 服務(wù)器），后端可能有多個(gè) MCP 服務(wù)器。
API 網(wǎng)關(guān)能實(shí)現(xiàn)部分功能，下面按復(fù)雜度遞增梳理常見(jiàn)的 MCP 網(wǎng)關(guān)模式：
? 簡(jiǎn)單透?jìng)鞔?/p>
? 部分協(xié)議理解
? MCP 協(xié)調(diào)代理（Brokering）
? MCP 多路復(fù)用（Multiplexing）
簡(jiǎn)單透?jìng)鞔?/h2>
最基礎(chǔ)的做法是讓 API 網(wǎng)關(guān)作為 MCP 流量的透?jìng)鞔怼Ｔ谶@種場(chǎng)景下，網(wǎng)關(guān)將 MCP 請(qǐng)求視為普通的 HTTP POST + JSON 負(fù)載，不理解 JSON-RPC 結(jié)構(gòu)或 MCP 語(yǔ)義，但仍能提供一定價(jià)值：
優(yōu)勢(shì)
? HTTP 層認(rèn)證（API Key、OAuth Token）
? 按客戶(hù)端或 IP 的基礎(chǔ)限流
? 傳輸層安全（TLS）終止與證書(shū)管理
? 請(qǐng)求/響應(yīng)日志與基礎(chǔ)指標(biāo)采集
MCP 透?jìng)鞔硎疽鈭D
例如，你可以校驗(yàn) HTTP Authorization 頭中的 JWT，并通過(guò)可信 IdP 驗(yàn)證 JWT。這是基礎(chǔ)的 HTTP 處理，任何 API 網(wǎng)關(guān)都能勝任。如果響應(yīng)為 SSE 流？幸運(yùn)的是，大多數(shù)現(xiàn)代 API 網(wǎng)關(guān)也能返回事件流。如果你想對(duì)響應(yīng)實(shí)施策略（如限制客戶(hù)端可見(jiàn)的工具），則需要理解 SSE 事件。簡(jiǎn)單透?jìng)鞔頍o(wú)法實(shí)現(xiàn)這一點(diǎn)。
SSE 下的網(wǎng)關(guān)局限
? 無(wú)法流式策略執(zhí)行：網(wǎng)關(guān)無(wú)法檢查或過(guò)濾單獨(dú)的 SSE 事件。
? 可觀測(cè)性有限：無(wú)法跟蹤進(jìn)度、檢測(cè)錯(cuò)誤或統(tǒng)計(jì)每個(gè)事件的延遲。
? 無(wú)中途授權(quán)能力：無(wú)法在流式過(guò)程中撤銷(xiāo)訪問(wèn)或動(dòng)態(tài)應(yīng)用策略。
? 會(huì)話(huà)上下文丟失：多個(gè) SSE 事件屬于同一 MCP 操作，但網(wǎng)關(guān)視為獨(dú)立片段。
這就像在數(shù)據(jù)庫(kù)前面加了個(gè)通用反向代理：你能獲得連接池和基礎(chǔ)監(jiān)控，但無(wú)法實(shí)現(xiàn)查詢(xún)級(jí)洞察或策略。一旦需要理解代理流量?jī)?nèi)容，這種方式就不夠用了。
部分協(xié)議支持
這里開(kāi)始變得有趣且復(fù)雜。通過(guò)自定義開(kāi)發(fā)，你可以讓 API 網(wǎng)關(guān)解析 MCP 的 JSON-RPC 負(fù)載，并提取有意義的信息用于策略決策。大多數(shù) API 網(wǎng)關(guān)支持通過(guò) JavaScript/Lua/模板策略等機(jī)制自定義請(qǐng)求體解析。例如，在 Apigee中，可以調(diào)用 JavaScript 擴(kuò)展策略實(shí)現(xiàn)自定義解析與策略。
能力提升
? 更好地理解 JSON-RPC 請(qǐng)求。
? 實(shí)現(xiàn)工具級(jí)授權(quán)（如“市場(chǎng)部用戶(hù)不能調(diào)用 database_query”）。
? 基礎(chǔ)請(qǐng)求轉(zhuǎn)換與校驗(yàn)。
部分協(xié)議支持示意圖
痛點(diǎn)在于：這種方式很快變得脆弱且維護(hù)成本高：
? 動(dòng)態(tài)解析復(fù)雜：MCP 工具列表長(zhǎng)度不定，JSONPath 表達(dá)式越來(lái)越復(fù)雜且易碎。
? 性能開(kāi)銷(xiāo)大：JavaScript 策略比原生網(wǎng)關(guān)策略慢。
? 維護(hù)負(fù)擔(dān)重：每新增 MCP 工具都可能需要更新網(wǎng)關(guān)策略，基礎(chǔ)設(shè)施團(tuán)隊(duì)與 MCP 服務(wù)器開(kāi)發(fā)強(qiáng)耦合。
? 流式支持有限：部分網(wǎng)關(guān)支持 SSE，但流中策略執(zhí)行復(fù)雜度指數(shù)級(jí)上升。
實(shí)際情況是，你最終會(huì)在現(xiàn)有網(wǎng)關(guān)之上再造一個(gè)網(wǎng)關(guān)，不斷為新特性和性能優(yōu)化而掙扎。
MCP 協(xié)調(diào)代理（Brokering）
MCP 協(xié)調(diào)代理要求網(wǎng)關(guān)主動(dòng)參與 MCP 協(xié)議對(duì)話(huà)，不僅僅是代理請(qǐng)求，還能根據(jù)策略修改、過(guò)濾或增強(qiáng)請(qǐng)求。例如，MCP 客戶(hù)端可用一個(gè)協(xié)議版本連接 MCP 網(wǎng)關(guān)，網(wǎng)關(guān)再與后端 MCP 服務(wù)器協(xié)商不同版本。這在企業(yè)環(huán)境中尤為關(guān)鍵——當(dāng) MCP 服務(wù)器升級(jí)協(xié)議版本時(shí)，不可能讓所有客戶(hù)端同步升級(jí)。
在前述模式基礎(chǔ)上，協(xié)調(diào)代理還可實(shí)現(xiàn)：
? 版本屏蔽：MCP 服務(wù)器升級(jí)時(shí)，保護(hù) MCP 客戶(hù)端免受破壞性變更影響。
? 請(qǐng)求過(guò)濾：根據(jù)兼容性需求，從發(fā)現(xiàn)響應(yīng)中移除部分工具。
? 響應(yīng)脫敏：根據(jù)用戶(hù)權(quán)限，從工具響應(yīng)中剝離敏感數(shù)據(jù)。
? 上下文注入：為工具調(diào)用添加企業(yè)上下文（如用戶(hù) ID、租戶(hù)信息）。
? 錯(cuò)誤處理：將 MCP 協(xié)議錯(cuò)誤轉(zhuǎn)化為企業(yè)合規(guī)的審計(jì)事件。
傳統(tǒng) API 網(wǎng)關(guān)難以勝任這些場(chǎng)景，因?yàn)樗鼈內(nèi)狈υ?JSON-RPC 理解和會(huì)話(huà)感知的策略引擎。
MCP 多路復(fù)用（Multiplexing）
這時(shí)，傳統(tǒng) API 網(wǎng)關(guān)徹底“撞墻”。MCP 多路復(fù)用要求將多個(gè)后端 MCP 服務(wù)器聚合為一個(gè)邏輯端點(diǎn)，即“虛擬 MCP”。
例如，客戶(hù)端只需連接一個(gè) MCP 端點(diǎn)，即可訪問(wèn)多個(gè)后端服務(wù)器的工具：
? 天氣工具來(lái)自 weather-service.internal
? 數(shù)據(jù)庫(kù)工具來(lái)自 analytics-service.internal
? 郵件工具來(lái)自 notification-service.internal
AI 智能體無(wú)需了解和連接眾多 MCP 服務(wù)器，只需對(duì)接一個(gè)虛擬端點(diǎn)，統(tǒng)一訪問(wèn)所有企業(yè)工具。
MCP 多路復(fù)用聚合示意圖
復(fù)雜度爆炸：實(shí)現(xiàn)這一點(diǎn)需要傳統(tǒng) API 網(wǎng)關(guān)不具備的能力：
1. 會(huì)話(huà)分發(fā)：客戶(hù)端發(fā)起“tools/list”時(shí)，網(wǎng)關(guān)需查詢(xún)所有后端服務(wù)器并合并結(jié)果。
2. 請(qǐng)求路由：工具調(diào)用需根據(jù)工具名路由到正確后端。
3. 響應(yīng)多路復(fù)用：多個(gè)后端的流式響應(yīng)需合并為單一 SSE 流。
4. 狀態(tài)協(xié)調(diào)：會(huì)話(huà) ID 和協(xié)議協(xié)商需在多個(gè)后端連接間管理。
5. 錯(cuò)誤隔離：某個(gè)后端故障不應(yīng)影響整個(gè)虛擬會(huì)話(huà)。
這種協(xié)議感知的聚合與虛擬化遠(yuǎn)超傳統(tǒng) API 網(wǎng)關(guān)的設(shè)計(jì)初衷。你幾乎需要重寫(xiě)網(wǎng)關(guān)的核心請(qǐng)求/響應(yīng)處理邏輯，以支持 MCP 的會(huì)話(huà)語(yǔ)義。
Agentgateway：為 MCP 而生的網(wǎng)關(guān)
Agentgateway 是 Linux 基金會(huì)開(kāi)源項(xiàng)目，采用 Rust 編寫(xiě)，專(zhuān)為 AI 智能體協(xié)議（如 MCP）設(shè)計(jì)，吸取了 API 網(wǎng)關(guān)的經(jīng)驗(yàn)教訓(xùn)。與為無(wú)狀態(tài) REST 交互優(yōu)化的傳統(tǒng) API 網(wǎng)關(guān)不同，agentgateway 原生理解 JSON-RPC 消息結(jié)構(gòu)，維護(hù)有狀態(tài)的會(huì)話(huà)映射，并支持 MCP 所需的雙向通信模式。
這種深度協(xié)議感知能力，使其能夠正確地多路復(fù)用/解復(fù)用 MCP 會(huì)話(huà)，將客戶(hù)端請(qǐng)求分發(fā)到多個(gè)后端 MCP 服務(wù)器，聚合工具列表，并維護(hù)服務(wù)器主動(dòng)向客戶(hù)端發(fā)消息時(shí)所需的關(guān)鍵雙向會(huì)話(huà)映射。agentgateway 的架構(gòu)天然契合 MCP 的會(huì)話(huà)導(dǎo)向、流式通信模型，無(wú)需與請(qǐng)求 - 響應(yīng) API 架構(gòu)“對(duì)抗”。
agentgateway 工作原理動(dòng)圖
基于此，agentgateway 可作為原生 MCP 網(wǎng)關(guān)、大語(yǔ)言模型（LLM）網(wǎng)關(guān)和智能體間（A2A）代理，提供傳統(tǒng) API 網(wǎng)關(guān)無(wú)法實(shí)現(xiàn)的安全、可觀測(cè)性和治理能力。
它支持 MCP 多路復(fù)用，將多個(gè)后端服務(wù)器的工具統(tǒng)一聯(lián)邦，細(xì)粒度授權(quán)控制客戶(hù)端可訪問(wèn)的工具，并無(wú)縫支持 stdio 與 HTTP Streamable 傳輸。
當(dāng)與 CNCF 項(xiàng)目 kgateway 作為控制面集成時(shí)，agentgateway 具備原生 Kubernetes 能力，團(tuán)隊(duì)可用標(biāo)準(zhǔn) Gateway API 資源管理 MCP 服務(wù)，協(xié)議復(fù)雜性由代理自動(dòng)處理。
這種專(zhuān)為 MCP 設(shè)計(jì)的方案，為企業(yè)級(jí) MCP 部署帶來(lái)高性能、安全性和運(yùn)維簡(jiǎn)潔性，避免了用 API 網(wǎng)關(guān)“硬改”帶來(lái)的脆弱性、維護(hù)負(fù)擔(dān)和架構(gòu)妥協(xié)。
