簡介面向AI研究人員、開發(fā)者以及關注智能體互聯(lián)的企業(yè)管理者與技術(shù)愛好者這份PDF資料系統(tǒng)梳理MCP、A2A、ANP三種智能體通信協(xié)議的背景與定位MCP以模型為中心解決LLM應用與外部工具和數(shù)據(jù)源的無縫集成A2A偏重企業(yè)內(nèi)部智能體的復雜協(xié)作ANP則從智能體身份、描述、發(fā)現(xiàn)等層面切入目標成為智能體互聯(lián)網(wǎng)時代的HTTP。資源包為單一PDF文檔大小8.14MB頁數(shù)緊湊但內(nèi)容密度高涵蓋協(xié)議演進脈絡、ANP分層架構(gòu)與開源社區(qū)落地進展并對MCP與ANP的技術(shù)邊界做了清晰對比。目前已有583人學習/下載適合希望理解智能體互聯(lián)趨勢并進行協(xié)議選型的讀者。通讀后可建立智能體通信協(xié)議的整體視圖明確三者適用場景與設計理念差異也能對AI原生數(shù)據(jù)網(wǎng)絡、消費互聯(lián)網(wǎng)與產(chǎn)業(yè)互聯(lián)網(wǎng)融合等未來方向獲得啟發(fā)。1. 智能體通信協(xié)議為什么 MCP 還不夠ANP 要補什么從 2024 年底到現(xiàn)在MCPModel Context Protocol幾乎成了 AI 應用連接外部工具的事實標準GitHub 上相關倉庫多到刷不完。但真正把智能體Agent當成一類獨立實體去設計通信方式時MCP 的短板就露出來了它擅長讓模型調(diào)用工具卻不擅長讓兩個智能體互相發(fā)現(xiàn)、認證、協(xié)作。Google A2A 想用統(tǒng)一接口解決企業(yè)內(nèi)智能體協(xié)作而 ANP 的目標更直接——成為智能體互聯(lián)網(wǎng)時代的 HTTP。這篇筆記從三個協(xié)議的定位差異講起再拆開 ANP 的分層架構(gòu)和執(zhí)行細節(jié)給想動手接協(xié)議的開發(fā)者一條能直接落地的路徑。這套資料適合正在選型智能體通信方案的開發(fā)者、架構(gòu)師也適合想搞懂 MCP 和 A2A 之間到底什么關系的人。下面內(nèi)容按照「協(xié)議邏輯 → 動手步驟 → 踩坑記錄 → 選型建議」的順序走中間穿插可復現(xiàn)的命令和代碼片段最后收在驗證方法和資源引導上。2. MCP 協(xié)議拆解模型連工具的 USB-C也是智能體通信的起點2.1 MCP 解決了什么解決不了什么MCP 全稱 Model Context Protocol由 Anthropic 提出并開源解決的問題非常聚焦讓 LLM 應用用一套標準方式連接外部數(shù)據(jù)源和工具。你可以把 MCP Server 看成是給模型準備的「USB-C 接口」模型通過 MCP Client 發(fā)現(xiàn)工具、調(diào)用工具、拿回結(jié)構(gòu)化結(jié)果。它的核心價值在于把「模型 ? 工具」之間的集成從 N×M 的對接矩陣壓縮成 NM 的插拔式連接。以前每接一個數(shù)據(jù)源就要專門寫一套函數(shù)調(diào)用邏輯現(xiàn)在只要實現(xiàn)一個 MCP Server任何支持 MCP 的客戶端都能直接調(diào)用。官方 SDK 覆蓋了 Python 和 TypeScript傳輸層默認走 JSON-RPC 2.0 over stdio 或 Streamable HTTP。但把 MCP 直接搬到智能體通信場景就不順手了。我拆 MCP 源碼時留意到幾個設計前設資源發(fā)現(xiàn)是拉取式的Server 被動等 Client 來連認證基于 OAuth但智能體之間的偶發(fā)協(xié)作不可能每對都走一遍用戶授權(quán)流程。更致命的是MCP 沒有定義智能體的公共身份。換句話說兩個 MCP 端點之間無法回答一個最基本的問題對方是誰憑什么信任它。2.2 MCP Server 最小實現(xiàn)用 Python 半小時跑通先動手把 MCP 跑起來后面對比 ANP 才有參照物。下面是最小可用的 MCP Server 代碼from mcp.server.fastmcp import FastMCP # 創(chuàng)建 MCP 服務實例 mcp FastMCP(hotel-booking) # 注冊一個工具天氣查詢便于后續(xù)測試 mcp.tool() def get_weather(city: str) - str: 查詢指定城市的天氣情況 return f{city} 今日晴24℃適合出行 # 注冊第二個工具模擬酒店查詢 mcp.tool() def search_hotel(city: str, date: str) - str: 按城市和日期查詢可預訂酒店 return f{city} 在 {date} 有 3 家可預訂酒店 if __name__ __main__: mcp.run(transportstdio)這段代碼注冊了兩個工具get_weather和search_hotel走 stdio 傳輸。注意FastMCP這個類隱藏了協(xié)議細節(jié)工具函數(shù)上方的 docstring 會被當作工具描述送給模型直接影響模型能不能理解工具的用途。啟動服務后再用 MCP Inspector 做一次快速驗證# 安裝 MCP Inspector全局裝一次即可 npx modelcontextprotocol/inspector # 在 MCP Inspector 界面連接 stdio 服務 # 啟動命令填python hotel_server.py用 Inspector 連上服務后能看到兩個工具暴露給客戶端直接傳參調(diào)用search_hotel返回的是我們寫好的假數(shù)據(jù)。這說明 MCP Server 已經(jīng)能被任何支持 MCP 的客戶端發(fā)現(xiàn)和調(diào)用了。2.3 MCP 在智能體通信里的三個硬傷MCP 用好用但用在智能體互聯(lián)上明顯吃力。我在實際接方案時撞到過三堵墻。第一堵墻是注冊墻個人助手想調(diào)酒店智能體的服務必須先在酒店系統(tǒng)里注冊賬號、拿 token。這在 MCP 的設計里沒有提供去中心化的身份方案每個工具端點都得維護自己的用戶體系。第二堵墻是被動墻MCP Server 是拉取式的模型客戶端主動找上門Server 沒有能力反推一條消息給某個智能體。放到真實場景中酒店智能體想主動把優(yōu)惠信息推給曾經(jīng)住過的用戶助手MCP 做不到。第三堵墻是發(fā)現(xiàn)墻MCP 沒有定義任何目錄服務或搜索機制客戶端實現(xiàn)時得硬編碼已知的工具端點地址。智能體數(shù)量一多靠配置文件維護連接地址完全不現(xiàn)實。3. A2A 協(xié)議拆解企業(yè)級智能體協(xié)作的 P2P 方案3.1 A2A 和 MCP 的分工邏輯A2AAgent2Agent是 Google 推出的協(xié)議主打企業(yè)內(nèi)多個智能體共同完成復雜任務。它的定位和 MCP 非?；パaMCP 把模型和工具連接起來A2A 把智能體和智能體連接起來。A2A 的設計有幾個關鍵選擇值得注意。第一它采用 P2P 架構(gòu)而不是中心化調(diào)度任何兩個智能體都能直接建立通信。第二它把「任務Task」作為協(xié)議的一等公民AgentCard 描述智能體能力任務對象跟蹤交互狀態(tài)。第三認證走 OAuth通信基于 JSON-RPC。企業(yè)落地時最大的收益是不用為每對智能體單獨開發(fā)對接邏輯A2A 兼容層能直接對話。3.2 AgentCard智能體對外的名片A2A 協(xié)議和 MCP 最大的形態(tài)差異在于 AgentCard——每個智能體用一個 JSON 文件描述自己的能力、端點地址和認證方式客戶端先拉取 AgentCard 再決定怎么協(xié)作。{ name: hotel-agent, description: 酒店查詢與預訂智能體支持查房、訂房、退訂, url: https://agent.hotel-example.com/, skills: [ { id: search_rooms, name: 查詢可預訂房間, inputModes: [text], outputModes: [text] } ], authentication: { schemes: [oauth2] } }這個 JSON 是 A2A 端點的門面?？蛻舳苏{(diào)用任何智能體之前先解析它的 AgentCard確認它提供哪些 skill再從url字段找到消息端點發(fā) JSON-RPC 請求。3.3 A2A 適合誰用A2A 更適合那些已經(jīng)跑在同一個組織邊界內(nèi)的多智能體系統(tǒng)。原因有兩點一是 OAuth 意味著你得有統(tǒng)一的身份供應方二是任務狀態(tài)跟蹤模型需要兩端都持續(xù)在線并維護任務對象這在小規(guī)模、內(nèi)網(wǎng)環(huán)境下可控性好但跨平臺協(xié)作時同步成本比較高。我個人的判斷是A2A 解決的是「組織內(nèi)部智能體協(xié)作標準化」ANP 解決的是「跨組織智能體互聯(lián)去中心化」兩者定位差異很明顯。如果你只關心企業(yè)內(nèi)部多個 Agent 分工完成一份報表A2A 是合適的如果你的 Agent 要和一個完全陌生平臺的 Agent 協(xié)作ANP 的 DID 身份方案更對路。4. ANP 協(xié)議實踐身份、描述、發(fā)現(xiàn)三層架構(gòu)怎么落地4.1 ANP 的分層設計ANPAgent Network Protocol是目前唯一一個直接宣稱「目標是做智能體互聯(lián)網(wǎng)時代 HTTP」的開源協(xié)議。它的核心思路是把智能體當成網(wǎng)站來設計智能體有自己的身份 ID、公開描述、可發(fā)現(xiàn)的入口。整個協(xié)議分為三層層級職責技術(shù)基礎身份與加密通信層智能體身份認證、加密通信W3C DID去中心化標識符元協(xié)議層能力描述、接口公開JSON-LD、schema.org應用協(xié)議層發(fā)現(xiàn)、訪問、調(diào)用DNS、搜索引擎機制第一層用 DID 解決「我是誰」基于非區(qū)塊鏈的去中心化方案讓任意兩個智能體用自己的 ID 互認。第二層用 JSON-LD 和 schema.org 把智能體的能力、接口、基本信息寫成結(jié)構(gòu)化數(shù)據(jù)能被機器理解。第三層復用 DNS 和搜索技術(shù)理論上搜索引擎能索引全網(wǎng)智能體。4.2 基于 DID 的智能體身份創(chuàng)建ANP 的身份層目前可以通過 Python SDK 來創(chuàng)建和注冊一個 DID 標識符。下面是一個最小示例# 安裝 ANP SDKpip install anp-sdk from anp_sdk import create_agent_identity, register_agent # 第一步為智能體創(chuàng)建去中心化身份標識 identity create_agent_identity(agent_namehotel-agent) # 第二步把身份和端點上鏈/登記到目錄 registration register_agent( dididentity.did, endpointhttps://agent.example.com/anp, public_keyidentity.public_key, ) print(DID:, identity.did) print(登記狀態(tài):, registration.status)create_agent_identity負責生成本地密鑰對和 DIDregister_agent把 DID、端點和公鑰發(fā)布到 ANP 目錄供其他智能體發(fā)現(xiàn)和驗證。整個過程中密鑰不上傳只上傳播放公鑰這是 ANP 身份層區(qū)別于中心化賬號體系的關鍵。4.3 JSON-LD 能力描述文件身份建好之后第二步是寫智能體的能力描述。ANP 復用 schema.org 詞匯表把智能體的能力暴露成結(jié)構(gòu)化數(shù)據(jù){ context: https://schema.org, type: Hotel, name: 示例酒店智能體, did: did:anp:7g3f..., endpoint: https://agent.example.com/anp, services: [ { type: Service, name: 房間預訂, url: https://agent.example.com/anp/booking } ] }描述文件同時聲明了 DID 和端點的對應關系。發(fā)現(xiàn)機制基于 DNS 和網(wǎng)頁搜索技術(shù)其他智能體可以通過搜索引擎或者目錄服務查到這份描述然后拿著 DID 建立認證。4.4 ANP 的交互流程完整走一遍從消息流程來看ANP 的交互可以拆成四步發(fā)現(xiàn)調(diào)用方通過目錄服務或搜索引擎查找目標智能體的 JSON-LD 描述文件認證調(diào)用方發(fā)起一個 DID 認證握手雙方驗證身份簽名協(xié)商通過元協(xié)議交換可調(diào)用的接口和權(quán)限范圍調(diào)用進入應用協(xié)議層執(zhí)行具體業(yè)務請求項目官方文檔里給了一個很典型的用例個人助手不需要在酒店平臺注冊賬號直接用 ANP SDK 發(fā)起一個帶 DID 簽名的請求酒店智能體驗證簽名后返回可預訂房間列表整個交互里不出現(xiàn)傳統(tǒng)的用戶名密碼。4.5 開源實操OpenManus 接入 ANP 的步驟ANP 社區(qū)已經(jīng)把owl和OpenManus都接上了 ANP 協(xié)議兩塊代碼都放 GitHub 倉庫里。如果想把一套 OpenManus 改造為支持 ANP 的智能體常見的做法是# 克隆支持 ANP 的 OpenManus 分支 git clone https://github.com/agent-network-protocol/OpenManus-ANP.git cd OpenManus-ANP # 安裝依賴 pip install -r requirements.txt # 運行支持 ANP 的智能體端點 python main.py --anp-enabled跑起來之后智能體會生成自己的 DID并開放一個包含 ANP 端點的入口地址。這時候用另一個 ANP 客戶端往這個地址發(fā)請求可以驗證協(xié)議棧的連通性。5. 協(xié)議選型必經(jīng)之坑身份、認證、超時這類問題的排查5.1 踩坑記錄MCP Server 一直報工具未注冊現(xiàn)象自己寫的 MCP Server 在 Inspector 里能看到工具但通過 Client SDK 調(diào)用時報Tool not found。原因MCP Client 端會緩存工具列表服務端更新工具但客戶端未重連時函數(shù)名不匹配。解決在啟動客戶端之前加一段工具列表刷新邏輯強制重拉一次。常見做法是每次會話開始先執(zhí)行client.list_tools()確認返回里包含最新的工具函數(shù)名。5.2 踩坑記錄A2A AgentCard 端點和實際服務端口不一致現(xiàn)象客戶端能拉到 AgentCard但發(fā)起 JSON-RPC 請求時連接被拒絕或超時。原因AgentCard 里url字段填的是公網(wǎng)地址實際服務監(jiān)聽在內(nèi)網(wǎng)端口反向代理沒有把所有路徑轉(zhuǎn)發(fā)對。解決先檢查 AgentCard 里的url能否直接在瀏覽器打開再確認反向代理的路徑轉(zhuǎn)發(fā)規(guī)則。建議在 AgentCard 的url中顯式寫到完整路徑不要依賴默認根路徑。5.3 踩坑記錄ANP DID 身份認證握手一直失敗現(xiàn)象兩個 ANP 端點互相發(fā)現(xiàn)成功但身份認證時簽名校驗不通過日志里看不到具體錯誤。原因DID 的密鑰對或方法標識符不匹配經(jīng)常是復制描述文件時把did字符串截斷了或者本地密鑰輪換過但目錄里還是舊公鑰。解決用官方 CLI 工具核對 DID方法簡單直接anp-cli verify-did --did did:anp:7g3f... --endpoint https://agent.example.com/anp如果返回INVALID_SIGNATURE那基本可以確定是公鑰或 DID 字符串的問題。5.4 踩坑記錄ANP 請求頻繁超時重試反而加重故障現(xiàn)象在弱網(wǎng)環(huán)境測試 ANP 調(diào)用請求失敗后直接重試結(jié)果服務端負載飆升所有請求都失敗。原因沒有做超時控制和指數(shù)退避重試風暴壓垮了服務端。解決客戶端統(tǒng)一走指數(shù)退避邏輯import time MAX_RETRIES 3 for attempt in range(MAX_RETRIES): try: response anp_request(payload) break except TimeoutError: wait_time 2 ** attempt time.sleep(wait_time) else: raise ConnectionError(ANP request failed after retries)5.5 避坑注意協(xié)議選型前先確認傳輸方式在實際選型的時候要最先確認協(xié)議運行環(huán)境。MCP 開發(fā)期走 stdio 很方便但生產(chǎn)環(huán)境多半要走 Streamable HTTPANP 官方倉庫對網(wǎng)絡環(huán)境有說明需要公網(wǎng)可達的 HTTPS 端點A2A 基本依賴企業(yè)內(nèi)網(wǎng)已有基礎設施。把這些前置條件列成清單比先選協(xié)議再補環(huán)境要穩(wěn)得多。6. 把三套協(xié)議放進同一張選型表驗證技巧與進階用法6.1 一張表看清選型邊界我在給團隊做技術(shù)方案時一般會把協(xié)議的邊界問題壓縮成一張表維度MCPA2AANP核心定位模型連接工具組織內(nèi) Agent 協(xié)作Agent 跨平臺互聯(lián)互通中心視角以模型為中心以任務為中心以智能體為中心身份方案OAuthOAuthW3C DID 去中心化發(fā)現(xiàn)機制客戶端硬編碼AgentCard 拉取DNS 搜索引擎主動通信不支持支持支持典型場景AI 編程、工具調(diào)用企業(yè)內(nèi)部多 Agent 分工跨平臺酒店預訂、電商協(xié)作成熟度行業(yè)事實標準剛發(fā)布迭代中項目落地中有開源案例選型判斷我一般看三個問題智能體數(shù)量是否超過十個是否存在跨組織協(xié)作模型是否占主導如果第一條為否A2A 能覆蓋如果第二條明顯ANP 值得押注。6.2 驗證協(xié)議棧連通性一條命令一個指示燈協(xié)議接完之后最怕的是「代碼能跑但不知道通沒通」。我習慣把一個連通性測試腳本丟進 CI 或者本地開發(fā)流程里對三個協(xié)議統(tǒng)一驗證# 一個快速連通性驗證腳本 import asyncio from anp_sdk import ANPClient async def check_agent_health(endpoint: str) - bool: client ANPClient(endpointendpoint) # 嘗試發(fā)現(xiàn)目標能力 info await client.discover() # 嘗試建立會話 session await client.create_session() return session.status ACTIVE print(asyncio.run(check_agent_health(https://agent.example.com/anp)))這段腳本檢查的是 ANP 端點最核心的兩件事發(fā)現(xiàn)服務和會話建立。能跑通說明身份、描述、通信三層都正常跑不通很大概率是 DID 注冊表沒生效或者 JSON-LD 描述的endpoint字段寫錯。6.3 一種更省事的進階思路讓 MCP 封裝 ANP對存量項目來說還有一條性價比很高的路徑——用 MCP 把 ANP 能力包一層。這種做法不用重寫業(yè)務邏輯Anthony 團隊在實踐中就是這么用的現(xiàn)有 MCP Server 內(nèi)部調(diào)用 ANP SDK對外仍然暴露 MCP 接口。好處是復用了現(xiàn)有 MCP 生態(tài)的客戶端同時把 ANP 的跨平臺身份協(xié)作能力嵌套了進來。我在自己接的項目里也踩過這個思路的坑MCP 的 stdio 傳輸和 ANP 的異步長連接模型混在一起會出現(xiàn)事件循環(huán)互相阻塞的問題。解決方案是給 MCP Server 的 tool 函數(shù)加一個異步包裝器把 ANP 調(diào)用丟到獨立的事件循環(huán)里運行避免阻塞 MCP 的 stdio 讀寫。從那以后我每次接新協(xié)議都會強制走一遍最小驗證先跑通官方 demo再改業(yè)務邏輯最后才看協(xié)議兼容性。這個習慣幫我躲掉了不少協(xié)議選型的坑。希望這組從 MCP 到 ANP 的拆解能讓你少走一段彎路動起手來反而比停留在概念對比更有收獲。本文還有配套的精品資源點擊獲取