大模型技术全景(十一)：智能体通信协议 MCP、A2A 与 ANP

📚 本文收录于「流浪」的系列专栏


🐧 Linux系统	⚙️ C++
📊 数据结构与算法	🐍 Python
🔗 LangChain & LangGraph	🗄️ MySQL 数据库
🌿 Git 工具	🌐 计算机网络
🤖 LLM	💯 大厂面试、八股
📚 学习筑基专栏

🏠 博客主页：流浪｜ 📝 原创首发于 CSDN

上篇文章把一群 Agent 怎么组队协作用七种模式拆透了：顺序流水线、交接、层级主管、路由、中心化协调、去中心化对话、动态图，各管一段路。但「组队」只解决了「谁干什么」，没解决 「之间怎么说话、怎么传话」 。一个用 LangChain 写的 Agent 和一个用 CrewAI 写的 Agent，连彼此的接口长什么样都不知道，硬凑到一起就是「鸡同鸭讲」。这一篇讲清楚 Agent 之间靠什么协议互通------MCP、A2A、ANP 三套协议各自解决什么问题，以及它们脚下那层你已经熟悉的网络协议（TCP/IP、HTTP、JSON-RPC、SSE、WebSocket、Webhook、TLS、DID）到底在哪发光。

一、为什么需要通信协议

单个 Agent 再强也是「单打独斗」，多 Agent 要的是「团队作战」。但团队作战的头号障碍是各讲方言：A 用 JSON 调工具，B 用 Protobuf 发消息，C 连消息格式都没定义，三者凑一起谁也听不懂谁。结果就是效率低、无法复用、且没有任何安全与权限约束------谁都能随便调别人的工具、读别人的数据。
通信协议的作用就是那个「翻译官」：它规定消息长什么样、怎么寻址、怎么鉴权、出错怎么兜底，让不同框架、不同厂商造出来的 Agent 能安全、稳定、可扩展地互通。

网络协议与 Agent 协议的分层关系

这里必须点透一件事：Agent 协议不是从零造轮子，而是构建在经典网络协议栈之上的应用层协议。三者是分层、不是替代：

TCP/IP 解决「数据能不能传到」------提供可靠的字节流和路由，让两个进程在网里找到彼此。这是地基。
HTTP / JSON-RPC / WebSocket 解决「双方怎么对话」------请求-响应、远程过程调用、全双工双向通道。这是对话的语法。
MCP / A2A / ANP 才解决「智能体之间说什么、怎么协作」------工具调用、任务委派、身份互信。这是语义层。

一句话：先有网络协议托底，才有 Agent 协议的空间。一个 Agent 协议如果自己重造一套可靠传输，等于退回到 1980 年重写 TCP，毫无必要。这也是为什么下文每一套 Agent 协议，都得先说清楚它「跑在什么网络传输上、为什么这么选」。

没有通信协议，多 Agent 只是一群各自为战的孤岛；通信协议解决的从来不是「谁更强」，而是「能不能互操作」。

二、MCP：智能体与工具/资源的标准化连接

MCP（Model Context Protocol）由 Anthropic 推出，定位是标准化智能体与外部工具、资源、上下文之间的通信方式 。它的核心设计理念是做一个「万能适配器」：把数据库、API、文件系统、搜索引擎这些外部能力，用统一接口动态插到 Agent 上，Agent 不必为每个工具重写一套调用代码。它最大的价值是上下文注入 ------把外部数据按统一格式喂进模型的上下文窗口，让工具结果成为模型可推理的「已知信息」。

网络基础（适当引入）

MCP 把「调一个工具」封装成标准化的请求/响应，传输层直接交给成熟的网络栈：

本地场景走 stdio：Agent 把工具当作自己启动的子进程，通过标准输入/输出（stdin/stdout）用管道通信，零网络开销、零端口暴露，最安全。
远程场景走 Streamable HTTP：每个消息是一次 HTTP POST 打到同一个 MCP 端点，回包可以是单个 JSON 对象，也可以是一条「请求作用域内的 SSE 流」回传增量结果。
消息体统一是 JSON-RPC：MCP 用 JSON-RPC 2.0 编码消息，UTF-8，请求/通知/响应结构由协议统一定义。

一个容易踩坑的点：早期 MCP 有一套独立的「HTTP+SSE」传输（客户端单向收 SSE），但在现行 spec（2026-07-28 版）里它已被 Streamable HTTP 取代------后者用单次 POST + 可选 SSE 流，更简洁、更易穿透代理。面试里如果说「MCP 用 SSE 传输」，准确说法应是「远程用 Streamable HTTP，SSE 只是它回传增量结果的一种承载方式」。

