MCP（Model Context Protocol）的熱度還未消散，新的 Agent 接口標(biāo)準(zhǔn) A2A（Agent2Agent）又悄然登場(chǎng)。

就在上周，Google 在 Cloud Next 大會(huì)上正式推出了 Agent2Agent（A2A）開放協(xié)議。簡(jiǎn)單來(lái)說(shuō)，A2A 旨在為 Agent 之間的通信提供一個(gè)開放標(biāo)準(zhǔn)，促進(jìn)不同 Agent 之間的協(xié)作與交互。

目前，AI 領(lǐng)域有三大巨頭在 Agent 生態(tài)中積極布局：

• Anthropic：推出了 MCP，旨在標(biāo)準(zhǔn)化 AI 大模型與外部工具和數(shù)據(jù)源的交互。
• Google：推出了 A2A，專注于 Agent 之間的通信和協(xié)作。
• OpenAI：早在2023年就推出了 Function Calling，為大模型提供了工具調(diào)用功能。

這三大巨頭的舉措，仿佛是在為 AI Agent 的發(fā)展鋪設(shè)一條從個(gè)體到集體的進(jìn)化之路。從大模型本身，到為大模型添加工具調(diào)用功能，再到大模型與工具的交互標(biāo)準(zhǔn)，最后到 AI Agent 之間的通信協(xié)議，這一系列的發(fā)展就像是為一個(gè)聰明的大腦逐步武裝四肢，賦予多種能力，最終使其能夠協(xié)作完成復(fù)雜任務(wù)，形成一個(gè)高效的團(tuán)隊(duì)。

接下來(lái)，我們對(duì) MCP、A2A 和 Function Calling 進(jìn)行全面的解讀與對(duì)比，探討它們之間的具體區(qū)別以及如何實(shí)現(xiàn)合作。

1、Function Calling：直接但缺乏擴(kuò)展性

Function Calling 是由 OpenAI 等公司推動(dòng)的一種技術(shù)，它允許大語(yǔ)言模型（LLM）通過(guò)自然語(yǔ)言指令與外部工具和服務(wù)進(jìn)行交互，從而將自然語(yǔ)言轉(zhuǎn)換為具體的 API 調(diào)用。這一技術(shù)解決了大語(yǔ)言模型在訓(xùn)練完成后知識(shí)更新停滯的問(wèn)題，使大模型能夠獲取實(shí)時(shí)信息，比如：當(dāng)前的天氣、股市收盤點(diǎn)數(shù)等。

第一、工作原理

Function Calling 的工作原理可以通過(guò)以下4個(gè)步驟來(lái)理解：

1.識(shí)別需求：大模型識(shí)別出用戶的問(wèn)題需要調(diào)用外部 API 來(lái)獲取實(shí)時(shí)信息。比如：用戶詢問(wèn)“今天北京的天氣如何？”大模型會(huì)識(shí)別出這是一個(gè)關(guān)于實(shí)時(shí)天氣的問(wèn)題。

2.選擇函數(shù)：大模型從可用的函數(shù)庫(kù)中選擇合適的函數(shù)。在這個(gè)例子中，大模型會(huì)選擇 get_current_weather 函數(shù)。

3.準(zhǔn)備參數(shù)：大模型準(zhǔn)備調(diào)用函數(shù)所需的參數(shù)。例如：

{
  "location": "北京",
  "unit": "celsius"
}

3.調(diào)用函數(shù)：AI 應(yīng)用使用這些參數(shù)調(diào)用實(shí)際的天氣 API，獲取北京的實(shí)時(shí)天氣數(shù)據(jù)。

4.整合回答：大模型將獲取的數(shù)據(jù)整合成一個(gè)完整的回答，比如：“根據(jù)最新數(shù)據(jù)，北京今天的天氣晴朗，當(dāng)前溫度23°C，濕度45%，微風(fēng)。今天的最高溫度預(yù)計(jì)為26°C，最低溫度為18°C。”

第二、對(duì)開發(fā)者的好處

對(duì)于開發(fā)者來(lái)說(shuō)，使用 LLM 的 Function Calling 入門相對(duì)容易。開發(fā)者只需按照 API 的要求定義函數(shù)規(guī)格（通常是 JSON 格式），并將其隨 Prompt 請(qǐng)求發(fā)送給大模型。大模型會(huì)根據(jù)需要調(diào)用這些函數(shù)，整個(gè)邏輯相當(dāng)直觀。因此，對(duì)于單一大模型、少量功能的簡(jiǎn)單應(yīng)用，F(xiàn)unction Calling 的實(shí)現(xiàn)非常直接，幾乎可以“一鍵”將大模型輸出對(duì)接到代碼邏輯中。

