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

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

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

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

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

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

圖片

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

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

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

MCP非常適用于業(yè)務或基于云的智能體生態(tài)系統(tǒng)中的多智能體工作流，使用標準化的 api 和 JSON 模式，旨在使用規(guī)劃邏輯衡量AI之間的協(xié)作努力?；贛CP的智能體并不對物理世界進行推理，它們只提取數(shù)據(jù)、處理數(shù)據(jù)，然后根據(jù)事先訓練和提示指令輸出結果。智能體的理解是根據(jù)上下文注入的，而不是自我建模的。

2. ACP：受控環(huán)境中的結構化協(xié)作

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

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

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

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

ACP的典型應用場景是邊緣設備上的多智能體協(xié)調 (例如，無人機、物聯(lián)網(wǎng)集群或機器人艦隊)，本地優(yōu)先的大模型系統(tǒng)協(xié)調調用，支持傳感器輸入和操作執(zhí)行。鑒于自治的運行時環(huán)境，智能體能夠在沒有云基礎設施的環(huán)境下進行協(xié)調。

簡而言之，ACP 為模塊化 AI 系統(tǒng)提供了本地協(xié)議層的運行時，優(yōu)先考慮低延遲協(xié)調、彈性和可組合性。對于隱私敏感、自治或邊緣優(yōu)先的部署來說，這是很自然的選擇，因為在這些環(huán)境中云優(yōu)先的部署中是不切實際的。

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

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

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

圖片

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

A2A協(xié)議的核心組件如下：

1. Agent Cards： json 文檔，描述了代理的功能、端點、支持的消息類型、身份驗證方法和運行時元數(shù)據(jù)。
2. A2A 客戶機/服務器接口： 每個智能體可以作為客戶機 (任務發(fā)起者)、服務器 (任務執(zhí)行者) 或兩者兼而有之，從而支持動態(tài)任務路由和協(xié)商。
3. 消息和工件交換：支持具有上下文的多部分任務、流輸出 (通過 SSE) 和持久化工件 (例如文件、知識模塊)。
4. 用戶體驗協(xié)商：智能體可以調整消息格式、內容粒度和可視化，以匹配下游代理的功能。

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

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

4. ANP：Web智能體的未來

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

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

圖片

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

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

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

5.智能體間通信協(xié)議的思考

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

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

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

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

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

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

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

開源工具和中間件可以挽救這種局面。這些項目位于代理和協(xié)議之間，抽象出它們之間的區(qū)別，并為開發(fā)人員提供一個干凈、統(tǒng)一的 API ーー同時根據(jù)代理運行的位置和方式在底層進行轉換。

6.小結

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

• MCP 簡化了智能體訪問工具和數(shù)據(jù)的方式。
• ACP 為企業(yè)智能體生態(tài)系統(tǒng)引入了本地結構化協(xié)作。
• A2A 通過創(chuàng)建共享任務語言解決了供應商鎖定問題。
• ANP 推進了代理身份和發(fā)現(xiàn)的去中心化愿景。

雖然 MCP、 ACP、 A2A 和 ANP 都在解決當今的智能體通信需求方面取得了長足的進步，但它們都誕生于一個特定的環(huán)境 —— AI 智能體，并在當前的互聯(lián)網(wǎng)結構中運行。隨著向主動推理智能體和分布式智能的演進，可能都有其局限性。

【參考資料】

• https://modelcontextprotocol.io
• Https://google.github.io/
• https：//agentcommunicationprotocol.dev
• https://github.com/agent-network-protocol
• https://zhuanlan.zhihu.com/p/1893720346567353628
• https://zhuanlan.zhihu.com/p/1894506009025836067
• A SURVEY OF AGENT INTEROPERABILITY PROTOCOLS,https://arxiv.org/pdf/2505.02279