TL;DR

API 作為數(shù)字世界的連接紐帶，雖推動了開放生態(tài)的繁榮，卻因協(xié)議碎片化、開發(fā)高成本陷入“巴別塔困境”。MCP（模型上下文協(xié)議）的誕生，標(biāo)志著 AI 交互范式從“人工編碼適配”邁向“機器自主協(xié)作”。通過標(biāo)準(zhǔn)化服務(wù)描述與上下文感知機制，MCP 成為 AI 時代的“萬能適配器”——既消除工具間的協(xié)議鴻溝，又支持運行時動態(tài)編排，使 AI 應(yīng)用能像“熱插拔硬件”一樣自由調(diào)用跨領(lǐng)域服務(wù)。

本文將從 API 的歷史演進、MCP 的設(shè)計理念、 以“幫我查詢周末的天氣，如果下雨就推薦附近的電影院”一個簡單場景為例，展示 MCP 如何實現(xiàn) AI 應(yīng)用的智能編排，助力 AI 應(yīng)用實現(xiàn)“所想即所得”的認(rèn)知革命。

從代碼接口到數(shù)字生態(tài)的基石

關(guān)鍵詞：標(biāo)準(zhǔn)化、能力復(fù)用、開放。

API（Application Programming Interface，應(yīng)用程序編程接口）是軟件系統(tǒng)之間交互的標(biāo)準(zhǔn)化接口，它定義了數(shù)據(jù)交換的規(guī)則和協(xié)議。從手機 App 到云計算平臺，API 支撐著現(xiàn)代數(shù)字世界的運行。

萌芽：本地化代碼接口

上個世界 60 年代，UNIX 操作系統(tǒng)率先使用系統(tǒng)調(diào)用（System Call），如文件讀寫 open()、write() 等，為應(yīng)用程序提供了訪問操作系統(tǒng)資源的接口，成為 API 的雛形。隨著結(jié)構(gòu)化編程的興起，API 逐漸演變?yōu)楹瘮?shù)庫（Library），如 C 語言的標(biāo)準(zhǔn)庫 stdio.h、stdlib.h 等，提供了更高級的接口。

網(wǎng)絡(luò)化：跨系統(tǒng)通信協(xié)議

隨著計算機網(wǎng)絡(luò)的發(fā)展，不同計算機之間的通信也需要標(biāo)準(zhǔn)化接口，于是網(wǎng)絡(luò)協(xié)議誕生了，如早期的 CORBA 通用對象請求代理架構(gòu)^[1]、DCOM 分布式組件對象模型^[2]，再到上世紀(jì)末的 SOAP 簡單對象訪問協(xié)議^[3] 為跨系統(tǒng)的通信提供了協(xié)議基礎(chǔ)。這些都是早期 Web API 的雛形。

Web：REST 與開放生態(tài)

進入新千年，Web 2.0 的興起，互聯(lián)網(wǎng)應(yīng)用迅速發(fā)展，API 也進入了新的階段。RESTful API^[4] 成為主流，它基于 HTTP 協(xié)議，使用 URL、HTTP 方法等標(biāo)準(zhǔn)化的方式，實現(xiàn)了資源的增刪改查等操作。

Web API 的爆發(fā)隨之而來的是開放平臺運動，如 Facebook、Twitter 等開放 API，讓第三方開發(fā)者可以訪問平臺數(shù)據(jù)，構(gòu)建出豐富的應(yīng)用生態(tài)。

成熟：標(biāo)準(zhǔn)化與多樣性

現(xiàn)代 Web API 如 OpenAPI、GraphQL、gRPC 等，進一步提升了 API 的開發(fā)效率和易用性。隨著 API 的成熟，出現(xiàn)了一大批以 API 為核心商業(yè)模式的公司。API 即產(chǎn)品的出現(xiàn)，帶來了 API 經(jīng)濟的崛起。

與此同時，通過標(biāo)準(zhǔn)化 API 解耦系統(tǒng)組件，實現(xiàn)了基礎(chǔ)設(shè)施的彈性、可觀測性和可擴展性，以此為核心的云原生技術(shù)帶來了現(xiàn)在基礎(chǔ)設(shè)施的變革。

趨勢展望：全域互聯(lián)與認(rèn)知革命

隨著物聯(lián)網(wǎng)、5G 、邊緣計算等技術(shù)的發(fā)展，我們迎來了超大規(guī)模的 API 網(wǎng)絡(luò)。各種各樣的設(shè)備、傳感器、服務(wù)都通過 API 連接在一起，構(gòu)成了數(shù)字化的生態(tài)系統(tǒng)。

風(fēng)頭正盛大模型不只是通過 API 對外提供服務(wù)，還會通過 API 與其他服務(wù)進行交互，實現(xiàn)更高級的認(rèn)知決策。

從機械式指令到認(rèn)知決策

關(guān)鍵詞：系統(tǒng)、決策、熱插拔

