MCP vs A2A vs ANP：AI Agent协议详解

什么是AI Agent协议？为什么重要？

AI Agent协议是定义Agent如何连接工具、相互通信以及在网络中发现同伴的开放标准。没有这些协议，每个集成都是一个定制的API封装。有了它们，你可以更换模型或工具，一切照常运行。

对于构建Agent系统的开发者来说，三个协议最为重要：MCP（Model Context Protocol）、A2A（Agent-to-Agent Protocol）和ANP（Agent Network Protocol）。它们不是竞争关系，而是一个技术栈中的不同层。

MCP将Agent连接到工具和数据。A2A让Agent将任务委派给其他Agent。ANP处理跨网络发现。如果你在VPS上自托管Agent，了解每个协议的位置可以避免简单场景的过度设计或复杂场景的设计不足。

本文提供的是思维模型。没有代码，只是你在开始构建之前需要的地图。

什么是MCP（Model Context Protocol）？

MCP是一个开放标准，最初由Anthropic创建，定义了AI Agent如何连接外部工具和数据源。MCP服务器向嵌入在AI应用中的MCP客户端公开能力。可以把它理解为AI的USB接口：任何Agent和任何工具之间的统一接口。Anthropic于2025年12月将MCP捐赠给Linux Foundation下的Agentic AI Foundation（AAIF）。

在MCP之前，将AI模型连接到数据库意味着编写一个定制集成。连接到第二个数据库就要再写一个。MCP用通用协议替代了这种模式。为你的数据库构建一个MCP服务器，每个兼容MCP的Agent都能使用它。

MCP如何工作？

MCP定义了三个角色：

Host：AI应用（Claude Desktop、Cursor、你的自定义应用）。它管理一个或多个MCP客户端。
Client：Host内部的连接器，与一个MCP服务器保持1:1连接。
Server：轻量级服务，向客户端公开工具、资源和提示。

通信使用JSON-RPC 2.0，通过以下两种传输方式之一：

stdio：标准输入/输出。适合在同一台机器上运行的本地服务器。Host将服务器作为子进程启动。
Streamable HTTP：基于HTTP的传输，让MCP服务器可以作为远程服务运行。客户端通过HTTP POST发送JSON-RPC请求。服务器可以流式返回响应。这使得在VPS上运行MCP服务器并远程连接成为可能。

旧的SSE（Server-Sent Events）传输仍然可用，但正被Streamable HTTP取代。后者支持无状态操作和水平扩展，无需粘性会话。

MCP服务器公开三种类型的原语：

原语	功能	控制方
Tools	模型可以调用的函数（查询数据库、发送邮件、运行脚本）	模型驱动（LLM决定何时调用）
Resources	Agent可以读取的数据（文件、数据库记录、API响应）	应用驱动（Host决定公开什么）
Prompts	模板消息和工作流	用户驱动（用户从可用提示中选择）

连接是有状态的。客户端和服务器在初始化期间协商能力，然后通过持久连接交换消息。服务器还可以请求sampling（让LLM生成文本）和elicitation（向用户请求输入），这使得递归Agent行为成为可能。

2026年MCP生态系统状况如何？

MCP是2026年AI工具的默认集成协议：

Python和TypeScript的SDK月下载量超过9700万
10,000+公开MCP服务器在生产环境运行
被所有主要AI平台采用：Claude、ChatGPT、Gemini、Copilot、Cursor、VS Code
由Linux Foundation下的AAIF管理，由Anthropic、OpenAI和Block联合创立
当前规范版本：2025-11-25

2026年路线图专注于让Streamable HTTP在大规模场景中达到生产就绪状态：无状态请求处理、简化的水平扩展，以及注册中心无需连接即可发现服务器能力的标准方法。

什么是A2A（Agent-to-Agent Protocol）？

A2A（Agent-to-Agent Protocol）是一个由Google最初创建的开放协议，标准化了AI Agent之间的通信和协作方式。一个Agent通过JSON-RPC over HTTP向另一个Agent发送任务。接收方发布一个Agent Card，描述其能力、认证要求和端点URL。A2A管理任务生命周期、结果流式传输和长时间运行操作的推送通知。

