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