第三、局限性

然而，F(xiàn)unction Calling 也有一些局限性：

缺乏跨大模型的一致性：每個(gè) LLM 供應(yīng)商的接口格式略有差異，這使得開發(fā)者在支持多個(gè)大模型時(shí)需要為不同的 API 做適配，或者使用額外的框架來(lái)處理這些差異。

平臺(tái)依賴性：Function Calling 通常依賴于特定的平臺(tái)或框架，這限制了其在不同環(huán)境中的通用性。

擴(kuò)展性有限：雖然 Function Calling 能夠解決特定問(wèn)題，但在面對(duì)更復(fù)雜的任務(wù)時(shí)，其擴(kuò)展性可能會(huì)受到限制。開發(fā)者可能需要為每個(gè)新功能編寫新的函數(shù)，并確保這些函數(shù)與模型的交互邏輯兼容。

第四、總結(jié)

Function Calling 是一種強(qiáng)大的工具，它為大語(yǔ)言模型提供了與外部工具和服務(wù)交互的能力，從而解決了大模型知識(shí)更新停滯的問(wèn)題。然而，它的局限性在于缺乏跨模型的一致性和平臺(tái)依賴性。盡管如此，F(xiàn)unction Calling 仍然是一個(gè)重要的技術(shù)，尤其是在需要快速實(shí)現(xiàn)特定功能時(shí)。未來(lái)，隨著技術(shù)的不斷發(fā)展，我們期待看到更多能夠克服這些局限性的解決方案。

2、MCP：構(gòu)建 AI 應(yīng)用與外部工具的橋梁

MCP（Model Context Protocol）是由 Anthropic 公司提出的一種協(xié)議，旨在解決不同大語(yǔ)言模型（LLM）與不同外部工具集成的標(biāo)準(zhǔn)化問(wèn)題。通過(guò)MCP，開發(fā)者能夠以一種統(tǒng)一的方式將各種數(shù)據(jù)源和工具連接到 AI 大模型，從而提升大模型的實(shí)用性和靈活性。

目前，MCP 生態(tài)已經(jīng)得到了廣泛的支持，包括 Anthropic 的 Claude 系列、OpenAI 的 GPT 系列、Meta 的 Llama 系列、DeepSeek、阿里的通義系列以及 Anysphere 的 Cursor 等主流模型均已接入 MCP 生態(tài)。

第一、MCP 的架構(gòu)設(shè)計(jì)

MCP 采用了客戶端-服務(wù)器架構(gòu)，主要包括以下幾個(gè)核心組件：

1.MCP 主機(jī)（Hosts）

角色：這是需要訪問(wèn)數(shù)據(jù)的程序，例如Claude Desktop、各種IDE或AI工具。

功能：它們是MCP生態(tài)系統(tǒng)的入口點(diǎn)，負(fù)責(zé)向用戶提供AI功能，并作為用戶與AI模型之間的橋梁。

2.MCP 客戶端（Clients）

角色：這些是協(xié)議客戶端，負(fù)責(zé)維持與 MCP 服務(wù)器的1:1連接。

功能：它們處理通信細(xì)節(jié)，確保主機(jī)和服務(wù)器之間的數(shù)據(jù)傳輸順暢，從而實(shí)現(xiàn)高效的數(shù)據(jù)交互。

3.MCP 服務(wù)器（Servers）

角色：這些是輕量級(jí)程序，每個(gè)服務(wù)器都通過(guò)標(biāo)準(zhǔn)化的 Model Context Protocol 暴露特定功能。

功能：服務(wù)器是 MCP 的核心，它們連接 AI 大模型與實(shí)際數(shù)據(jù)源，使模型能夠訪問(wèn)和操作數(shù)據(jù)。

4.數(shù)據(jù)源

本地?cái)?shù)據(jù)源：包括您計(jì)算機(jī)上的文件、數(shù)據(jù)庫(kù)和服務(wù)，MCP 服務(wù)器可以安全地訪問(wèn)這些資源。

遠(yuǎn)程服務(wù)：通過(guò)互聯(lián)網(wǎng)可用的外部系統(tǒng)（比如：通過(guò) API），MCP 服務(wù)器可以連接這些系統(tǒng)，從而擴(kuò)展模型的能力。

第二、MCP 的優(yōu)勢(shì)

統(tǒng)一性：MCP 提供了一個(gè)統(tǒng)一的協(xié)議標(biāo)準(zhǔn)，使得不同 AI 大模型能夠以一致的方式連接到各種數(shù)據(jù)源和工具，從而避免了平臺(tái)依賴性問(wèn)題。

安全性：通過(guò) MCP，數(shù)據(jù)的傳輸和訪問(wèn)過(guò)程更加安全，敏感數(shù)據(jù)可以保留在本地，無(wú)需全部上傳到云端。