MCP 解决的是「Agent 怎么用工具」，属于垂直连接（Agent 向下接外设），类比「AI 的 USB-C 接口」：插上就能用，不关心另一端是数据库还是天气 API。

三、A2A：Agent 间的通信规范

3.1 什么是 A2A 协议

A2A（Agent2Agent Protocol）最初由 Google 主导，后捐赠给 Linux 基金会，以 Apache 2.0 许可开源，技术指导委员会由 AWS、Cisco、Google、IBM、Microsoft、Salesforce、SAP、ServiceNow 等共同维护。它的目标是成为 Agent 的「通用语言」，被形容为「智能体互联网时代的 HTTP」------让用不同框架（LangGraph、CrewAI、Semantic Kernel、自研）造出来的 Agent 能互相发现、委派任务、交换结果。

A2A 里有一个关键概念 Agent Card ：用一份 JSON 文档描述这个 Agent 的技能、接口、认证方式。Client 与 Server 是相对角色------发起请求的是 Client，响应的是 Server，同一个 Agent 在不同交互里可以切换角色。

3.2 为什么需要 A2A：三大痛点

框架不兼容：LangGraph 写的 Agent 和 CrewAI 写的 Agent 接口方言不同，直接对接就是「鸡同鸭讲」。
框架锁定：业务一旦深度绑定某个 Agent 框架，未来想换技术栈就被「绑架」。
厂商壁垒：各家 Agent 各建各的协作方式，跨企业、跨平台时谁也不认识谁。

A2A 的本质，是给智能体之间立一套「TCP/IP 级别」的互联标准------不关心你 internal 怎么想，只规定对外怎么握手、怎么传话。

3.3 A2A 核心组件

A2A 的交互由几个基本对象拼成：

A2A Server / A2A Client：服务端与客户端，角色相对。
Agent Card：能力名片（JSON），声明技能、接口、认证要求。
Task：一次协作的任务单元，有完整生命周期。

Artifact：任务的最终产出物，区别于对话用的 Message。

Messages / Part：消息与消息内的最小内容单元（文本、文件、结构化数据）。
Notifications ：进度与状态通知。

3.4 工作过程：发现 → 认证 → 通信与任务执行 → 完成

发现：Client 向 Server 的标准 HTTP 端点（如 /.well-known/agent-card.json）发一次 GET，拿到对方的 Agent Card，知道它「能干什么、接口在哪、要什么认证」。

认证：按 Agent Card 声明的方式（OAuth / API Key 等）完成鉴权，遵循最小权限------只给本次任务需要的那点权限。

通信与执行 ：通过 SendMessage / SendStreamingMessage 发起或继续任务。A2A 区分无状态消息 （一问一答）和有状态任务 （跨多轮、长时运行）。任务有清晰的生命周期：submitted → working → input-required → completed / failed / canceled，用 contextId 把多轮交互归到同一上下文里。

进度获取有三条路径，对应不同场景：

流式（SSE）：服务端通过 Server-Sent Events 持续往客户端推状态/片段。
轮询（tasks/get）：客户端定时查任务状态，适合不能长连的场景。
推送（Webhook） ：客户端先注册一个回调 URL，服务端在状态重大变化时主动 POST 过去，适合跑几小时甚至几天的长任务。

网络基础（适当引入）

A2A 整套流程全程跑在 HTTP/HTTPS 上，用 JSON-RPC 2.0 做消息信封------请求、响应、通知都有统一结构，任何语言都能手搓，调试时直接 curl 就能打，不需要生成客户端桩代码。「发现」就是一次普通的 HTTP GET；「实时进度」用 SSE （服务端→客户端单向推流）而不是 WebSocket，原因在于：Agent 任务的实时需求几乎全是「服务端推状态/片段给客户端」这一个方向，SSE 的单向模型刚好契合，且它走标准 HTTP，穿代理、过网关的兼容性远好于 WebSocket（WebSocket 是独立协议，常被网关、负载均衡特殊对待，运维成本高）。长时任务则让服务端用 Webhook （服务端→服务端回调）反向通知，把「推送」当作信号、客户端再按需 tasks/get 拉全量。

3.5 A2A 与 MCP 的关系

两者不是对手，是互补：

MCP = Agent 与外部工具（偏内部事务，本地走 stdio、远程走 Streamable HTTP）。
A2A = Agent 与 Agent（更高层的集成，偏 HTTP/JSON-RPC 之上的任务委派与协作）。

