智能體間協作的 "巴別塔困境" 如何破解？解讀 Agent 通信 4 大協議：MCP-ACP-A2A-ANP

AI 智能體的興起觸發了 AI 應用協作的新領域。這些智能體不再侷限於被動的聊天機器人或獨立的系統，它們現在被設計用於推理、計劃和協作ーー跨任務、跨域甚至跨組織。但隨着這一願景成爲現實，一個挑戰很快浮出水面： 智能體如何以一種安全、可伸縮和可互操作的方式可靠地相互交流、共享上下文並共同做出決策？

一類新的通信協議應運而生。從模型上下文協議 (MCP) 到 IBM 和思科的智能體通信協議 (ACP) ，從谷歌的跨廠商智能體對智能體協議 (A2A) 到去中心化的代理網絡協議 (ANP) ，這些協議正在競相定義智能體在 AI 時代如何協調。

這些方法都帶來了獨特的優勢，不是理論上的，它們正在被實現、試驗和標準化ーー幫助開發人員解決當前的問題，並使第一波自治系統能夠在生產環境中運行。它們對互操作性、上下文共享和安全通信的貢獻不僅僅是有價值的，而且可能是必不可少的。

1. MCP ： 結構化上下文注入

Anthropic 引入的模型上下文協議 (Model Context Protocol，MCP) 定義了一個標準化的接口，用於向大模型提供結構化的實時上下文。使得像 GPT 或 DeepSeek 這樣的語言模型可以訪問工具和知識，減少了對硬編碼集成或自定義流水線的需求，允許開發人員將 “實時” 信息插入其他靜態模型

一個通俗一點的類比，可以將其視爲大模型的通用適配器。它確保不同的應用程序可以輕鬆地插入它們的數據和函數，以便大模型可以有效地使用它們，而不管它們來自哪個源。

MCP 的核心功能是上下文數據注入。MCP 允許外部資源 (如文件、數據庫行或 API 響應) 直接拉入提示詞或工作內存。所有這些都通過標準化的接口實現，因此大模型可以保持輕量且乾淨。MCP 還允許大模型動態地調用工具或者生成報告 ，並且按需調用。這就像給 AI 增加了一個可以訪問一個工具箱，而且沒有硬連接到模型本身的工具箱。MCP 不是用所有可能的細節來填充提示詞，而是幫助組合重要的背景信息，採用模塊化的、即時的提示詞構建，使用更智能的背景信息，更少的 token，得到更好的輸出。

MCP 使用基於 json 的能力描述符在 HTTP (s) 上運行，在設計上是爲與模型無關，任何具有大模型都可以利用兼容 MCP 的服務器。而且，與 API 網關和企業認證標準 (如 OAuth2) 兼容。

MCP 的典型應用場景是內部 API 與大模型的集成， 支持對結構化業務數據的安全、只讀或交互式訪問，而不暴露原始端點，能夠爲自治智能體配備來自 Salesforce、 SAP 或內部知識庫等工具的運行時上下文。同時，根據用戶會話、系統狀態或任務流水線邏輯定製提示詞。

MCP 非常適用於業務或基於雲的智能體生態系統中的多智能體工作流，使用標準化的 api 和 JSON 模式，旨在使用規劃邏輯衡量 AI 之間的協作努力。基於 MCP 的智能體並不對物理世界進行推理，它們只提取數據、處理數據，然後根據事先訓練和提示指令輸出結果。智能體的理解是根據上下文注入的，而不是自我建模的。

2. ACP：受控環境中的結構化協作

智能體通信協議 (Agent Communication Protocol，ACP) 是一個開放標準，最初由 BeeAI 和 IBM 提出，用於支持在同一局部或邊緣環境中運行的 AI 智能體 之間的結構化通信、發現和協作。

一個通俗的類比，我們可以把它想象成 AI 智能體的郵政服務ーー ACP 定義了 “信封”(消息格式) 和傳遞規則，這樣使用不同堆棧的智能體仍然可以交換有意義的信息。與面向雲的協議 (如 A2A) 或上下文路由協議 (如 MCP) 不同，ACP 是爲本地優先的實時代理編排而設計的，具有最小的網絡開銷和在共享運行時內部署的智能體之間的緊密集成。

ACP 定義了一個去中心化的代理環境，其中每個智能體使用本地廣播 / 發現層公佈其身份、功能和狀態。智能體通過事件驅動的消息傳遞進行通信，通常使用本地總線或 IPC (進程間通信) 系統，可選的運行時控制器可以編排智能體行爲、聚合遙測和執行策略。ACP 智能體通常作爲輕量級、無狀態的服務或具有共享通信底層的容器運行。

