11張圖全面總結 MCP、A2A、Function Calling 架構設計間關系 原創(chuàng) 精華
MCP（Model Context Protocol）的熱度還未消散，新的 Agent 接口標準 A2A（Agent2Agent）又悄然登場。
就在上周，Google 在 Cloud Next 大會上正式推出了 Agent2Agent（A2A）開放協(xié)議。簡單來說，A2A 旨在為 Agent 之間的通信提供一個開放標準，促進不同 Agent 之間的協(xié)作與交互。
目前，AI 領域有三大巨頭在 Agent 生態(tài)中積極布局：
- Anthropic：推出了 MCP，旨在標準化 AI 大模型與外部工具和數(shù)據(jù)源的交互。
- Google：推出了 A2A，專注于 Agent 之間的通信和協(xié)作。
- OpenAI：早在2023年就推出了 Function Calling，為大模型提供了工具調(diào)用功能。
這三大巨頭的舉措，仿佛是在為 AI Agent 的發(fā)展鋪設一條從個體到集體的進化之路。從大模型本身，到為大模型添加工具調(diào)用功能，再到大模型與工具的交互標準，最后到 AI Agent 之間的通信協(xié)議，這一系列的發(fā)展就像是為一個聰明的大腦逐步武裝四肢，賦予多種能力，最終使其能夠協(xié)作完成復雜任務，形成一個高效的團隊。
接下來，我們對 MCP、A2A 和 Function Calling 進行全面的解讀與對比，探討它們之間的具體區(qū)別以及如何實現(xiàn)合作。
1、Function Calling：直接但缺乏擴展性
Function Calling 是由 OpenAI 等公司推動的一種技術，它允許大語言模型（LLM）通過自然語言指令與外部工具和服務進行交互，從而將自然語言轉(zhuǎn)換為具體的 API 調(diào)用。這一技術解決了大語言模型在訓練完成后知識更新停滯的問題，使大模型能夠獲取實時信息，比如：當前的天氣、股市收盤點數(shù)等。
第一、工作原理
Function Calling 的工作原理可以通過以下4個步驟來理解：
1.識別需求：大模型識別出用戶的問題需要調(diào)用外部 API 來獲取實時信息。比如：用戶詢問“今天北京的天氣如何？”大模型會識別出這是一個關于實時天氣的問題。
2.選擇函數(shù)：大模型從可用的函數(shù)庫中選擇合適的函數(shù)。在這個例子中，大模型會選擇 get_current_weather 函數(shù)。
3.準備參數(shù)：大模型準備調(diào)用函數(shù)所需的參數(shù)。例如：
{
"location": "北京",
"unit": "celsius"
}3.調(diào)用函數(shù)：AI 應用使用這些參數(shù)調(diào)用實際的天氣 API，獲取北京的實時天氣數(shù)據(jù)。
4.整合回答：大模型將獲取的數(shù)據(jù)整合成一個完整的回答，比如：“根據(jù)最新數(shù)據(jù)，北京今天的天氣晴朗，當前溫度23°C，濕度45%，微風。今天的最高溫度預計為26°C，最低溫度為18°C。”
第二、對開發(fā)者的好處
對于開發(fā)者來說，使用 LLM 的 Function Calling 入門相對容易。開發(fā)者只需按照 API 的要求定義函數(shù)規(guī)格（通常是 JSON 格式），并將其隨 Prompt 請求發(fā)送給大模型。大模型會根據(jù)需要調(diào)用這些函數(shù)，整個邏輯相當直觀。因此，對于單一大模型、少量功能的簡單應用，F(xiàn)unction Calling 的實現(xiàn)非常直接，幾乎可以“一鍵”將大模型輸出對接到代碼邏輯中。
第三、局限性
然而，F(xiàn)unction Calling 也有一些局限性：
缺乏跨大模型的一致性：每個 LLM 供應商的接口格式略有差異，這使得開發(fā)者在支持多個大模型時需要為不同的 API 做適配，或者使用額外的框架來處理這些差異。
平臺依賴性：Function Calling 通常依賴于特定的平臺或框架，這限制了其在不同環(huán)境中的通用性。
擴展性有限：雖然 Function Calling 能夠解決特定問題，但在面對更復雜的任務時，其擴展性可能會受到限制。開發(fā)者可能需要為每個新功能編寫新的函數(shù)，并確保這些函數(shù)與模型的交互邏輯兼容。
第四、總結
Function Calling 是一種強大的工具，它為大語言模型提供了與外部工具和服務交互的能力，從而解決了大模型知識更新停滯的問題。然而，它的局限性在于缺乏跨模型的一致性和平臺依賴性。盡管如此，F(xiàn)unction Calling 仍然是一個重要的技術，尤其是在需要快速實現(xiàn)特定功能時。未來，隨著技術的不斷發(fā)展，我們期待看到更多能夠克服這些局限性的解決方案。
2、MCP：構建 AI 應用與外部工具的橋梁
MCP（Model Context Protocol）是由 Anthropic 公司提出的一種協(xié)議，旨在解決不同大語言模型（LLM）與不同外部工具集成的標準化問題。通過MCP，開發(fā)者能夠以一種統(tǒng)一的方式將各種數(shù)據(jù)源和工具連接到 AI 大模型，從而提升大模型的實用性和靈活性。
目前，MCP 生態(tài)已經(jīng)得到了廣泛的支持，包括 Anthropic 的 Claude 系列、OpenAI 的 GPT 系列、Meta 的 Llama 系列、DeepSeek、阿里的通義系列以及 Anysphere 的 Cursor 等主流模型均已接入 MCP 生態(tài)。
第一、MCP 的架構設計
MCP 采用了客戶端-服務器架構，主要包括以下幾個核心組件：
1.MCP 主機（Hosts）
角色：這是需要訪問數(shù)據(jù)的程序，例如Claude Desktop、各種IDE或AI工具。
功能：它們是MCP生態(tài)系統(tǒng)的入口點，負責向用戶提供AI功能，并作為用戶與AI模型之間的橋梁。
2.MCP 客戶端（Clients）
角色：這些是協(xié)議客戶端，負責維持與 MCP 服務器的1:1連接。
功能：它們處理通信細節(jié)，確保主機和服務器之間的數(shù)據(jù)傳輸順暢，從而實現(xiàn)高效的數(shù)據(jù)交互。
3.MCP 服務器（Servers）
角色：這些是輕量級程序，每個服務器都通過標準化的 Model Context Protocol 暴露特定功能。
功能：服務器是 MCP 的核心，它們連接 AI 大模型與實際數(shù)據(jù)源，使模型能夠訪問和操作數(shù)據(jù)。
4.數(shù)據(jù)源
本地數(shù)據(jù)源：包括您計算機上的文件、數(shù)據(jù)庫和服務，MCP 服務器可以安全地訪問這些資源。
遠程服務：通過互聯(lián)網(wǎng)可用的外部系統(tǒng)（比如：通過 API），MCP 服務器可以連接這些系統(tǒng)，從而擴展模型的能力。
第二、MCP 的優(yōu)勢
統(tǒng)一性：MCP 提供了一個統(tǒng)一的協(xié)議標準，使得不同 AI 大模型能夠以一致的方式連接到各種數(shù)據(jù)源和工具，從而避免了平臺依賴性問題。
安全性：通過 MCP，數(shù)據(jù)的傳輸和訪問過程更加安全，敏感數(shù)據(jù)可以保留在本地，無需全部上傳到云端。
靈活性：MCP 支持多種數(shù)據(jù)源和工具的連接，無論是本地資源還是遠程服務，都可以輕松集成到AI 應用中。
生態(tài)豐富：MCP 生態(tài)已經(jīng)得到了廣泛的支持，開發(fā)者可以利用現(xiàn)有的MCP服務器和工具，快速構建和部署AI應用。
第三、總結
MCP 通過其客戶端-服務器架構和標準化的協(xié)議，為 AI 大模型與外部工具和數(shù)據(jù)源的集成提供了一個高效、安全且靈活的解決方案。它不僅解決了不同大模型與工具之間的兼容性問題，還為開發(fā)者提供了一個豐富的生態(tài)系統(tǒng)，使得AI應用的開發(fā)和部署變得更加簡單和高效。
3、A2A：助力 Agent 間的通信與協(xié)同
谷歌最新推出的 A2A（Agent2Agent）開放協(xié)議，專注于解決不同 Agent 之間的通信和協(xié)同問題，旨在構建一個更加靈活和高效的多 Agent 系統(tǒng)。
要深入理解A2A協(xié)議，我們首先需要掌握幾個關鍵概念：
第一、關鍵概念
A2A Client：類似于點餐的顧客，負責向 A2A Server 發(fā)送請求，啟動任務。
A2A Server：類似于餐廳的服務員和廚師團隊，負責處理請求并返回響應，告知任務的狀態(tài)。
任務狀態(tài)：任務在執(zhí)行過程中可能會經(jīng)歷多個狀態(tài)，比如：已提交、處理中、需要輸入等，最終完成或失敗。
第二、典型工作流程
A2A 協(xié)議的典型工作流程可以分為以下幾個步驟：
1.請求發(fā)送：A2A Client 向 A2A Server 發(fā)送請求，啟動一個任務。這個請求包含了任務的詳細信息和所需的操作。
2.請求處理：A2A Server 接收到請求后，開始處理任務，并返回一個初始響應，告知任務的當前狀態(tài)。
3.狀態(tài)更新：任務在執(zhí)行過程中會經(jīng)歷多個狀態(tài)變化。A2A Server 會定期更新任務狀態(tài)，并將這些狀態(tài)信息反饋給 A2A Client。
4.任務完成或失敗：任務最終會完成或失敗。A2A Server 會將最終結果返回給 A2A Client，告知任務的執(zhí)行結果。
第三、A2A 的優(yōu)勢
靈活性：A2A 協(xié)議允許不同 Agent 之間的動態(tài)通信和協(xié)同，使得系統(tǒng)能夠靈活應對各種復雜任務。
擴展性：通過標準化的通信機制，A2A 協(xié)議支持多 Agent 系統(tǒng)的擴展，可以輕松添加新的 Agent 或服務。
任務管理：A2A 協(xié)議提供了豐富的任務狀態(tài)管理功能，使得任務的執(zhí)行過程更加透明和可控。
協(xié)同能力：A2A 協(xié)議促進了 Agent 之間的協(xié)作，使得多個 Agent 可以共同完成復雜的任務，提高系統(tǒng)的整體效率。
第四、總結
A2A 協(xié)議通過其靈活的通信機制和強大的任務管理功能，為不同 Agent 之間的協(xié)同工作提供了一個高效、透明的解決方案。它不僅解決了 Agent 之間的通信問題，還提升了多 Agent 系統(tǒng)的整體性能和擴展性。隨著技術的不斷發(fā)展，A2A 協(xié)議有望在更多領域得到廣泛應用，推動 AI 技術的發(fā)展。
4、MCP vs Function Calling vs A2A 關系
第一、MCP ? Function Calling 關系：設計理念與應用場景的差異
盡管 MCP 和 Function Calling 都旨在促進大語言模型（LLM）與外部工具和服務的交互，但它們在設計理念和應用場景上存在顯著差異，尤其是在可擴展性方面。
1.Function Calling 的局限性
Function Calling 由于缺乏統(tǒng)一標準，不同 LLM 需要各自的函數(shù)定義格式。如果有 M 個不同 LLM 應用和 N 個不同工具/服務，理論上可能需要實現(xiàn) M×N 次重復的對接工作。此外，F(xiàn)unction Calling 本身并不直接支持多步調(diào)用組合，大模型只能一次調(diào)用一個函數(shù)，獲取結果后如果需調(diào)用下一個函數(shù)，需要由應用邏輯將結果饋入大模型下一輪對話，再觸發(fā)下一個函數(shù)調(diào)用。雖然在原理上可以實現(xiàn)函數(shù)輸出作為輸入形成鏈條，但這一切需要開發(fā)者在應用層精心編排，大模型自身缺乏對跨調(diào)用流程的全局觀。
2.MCP 的擴展性優(yōu)勢
MCP 的擴展性則通過統(tǒng)一的接口標準，將復雜的 M（個模型）×N（個外部工具對接）問題轉(zhuǎn)化為 M+N 的問題。工具創(chuàng)建者只需為每個工具/系統(tǒng)實現(xiàn)一次 MCP Server，應用開發(fā)者只需為每個應用實現(xiàn)一次 MCP Client，各自遵循通用協(xié)議即可協(xié)同工作，擴展新功能的邊際成本大幅降低。
第二、MCP ? A2A 關系：能力互補
那么，為什么在有了 MCP 之后，還需要 A2A 來協(xié)作不同 Agent 呢？對比 MCP 與 A2A，可以發(fā)現(xiàn)兩者的關系更多是一種能力的互補：MCP 讓 Agent 能夠使用工具，而 A2A 讓 Agent 能夠與其他 Agent 協(xié)作。一個解決“做什么”，一個解決“與誰合作”。
背后的邏輯就像上班，有的同事（Agent）擅長研發(fā)汽車發(fā)動機，有的同事（Agent）擅長組裝。所有人通過一個流水線串聯(lián)共同完成一個項目，一定比一個同事（Agent）獨自研發(fā)汽車，然后再組裝并營銷的效率更高。
第三、A2A ? Function Calling 關系：能力協(xié)同
A2A 可以支持 Agent 之間的通信，而每個 Agent 可以通過 Function Calling 調(diào)用外部工具。
這種結合可以實現(xiàn)復雜的任務分配和協(xié)作，提升系統(tǒng)的整體性能。
第四、未來趨勢：技術融合
長期來看，我們可能會看到這三大通信機制（Function Calling、MCP、A2A）逐漸融合的趨勢。不過，目前 OpenAI 和 Anthropic 尚未支持 A2A。這可能是因為，盡管大家在技術布道時都有自己的理念，但最終如何選擇取決于商業(yè)決策。然而，從長期來看，技術融合之路勢在必行。
本文轉(zhuǎn)載自公眾號玄姐聊AGI 作者：玄姐
