TL;DR

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

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

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

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

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

萌芽：本地化代碼接口

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MCP：語(yǔ)義一致性基座

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

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

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

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

上下文感知的“粘合劑”

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

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

聲明式服務(wù)

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

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

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

圖片

服務(wù)智能編排

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

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

圖片

能力熱插拔

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

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

展望

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

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

參考資料

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

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

[3]SOAP 簡(jiǎn)單對(duì)象訪問(wèn)協(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/