架構(gòu)解析：MCP 并非靈丹妙藥
Hello folks，我是 Luga，今天我們來(lái)聊一下人工智能應(yīng)用場(chǎng)景中大語(yǔ)言模型（LLM）標(biāo)準(zhǔn)協(xié)議 - MCP。
在大模型工程化落地的浪潮中，MCP（Model Context Protocol）正在經(jīng)歷一個(gè)典型的技術(shù)擴(kuò)散周期。
從“解決具體問(wèn)題的協(xié)議設(shè)計(jì)”，迅速演變?yōu)椤氨患挠韬裢募軜?gòu)銀彈”。甚至，在一些討論中，MCP 被賦予了過(guò)高的預(yù)期：
- 用 MCP 統(tǒng)一 Agent 工具調(diào)用
- 用 MCP 解決上下文混亂
- 用 MCP 構(gòu)建通用 Agent 平臺(tái)
這些判斷并非完全錯(cuò)誤，但隱含了一個(gè)危險(xiǎn)前提：把“協(xié)議能力”誤當(dāng)成“系統(tǒng)能力”……
最近跟一位社區(qū)的朋友在探討 MCP 在生產(chǎn)環(huán)境中落地的場(chǎng)景時(shí)，他來(lái)了一句：“MCP violates several assumptions we rely on for building reliable systems.”
故此，寫(xiě)文敘之……
本文將從架構(gòu)層級(jí)、系統(tǒng)職責(zé)與工程落地三個(gè)維度，對(duì) MCP 進(jìn)行一次徹底“去神話化”的拆解，并給出一個(gè)清晰結(jié)論：MCP 是一塊必要但有限的拼圖，而不是完整答案 ……
一、架構(gòu)透視：MCP 本質(zhì)上是“倒置控制權(quán)的 RPC”
眾所周知，在經(jīng)典微服務(wù)體系中，調(diào)用鏈的控制權(quán)始終掌握在確定性代碼手中：
即便是復(fù)雜的服務(wù)編排（Saga、Workflow），決策邏輯仍然是可審計(jì)、可回放、可測(cè)試的代碼路徑。
而 MCP 引入之后，調(diào)用鏈則變?yōu)椋?/p>
MCP 架構(gòu)的核心變化，并不在于 JSON-RPC 這種傳輸形式，而在于“誰(shuí)決定要調(diào)用什么”。因此，在 MCP 中：
- 調(diào)用發(fā)起者不再是代碼，而是 LLM
- 調(diào)用條件不是 if/else，而是概率推斷
- 調(diào)用參數(shù)不是結(jié)構(gòu)化輸入，而是自然語(yǔ)言解析結(jié)果
這是一種典型的控制反轉(zhuǎn)（Inversion of Control），但控制權(quán)并沒(méi)有交給框架，而是交給了一個(gè)不可預(yù)測(cè)的模型。
我們來(lái)看一段典型的 MCP JSON-RPC 請(qǐng)求：
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "database_query",
"arguments": {
"sql": "DELETE FROM users WHERE id = 'U123'; -- Oops"
}
},
"id": 1
}從協(xié)議視角看，這沒(méi)有任何問(wèn)題：
- JSON-RPC 合法
- 方法名正確
- 參數(shù)結(jié)構(gòu)清晰
但從架構(gòu)視角看，這是一次嚴(yán)重的責(zé)任缺失。MCP 協(xié)議只承擔(dān)了一件事，即：
“把 LLM 生成的意圖，原樣搬運(yùn)到后端。”
它不做、也無(wú)法做：
- 參數(shù)語(yǔ)義校驗(yàn)
- 權(quán)限校驗(yàn)
- 業(yè)務(wù)上下文一致性驗(yàn)證
問(wèn)題卻恰恰在這里……
一旦后端服務(wù)默認(rèn)信任 MCP Server 的轉(zhuǎn)發(fā)行為，整個(gè)系統(tǒng)就發(fā)生了一個(gè)危險(xiǎn)的等價(jià)變換：
你并不是在“給 LLM 接工具”，而是在把內(nèi)部 RPC 接口暴露給一個(gè)不可控的決策者。
二、MCP 生產(chǎn)落地的 3 大陷阱解析
1. 陷阱一：信任邊界塌陷 —— MCP 天生是 Confused Deputy
Confused Deputy（混淆代理）并不是 MCP 獨(dú)有的問(wèn)題，但 MCP 天然放大了這個(gè)風(fēng)險(xiǎn)。在傳統(tǒng)系統(tǒng)設(shè)計(jì)中：
- 用戶身份清晰
- 權(quán)限與接口強(qiáng)綁定
- 調(diào)用路徑可控
而在 MCP 中，調(diào)用路徑變成了：User Intent → Prompt → LLM 推斷 → Tool
Call 中間這一跳，是不可驗(yàn)證的。
于是，出現(xiàn)如下場(chǎng)景：
從實(shí)際的架構(gòu)設(shè)計(jì)中，MCP Server 無(wú)法判斷：這是用戶的真實(shí)意圖 or 還是 LLM 的幻覺(jué) 亦或是 還是一次攻擊成功的結(jié)果。
2. 陷阱二：可觀測(cè)性斷裂 —— LLM 是天然的 Trace 黑洞
在云原生 Kubernetes 體系中，我們依賴如下假設(shè)：
- Trace Context 可以跨進(jìn)程傳播
- 每個(gè)調(diào)用都有確定的 Span 邊界
- 時(shí)間消耗可被精確歸因
而 MCP 的調(diào)用鏈實(shí)際上是：
User
→ HTTP Request (Trace A)
→ LLM Gateway
→ 模型推理（不可觀測(cè)）
→ MCP JSON-RPC（Trace 丟失）
→ 后端服務(wù)（新 Trace）因此，在某種場(chǎng)景下，我們往往看到的只是數(shù)據(jù)庫(kù)報(bào)錯(cuò)，卻永遠(yuǎn)找不到是哪一次用戶提問(wèn)觸發(fā)的。
3. 陷阱三：無(wú)狀態(tài)協(xié)議 vs 有狀態(tài)業(yè)務(wù)的結(jié)構(gòu)性沖突
MCP 是 Stateless 的，這是優(yōu)點(diǎn)，而業(yè)務(wù)是 Stateful 的，這是現(xiàn)實(shí)。當(dāng)你讓 LLM 承擔(dān)“上下文維護(hù)”職責(zé)時(shí)，本質(zhì)上是在：
- 用 Token 換狀態(tài)
- 用 Prompt 堆疊替代事務(wù)管理
- 用概率推斷模擬狀態(tài)機(jī)
這在工程上是不可持續(xù)的。正確的設(shè)計(jì)原則應(yīng)該是：
- 狀態(tài)永遠(yuǎn)由服務(wù)端維護(hù)
- LLM 只負(fù)責(zé)意圖表達(dá)
- MCP Server 是“富客戶端”，而非函數(shù)轉(zhuǎn)發(fā)器
我們以航班機(jī)票為例，需求為：“幫我訂一張明天從北京到上海的機(jī)票，預(yù)算2000元以內(nèi)。” 此時(shí)，需要：
- 查詢航班（MCP 調(diào)用）；
- 過(guò)濾價(jià)格（LLM 決策）；
- 調(diào)用支付（MCP 調(diào)用）；
- 處理失敗回滾（狀態(tài)協(xié)調(diào)）。
MCP 協(xié)議本身不提供狀態(tài)機(jī)、不支持事務(wù)、不記錄中間結(jié)果。所有狀態(tài)必須由 LLM 在上下文中“記住”，極易因 Token 截?cái)嗷蛏慑e(cuò)誤而丟失。
這就像讓一個(gè)人用便簽紙記賬，而不是用數(shù)據(jù)庫(kù)。
三、該如何理解 MCP 在生產(chǎn)環(huán)境中的落地呢 ？
MCP 要在生產(chǎn)環(huán)境可用，不能只實(shí)現(xiàn)協(xié)議，而必須構(gòu)建一套完整的治理架構(gòu)。因?yàn)椋簠f(xié)議只是表象，治理才是核心。
MCP 的本質(zhì)，是一個(gè)輕量級(jí)的工具調(diào)用協(xié)議，解決的是“如何讓 LLM 調(diào)用函數(shù)”的語(yǔ)法問(wèn)題，但遠(yuǎn)未解決“如何在生產(chǎn)環(huán)境中安全、可靠、可觀測(cè)地集成 AI 與系統(tǒng)”的架構(gòu)問(wèn)題。
因此，在云原生 K8s 環(huán)境中，若要落地 MCP，必須做到如下：
- 協(xié)議之上建治理：注冊(cè)、鑒權(quán)、校驗(yàn)、審計(jì)缺一不可；
- 網(wǎng)絡(luò)與執(zhí)行隔離：MCP Server 必須運(yùn)行在受限沙箱中；
- 可觀測(cè)性貫通：Trace ID 必須貫穿 LLM → MCP → 后端；明確使用邊界：只用于低風(fēng)險(xiǎn)、只讀、封閉場(chǎng)景。
否則，MCP 非但不能“增強(qiáng)智能”，反而會(huì)成為系統(tǒng)中最危險(xiǎn)的單點(diǎn)。畢竟，真正的 AI 原生架構(gòu)，不在于引入多少新協(xié)議，而在于如何將 AI 能力嵌入現(xiàn)有工程體系，而不破壞其可靠性根基。
因此，毫不避諱的說(shuō)：MCP 可以是其中一環(huán)，但絕不是靈丹妙藥。
Happy Coding ~
Reference ：
- [1] https://www.iweaver.ai/blog/mcp-explained-i-breaking-ais-context-limits-for-collab/
- [2] https://blog.sshh.io/p/everything-wrong-with-mcp
Adiós !