ACP 專爲低延遲環境設計 (例如，本地協調、機器人、離線邊緣 AI)，可以通過 gRPC、 ZeroMQ 或自定義運行時總線實現。ACP 強調本地自主權限，而不需要雲依賴或外部服務註冊，同時支持自動任務路由的功能和語義描述符。

ACP 的典型應用場景是邊緣設備上的多智能體協調 (例如，無人機、物聯網集羣或機器人艦隊)，本地優先的大模型系統協調調用，支持傳感器輸入和操作執行。鑑於自治的運行時環境，智能體能夠在沒有云基礎設施的環境下進行協調。

簡而言之，ACP 爲模塊化 AI 系統提供了本地協議層的運行時，優先考慮低延遲協調、彈性和可組合性。對於隱私敏感、自治或邊緣優先的部署來說，這是很自然的選擇，因爲在這些環境中雲優先的部署中是不切實際的。

3.A2A：跨廠商智能體的互操作性

由 Google 引入的 Agent-to-Agent (A2A) 協議是一個跨平臺規範，用於使 AI 智能體能夠跨異構系統進行通信、協作和委託任務，並以結構化格式返回結果。與 ACP 的本地優先或 MCP 的工具集成層不同，A2A 解決了水平互操作性問題，能夠將來自不同供應商或運行時的智能體進行標準化，並在開放網絡上交換功能集和協調工作流。

一個通俗一點的類比，我們可以想象一個項目管理平臺，其中 AI 智能體可以看到彼此的技能 並委託任務。A2A 爲他們如何協調和共享他們的工作 (“工件”) 提供了規則。

A2A 選擇使用 Task 來作爲核心的概念，Task 是比 MCP 中的 Tools、Resources 等抽象級別更高的概念。A2A 定義了一個基於 http 的通信模型，其中智能體被視爲可互操作的服務。智能體利用一個機器可讀的 JSON 描述符來通過編程發現彼此，協商任務和角色，交換消息、數據和流更新。A2A 原則上與傳輸層無關，但目前指定基於 HTTPS 的 JSON-RPC 2.0 作爲其交互的核心機制。

A2A 協議的核心組件如下：

  1. Agent Cards： json 文檔，描述了代理的功能、端點、支持的消息類型、身份驗證方法和運行時元數據。

  2. A2A 客戶機 / 服務器接口： 每個智能體可以作爲客戶機 (任務發起者)、服務器 (任務執行者) 或兩者兼而有之，從而支持動態任務路由和協商。

  3. 消息和工件交換：支持具有上下文的多部分任務、流輸出 (通過 SSE) 和持久化工件 (例如文件、知識模塊)。

  4. 用戶體驗協商：智能體可以調整消息格式、內容粒度和可視化，以匹配下游代理的功能。

A2A 基於 OAuth 2.0 和基於密鑰的 API 進行授權，也就是說，A2A 基於 HTTP、 JSON-RPC 和標準 web 的安全性完成構建，是 web 原生的安全性設計。智能體只公開聲明的交互所需的函數來明確端點的能力範圍，以在 “不透明” 模式下運行，隱藏內部邏輯，同時顯示可調用的服務。A2A 具有模型無關性， 能夠與任何實現該協議的智能體系統 (例如，大模型 或其他服務) 一起工作，支持任務流和輕量級有效負載的多輪協作。

A2A 的典型應用場景是對來自不同團隊或供應商的智能體進行安全互操作，形成跨平臺的智能體生態系統。其中，採用了雲原生 AI 境中的分佈式智能體編排 ，例如，Vertex AI，LangChain，HuggingFace 智能體 s 等。作爲一個多智能體協作框架，能夠支持跨多個企業系統的 AI 工作流 ，解決了 crm、 HR 系統或生產力代理等工具之間的互操作性問題，得到了主要企業供應商的支持。

4. ANP：Web 智能體的未來

在當前所有的代理協議中，代理網絡協議 (ANP) 最符合主動推理和空間網絡的要求。ANP 建立在分佈式標識符 (distributed identifiers，DIDs) 和 JSON-LD 鏈接數據之上，它允許智能體在語義上描述自己，在全局範圍內發現彼此，並進行對等通信。

我們做一個簡單的類比，想象一個全球性的，安全的 AI 智能體在線市場，ANP 爲智能體提供了 id (如數字護照) 和規則，以發現彼此，證明他們的身份，並公開和安全地協作。協議本身會攜帶身份信息、身份驗證信息，目前主要是使用 W3C 的 DID 方案，一個智能體可以用自己的身份信息，與其他所有的智能體進行交互，不必在其他智能體平臺申請賬號。ANP 採用了去中心化的身份安全通信，基於關聯數據的語義建模，通過開放註冊表或搜索索引智能體的描述進行發現。

