從架構設計側剖析： MCP vs A2A 是朋友還是對手？ 原創
Anthropic 推出的 MCP（模型上下文協議）取得了成功，這顯然激發了 AI 行業里的其他參與者，大家都想來定義一些開放協議，好用在 AI Agent 系統（Agentic Systems）的集成里。
上周周，谷歌公開發布了一個叫 A2A（Agent2Agent）的開放協議，目標是規范多 AI Agent 系統通信的實現方式。很多人（可能有點誤解）說這兩種協議是競爭關系，而不是互補關系。
谷歌公開說 A2A 和 MCP 是互補的。這話挺合理的。但會不會有隱藏的長期競爭目標呢？我們會不會很快看到協議之間的競爭開始呢？
很多人都問我，我覺得這兩種協議未來會不會變得有競爭？本文從架構設計來剖析 MCP vs A2A 是朋友有還是對手？
本文重點剖析：
- A2A 架構設計
- MCP 架構設計
- A2A 如何與 MCP 互補，反之亦然？
- 長期來看，A2A 是否會在長期內取代 MCP？
下文詳細剖析之。
1、A2A 架構設計
第一、為什么會有 A2A？
現在越來越清楚，未來的 AI Agent 系統（Agentic Systems）將是多 AI Agent 的。而且，這些 AI Agent 會在彼此之間遠程協作，每個 AI Agent 都可能使用不同的 AI Agent 框架（比如：LangGraph、AutoGen、CrewAI、Agent Development Kit 等）來實現。
這里面有3個固有的問題：
1.不同框架實現的 AI Agent 系統之間，不支持系統狀態的轉移和交換。
2.遠程 AI Agent 之間也無法轉移系統狀態。
3.離線的 AI Agent 不共享工具、上下文和內存（包括系統狀態）。
第二、A2A 解決方案
A2A 是一個開放協議，它為 AI Agent 之間提供了一種標準方式，無論底層開發框架或供應商如何，都可以進行協作。
根據谷歌的官方文檔： A2A 協議促進了“客戶端”和“遠程” AI Agent 之間的通信。
簡單來說，“客戶端” AI Agent 創建任務并與“遠程” AI Agent 溝通，期望執行某些工作或返回數據。
第三、A2A 架構設計
1.能力發現：所有實現 A2A 的 AI Agent 都通過“Agent Card”公開其能力目錄。這有助于其他 AI Agent 發現給定 AI Agent 實現的潛在有用功能。
2.任務管理：通信協議，時代短期和長期任務變得更容易。它幫助通信中的 AI Agent 保持同步，直到請求的任務完成并返回答案。這很重要，因為有些 AI Agent 可能需要很長時間來執行工作，而且目前沒有統一標準如何等待這種情況發生。
3.協作：AI Agent 可以相互發送消息以傳達上下文、回復、工件或用戶指令。
4.用戶體驗協商：這是一個很有趣的功能。它允許協商數據返回的格式，以符合用戶界面的期望（比如：圖像、視頻、文本等）。
通過 A2A 公開的 AI Agent 的發現是一個重要話題。谷歌建議使用統一的位置來存儲組織的“Agent Card”。
比如：
https://<DOMAIN>/<agreed-path>/agent.json這并不意外，因為谷歌將處于最佳位置，能夠索引全球所有可用的 AI Agent，可能創建一個類似于當前搜索引擎索引的全球 AI Agent 目錄。
我喜歡 A2A 強調無需重新發明輪子，并且建立在現有標準之上：
1.該協議建立在現有、流行的標準之上，包括：HTTP、SSE、JSON-RPC，這意味著它更容易與企業日常使用的現有 IT 堆棧集成。
2.默認安全 - A2A 旨在支持企業級身份驗證和授權，與 OpenAPI 的身份驗證方案相當。
2、MCP 架構設計
MCP（模型上下文協議）是由 Anthropic 定義的一個開放協議，標準化應用程序如何為大語言模型（LLM）提供上下文。更具體地說，它試圖標準化基于 LLM 的應用程序與其他環境集成的協議。
在 AI Agent 系統（Agentic Systems）中，上下文可以通過多種方式提供：
1.外部數據：這是長期記憶的一部分。
2.工具：系統與環境交互的能力。
3.動態提示詞：可以作為系統提示詞（System Prompt）的一部分注入。
第一、為什么要標準化？
目前，AI Agent 應用的開發流程很混亂：
1.有許多 AI Agent 框架存在細微差異。雖然看到生態系統蓬勃發展令人鼓舞，但這些細微差異很少能帶來足夠的價值，但可能會顯著改變你的代碼編寫方式。
2.與外部數據源的集成通常是臨時實現的，并且使用不同的協議，即使在組織內部也是如此。對于不同公司來說，這顯然是如此。
3.工具在代碼庫中以略微不同的方式定義。如何將工具附加到增強型 LLM 上也是不同的。
目標是提高我們創新 AI Agent 應用的速度、安全性以及將相關數據帶入上下文的便利性。
第二、MCP 架構設計
1.MCP Host：使用 LLM 為核心并希望通過 MCP 訪問數據的程序。
2.MCP Client：與 MCP Server 保持1:1連接的客戶端。
3.MCP Server：每個 MCP Server 都通過標準化的模型上下文協議公開特定功能的輕量級程序。
4.Local Data Sources：你計算機上的文件、數據庫和服務，MCP Server 可以安全訪問。
5.Remote Data Sources：通過互聯網可用的外部系統（比如：通過 API），MCP Server 可以連接到這些系統。
第三、通過 MCP 分離控制責任
MCP Server 公開三個主要元素（Prompts、Resoures、Tools），這些元素是有意設計的，以幫助實現特定的控制分離。
1.Prompts 提示詞被設計為用戶控制的。后端的程序員可以公開特定的提示詞（適用于與后端服務公開的數據交互），這些提示詞可以注入到使用 LLM 的應用程序中，并暴露給給定應用程序的用戶。
2.Resoures 資源被設計為應用程序控制的。Resources 資源是任何可以被利用 LLM 構建的應用程序使用的數據（文本或二進制）。應用程序的程序員（通常是 AI 應用開發工程師）負責將這些信息編碼到應用程序中。通常，這里沒有自動化，LLM 不參與此選擇。
3.Tools 工具被設計為大模型控制的。如果我們賦予應用程序如何與環境交互的代理權，我們使用 Tools 工具來實現這一點。MCP Server 公開一個端點，可以列出所有可用 Tools 工具及其描述和所需參數，應用程序可以將此列表傳遞給 LLM，以便它決定哪些 Tools 工具適用于手頭的任務以及如何調用它們。
3、A2A + MCP 協同架構設計
第一、A2A + MCP 協同架構設計
谷歌說得很清楚：AI Agent 應用需要 A2A 和 MCP。我們推薦用 MCP 來處理工具，用 A2A 來處理 AI Agents。
這話啥意思呢？我們來看看一個涉及多個 AI Agent 系統架構。
MCP 里的組件：
1.MCP Host：這里有意思了，和 A2A 結合后，MCP Server 就是 AI Agent。
2.MCP Client。
3.MCP Server。
4.Local Data Sources。
5.Remote Data Sources。
A2A 這邊：
6.AI Agent（MCP Host）會通過 A2A 協議來實現和通信，這個協議能實現：
- 安全協作：MCP 沒有身份驗證功能。[更新：最近 MCP 在身份驗證方面有了很多改進。
- 任務和狀態管理。
- 用戶體驗協商。
- 能力發現：和MCP工具類似。
谷歌建議，MCP 主要用于把傳統的數據系統（MCP Resources）和 API（MCP Tools）跟基于 LLM 的應用整合起來，而 A2A 則負責 AI Agent 之間的通信。
我確實覺得，往后發展，大家會越來越傾向于把平臺暴露成 AI Agent，而不是 MCP Server，所以 MCP 在第5點的重要性會逐漸降低。
第二、通過 MCP 進行 AI Agent 發現
谷歌甚至建議通過 MCP Server Resources 來暴露 A2A AI Agent。
1.網格（Mesh）中的每個 AI Agent 都可以通過 MCP Client 連接到一個專門的 MCP Server，并瀏覽 Resources 目錄來發現其他可用的 AI Agent。建議通過這些 MCP Resources 來暴露 Agent Cards。
2.發現之后，AI Agent 之間會繼續利用 A2A 協議進行通信。
話說回來，如果我們朝著通過全球索引進行 AI Agent 發現的方向發展，MCP 在這里的重要性也會降低，甚至可能會消失。
4、長期來看，A2A 會不會取代 MCP？
第一、MCP 會不會逐漸變得不重要？
其實，一直以來，人們都在尋找一種方法，能讓大量的 AI Agent 之間互相連接，還能和傳統的系統連接。之前有人提到過無頭瀏覽器（headless browsers），但現在看來，開放的通信協議可能才是未來的方向。我覺得，這也是為什么有人說 MCP 是“新的 HTTP 時刻”（雖然可能有點夸張）。
以下的想法是基于一些假設的：
- 開放的通信協議會把新世界的 AI Agent 整合在一起。
- 成為領先的協議是有好處的。
- 這兩種協議都會繼續發展，可能會擴大它們的責任范圍。
第二、MCP 和 A2A 有一些相似之處
在 AI Agent 協議方面，兩者都有明顯的相似性，用戶可以選擇多種方式來構建他們的 AI Agent 應用，并將它們展示給世界。
隨著 MCP 的迅速流行，公司把 MCP Server 作為他們產品的一部分變得很常見，這樣開發者就可以輕松地把這些平臺的內容整合到他們自己的基于 LLM 的應用中。
然而，MCP 在推廣過程中遇到了一些問題。
- 這個協議最大的缺點之一就是缺乏安全性和身份驗證。如果你想安全地展示一個遠程的 MCP Server，你需要在基本實現上做一些調整。
- Tools 工具可以描述任何東西，包括其他 AI Agent。不幸的是，MCP 沒有實現任何可以讓 AI Agent 通過工具進行適當通信的機制（比如狀態/上下文交換、長期任務支持等）。
這可能是谷歌通過 A2A 進入協議競爭的一個切入點，因為它解決了上述問題。
我總覺得 Anthropic 對 MCP 的規劃比現在看到的要大，包括把多個 AI Agent 連接在一起。現在，A2A 的出現可能已經關上了向這個方向發展的大門。
從長遠來看，AI Agent 的世界會是什么樣子呢？
- 公司會把他們的數據資產暴露給 AI Agent 使用。
- 公司會暴露可以返回數據或執行操作的 AI Agent。
- 公司本身就是可以和其他 AI Agent 互動的 AI Agent。
我傾向于最后一種情況。
如果這個假設成立，那么真正有權力的是控制遠程 AI Agent 通信協議的那個協議。
即使在短期內，假設新出現的公司默認會選擇第二種方式，如果他們選擇通過 AI Agent 來暴露數據，那么 A2A 顯然是贏家。
說了這么多，MCP 會不會繼續作為連接新型應用和傳統系統的協議，而一旦 AI Agent 占據主導地位，MCP 就會變得無關緊要呢？誰知道呢，讓我們拭目以待。
但如果真有那么一天，猜猜我在行業里會支持誰呢？ ：）
第三、總結一下
我們正處在一個激動人心的時代。新型 AI Agent 應用的大規模連接方式正在我們眼前被定義。
A2A 雖然是新來者，但它很快就在 AI Agent 通信領域嶄露頭角。雖然 MCP 為 LLM 如何整合上下文帶來了結構，但 A2A 正在解決 MCP 所缺乏的東西：安全性、狀態管理和實時協作。A2A 會不會取代 MCP？誰知道呢。
盡管官方立場是這兩種協議解決的是完全不同的問題，但它們之間可能存在潛在的重疊，而且可以預見這些協議的范圍也會擴大。
如果未來是 AI Agent 的天下，公司開始暴露 AI Agent 而不僅僅是工具或數據，那么能夠實現無縫 AI Agent 互動的協議可能就是贏家。現在看來，A2A 似乎正在做出正確的選擇。
本文轉載自公眾號玄姐聊AGI 作者：玄姐