MCP将Agent连接到工具。A2A将Agent连接到其他Agent。MCP服务器是透明的：你能看到它们做什么。A2A Agent是不透明的。调用方Agent不知道也不需要知道远程Agent内部运行什么模型、框架或逻辑。它发送任务，获取结果。

A2A如何工作？

A2A定义了三个角色：

User：请求工作的人类或自动化服务。
A2A Client：代表用户发送任务的应用。
A2A Server：公开HTTP端点的远程Agent。作为黑盒运行。

Agent Card是发现机制。每个A2A服务器发布一个JSON文档（通常在/.well-known/agent-card.json），描述：

Agent身份（名称、描述、提供者）
服务端点URL
支持的能力（流式传输、推送通知）
可用技能及描述
认证要求
可选的数字签名用于验证

Task（任务）是工作单元。每个任务有唯一ID，并经历一个生命周期：

submitted → working → completed
                   → failed
                   → canceled
                   → rejected
           → input-required (多轮：Agent需要客户端提供更多信息)

消息包含Parts：文本、文件引用或结构化JSON数据。任务输出称为Artifacts，同样包含Parts。Agent可以在单次响应中返回代码文件、文本摘要和JSON报告。

A2A支持三种通信模式：

Request/Response：客户端发送任务，用GetTask轮询状态。
Streaming（SSE）：通过持久HTTP连接进行实时增量更新。客户端调用SendStreamingMessage，在Agent工作时接收事件。
Push Notifications（Webhooks）：对于长时间运行的任务，Agent将状态更新POST到客户端注册的Webhook URL。

所有通信使用JSON-RPC 2.0 over HTTPS。版本0.3添加了gRPC支持和签名Agent Card。当前版本是A2A v1.0.0。

A2A和ACP是如何合并的？

IBM于2025年3月推出了Agent Communication Protocol（ACP），为其BeeAI平台提供支持。Google在下个月发布了A2A。两个协议解决同一个问题：Agent间通信。

2025年8月，Linux Foundation宣布ACP将合并到A2A中。IBM的ACP团队在Kate Blair的带领下加入了A2A技术指导委员会，与Google、Microsoft、AWS、Cisco、Salesforce、ServiceNow和SAP并列。BeeAI平台从ACP切换到A2A，ACP的专项开发停止。

如果你之前在单独评估ACP，停下来。答案是A2A。

什么是ANP（Agent Network Protocol）？

ANP（Agent Network Protocol）是一个点对点协议，让AI Agent可以在开放网络中相互发现和通信，无需中央权威。与MCP的客户端-服务器模型和A2A的客户端-服务器任务委派不同，ANP将每个Agent视为平等的对等方。它使用W3C去中心化标识符（DIDs）作为身份标识，JSON-LD进行数据交换，并包含一个元协议层，Agent在其中协商通信方式。

ANP解决的问题与MCP和A2A不同。那些协议假设你知道要与哪个服务器或Agent通信。ANP回答的问题是：一个Agent如何找到它从未交互过的其他Agent，跨越组织边界，没有中央目录？

ANP与A2A有何不同？

ANP有三层架构：

**第1层：身份和加密通信。**每个Agent获得一个W3C去中心化标识符，使用did:wba（Web-Based Agent）方法。每个DID映射到一个HTTPS托管的DID文档，因此身份解析使用现有的Web基础设施。两个Agent可以相互验证身份并建立加密通道，无需中央权威。

**第2层：元协议。**Agent动态协商通信协议。两个Agent不需要支持相同的固定协议，而是以结构化形式交换提议的要求，商定协议，然后使用该协议通信。这使ANP能够适应A2A的固定JSON-RPC方法无法处理的场景。

**第3层：应用协议。**Agent描述使用JSON-LD，链接到schema.org本体。发现有两种方式：