ANP 的核心概念是 Interface，包括自然語言接口和結構化接口，將智能體交互方式的定義下放到了 Interface 中，支持自主發現、去中心化身份驗證和語義推理，雖然 ANP 目前不支持像 rgm 這樣的預測或分層推理體系結構，但是它的基礎設施可以提供傳輸和發現層的智能體。

ANP 的智能體描述則是基於 JSON-LD 和 http://schema.org，這是語義網的技術，具體可以參考《從語義網到知識圖譜》一文。其目的是提高兩個智能體對信息理解的一致性。ANP 採用的是語義網的 Linked-Data 技術，目標是構建一個便於 AI 訪問和理解的 AI 原生數據網絡。

同樣，ANP 可能缺乏共享的全局上下文和空間網絡提供的事務性知識圖譜。它能夠連接智能體，但不連接它們的環境。這或許是空間網絡開始接管的地方。

5. 智能體間通信協議的思考

在一定意義上，A2A 和 MCP 是互補的，它們解決的是 AI 智能體完全不同的部分，而且它們實際上可以配合得非常好。可以把 MCP 看作是讓 AI 智能體接入世界的協議， MCP 使智能體能夠訪問文件、 api 和數據庫，基本上就是他們做一些有用的事情所需要的所有結構化上下文。無論是提取實時銷售數據還是生成自定義報告，MCP 都處理與工具和數據的連接。A2A 是智能體開始合作的地方，A2A 爲他們提供了一種共享的語言和一套規則來發現彼此、委派任務、協商他們如何一起工作ーー即使他們是由不同的供應商構建或運行在不同的平臺上。

簡單而言，MCP 連接 AI 和工具，而 A2A 連接 AI 和其他 AI，它們共同構成了構建智能協作系統的強大模塊基礎。

ACP 採用了完全不同的方法。這完全是本地優先代理協調的問題，不需要雲服務。ACP 不使用 HTTP 和基於 web 的發現，而是允許代理在共享運行時內部相互查找和通信。這非常適用於帶寬有限或者需要低延遲 (比如機器人技術或者設備上的助手) 的場景, 或者隱私級別很高，以及在沒有互聯網的環境中部署 (例如，工廠車間、邊緣節點)。

ACP 並非試圖與 A2A 競爭，它只是填補了一個不同的利基市場。但是在一些設置中，特別是在嚴格控制的環境中，ACP 可能完全取代 A2A，因爲它跳過了 web 本地協議的開銷，只是在本地完成工作。

ANP 則像是充滿了互聯網情懷方法，實現智能體在互聯網上的連接與協作。ANP 的最大價值在於社區對未來智能體互聯網的設想，是社區獨特的互聯網理念（連接即權力），以及 DID + 語義網的技術路線。這可能是 ANP 演進的核心動力。

MCP/ACP/A2A 使用註冊表或服務描述符 (如代理卡) 來公佈代理功能。每個協議都定義了自己的發現方法，通常需要一個已知的目錄或端點。ANP 更進一步，通過 JSON-LD 和 did 實現去中心化發現，使代理具有自主身份和開放 web 上的語義可見性。

AwLwHK

接下來，一種理想的情況是各協議趨同互補。設想一個統一的智能體平臺，其中 A2A 處理企業內部智能體之間的來回操作，MCP 管理對工具和數據的訪問，ACP 風格的運行時插件用於邊緣或離線場景，ANP 則可以安全地使用互聯網上的各種智能體。一切正常運行，開發人員可以在此基礎上進行構建，而無需擔心哪個協議在幕後做什麼。最壞的情況是支離破碎，不同的供應商推出不同風格的 MCP/ACP/A2A/ANP ，結果就是一團糟，就像 web 服務的早期，沒有大量的膠水代碼，什麼都不能與其他任何東西進行交互。

開源工具和中間件可以挽救這種局面。這些項目位於代理和協議之間，抽象出它們之間的區別，併爲開發人員提供一個乾淨、統一的 API ーー同時根據代理運行的位置和方式在底層進行轉換。

6. 小結

MCP，ACP，A2A，ANP 基本上都能夠使智能體相互發現對方、協商任務和直接共享消息。在大多數情況下，每個智能體管理自己的本地狀態和上下文。

雖然 MCP、 ACP、 A2A 和 ANP 都在解決當今的智能體通信需求方面取得了長足的進步，但它們都誕生於一個特定的環境 —— AI 智能體，並在當前的互聯網結構中運行。隨着向主動推理智能體和分佈式智能的演進，可能都有其侷限性。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5udbNJFIt1lN_Lkx31-otw

猜你喜歡