譯者 | 核子可樂

審校 | 重樓

隨著AI原生應(yīng)用與智能體系統(tǒng)的興起，開發(fā)者社區(qū)正迅速迎接種種新興技術(shù)、抽象與架構(gòu)模式。而作為大模型與生成式AI生態(tài)中的新成果，模型上下文協(xié)議（MCP）在引起廣泛關(guān)注的同時，也讓不少開發(fā)者感到困惑：

作為新型傳輸協(xié)議，MCP會最終取代HTTP嗎？

簡單來講：不會。

本文將嘗試討論以下問題，幫助大家理解這兩種協(xié)議之間的核心區(qū)別：

• MCP究竟是什么
• 它與HTTP有何不同
• 為什么會引發(fā)這種困惑
• 二者如何在AI應(yīng)用中協(xié)同起效

模型上下文協(xié)議究竟是什么？

模型上下文協(xié)議的作用，在于定義AI模型如何跨會話與上下文（包括記憶、工具、函數(shù)、用戶偏好與系統(tǒng)指令）進(jìn)行交互。

大家可以把MCP理解成一種應(yīng)用層協(xié)議，旨在幫助AI模型在結(jié)構(gòu)化的架構(gòu)模式與環(huán)境中更加智能、高效地工作。

此協(xié)議負(fù)責(zé)管理以下內(nèi)容：

• 如何初始化及更新上下文
• 模型如何決定調(diào)用哪些工具或函數(shù)
• 如何在會話期間寫入或檢索記憶
• 模型可以對用戶或任務(wù)做出哪些假設(shè)

MCP對于智能體的行為實(shí)現(xiàn)至關(guān)重要。在其幫助下，AI系統(tǒng)可以訪問狀態(tài)信息與外部工具，跨多步驟任務(wù)做出決策。需要強(qiáng)調(diào)的是，MCP本身并非傳輸協(xié)議，因此無法管理字節(jié)在網(wǎng)絡(luò)中的傳輸方式。

那么，HTTP又是什么？

HTTP屬于Web基礎(chǔ)協(xié)議。這種完善的傳輸協(xié)議定義了如何在客戶端與服務(wù)器之間對請求和響應(yīng)進(jìn)行格式化與傳輸。

• 支持Web瀏覽
• 屬于REST API的基礎(chǔ)協(xié)議
• 充當(dāng)大多數(shù)現(xiàn)代應(yīng)用程序的互聯(lián)網(wǎng)通信方式

以下是二者之間的主要區(qū)別：

為何容易混淆？

造成混淆的主要原因包括：

• 二者都被稱為協(xié)議，且遵循客戶端-服務(wù)器拓?fù)浣Y(jié)構(gòu)。必須意識到“協(xié)議”屬于廣義術(shù)語，且MCP的抽象層遠(yuǎn)高于HTTP。
• MCP剛剛興起，且用于涉及上下文的AI通信。其相關(guān)說明文檔和理解水平仍在發(fā)展當(dāng)中。
• 很多人誤以為MCP是一種基礎(chǔ)設(shè)施，類似于HTTP或者WebSocket——但相反，它更像是模型的對話管理器。

MCP如何與HTTP協(xié)同工作？

MCP并非旨在取代HTTP，而是運(yùn)行在HTTP、WebSocket或者其他傳輸層之上。

與之類似的還有HTTP之上的GraphQL、基于HTTP/2的gRPC以及通過HTTP編碼并發(fā)送的JSON。

MCP負(fù)責(zé)定義模型處理請求的語義，而HTTP則是在客戶端與服務(wù)器之間傳輸這些請求。

AI應(yīng)用程序可能會通過HTTP發(fā)送符合MCP的請求負(fù)載。該負(fù)載包含模型智能運(yùn)行所需要的一切：先前消息、可用工具、用戶記憶、函數(shù)定義等等。

因此可以得出哪些結(jié)論？

• 從定義來看，MCP并非傳輸協(xié)議，也不會取代HTTP。
• MCP是用于管理AI上下文交互的高級別協(xié)議。
• MCP與AI智能體的未來工作方式緊密相關(guān)，包括記憶、工具和推理。
• 換言之，MCP與HTTP屬于互補(bǔ)關(guān)系、而非競爭關(guān)系。

總結(jié)

隨著我們逐步邁向AI原生軟件架構(gòu)，理解MCP等新興概念也變得愈發(fā)重要?？梢钥吹?，MCP正成為構(gòu)建更智能、更持久、更強(qiáng)大AI系統(tǒng)（可作為真正智能體自主運(yùn)作）的廣泛趨勢中的重要組成部分。

但我們必須明確一點(diǎn)：HTTP仍然在幕后承擔(dān)著繁重的工作。

總而言之，MCP改變的是我們與AI模型的交互方式，而非數(shù)據(jù)從A點(diǎn)傳輸至B點(diǎn)的方式。

原文標(biāo)題：Is the Model Context Protocol a Replacement for HTTP?，作者：Vijay Joshi