主动发现：查询域的/.well-known/agent-descriptions端点。
被动发现：Agent向索引服务注册，索引服务爬取和编目描述。

ANP与A2A的架构对比：

方面	A2A	ANP
拓扑	客户端-服务器	点对点
身份	Agent Card（自发布JSON）	W3C DIDs（去中心化、可验证）
发现	已知URL（`/.well-known/agent-card.json`）	去中心化索引 + well-known端点
协议灵活性	固定（JSON-RPC 2.0）	元协议协商
数据格式	JSON Parts（文本、文件、结构化数据）	JSON-LD（语义链接数据）

当前状态：ANP仍处于提案和早期开发阶段。它有一个GitHub仓库和W3C社区组白皮书，但尚无生产级SDK或广泛采用。规范不在AAIF管理之下。

MCP、A2A和ANP如何对比？

三个协议在设计Agent系统时需要关注的维度上的对比：

	MCP	A2A	ANP
解决的问题	Agent到工具的连接	Agent到Agent的任务委派	跨网络Agent发现和通信
架构	客户端-服务器（host → client → server）	客户端-服务器（client → 远程agent）	点对点（agent ↔ agent）
传输	stdio、Streamable HTTP	HTTPS（JSON-RPC 2.0）、SSE、gRPC	HTTPS，可通过元协议协商
身份模型	服务器身份隐含（由host配置）	Agent Card（自发布JSON）	W3C DIDs（`did:wba`）
数据格式	JSON-RPC 2.0	JSON-RPC 2.0带Parts（文本、文件、结构化）	JSON-LD（语义链接数据）
发现	手动配置或注册中心查询	`/.well-known/agent-card.json`	DID解析 + 去中心化索引
治理	AAIF / Linux Foundation	AAIF / Linux Foundation	W3C社区组（独立）
规范版本	2025-11-25	v1.0.0	白皮书阶段
成熟度	生产环境（SDK月下载量97M+）	生产环境（v1.0.0，主要厂商SDK）	早期开发（无生产级SDK）
使用场景	让Agent访问数据库、API、文件	让Agent将工作委派给专业Agent	让Agent在开放互联网中相互发现

这些协议如何协同工作？

这些协议不是替代关系，而是层级关系。看一个具体例子。

假设你在VPS上运行一个编程Agent。它需要：

从Git仓库读取文件
查询项目数据库获取Schema信息
请求一个独立的代码审查Agent检查它的工作
找到客户基础设施团队运行的部署Agent

协议如此分层：

┌─────────────────────────────────────────────────────────┐
│                    你的VPS                               │
│                                                         │
│  ┌──────────────┐    MCP     ┌───────────────────────┐  │
│  │              │◄──────────►│ MCP Server: Git tools  │  │
│  │  编程        │            └───────────────────────┘  │
│  │  Agent       │    MCP     ┌───────────────────────┐  │
│  │  (Host)      │◄──────────►│ MCP Server: DB schema  │  │
│  │              │            └───────────────────────┘  │
│  │              │                                       │
│  │              │    A2A     ┌───────────────────────┐  │
│  │              │───────────►│ Review Agent (A2A)     │  │
│  └──────┬───────┘            └───────────────────────┘  │
│         │                                               │
└─────────┼───────────────────────────────────────────────┘
          │
          │  ANP（跨网络发现）
          ▼
┌─────────────────────┐
│ 客户的部署Agent      │
│（通过DID解析发现）    │
└─────────────────────┘

第1层（MCP）：编程Agent使用MCP客户端连接本地MCP服务器，进行Git操作和数据库查询。这些是工具集成。Agent调用函数并读取数据。

第2层（A2A）：编程Agent将代码审查委派给同一服务器（或不同服务器）上的独立审查Agent。它通过A2A发送任务，审查Agent异步工作并流式返回结果。编程Agent不知道审查Agent使用什么模型或框架。

第3层（ANP）：编程Agent需要找到一个从未交互过的部署Agent，由另一个组织运行。ANP基于DID的发现定位该Agent，验证其身份，并协商通信协议。

