前面幾篇文章中，我介紹了AI大模型領(lǐng)域常見的幾種專業(yè)術(shù)語，分別是：AGI、RAG、AIGC、LLM、MCP、EMB、向量庫、訓練集、多模態(tài)。了解基礎(chǔ)概念和專業(yè)術(shù)語之后，有助于我們在工作和生活中深入學習和應(yīng)用AI。

這個時候，可能有同學會產(chǎn)生疑問，這么多大模型、ChatBot、智能體等AI工具，我該如何將它們?nèi)谌氲阶约旱纳詈凸ぷ鲌鼍爸心兀縿e急，這篇文章，解答你的疑惑。

過去在IT互聯(lián)網(wǎng)技術(shù)領(lǐng)域，一個APP背后的技術(shù)架構(gòu)，有web層、server層、中間件、數(shù)據(jù)庫和底層的操作系統(tǒng)，看起來很復雜。后來大家逐漸形成了較為統(tǒng)一的標準，即通過API接口將不同層級之間串聯(lián)起來，最終才能形成一個能提供完善服務(wù)的APP應(yīng)用。

在AI領(lǐng)域，現(xiàn)在以及未來也會有類似的統(tǒng)一標準或者機制出現(xiàn)，來實現(xiàn)大模型、智能體等AI工具之間的協(xié)作通信。截至目前來看，AI交互協(xié)議共出現(xiàn)了三種代表性的范式，如下圖所示，分別是FC、MCP、A2A。

圖片

一、FC：函數(shù)調(diào)用技術(shù)

FC(Function Calling)是一種函數(shù)調(diào)用技術(shù)，由OpenAI推動，旨在通過調(diào)用外部函數(shù)或API，使大型語言模型(LLM)能夠與外部系統(tǒng)交互，從而擴展其能力。其核心原理包括以下幾點：

1、工作原理

允許開發(fā)者定義一組函數(shù)，并通過自然語言指令觸。這些函數(shù)通常以JSON格式描述，包含函數(shù)名稱、參數(shù)和返回值等信息。

當用戶提出需要執(zhí)行特定任務(wù)的問題時，模型會解析問題并判斷是否需要調(diào)用預定義的函數(shù)。如果需要，模型會生成調(diào)用函數(shù)所需的參數(shù)，并通過API執(zhí)行該函數(shù)，最后將結(jié)果返回給用戶。

2、技術(shù)實現(xiàn)

Function Calling依賴于模型對自然語言的理解能力，通過解析用戶輸入生成函數(shù)調(diào)用參數(shù)。例如，當用戶詢問天氣時，模型會調(diào)用一個獲取天氣信息的函數(shù)，并將結(jié)果以自然語言形式呈現(xiàn)。

在OpenAI的實現(xiàn)中，F(xiàn)unction Calling通過API調(diào)用外部服務(wù)，如數(shù)據(jù)庫查詢或?qū)崟r數(shù)據(jù)獲取。開發(fā)者可以定義函數(shù)并將其與模型綁定，使模型能夠根據(jù)輸入選擇合適的函數(shù)執(zhí)行。

3、優(yōu)勢與不足

主要優(yōu)勢：簡化復雜操作、提高開發(fā)效率，并增強模型的生成能力和應(yīng)用范圍。

不足之處：不同開發(fā)者可能采用不同的函數(shù)定義方式，導致通用性不足；此外，處理多任務(wù)時可能會遇到上下文限制問題。

二、MCP：模型上下文協(xié)議

MCP(Model Context Protocol)是一種標準化的開放通信協(xié)議，由Anthropic公司于2024年11月推出，旨在為大型語言模型(LLM)提供標準化的接口，實現(xiàn)與外部數(shù)據(jù)源和工具的無縫集成。

它通過統(tǒng)一接口連接AI模型與外部工具和資源，類似于USB接口在電子設(shè)備中的作用。它允許AI模型動態(tài)發(fā)現(xiàn)并調(diào)用外部服務(wù)，而無需預先定義固定代碼。其核心目標是簡化AI應(yīng)用開發(fā)，提高效率并減少重復開發(fā)工作。

1、技術(shù)原理

• MCP采用客戶端-服務(wù)器架構(gòu)，主要由三部分組成：
• MCP主機(Host)： 負責發(fā)起對外部數(shù)據(jù)源的請求，處理和轉(zhuǎn)發(fā)這些請求。
• MCP客戶端(Client)： 嵌入在主機應(yīng)用中，負責與外部MCP服務(wù)器建立連接并傳遞數(shù)據(jù)。
• MCP服務(wù)器(Server)： 提供工具、資源和提示模板等核心功能，支持雙向?qū)崟r通信。

2、工作流程

• 創(chuàng)建階段： 配置并注冊MCP服務(wù)器，包括安裝、驗證和授權(quán)。
• 運行階段： 處理工具調(diào)用請求，執(zhí)行外部API調(diào)用，并將結(jié)果返回給AI模型。
• 更新階段： 確保服務(wù)器保持最新狀態(tài)，適應(yīng)不斷變化的需求。

3、核心功能

• 統(tǒng)一接口： 提供標準化的JSON-RPC消息格式，簡化了AI模型與外部工具的交互。
• 動態(tài)發(fā)現(xiàn)： AI模型能夠動態(tài)識別可用工具并調(diào)用它們，無需人工干預。
• 雙向通信： 支持實時數(shù)據(jù)傳輸，類似于WebSockets。

4、核心優(yōu)勢