靈活性：MCP 支持多種數(shù)據(jù)源和工具的連接，無(wú)論是本地資源還是遠(yuǎn)程服務(wù)，都可以輕松集成到AI 應(yīng)用中。

生態(tài)豐富：MCP 生態(tài)已經(jīng)得到了廣泛的支持，開發(fā)者可以利用現(xiàn)有的MCP服務(wù)器和工具，快速構(gòu)建和部署AI應(yīng)用。

第三、總結(jié)

MCP 通過(guò)其客戶端-服務(wù)器架構(gòu)和標(biāo)準(zhǔn)化的協(xié)議，為 AI 大模型與外部工具和數(shù)據(jù)源的集成提供了一個(gè)高效、安全且靈活的解決方案。它不僅解決了不同大模型與工具之間的兼容性問(wèn)題，還為開發(fā)者提供了一個(gè)豐富的生態(tài)系統(tǒng)，使得AI應(yīng)用的開發(fā)和部署變得更加簡(jiǎn)單和高效。

3、A2A：助力 Agent 間的通信與協(xié)同

谷歌最新推出的 A2A（Agent2Agent）開放協(xié)議，專注于解決不同 Agent 之間的通信和協(xié)同問(wèn)題，旨在構(gòu)建一個(gè)更加靈活和高效的多 Agent 系統(tǒng)。

要深入理解A2A協(xié)議，我們首先需要掌握幾個(gè)關(guān)鍵概念：

第一、關(guān)鍵概念

A2A Client：類似于點(diǎn)餐的顧客，負(fù)責(zé)向 A2A Server 發(fā)送請(qǐng)求，啟動(dòng)任務(wù)。

A2A Server：類似于餐廳的服務(wù)員和廚師團(tuán)隊(duì)，負(fù)責(zé)處理請(qǐng)求并返回響應(yīng)，告知任務(wù)的狀態(tài)。

任務(wù)狀態(tài)：任務(wù)在執(zhí)行過(guò)程中可能會(huì)經(jīng)歷多個(gè)狀態(tài)，比如：已提交、處理中、需要輸入等，最終完成或失敗。

第二、典型工作流程

A2A 協(xié)議的典型工作流程可以分為以下幾個(gè)步驟：

1.請(qǐng)求發(fā)送：A2A Client 向 A2A Server 發(fā)送請(qǐng)求，啟動(dòng)一個(gè)任務(wù)。這個(gè)請(qǐng)求包含了任務(wù)的詳細(xì)信息和所需的操作。

2.請(qǐng)求處理：A2A Server 接收到請(qǐng)求后，開始處理任務(wù)，并返回一個(gè)初始響應(yīng)，告知任務(wù)的當(dāng)前狀態(tài)。

3.狀態(tài)更新：任務(wù)在執(zhí)行過(guò)程中會(huì)經(jīng)歷多個(gè)狀態(tài)變化。A2A Server 會(huì)定期更新任務(wù)狀態(tài)，并將這些狀態(tài)信息反饋給 A2A Client。

4.任務(wù)完成或失?。喝蝿?wù)最終會(huì)完成或失敗。A2A Server 會(huì)將最終結(jié)果返回給 A2A Client，告知任務(wù)的執(zhí)行結(jié)果。

第三、A2A 的優(yōu)勢(shì)

靈活性：A2A 協(xié)議允許不同 Agent 之間的動(dòng)態(tài)通信和協(xié)同，使得系統(tǒng)能夠靈活應(yīng)對(duì)各種復(fù)雜任務(wù)。

擴(kuò)展性：通過(guò)標(biāo)準(zhǔn)化的通信機(jī)制，A2A 協(xié)議支持多 Agent 系統(tǒng)的擴(kuò)展，可以輕松添加新的 Agent 或服務(wù)。

任務(wù)管理：A2A 協(xié)議提供了豐富的任務(wù)狀態(tài)管理功能，使得任務(wù)的執(zhí)行過(guò)程更加透明和可控。

協(xié)同能力：A2A 協(xié)議促進(jìn)了 Agent 之間的協(xié)作，使得多個(gè) Agent 可以共同完成復(fù)雜的任務(wù)，提高系統(tǒng)的整體效率。

第四、總結(jié)

A2A 協(xié)議通過(guò)其靈活的通信機(jī)制和強(qiáng)大的任務(wù)管理功能，為不同 Agent 之間的協(xié)同工作提供了一個(gè)高效、透明的解決方案。它不僅解決了 Agent 之間的通信問(wèn)題，還提升了多 Agent 系統(tǒng)的整體性能和擴(kuò)展性。隨著技術(shù)的不斷發(fā)展，A2A 協(xié)議有望在更多領(lǐng)域得到廣泛應(yīng)用，推動(dòng) AI 技術(shù)的發(fā)展。

