萌芽:本地化代碼接口

上個世界 60 年代,UNIX 操作系統(tǒng)率先使用系統(tǒng)調(diào)用(System Call),如文件讀寫

open()

write()

等,為應用程序提供了訪問操作系統(tǒng)資源的接口,成為 API 的雛形。隨著結(jié)構(gòu)化編程的興起,API 逐漸演變?yōu)楹瘮?shù)庫(Library),如 C 語言的標準庫

stdio.h

stdlib.h

等,提供了更高級的接口。

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

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

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

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

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

成熟:標準化與多樣性

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

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

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

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

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

從機械式指令到認知決策

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

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

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

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

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

image

如果需要集成更多的能力,我們需要調(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)的,應用與 API 之間是強耦合的關(guān)系,擴展、升級、替換 API 都需要重新設(shè)計和開發(fā)。

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

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

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

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

這個過程中,涉及了多種 API 的調(diào)用、決策邏輯的處理,以及上下文數(shù)據(jù)的傳遞。但要讓這一愿景真正落地,僅靠大模型的語義理解能力并不足夠。

當多個 API 的調(diào)用邏輯嵌套、上下文數(shù)據(jù)需要跨系統(tǒng)流轉(zhuǎn)時,如何確保不同協(xié)議的參數(shù)對齊?如何處理調(diào)用異常,避免流程的中斷,提供備選方案。

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

MCP:語義一致性基座

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

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

MCP 是典型的客戶端 – 服務器架構(gòu)。服務器端提供特定的功能,應用程序通過客戶端來使用服務器端的功能。客戶端與服務器端是一對一的關(guān)系,維護者二者之間的通信(目前有兩種方式:標準輸入輸出和 SSE),使用?JSON-RPC[6]?2.0 作為消息格式。

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

上下文感知的“粘合劑”

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

image

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

聲明式服務

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

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

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

image

服務智能編排

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

image

能力熱插拔

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

image

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

展望未來