一个主 Agent 可以一边用 MCP 调数据库、一边用 A2A 把子任务委派给另一个专业 Agent------一个负责「用工具」，一个负责「找人帮忙」，处在系统的不同层次。

A2A 把「Agent 互操作」标准化成 HTTP 之上的 JSON-RPC，用 SSE 解决流式、用 Webhook 解决长时推送；它与 MCP 是「水平通信」对「垂直连接」的互补关系，谁也替代不了谁。

四、ANP：开放互联网上的智能体协作网络

4.1 什么是 ANP 协议

ANP（Agent Network Protocol）是一个开源协议，愿景同样是「智能体互联网时代的 HTTP」，但出发点和 MCP/A2A 不同：它要的是为数十亿个、跨组织、互不认识 的智能体，建一张开放、安全、高效的协作网络。如果说 MCP 解决「用工具」、A2A 解决「熟人/同生态内协作」，ANP 解决的是「开放网络里两个陌生 Agent 怎么互信、怎么对接」。

官网：https://agent-network-protocol.com/

协议内容： https://agent-network-protocol.com/specs/white-paper

4.2 ANP 三层架构

ANP 用三层架构把「找谁、信谁、怎么谈」一次解决：

身份与加密通信层 ：基于 W3C 的 DID （去中心化标识符，ANP 用 did:wba 方法）做身份，配合 ECDHE 端到端加密 做链路保护。每个智能体拥有独一无二的 DID，像数字世界的护照，能独立验证对方身份，不依赖任何第三方授权服务器。
元协议层 ：负责两个 Agent 建立连接后，动态协商到底用哪种通信方法、格式、版本------甚至可以用自然语言商量、再生成代码执行。让网络具备自适应、自协商能力，不用事前约定死协议。
应用协议层：基于语义网技术（JSON-LD）实现能力描述与发现------Agent 通过标准化的描述文档（ADP，Agent Description Protocol）公布自己的功能清单和接口，类似「交换电子名片」，让对方不仅收到数据，还理解数据的语义。

一个具体例子：私人旅行助理「小旅」要订酒店，先通过身份层用 DID 验证酒店预订系统「小酒」的身份，再在元协议层协商好交互格式，最后在应用层用 ADP 读懂小酒提供的房型与价格接口并完成预订。

网络基础（适当引入）

ANP 与 MCP/A2A 最大的不同，是把「身份与加密」从应用约定提升为一层独立、可移植的基础设施 。传统 HTTPS 的信任靠 CA 证书 + 中心化域名（你得相信证书机构、相信 DNS），ANP 把这替换为 W3C DID 的去中心化身份信任 ------身份由智能体自己生成、点对点验证，没有中心机构能卡脖子；链路加密则依托 TLS 类机制（ANP 的基础层直接复用 HTTP、CA、DNS、CDN、TLS 等开放互联网设施），保证传输不被窃听。换句话说，ANP 不是不要 TLS，而是把「谁是我、我信谁」这件事，从「靠中心发证件」升级成了「靠密码学自证」。

4.3 ANP 与 MCP、A2A 的比较

把三者摆在一起看全貌：

协议	全称	核心定位	类比	身份/发现模型
MCP	Model Context Protocol	Agent ↔ 工具/资源	USB-C 接口	客户端-服务器，无强制身份
A2A	Agent2Agent Protocol	Agent ↔ Agent（同/跨生态）	智能体间 HTTP	Agent Card 发现，OAuth/API Key
ANP	Agent Network Protocol	开放网络的 Agent 互信协作	智能体互联网 HTTP	W3C DID 去中心化身份

三者不是竞争关系，而是协作栈上的不同层 ：MCP 是「手」（动手做）、A2A 是「嘴」（找人帮忙）、ANP 是「眼」（在茫茫网络里找到并信任对的人）。真实系统里，一个 Agent 可能同时用 MCP 接工具、用 A2A 派活、用 ANP 在开放网络发现陌生协作者。

ANP 用 DID 把身份去中心化，用三层架构把「找谁、信谁、怎么谈」一次性解耦，最适合跨组织、开放、要隐私的协作场景；代价是生态尚早（实验阶段）、实现复杂度高，短期内难和已成事实标准的 MCP/A2A 正面拼落地。

五、面试题

5.1 推导题

【推导】从「单 Agent 上下文过载 + 多 Agent 协作」出发，推导为什么规模化必须依赖标准化通信协议；并进一步推导：为什么这些 Agent 协议普遍选择建在 HTTP / JSON-RPC 之上，而不是自定义一套二进制协议？

推导链：