大模型的出現(xiàn)，為 API 的智能化交互提供了新的機會，如自然語言處理、多模態(tài)交互、自主決策等。實現(xiàn)了 API 的交互模式完成了從機械式指令、資源化操作到語義化交互、認(rèn)知型決策的演進。

這一轉(zhuǎn)變，將原本面向機器通信，強調(diào)功能和數(shù)據(jù)調(diào)用的 API，轉(zhuǎn)變?yōu)槊嫦?AI 交互。

“方言“林立：API 的巴別塔困局

假設(shè)我們想將一個外部服務(wù)集成到我們的應(yīng)用中，我們可以通過 API 調(diào)用的方式，將外部服務(wù)的功能引入到我們的應(yīng)用中。此時，我們需要閱讀該服務(wù)公開的 API 文檔，了解 API 的功能、參數(shù)、調(diào)用方式等，然后編寫代碼調(diào)用 API，實現(xiàn)功能的集成。

如果需要集成更多的能力，我們需要調(diào)用更多的 API，編寫更多的代碼。由于 API 的生態(tài)多樣性，不同的 API 在協(xié)議、參數(shù)、調(diào)用方式等方面都有所不同，API 的巴別塔困局使得開發(fā)者需要花費大量時間和精力去理解和調(diào)用不同的 API、處理調(diào)用異常，還需要編寫大量的粘合代碼來實現(xiàn)不同 API 之間的數(shù)據(jù)轉(zhuǎn)換和調(diào)用。

這一切都是在設(shè)計階段實現(xiàn)的，應(yīng)用與 API 之間是強耦合的關(guān)系，擴展、升級、替換 API 都需要重新設(shè)計和開發(fā)。

LLM 驅(qū)動：以智能跨越鴻溝

大模型 LLM 可以理解自然語言，自然也可以理解結(jié)構(gòu)化的 API 文檔并與之交互。學(xué)習(xí) API 的負(fù)擔(dān)從開發(fā)人員轉(zhuǎn)移到了大模型，這一學(xué)習(xí)過程甚至可以在運行時進行，并持續(xù)進行。

這一方式有可能顛覆傳統(tǒng)的 API 集成模式，從“人工編碼適配”轉(zhuǎn)向“機器自主學(xué)習(xí)”，成為破解 API 巴別塔困局的關(guān)鍵路徑。

舉個例子，用戶輸入指令 “幫我查詢周末的天氣，如果下雨就推薦附近的電影院”。大模型可以自動識別這一需求，并調(diào)用設(shè)備 API 獲取位置信息、調(diào)用天氣 API 獲取未來的天氣狀況、調(diào)用地圖 API 根據(jù)位置信息獲取附近的電影院，最終將結(jié)果返回給用戶。這個過程中，涉及了多種 API 的調(diào)用、決策邏輯的處理，以及上下文數(shù)據(jù)的傳遞。

但要讓這一愿景真正落地，僅靠大模型的語義理解能力并不足夠。當(dāng)多個 API 的調(diào)用邏輯嵌套、上下文數(shù)據(jù)需要跨系統(tǒng)流轉(zhuǎn)時，如何確保不同協(xié)議的參數(shù)對齊？如何處理調(diào)用異常，避免流程的中斷，提供備選方案。

試想：當(dāng)用戶說“如果下雨就推薦電影院”，大模型首先要理解各個 API 的能力，明確 API 的使用場景和調(diào)用方式。執(zhí)行是要記住“下雨”狀態(tài)并傳遞給地圖 API，還需要確保這一狀態(tài)在設(shè)備定位、天氣服務(wù)與影院推薦服務(wù)之間無縫同步——**這才是跨越巴別塔的真正橋梁：既讓機器聽懂人言，又讓機器之間說同一種語言。

MCP：語義一致性基座

2024 年 11 月 Anthropic 公司發(fā)布了 MCP（Model Context Protocol）^[5] 協(xié)議，這是一個開放協(xié)議，旨在為 AI 應(yīng)用向大模型提供環(huán)境上下文建立標(biāo)準(zhǔn)化接口。

MCP 如同人工智能領(lǐng)域的 USB-C 接口，通過統(tǒng)一的數(shù)據(jù)接入標(biāo)準(zhǔn)，使各類 AI 模型能夠無縫對接多樣化數(shù)據(jù)源及功能工具。其核心價值在于構(gòu)建通用連接規(guī)范，實現(xiàn)模型與外部系統(tǒng)的高效互操作性。

MCP 是典型的客戶端 - 服務(wù)器架構(gòu)。服務(wù)器端提供特定的功能，應(yīng)用程序通過客戶端來使用服務(wù)器端的功能?？蛻舳伺c服務(wù)器端是一對一的關(guān)系，維護者二者之間的通信（目前有兩種方式：標(biāo)準(zhǔn)輸入輸出和 SSE），使用 JSON-RPC^[6] 2.0 作為消息格式。