MCP 或?qū)⒊蔀?AI 服務生態(tài)的“神經(jīng)系統(tǒng)”:在更多場景中協(xié)調(diào)多模態(tài)設(shè)備/服務,在決策中串聯(lián)數(shù)據(jù)分析與認知模型,甚至成為通用 AI Agent 的底層協(xié)作協(xié)議。隨著工具生態(tài)的完善,MCP 將推動 AI 應用從“功能固化的程序”進化為“自主進化的智能體”,最終實現(xià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/

文章轉(zhuǎn)載自云原生指北。點擊這里閱讀原文了解更多。

申請 KubeCon + CloudNativeCon 最終用戶門票(免費邀請票數(shù)量有限,先到先得。)

贊助 KubeCon + CloudNativeCon(簽署的合同必須在 2025 年 4 月 18 日前提交。)

原文轉(zhuǎn)載自:https://mp.weixin.qq.com/s/krWo7LEA3rUDaZpmX6haqQ

熱門推薦
一個賬號試用1000+ API
助力AI無縫鏈接物理世界 · 無需多次注冊
3000+提示詞助力AI大模型
和專業(yè)工程師共享工作效率翻倍的秘密
返回頂部
上一篇
2025年虛擬信用卡推薦與評測
下一篇
使用自然語言管理 API:APISIX MCP Server
国内精品久久久久影院日本,日本中文字幕视频,99久久精品99999久久,又粗又大又黄又硬又爽毛片
久久香蕉国产线看观看99| 91精品久久久久久久99蜜桃| 国产露脸91国语对白| 欧美成人三级电影在线| 国产在线一区二区| 国产精品久久久久国产精品日日| 成人av一区二区三区| 成人免费在线观看入口| 欧美视频在线观看一区二区| 午夜精品一区在线观看| 欧美一卡二卡三卡四卡| 国产成人免费视频一区| 一区二区高清免费观看影视大全| 91精品国产色综合久久不卡电影 | 久久99蜜桃精品| 久久免费的精品国产v∧| 一本一本久久a久久精品综合麻豆| 日韩美女精品在线| 欧美精品在线视频| 波多野结衣精品在线| 五月天激情综合| 国产精品美女视频| 精品日本一线二线三线不卡| 91免费视频观看| 另类小说欧美激情| 亚洲成a天堂v人片| 1024成人网色www| 精品国产麻豆免费人成网站| 在线观看日韩高清av| 国产成人精品免费在线| 日韩精品一级二级| 亚洲黄色免费网站| 亚洲欧美综合另类在线卡通| 久久嫩草精品久久久精品| 欧美日韩免费一区二区三区视频| 成人网在线播放| 国产一区二区视频在线播放| 丝袜亚洲另类欧美综合| 亚洲已满18点击进入久久| 中文字幕精品一区二区三区精品| 欧美mv日韩mv| 欧美精品一区男女天堂| 欧美日韩1234| 欧美日韩国产精品成人| 欧美性色黄大片| 在线观看亚洲精品| 欧美日韩二区三区| 8x8x8国产精品| 日韩免费成人网| 久久影院视频免费| 国产精品视频麻豆| 综合欧美一区二区三区| 亚洲精品日韩一| 亚洲成av人片在线| 看电视剧不卡顿的网站| 国产真实精品久久二三区| 国产精品99久久久久久久vr| 国产精品亚洲专一区二区三区 | 日韩美一区二区三区| 26uuu亚洲综合色欧美| 久久影院电视剧免费观看| 国产欧美日韩精品在线| 亚洲人成精品久久久久| 五月综合激情婷婷六月色窝| 美女视频黄a大片欧美| 国产中文字幕一区| 色综合久久天天| 欧美一区二区三区婷婷月色| 精品国产三级a在线观看| 日韩一区欧美一区| 日韩精品视频网站| 粉嫩av一区二区三区粉嫩| 色狠狠综合天天综合综合| 日韩一区二区三区电影在线观看| 久久精品视频免费观看| 一区二区三区国产豹纹内裤在线| 婷婷国产v国产偷v亚洲高清| 国产成人啪午夜精品网站男同| 在线视频国内一区二区| 精品电影一区二区| 香蕉乱码成人久久天堂爱免费| 久久激情五月婷婷| 在线视频欧美精品| 中文字幕精品一区| 久久精品二区亚洲w码| 欧美午夜一区二区| 国产精品国产三级国产| 极品少妇xxxx精品少妇偷拍| 欧美日韩成人综合天天影院| 国产精品免费丝袜| 国产一区中文字幕| 日韩一区二区免费高清| 亚洲午夜精品一区二区三区他趣| 岛国一区二区三区| 久久久久亚洲综合| 国产真实乱对白精彩久久| 日韩精品一区国产麻豆| 亚洲18影院在线观看| 色哟哟国产精品| 国产日韩精品一区二区三区在线| 日本在线不卡一区| 欧美一卡在线观看| 肉丝袜脚交视频一区二区| 精品视频免费看| 亚洲国产精品一区二区久久 | 天堂成人免费av电影一区| 欧美色爱综合网| 亚洲国产精品久久久男人的天堂| 99国产精品一区| 亚洲精品日产精品乱码不卡| 欧洲视频一区二区| 五月婷婷激情综合| 日韩美女在线视频| 国产精品亚洲第一区在线暖暖韩国| 亚洲精品一线二线三线| 国产精品自拍三区| 国产精品亲子伦对白| 色综合一区二区| 一区二区在线观看视频| 国产精品99久久久久久久vr | 欧美日韩一区二区三区四区五区| 亚洲激情av在线| 51午夜精品国产| 久久草av在线| 中文字幕中文字幕一区| 日韩欧美卡一卡二| 日本午夜精品视频在线观看 | 欧美欧美欧美欧美| 亚洲妇女屁股眼交7| 欧美tickling挠脚心丨vk| 国产在线不卡一卡二卡三卡四卡| 欧美大黄免费观看| 91性感美女视频| 日韩中文欧美在线| 国产拍欧美日韩视频二区| 在线中文字幕一区| 99这里只有精品| 国产欧美综合色| gogo大胆日本视频一区| 亚洲午夜精品17c| 亚洲美女视频在线| 日韩一级免费一区| 91年精品国产| 国产成人啪午夜精品网站男同| 伊人一区二区三区| 日本一二三不卡| 日韩欧美亚洲国产另类| av在线播放不卡| 国产精品一区二区三区99| 石原莉奈在线亚洲三区| 一区二区三区在线视频播放| 国产午夜精品一区二区三区嫩草| 欧美一级日韩免费不卡| 欧洲生活片亚洲生活在线观看| 成人精品小蝌蚪| 成人美女视频在线观看18| 麻豆传媒一区二区三区| 一区二区三区 在线观看视频| 国产女人水真多18毛片18精品视频 | 亚洲精品视频在线| 欧美国产乱子伦| 久久中文字幕电影| 日韩欧美成人激情| 91精品国产日韩91久久久久久| 色婷婷综合久久久久中文一区二区 | 亚洲欧美韩国综合色| 国产精品久久久久久亚洲伦| 久久久久久久久99精品| 欧美美女视频在线观看| 欧美日本在线一区| 日韩欧美在线观看一区二区三区| 欧美精品在欧美一区二区少妇| 欧美久久久久久蜜桃| 日韩视频不卡中文| 欧美精品一区二区精品网| 久久久综合精品| 国产精品乱人伦| 亚洲欧美一区二区不卡| 亚洲午夜一二三区视频| 蜜桃久久久久久久| 国产精品一区二区三区网站| 成人午夜在线免费| 在线亚洲人成电影网站色www| 欧美少妇性性性| 欧美变态凌虐bdsm| 一区二区中文视频| 丝袜美腿亚洲色图| 国产经典欧美精品| 欧美日韩精品一区视频| 久久婷婷国产综合精品青草| 国产精品国产a级| 日本91福利区| 99re热这里只有精品视频| 91精品国产全国免费观看| 中文字幕不卡在线观看| 婷婷成人综合网| jizzjizzjizz欧美| 日韩一级片网站| 亚洲午夜久久久久久久久久久| 国内外成人在线视频|