单 Agent 受上下文窗口物理上限约束，长任务易遗忘/幻觉（见大模型技术全景(六)：AI 的"逐字接龙"------Token 与自回归生成背后的真相）→ 规模化要靠多 Agent 分工，每个 Agent 只背自己那点上下文。
多 Agent 一旦变多，若每个 Agent 用自己的私有消息格式，对接成本随组合数量爆炸，「会干活」却「说不到一块」→ 必须有一套标准化通信协议把「消息格式、寻址、鉴权、兜底」统一，否则多 Agent 只是一个个孤岛，谈不上协作。
协议要标准化，第一反应是「传什么」；但更底层的问题是「怎么传」。如果自造一套二进制传输，等于重造可靠传输、重造路由、重造鉴权------成本高且和现有基础设施不兼容。
既有的 TCP/IP 已解决可靠字节流与路由，HTTP 已解决请求-响应与穿透防火墙，JSON-RPC 已解决结构化的远程调用。Agent 协议直接架在这套成熟网络栈之上（MCP 用 Streamable HTTP + JSON-RPC，A2A 用 HTTP + JSON-RPC 2.0 + SSE/Webhook，ANP 复用 HTTP/TLS/DNS），好处是：零额外基础设施、天然防火墙友好、全生态工具（curl、网关、负载均衡）直接复用、跨语言零门槛。所以「建在 HTTP/JSON-RPC 之上」不是偷懒，而是工程上最优选------把精力留给真正属于 Agent 的语义层（工具调用、任务委派、身份互信）。

5.2 真题

【真题·转述自《A2A 协议实战：Agent Card、Task 与多 Agent 编排》】 A2A 为什么选 SSE 而不是 WebSocket 做流式推送？Agent Card 起什么作用？

思路：SSE 是「服务端→客户端」单向推流，恰好匹配 Agent 任务「服务端推状态/片段」这一唯一方向的需求；且 SSE 走标准 HTTP，穿代理、过网关的兼容性远好于 WebSocket，调试直接 curl 就能打。Agent Card 是 Agent 的「能力名片」（JSON），声明技能、接口、认证方式，供其他 Agent 在 /.well-known/agent-card.json 这类标准端点发现------没有它，跨框架的 Agent 连对方「能干什么、怎么调」都无从知晓。

【真题·转述自《A2A、AG UI、SSE、WebSockets 协议对比与关系解析》】 MCP 和 A2A 的核心区别是什么？分别解决什么问题？

思路：核心区别在「连接对象」。MCP 面向 Agent ↔ 工具/资源，是垂直连接，类比 USB-C，解决「Agent 怎么用工具/取数据」；A2A 面向 Agent ↔ Agent，是水平通信，类比智能体间的 HTTP，解决「多个 Agent 怎么发现、沟通、委派任务」。选型判断：先问系统要连的是「工具」还是「智能体」------工具调用优先 MCP，多智能体协作优先 A2A，两者可同系统并存。

【真题·转述自《Agent Network Protocol (ANP)》官方文档】 ANP 用 DID 解决什么？三层架构各自职责？与传统 HTTPS 信任模型有何不同？

思路：DID 提供去中心化、自主权的 Agent 身份，让两个陌生智能体无需中心 CA/域名即可点对点互验。三层：身份与加密通信层（W3C DID + 端到端加密，解决「我是谁、怎么安全通信」）、元协议层（动态协商通信方法/格式/版本）、应用协议层（ADP 描述能力 + 发现机制，语义网交互）。传统 HTTPS 信任靠中心化 CA 证书 + 域名，ANP 信任靠 DID 文档密码学自证------把「身份与加密」从应用约定提升为独立基础设施。

💬 结语： 一个 Agent 会干活了，一群 Agent 要组队了，但组队的前提是「能对话」------这正是通信协议的活。MCP 把「Agent 怎么用工具」标准化成垂直连接（类比 USB-C），A2A 把「Agent 怎么找人、怎么协作」标准化成水平通信（HTTP 上的 JSON-RPC，用 SSE 推流、Webhook 兜底），ANP 再把「身份与信任」去中心化（W3C DID + 三层架构），让开放网络上的陌生智能体也能互信协作。三者都建在 TCP/IP、HTTP、JSON-RPC 这些成熟网络协议之上，而不是另起炉灶------复用网络栈，才有生态互通的底气。MCP 是手、A2A 是嘴、ANP 是眼，互补而非竞争。哪一层你以前没想清楚，评论区聊聊。觉得有收获，点个赞再走，关注流浪，大模型技术全景持续更新。