• 靈活性： 允許AI模型靈活調(diào)用多種工具，而無需為每個工具單獨開發(fā)適配代碼。
• 安全性： 提供安全隱私保護機制，確保數(shù)據(jù)傳輸?shù)陌踩浴?/li>
• 去中心化： 促進生態(tài)繁榮，形成類似“插件市場”的生態(tài)系統(tǒng)。

5、面臨的挑戰(zhàn)

• 跨平臺兼容性： 需要解決不同平臺間的兼容性問題。
• 性能優(yōu)化： 在大規(guī)模部署中優(yōu)化性能。
• 安全性提升： 加強認證授權(quán)和服務(wù)器發(fā)現(xiàn)的安全性。

三、A2A：智能體開放通信協(xié)議

A2A(Agent-to-Agent)是一種開放的智能體通信協(xié)議，由Google最近推出，旨在標準化不同AI智能體之間的通信與協(xié)作。

A2A協(xié)議通過統(tǒng)一的通信方式，允許智能體以結(jié)構(gòu)化和一致的方式進行交互，包括任務(wù)管理、狀態(tài)更新、多模態(tài)數(shù)據(jù)交換等。其核心目標是打破系統(tǒng)孤島，實現(xiàn)跨平臺、跨框架的智能體無縫協(xié)作，從而支持復雜任務(wù)的自動化處理。

1、技術(shù)原理

• 任務(wù)管理：A2A協(xié)議定義了任務(wù)生命周期管理機制，支持從即時任務(wù)到長周期任務(wù)的協(xié)作。任務(wù)創(chuàng)建、執(zhí)行、狀態(tài)更新和完成均圍繞任務(wù)對象展開。
• 多模態(tài)交互：支持文本、音頻、視頻等多種數(shù)據(jù)格式的交互，使智能體之間的協(xié)作更加自然和靈活。
• 客戶端-服務(wù)器架構(gòu)：采用客戶端(Client Agent)和遠程服務(wù)器(Remote Agent)的架構(gòu)，客戶端負責發(fā)起任務(wù)并管理狀態(tài)更新，服務(wù)器則處理具體任務(wù)執(zhí)行。
• 實時反饋與狀態(tài)更新：通過SSE(Server-Sent Events)流式傳輸技術(shù)，實時推送任務(wù)狀態(tài)更新，避免長時間阻塞。
• 安全性與標準化：基于現(xiàn)有標準(如JSON-RPC、HTTP、OpenAPI等)構(gòu)建，確保與現(xiàn)有IT系統(tǒng)的兼容性，并提供企業(yè)級的安全認證和授權(quán)機制。

2、核心優(yōu)勢

• 靈活性：支持非結(jié)構(gòu)化模式下的智能體協(xié)作，適應(yīng)復雜任務(wù)需求。
• 安全性：通過標準化協(xié)議確保通信安全。
• 跨平臺協(xié)作：打破不同生態(tài)系統(tǒng)間的壁壘，實現(xiàn)智能體間的高效協(xié)同。

四、三大范式的典型應(yīng)用場景

1、Function Calling

• 簡單數(shù)據(jù)查詢：如“北京今日氣溫”調(diào)用天氣API。
• 內(nèi)部系統(tǒng)調(diào)用：如“查詢我的訂單”觸發(fā)數(shù)據(jù)庫檢索。

2、MCP

• 跨平臺集成：如AI助手同時訪問Google Drive和本地文件。
• 敏感數(shù)據(jù)操作：如醫(yī)生通過MCP查詢加密的患者病歷。

3、A2A

• 企業(yè)流程自動化：如跨平臺客服、招聘流程優(yōu)化、公司內(nèi)部業(yè)務(wù)協(xié)作(HR Agent與財務(wù)Agent協(xié)作處理員工報銷)。
• 多智能體協(xié)作：支持多個獨立智能體協(xié)同完成復雜任務(wù)，且可以對復雜任務(wù)進行分解，提高任務(wù)整體的執(zhí)行效率。

五、三大范式未來可能的發(fā)展趨勢

從OpenAI提出Function Calling，到Anthropic提出MCP，再到Google提出A2A，你會發(fā)現(xiàn)他們的核心功能和特性，基本是按照技術(shù)發(fā)展的趨勢在不斷演進，即從單點功能到群體協(xié)作。

其中，F(xiàn)unction Calling面向單點功能，你可以把Function Calling是“工具調(diào)用”的基礎(chǔ)設(shè)施；MCP更看重系統(tǒng)間的交互，是多系統(tǒng)之間的“連接協(xié)議”，解決模型與外部系統(tǒng)的標準化交互；而A2A更擅長群體(Agent)協(xié)作，可以推動上述二者的基礎(chǔ)上推動多智能體生態(tài)的形成。

三者分別面向單點功能、系統(tǒng)連接、群體協(xié)同三個層級，結(jié)合起來，則可以構(gòu)成一個自頂向下、從內(nèi)部任務(wù)處理到外部多智能體工具協(xié)同的技術(shù)生態(tài)。共同構(gòu)建AI從“理解”到“實干”的能力。

三者未來的發(fā)展趨勢可能會趨向于：MCP可能成為底層協(xié)議，A2A在其上實現(xiàn)多Agent協(xié)作，F(xiàn)unction Calling作為輕量級補充。

在此基礎(chǔ)上進行擴展，未來MCP可能會形成類似于功能插件的角色，或者說工具庫。而A2A的Agent生態(tài)可能會形成類似“應(yīng)用商店”的體系。

當然，目前來看這三者依然處在初級階段，一定會有后來者推出全新的協(xié)議來參與競爭，直至出現(xiàn)類似IT互聯(lián)網(wǎng)時代的HTTP與TCP/IP協(xié)議，甚至可能出現(xiàn)更通用的AI交互協(xié)議。