4、MCP vs Function Calling vs  A2A 關(guān)系

第一、MCP  ?  Function Calling 關(guān)系：設(shè)計(jì)理念與應(yīng)用場(chǎng)景的差異

盡管 MCP 和 Function Calling 都旨在促進(jìn)大語(yǔ)言模型（LLM）與外部工具和服務(wù)的交互，但它們?cè)谠O(shè)計(jì)理念和應(yīng)用場(chǎng)景上存在顯著差異，尤其是在可擴(kuò)展性方面。

1.Function Calling 的局限性

Function Calling 由于缺乏統(tǒng)一標(biāo)準(zhǔn)，不同 LLM 需要各自的函數(shù)定義格式。如果有 M 個(gè)不同 LLM 應(yīng)用和 N 個(gè)不同工具/服務(wù)，理論上可能需要實(shí)現(xiàn) M×N 次重復(fù)的對(duì)接工作。此外，F(xiàn)unction Calling 本身并不直接支持多步調(diào)用組合，大模型只能一次調(diào)用一個(gè)函數(shù)，獲取結(jié)果后如果需調(diào)用下一個(gè)函數(shù)，需要由應(yīng)用邏輯將結(jié)果饋入大模型下一輪對(duì)話，再觸發(fā)下一個(gè)函數(shù)調(diào)用。雖然在原理上可以實(shí)現(xiàn)函數(shù)輸出作為輸入形成鏈條，但這一切需要開發(fā)者在應(yīng)用層精心編排，大模型自身缺乏對(duì)跨調(diào)用流程的全局觀。

2.MCP 的擴(kuò)展性優(yōu)勢(shì)

MCP 的擴(kuò)展性則通過(guò)統(tǒng)一的接口標(biāo)準(zhǔn)，將復(fù)雜的 M（個(gè)模型）×N（個(gè)外部工具對(duì)接）問(wèn)題轉(zhuǎn)化為 M+N 的問(wèn)題。工具創(chuàng)建者只需為每個(gè)工具/系統(tǒng)實(shí)現(xiàn)一次 MCP Server，應(yīng)用開發(fā)者只需為每個(gè)應(yīng)用實(shí)現(xiàn)一次 MCP Client，各自遵循通用協(xié)議即可協(xié)同工作，擴(kuò)展新功能的邊際成本大幅降低。

第二、MCP  ?  A2A 關(guān)系：能力互補(bǔ)

那么，為什么在有了 MCP 之后，還需要 A2A 來(lái)協(xié)作不同 Agent 呢？對(duì)比 MCP 與 A2A，可以發(fā)現(xiàn)兩者的關(guān)系更多是一種能力的互補(bǔ)：MCP 讓 Agent 能夠使用工具，而 A2A 讓 Agent 能夠與其他 Agent 協(xié)作。一個(gè)解決“做什么”，一個(gè)解決“與誰(shuí)合作”。

背后的邏輯就像上班，有的同事（Agent）擅長(zhǎng)研發(fā)汽車發(fā)動(dòng)機(jī)，有的同事（Agent）擅長(zhǎng)組裝。所有人通過(guò)一個(gè)流水線串聯(lián)共同完成一個(gè)項(xiàng)目，一定比一個(gè)同事（Agent）獨(dú)自研發(fā)汽車，然后再組裝并營(yíng)銷的效率更高。

第三、A2A  ?  Function Calling 關(guān)系：能力協(xié)同

A2A 可以支持 Agent 之間的通信，而每個(gè) Agent 可以通過(guò) Function Calling 調(diào)用外部工具。

這種結(jié)合可以實(shí)現(xiàn)復(fù)雜的任務(wù)分配和協(xié)作，提升系統(tǒng)的整體性能。

第四、未來(lái)趨勢(shì)：技術(shù)融合

長(zhǎng)期來(lái)看，我們可能會(huì)看到這三大通信機(jī)制（Function Calling、MCP、A2A）逐漸融合的趨勢(shì)。不過(guò)，目前 OpenAI 和 Anthropic 尚未支持 A2A。這可能是因?yàn)?，盡管大家在技術(shù)布道時(shí)都有自己的理念，但最終如何選擇取決于商業(yè)決策。然而，從長(zhǎng)期來(lái)看，技術(shù)融合之路勢(shì)在必行。

本文轉(zhuǎn)載自公眾號(hào)玄姐聊AGI  作者：玄姐

原文鏈接：??https://mp.weixin.qq.com/s/A5imoZWlLjAWJtT_tmlF3g??