对于今天大多数自托管场景，MCP就够了。当你有多个需要协作的专业Agent时，添加A2A。ANP目前对生产环境还没有实际用途，但当Agent生态系统跨越组织边界时会变得重要。

应该使用哪个协议？

从能解决问题的最简单协议开始。只在遇到限制时才添加新层。

决策指南：

你的Agent需要访问工具、数据库或API吗？ 是 → 实现MCP。为你的数据源构建或安装MCP服务器。这覆盖了80%的Agent集成需求。
你有多个Agent需要相互委派任务吗？ 是 → 添加A2A。为每个Agent发布Agent Card。使用A2A进行任务委派和结果流式传输。否 → 不需要A2A。如果只有一个Agent通过MCP调用API，那就够了。
你的Agent需要跨组织边界发现未知Agent吗？ 是 → 等生产级SDK可用时评估ANP。目前可以用手动注册中心或共享的A2A Agent目录解决。否 → 暂时跳过ANP。

常见模式：

场景	需要的协议
单Agent + 工具（大多数项目）	仅MCP
同一服务器上多个专业Agent	MCP + A2A
跨组织Agent协作	MCP + A2A + ANP（成熟后）
Agent市场 / 开放发现	A2A + ANP

如果你刚开始在VPS上使用AI Agent，从MCP开始。让一个Agent连接一个工具。让它跑起来。然后根据需求增长来扩展架构。

每个协议有什么安全风险？

每个协议打开不同的攻击面。如果你自托管Agent，以下是需要关注的威胁。

协议	威胁	后果	缓解措施
MCP	服务端请求伪造（SSRF）	恶意提示诱骗Agent调用MCP工具，向内部服务（元数据端点、数据库、管理面板）发送请求。	在隔离的网络命名空间中运行MCP服务器。用防火墙规则限制出站连接。在服务端验证工具输入。
MCP	不可信的工具描述	MCP工具注释（描述、参数Schema）来自服务器。被入侵的服务器可以对工具功能撒谎来操纵LLM。	只连接你控制或信任的MCP服务器。审查工具描述。MCP规范明确标记工具注释为不可信。
A2A	Agent冒充	没有签名的Agent Card，攻击者可以在已知URL发布假Agent Card，拦截发给合法Agent的任务。	使用A2A的Agent Card数字签名功能（v0.3添加）。发送任务前验证签名。固定已知Agent端点。
A2A	任务数据泄露	任务可能包含敏感数据（代码、凭证、业务逻辑）。如果远程Agent被入侵，数据就会泄露。	在应用层加密敏感任务数据。在Agent之间使用双向TLS。最小化任务中发送的数据。
ANP	DID信任引导	`did:wba`方法依赖HTTPS托管的DID文档。如果域被入侵，该域上所有Agent身份都被入侵。	为Agent身份使用独立域。监控DID文档变更。对已知Agent实施DID文档固定。
ANP	元协议滥用	协商层可能被利用来诱骗Agent使用不安全或恶意的通信协议。	将元协议协商限制在已知协议的白名单内。记录和审计所有协议协商。

完整的Agent服务器安全加固指南参见。

治理走向何方？

MCP和A2A都在**Agentic AI Foundation（AAIF）**之下，属于Linux Foundation。AAIF于2025年12月由三个联合创始人成立：Anthropic、OpenAI和Block。Google、Microsoft、AWS、Bloomberg和Cloudflare作为白金会员加入。没有任何单一厂商控制协议方向。

AAIF还托管了goose（Block的开源Agent框架）和AGENTS.md（OpenAI为AI Agent提供项目特定指导的标准）。

ANP通过W3C社区组独立治理。它不属于AAIF。ANP最终加入AAIF还是保持独立，将影响其采用轨迹。

治理分裂有一个实际影响：MCP和A2A将在协调管理下共同演进。ANP将按自己的时间表演进。如果你在做架构决策，MCP和A2A的治理风险更低。