简介面向AI研究人员、开发者以及关注智能体互联的企业管理者与技术爱好者这份PDF资料系统梳理MCP、A2A、ANP三种智能体通信协议的背景与定位MCP以模型为中心解决LLM应用与外部工具和数据源的无缝集成A2A偏重企业内部智能体的复杂协作ANP则从智能体身份、描述、发现等层面切入目标成为智能体互联网时代的HTTP。资源包为单一PDF文档大小8.14MB页数紧凑但内容密度高涵盖协议演进脉络、ANP分层架构与开源社区落地进展并对MCP与ANP的技术边界做了清晰对比。目前已有583人学习/下载适合希望理解智能体互联趋势并进行协议选型的读者。通读后可建立智能体通信协议的整体视图明确三者适用场景与设计理念差异也能对AI原生数据网络、消费互联网与产业互联网融合等未来方向获得启发。1. 智能体通信协议为什么 MCP 还不够ANP 要补什么从 2024 年底到现在MCPModel Context Protocol几乎成了 AI 应用连接外部工具的事实标准GitHub 上相关仓库多到刷不完。但真正把智能体Agent当成一类独立实体去设计通信方式时MCP 的短板就露出来了它擅长让模型调用工具却不擅长让两个智能体互相发现、认证、协作。Google A2A 想用统一接口解决企业内智能体协作而 ANP 的目标更直接——成为智能体互联网时代的 HTTP。这篇笔记从三个协议的定位差异讲起再拆开 ANP 的分层架构和执行细节给想动手接协议的开发者一条能直接落地的路径。这套资料适合正在选型智能体通信方案的开发者、架构师也适合想搞懂 MCP 和 A2A 之间到底什么关系的人。下面内容按照「协议逻辑 → 动手步骤 → 踩坑记录 → 选型建议」的顺序走中间穿插可复现的命令和代码片段最后收在验证方法和资源引导上。2. MCP 协议拆解模型连工具的 USB-C也是智能体通信的起点2.1 MCP 解决了什么解决不了什么MCP 全称 Model Context Protocol由 Anthropic 提出并开源解决的问题非常聚焦让 LLM 应用用一套标准方式连接外部数据源和工具。你可以把 MCP Server 看成是给模型准备的「USB-C 接口」模型通过 MCP Client 发现工具、调用工具、拿回结构化结果。它的核心价值在于把「模型 ↔ 工具」之间的集成从 N×M 的对接矩阵压缩成 NM 的插拔式连接。以前每接一个数据源就要专门写一套函数调用逻辑现在只要实现一个 MCP Server任何支持 MCP 的客户端都能直接调用。官方 SDK 覆盖了 Python 和 TypeScript传输层默认走 JSON-RPC 2.0 over stdio 或 Streamable HTTP。但把 MCP 直接搬到智能体通信场景就不顺手了。我拆 MCP 源码时留意到几个设计前设资源发现是拉取式的Server 被动等 Client 来连认证基于 OAuth但智能体之间的偶发协作不可能每对都走一遍用户授权流程。更致命的是MCP 没有定义智能体的公共身份。换句话说两个 MCP 端点之间无法回答一个最基本的问题对方是谁凭什么信任它。2.2 MCP Server 最小实现用 Python 半小时跑通先动手把 MCP 跑起来后面对比 ANP 才有参照物。下面是最小可用的 MCP Server 代码from mcp.server.fastmcp import FastMCP # 创建 MCP 服务实例 mcp FastMCP(hotel-booking) # 注册一个工具天气查询便于后续测试 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这个类隐藏了协议细节工具函数上方的 docstring 会被当作工具描述送给模型直接影响模型能不能理解工具的用途。启动服务后再用 MCP Inspector 做一次快速验证# 安装 MCP Inspector全局装一次即可 npx modelcontextprotocol/inspector # 在 MCP Inspector 界面连接 stdio 服务 # 启动命令填python hotel_server.py用 Inspector 连上服务后能看到两个工具暴露给客户端直接传参调用search_hotel返回的是我们写好的假数据。这说明 MCP Server 已经能被任何支持 MCP 的客户端发现和调用了。2.3 MCP 在智能体通信里的三个硬伤MCP 用好用但用在智能体互联上明显吃力。我在实际接方案时撞到过三堵墙。第一堵墙是注册墙个人助手想调酒店智能体的服务必须先在酒店系统里注册账号、拿 token。这在 MCP 的设计里没有提供去中心化的身份方案每个工具端点都得维护自己的用户体系。第二堵墙是被动墙MCP Server 是拉取式的模型客户端主动找上门Server 没有能力反推一条消息给某个智能体。放到真实场景中酒店智能体想主动把优惠信息推给曾经住过的用户助手MCP 做不到。第三堵墙是发现墙MCP 没有定义任何目录服务或搜索机制客户端实现时得硬编码已知的工具端点地址。智能体数量一多靠配置文件维护连接地址完全不现实。3. A2A 协议拆解企业级智能体协作的 P2P 方案3.1 A2A 和 MCP 的分工逻辑A2AAgent2Agent是 Google 推出的协议主打企业内多个智能体共同完成复杂任务。它的定位和 MCP 非常互补MCP 把模型和工具连接起来A2A 把智能体和智能体连接起来。A2A 的设计有几个关键选择值得注意。第一它采用 P2P 架构而不是中心化调度任何两个智能体都能直接建立通信。第二它把「任务Task」作为协议的一等公民AgentCard 描述智能体能力任务对象跟踪交互状态。第三认证走 OAuth通信基于 JSON-RPC。企业落地时最大的收益是不用为每对智能体单独开发对接逻辑A2A 兼容层能直接对话。3.2 AgentCard智能体对外的名片A2A 协议和 MCP 最大的形态差异在于 AgentCard——每个智能体用一个 JSON 文件描述自己的能力、端点地址和认证方式客户端先拉取 AgentCard 再决定怎么协作。{ name: hotel-agent, description: 酒店查询与预订智能体支持查房、订房、退订, url: https://agent.hotel-example.com/, skills: [ { id: search_rooms, name: 查询可预订房间, inputModes: [text], outputModes: [text] } ], authentication: { schemes: [oauth2] } }这个 JSON 是 A2A 端点的门面。客户端调用任何智能体之前先解析它的 AgentCard确认它提供哪些 skill再从url字段找到消息端点发 JSON-RPC 请求。3.3 A2A 适合谁用A2A 更适合那些已经跑在同一个组织边界内的多智能体系统。原因有两点一是 OAuth 意味着你得有统一的身份供应方二是任务状态跟踪模型需要两端都持续在线并维护任务对象这在小规模、内网环境下可控性好但跨平台协作时同步成本比较高。我个人的判断是A2A 解决的是「组织内部智能体协作标准化」ANP 解决的是「跨组织智能体互联去中心化」两者定位差异很明显。如果你只关心企业内部多个 Agent 分工完成一份报表A2A 是合适的如果你的 Agent 要和一个完全陌生平台的 Agent 协作ANP 的 DID 身份方案更对路。4. ANP 协议实践身份、描述、发现三层架构怎么落地4.1 ANP 的分层设计ANPAgent Network Protocol是目前唯一一个直接宣称「目标是做智能体互联网时代 HTTP」的开源协议。它的核心思路是把智能体当成网站来设计智能体有自己的身份 ID、公开描述、可发现的入口。整个协议分为三层层级职责技术基础身份与加密通信层智能体身份认证、加密通信W3C DID去中心化标识符元协议层能力描述、接口公开JSON-LD、schema.org应用协议层发现、访问、调用DNS、搜索引擎机制第一层用 DID 解决「我是谁」基于非区块链的去中心化方案让任意两个智能体用自己的 ID 互认。第二层用 JSON-LD 和 schema.org 把智能体的能力、接口、基本信息写成结构化数据能被机器理解。第三层复用 DNS 和搜索技术理论上搜索引擎能索引全网智能体。4.2 基于 DID 的智能体身份创建ANP 的身份层目前可以通过 Python SDK 来创建和注册一个 DID 标识符。下面是一个最小示例# 安装 ANP SDKpip install anp-sdk from anp_sdk import create_agent_identity, register_agent # 第一步为智能体创建去中心化身份标识 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(登记状态:, registration.status)create_agent_identity负责生成本地密钥对和 DIDregister_agent把 DID、端点和公钥发布到 ANP 目录供其他智能体发现和验证。整个过程中密钥不上传只上传播放公钥这是 ANP 身份层区别于中心化账号体系的关键。4.3 JSON-LD 能力描述文件身份建好之后第二步是写智能体的能力描述。ANP 复用 schema.org 词汇表把智能体的能力暴露成结构化数据{ 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 和端点的对应关系。发现机制基于 DNS 和网页搜索技术其他智能体可以通过搜索引擎或者目录服务查到这份描述然后拿着 DID 建立认证。4.4 ANP 的交互流程完整走一遍从消息流程来看ANP 的交互可以拆成四步发现调用方通过目录服务或搜索引擎查找目标智能体的 JSON-LD 描述文件认证调用方发起一个 DID 认证握手双方验证身份签名协商通过元协议交换可调用的接口和权限范围调用进入应用协议层执行具体业务请求项目官方文档里给了一个很典型的用例个人助手不需要在酒店平台注册账号直接用 ANP SDK 发起一个带 DID 签名的请求酒店智能体验证签名后返回可预订房间列表整个交互里不出现传统的用户名密码。4.5 开源实操OpenManus 接入 ANP 的步骤ANP 社区已经把owl和OpenManus都接上了 ANP 协议两块代码都放 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 客户端往这个地址发请求可以验证协议栈的连通性。5. 协议选型必经之坑身份、认证、超时这类问题的排查5.1 踩坑记录MCP Server 一直报工具未注册现象自己写的 MCP Server 在 Inspector 里能看到工具但通过 Client SDK 调用时报Tool not found。原因MCP Client 端会缓存工具列表服务端更新工具但客户端未重连时函数名不匹配。解决在启动客户端之前加一段工具列表刷新逻辑强制重拉一次。常见做法是每次会话开始先执行client.list_tools()确认返回里包含最新的工具函数名。5.2 踩坑记录A2A AgentCard 端点和实际服务端口不一致现象客户端能拉到 AgentCard但发起 JSON-RPC 请求时连接被拒绝或超时。原因AgentCard 里url字段填的是公网地址实际服务监听在内网端口反向代理没有把所有路径转发对。解决先检查 AgentCard 里的url能否直接在浏览器打开再确认反向代理的路径转发规则。建议在 AgentCard 的url中显式写到完整路径不要依赖默认根路径。5.3 踩坑记录ANP DID 身份认证握手一直失败现象两个 ANP 端点互相发现成功但身份认证时签名校验不通过日志里看不到具体错误。原因DID 的密钥对或方法标识符不匹配经常是复制描述文件时把did字符串截断了或者本地密钥轮换过但目录里还是旧公钥。解决用官方 CLI 工具核对 DID方法简单直接anp-cli verify-did --did did:anp:7g3f... --endpoint https://agent.example.com/anp如果返回INVALID_SIGNATURE那基本可以确定是公钥或 DID 字符串的问题。5.4 踩坑记录ANP 请求频繁超时重试反而加重故障现象在弱网环境测试 ANP 调用请求失败后直接重试结果服务端负载飙升所有请求都失败。原因没有做超时控制和指数退避重试风暴压垮了服务端。解决客户端统一走指数退避逻辑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 避坑注意协议选型前先确认传输方式在实际选型的时候要最先确认协议运行环境。MCP 开发期走 stdio 很方便但生产环境多半要走 Streamable HTTPANP 官方仓库对网络环境有说明需要公网可达的 HTTPS 端点A2A 基本依赖企业内网已有基础设施。把这些前置条件列成清单比先选协议再补环境要稳得多。6. 把三套协议放进同一张选型表验证技巧与进阶用法6.1 一张表看清选型边界我在给团队做技术方案时一般会把协议的边界问题压缩成一张表维度MCPA2AANP核心定位模型连接工具组织内 Agent 协作Agent 跨平台互联互通中心视角以模型为中心以任务为中心以智能体为中心身份方案OAuthOAuthW3C DID 去中心化发现机制客户端硬编码AgentCard 拉取DNS 搜索引擎主动通信不支持支持支持典型场景AI 编程、工具调用企业内部多 Agent 分工跨平台酒店预订、电商协作成熟度行业事实标准刚发布迭代中项目落地中有开源案例选型判断我一般看三个问题智能体数量是否超过十个是否存在跨组织协作模型是否占主导如果第一条为否A2A 能覆盖如果第二条明显ANP 值得押注。6.2 验证协议栈连通性一条命令一个指示灯协议接完之后最怕的是「代码能跑但不知道通没通」。我习惯把一个连通性测试脚本丢进 CI 或者本地开发流程里对三个协议统一验证# 一个快速连通性验证脚本 import asyncio from anp_sdk import ANPClient async def check_agent_health(endpoint: str) - bool: client ANPClient(endpointendpoint) # 尝试发现目标能力 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 端点最核心的两件事发现服务和会话建立。能跑通说明身份、描述、通信三层都正常跑不通很大概率是 DID 注册表没生效或者 JSON-LD 描述的endpoint字段写错。6.3 一种更省事的进阶思路让 MCP 封装 ANP对存量项目来说还有一条性价比很高的路径——用 MCP 把 ANP 能力包一层。这种做法不用重写业务逻辑Anthony 团队在实践中就是这么用的现有 MCP Server 内部调用 ANP SDK对外仍然暴露 MCP 接口。好处是复用了现有 MCP 生态的客户端同时把 ANP 的跨平台身份协作能力嵌套了进来。我在自己接的项目里也踩过这个思路的坑MCP 的 stdio 传输和 ANP 的异步长连接模型混在一起会出现事件循环互相阻塞的问题。解决方案是给 MCP Server 的 tool 函数加一个异步包装器把 ANP 调用丢到独立的事件循环里运行避免阻塞 MCP 的 stdio 读写。从那以后我每次接新协议都会强制走一遍最小验证先跑通官方 demo再改业务逻辑最后才看协议兼容性。这个习惯帮我躲掉了不少协议选型的坑。希望这组从 MCP 到 ANP 的拆解能让你少走一段弯路动起手来反而比停留在概念对比更有收获。本文还有配套的精品资源点击获取