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之間的協作努力?；贛CP的智能體并不對物理世界進行推理，它們只提取數據、處理數據，然后根據事先訓練和提示指令輸出結果。智能體的理解是根據上下文注入的，而不是自我建模的。

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 上的語義可見性。

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

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

6.小結

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

• MCP 簡化了智能體訪問工具和數據的方式。
• ACP 為企業智能體生態系統引入了本地結構化協作。
• A2A 通過創建共享任務語言解決了供應商鎖定問題。
• ANP 推進了代理身份和發現的去中心化愿景。

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

【參考資料】

• 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