MCP 的目標(biāo)建立一個所有機器都能理解的“世界語”，通過標(biāo)準(zhǔn)化上下文傳遞、協(xié)議轉(zhuǎn)換和意圖映射，讓跨系統(tǒng)協(xié)作像單系統(tǒng)般自然流暢。這是實現(xiàn)“機器自主協(xié)作”而非“人工編碼適配”的關(guān)鍵基礎(chǔ)設(shè)施。

上下文感知的“粘合劑”

在跨服務(wù)的調(diào)用鏈中（如“查天氣→推薦影院”），MCP 自動維護上下文狀態(tài)（如用戶位置、天氣狀態(tài)、影院篩選條件），確保數(shù)據(jù)在流程中無損傳遞。

通過引入不同的 MCP 服務(wù)器，應(yīng)用程序可以變身成為多面手。例如，通過引入天氣服務(wù) MCP，應(yīng)用程序可以查詢天氣信息；通過引入地圖服務(wù) MCP，應(yīng)用程序可以查詢地圖信息。這樣，應(yīng)用程序可以通過 MCP 與不同的服務(wù)進行交互，實現(xiàn)更多的功能。

聲明式服務(wù)

MCP 通過聲明式服務(wù)描述，將服務(wù)的能力、輸入輸出、調(diào)用方式等信息進行標(biāo)準(zhǔn)化，使得大模型可以獲取并理解服務(wù)的能力，自動調(diào)用服務(wù)，實現(xiàn)服務(wù)的智能編排。

{
  "mcpServers": {
    "amap-maps": {
      "command": "npx",
      "args": [
        "-y",
        "@amap/amap-maps-mcp-server"
      ],
      "env": {
        "AMAP_MAPS_API_KEY": "KEY"
      }
    }
  }
}

只需將服務(wù)通過聲明的形式描述出來，大模型便可以自動獲取服務(wù)的能力。在應(yīng)用連接到 MCP 服務(wù)器后，會自動從 MCP 服務(wù)器獲取服務(wù)的能力。所以，當(dāng)我們詢問該服務(wù)器都有哪些能力時，可以即刻返回功能列表，無需調(diào)用任何工具。

圖片

服務(wù)智能編排

通過 MCP，大模型可以獲取服務(wù)的能力，自動調(diào)用服務(wù)，實現(xiàn)服務(wù)的智能編排。例如，用戶輸入“幫我查詢周末的天氣，如果下雨就推薦附近的電影院”，大模型會自動編排決定功能的調(diào)用順序：

1. 調(diào)用定位服務(wù)獲取用戶位置信息。這里由于獲取 IP 地址失敗，應(yīng)用自動提供交互界面，不會中斷流程。（我選擇了廣州）
2. 根據(jù)獲取到的位置信息以及當(dāng)前的時間，調(diào)用天氣服務(wù)獲取周末的天氣信息。
3. 如果天氣信息顯示周末會下雨，調(diào)用地圖服務(wù)獲取附近的電影院信息。（正好廣州周末會下雨）

圖片

能力熱插拔

這讓我想起小時候看過的動畫片正義戰(zhàn)士（Centurions）中的裝備升級。每次戰(zhàn)斗前，他們可以根據(jù)不同的敵人和戰(zhàn)場情況，選擇不同的裝備。裝備通過太空中的空間站投送到戰(zhàn)場上，戰(zhàn)士們可以快速更換裝備，加入戰(zhàn)斗。

通過 MCP，應(yīng)用程序可以動態(tài)添加、刪除服務(wù)，實現(xiàn)能力的熱插拔。這點與傳統(tǒng) API 在設(shè)計階段的集成方式方式不同，MCP 可以實現(xiàn)在運行時動態(tài)添加服務(wù)，實現(xiàn)功能的快速擴展。

展望

未來，MCP 或?qū)⒊蔀?AI 服務(wù)生態(tài)的“神經(jīng)系統(tǒng)”：在更多場景中協(xié)調(diào)多模態(tài)設(shè)備/服務(wù)，在決策中串聯(lián)數(shù)據(jù)分析與認(rèn)知模型，甚至成為通用 AI Agent 的底層協(xié)作協(xié)議。

隨著工具生態(tài)的完善，MCP 將推動 AI 應(yīng)用從“功能固化的程序”進化為“自主進化的智能體”，最終實現(xiàn)“所想即所得”的認(rèn)知革命。

參考資料

[1]CORBA 通用對象請求代理架構(gòu): https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

[2]DCOM 分布式組件對象模型: https://en.wikipedia.org/wiki/Distributed_Component_Object_Model

[3]SOAP 簡單對象訪問協(xié)議: https://en.wikipedia.org/wiki/SOAP

[4]RESTful API: https://en.wikipedia.org/wiki/REST

[5]MCP（Model Context Protocol）: https://modelcontextprotocol.io/

[6]JSON-RPC: https://www.jsonrpc.org/