Agents 互联！A2A/MCP/ANP/ACP 四大协议详解，还有一张看不见的攻击面地图！

admin@yesmiracle.net (万戈) — Sun, 26 Jul 2026 00:00:00 +0000

如果你关注 AI Agent 生态，过去一年半你一定被三个字母的协议缩写轰炸过：MCP、A2A、ACP、ANP、AGORA……

坦白说，我刚接触时也是一脸懵——它们到底有什么不同？是不是互相竞争？选哪个才对？

这个问题的答案其实很简单：它们不是「哪个更好」的关系，而是「不同层」的关系。

打个比方：如果把多 Agent 系统想象成一个软件公司——

MCP 是员工和工具的关系（我怎么用数据库、怎么调 API）
A2A 是员工和员工的关系（项目经理怎么把任务派给你）
ANP 是公司和公司的关系（跨组织怎么协作）
ACP 曾经是个独立方案，现在基本被 A2A 吸收了

这篇文章会带你从零理清 Agent 通信协议的版图，并且——作为一个做了 AI Agent 攻击面全景的人——我还会聊聊那些协议文档里不会写的安全隐患。

为什么需要 Agent 通信协议？

先把时间拨回 2024 年底。

当时的主流 AI 应用还是「一个模型 + 一个 Chat UI」的形态。Agent 这个概念虽然火，但大多数 Agent 都是单兵作战——一个 Agent 调几个工具，完成任务。

到了 2025-2026 年，情况变了。企业开始部署 多 Agent 系统：一个采购 Agent、一个库存 Agent、一个物流 Agent，它们需要协作完成「帮用户下单」这么一件简单的事。

问题来了：这三个 Agent 可能是不同团队用不同框架开发的。采购 Agent 用的是 LangGraph，库存 Agent 用的是 Google ADK，物流 Agent 是 Claude Code 写的脚本……没有统一协议，它们根本没法对话。

这就是 Agent 通信协议要解决的核心问题。

五大协议速览：一张表看懂

要素	MCP	A2A	ANP	ACP	AGORA
创造者	Anthropic（2024.11）	Google（2025.4）	社区（2024-2025）	IBM（2024）	社区
治理	Linux Foundation	Linux Foundation	社区	Linux Foundation（已合并）	社区
定位	Agent → 工具	Agent ↔ Agent	去中心化 Agent 网络	企业消息（已并入 A2A）	自然语言元协议
消息格式	JSON-RPC 2.0	JSON-RPC 2.0	JSON-LD + DID	Multipart MIME	NL 指令
发现机制	手动/静态配置	Agent Card（.well-known）	DID + DPKI	注册中心	无标准化
传输	HTTP/SSE	HTTP/SSE/gRPC	HTTPS P2P	REST + 消息队列	LLM 推理
安全模型	OAuth 2.1 + PKCE	OAuth 2.0/mTLS/OIDC	DPKI 零信任	ACL + Broker auth	隐式信任
容错	低（依赖中心服务）	中（Peer reconnection）	高（P2P 冗余）	中高（Broker 集群）	中（依赖 LLM）

逐个拆解：每个协议做什么

MCP：Agent 的「USB-C 接口」

MCP（Model Context Protocol）是四个协议中最早、最成熟的一个。它的定位非常清晰：让 Agent 能调用外部工具。

一个 Agent 想查数据库、发邮件、读文件，不需要为每个工具写自定义集成代码，只要工具暴露一个 MCP Server，Agent 就能通过标准化的 JSON-RPC 调用它。

MCP 定义了三种核心原语：

Tools：可调用的函数，有类型化的输入输出 schema
Resources：只读数据端点（文件、数据库行、API 响应）
Prompts：可复用的提示模板

2024 年刚发布时 MCP 还是个简陋的协议，到 2025 年底的 spec（2025-11-25）已经相当成熟，加入了 Streaming、Sampling（服务端主动发起 LLM 推理请求）、Tool Use 支持等关键能力。

典型场景：Cursor/Claude Code 里 Agent 调 MCP Server 查询数据库、读取文件、操作 GitHub。

A2A：Agent 的「协作框架」

Google 在 2025 年 4 月发布的 A2A（Agent-to-Agent Protocol），是真正意义上的「Agent 对 Agent」通信协议。

A2A 的核心设计理念是「不透明协作」（opacity）——Agent 之间通过声明能力来合作，但不需要暴露内部推理过程、记忆或工具实现。

A2A 有四个核心组件：

Agent Card：每台 Agent 的「数字名片」，是一个 JSON 文档，声明了 Agent 的名称、描述、能力列表、支持的认证方案等。Agent Card 通常放在 /.well-known/agent-card.json，供其他 Agent 发现。

{
  "name": "库存管理Agent",
  "description": "管理商品库存和库存水平",
  "url": "https://agent.example.com/",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "check_stock",
      "name": "查询库存",
      "description": "查询任意商品的当前库存"
    }
  ],
  "securitySchemes": {
    "oauth2": {
      "type": "oauth2",
      "flows": {
        "clientCredentials": {
          "tokenUrl": "https://auth.example.com/token"
        }
      }
    }
  }
}

Task：任务单元，定义了请求者（Client Agent）和工作者（Remote Agent）之间的工作契约。任务有完整的状态机：submitted → working → completed/failed/canceled，还支持 input_required（需要用户输入）和 auth_required（需要凭证交接）等中间状态。

Message & Part：消息体被拆分成「Part」，每个 Part 可以有不同的媒体类型（text、image、audio 等），支持多模态通信。

Transport：支持三种传输绑定——JSON-RPC over HTTPS（默认）、gRPC、HTTP+REST。流式更新用 SSE，长任务用 Webhook（Push Notification）。

A2A v1.0 在 2026 年初正式发布，现已托管到 Linux Foundation，拥有 50+ 企业合作伙伴包括 Salesforce、SAP、ServiceNow、Workday 等。IBM 的 ACP 在 2025 年 8 月宣布并入 A2A，基本宣告了 A2A 在企业级 Agent 协作领域的领先地位。

典型场景：一个「采购 Agent」发现库存不足，通过 A2A 把补货任务委派给「供应商 Agent」。「供应商 Agent」执行完后，通过 A2A 返回结果。

ANP：去中心化的 Agent 互联网

ANP（Agent Network Protocol）是社区驱动的协议，目标更大——它想做一个去中心化的 Agent 网络。

如果说 A2A 是企业内部或跨企业的 Agent 协作协议，ANP 想做的是类似「Agent 版的互联网」：任何 Agent 可以不需要中心化注册中心就能发现、认证、通信。

ANP 的架构分三层：

身份层：基于 DID（去中心化标识符）和 DPKI，每个 Agent 有密码学身份，不需要 CA
元协议层：动态协商通信协议——两个 Agent 可以先握手，再决定用什么协议说话
应用层：基于语义的能力描述（JSON-LD）

ANP 的容错性极好——因为它用 gossip 协议广播发现消息，没有单点故障。但代价是延迟较高，不适合对实时性要求高的场景。

典型场景：IoT 场景中，数以万计的 Agent 设备自动发现和协作，没有中央服务。

ACP 和 AGORA

ACP（Agent Communication Protocol） 是 IBM 在 2024 年推出的协议，定位很务实：企业级、可靠消息、多模态。ACP 的设计基于成熟的 MIME 标准和消息队列（MQTT/AMQP/Kafka），在金融、保险等对消息可靠性要求极高的行业有一定市场。但 2025 年 8 月 IBM 宣布将 ACP 的核心概念和技术合并到 A2A 中，ACP 不再作为独立协议发展。

AGORA 比较特殊——它不是一个标准化的协议，而是一套基于自然语言的「元协议」。Agent 之间不用严格的 JSON schema 约束，而是用自然语言指令直接对话。好处是灵活，坏处是依赖 LLM 的能力和安全加固。适合需要高度协商能力的场景（如商务谈判 Agent），但离生产级还有距离。

常见实战场景

场景一：AI 编程助手

一个 AI 编程 Agent（Claude Code 或 Copilot）需要：

通过 MCP 读取代码仓库、查询数据库 schema、调 Git API
通过 A2A 把代码审查任务委派给另一个专门做安全审查的 Agent
安全审查 Agent 审查完后，通过 A2A 返回漏洞报告

场景二：企业客服升级

某电商公司的客服系统：

下单 Agent：通过 MCP 访问订单数据库
库存 Agent：通过 MCP 查询 WMS 系统
物流 Agent：通过 MCP 调用快递 API
当用户问「我的单为什么还没发货」：下单 Agent 通过 A2A 向库存 Agent 查询备货状态，再向物流 Agent 查询配送信息，最后汇总给用户

场景三：供应链跨企业协作

A 公司的采购 Agent 通过 A2A 发现 B 公司的供应商 Agent，查询原材料报价、库存量和交货时间，然后通过 A2A 发起采购订单。B 公司的物流 Agent 接单后，通过 ANP 在物流联盟网络中寻找最便宜的运输方案。

场景四：企业内部安全编排

一个 SOC（安全运营中心）的多个 Agent：

威胁检测 Agent：通过 MCP 读 SIEM 数据
漏洞扫描 Agent：通过 MCP 调扫描器
当威胁检测 Agent 发现可疑行为，通过 A2A 通知漏洞扫描 Agent 做针对性扫描，再通过 A2A 通知隔离 Agent 执行隔离操作

安全隐患：协议文档不会告诉你的五件事

这是我做 OWASP Agentic Top 10 解读时反复强调的一点：任何通信协议在引入便利性的同时，都打开了新的攻击面。A2A 和 MCP 也不例外。

1. Agent Card 注入攻击

Agent Card 是 A2A 的核心发现机制。但协议的 Agent Card 签名是可选的（虽然 spec 推荐了 JWS 签名，但没强制）。

这意味着：攻击者可以伪造一个 Agent Card，声明自己「精通库存管理」，但实际 Skill Description 里塞了 prompt injection payload。Client Agent 在读取这个描述后，会被注入恶意指令。

真实案例：2025 年 arXiv 上有人发表了针对 Agent Card 的攻击论文，展示了如何通过精心构造的 skill description，让 orchestrator Agent 执行非预期的操作。

防御：强制 Agent Card 签名验证、用 DNSSEC 保护发现过程、对 Card 内容做注入检测。

2. 凭证代理泄漏（Credential Delegation Leak）

A2A 的 auth_required 状态设计上是为了在任务执行过程中实现凭证交接。但问题在于：Agent 不是人类，它的凭证生命周期和人类完全不同。

如果一个 Client Agent 把自己的 OAuth token 委派给了 Remote Agent，而这个 Remote Agent 是恶意的或被攻陷的——这个 token 可以被用来冒充 Client Agent 做其他操作。

防御：短生命周期 token（TTL < 15 分钟）、作用域声明、每次任务单独授权而非会话级委派。

3. Webhook SSRF

A2A 的 Push Notification 机制允许 Client Agent 注册一个 Webhook URL，供 Remote Agent 在任务完成后回调。

攻击者可以注册一个内网地址（如 http://169.254.169.254/latest/meta-data/）作为 Webhook，诱导 A2A Server 向该地址发起请求，获取云实例的元数据（即经典的 SSRF 攻击）。

防御：Webhook URL 域名白名单、域所有权验证（challenge-response）、网络层封禁内网 IP 和元数据服务地址。

4. Replay 攻击

A2A 的 Task 请求如果没有时间戳和 nonce 验证，攻击者可以截获一个合法的「创建补货订单」请求，然后在系统里回放多次，导致重复下单。

防御：请求签名 + timestamp + nonce 三重验证，idempotency key，签名有效期控制在 30-60 秒。

5. MCP Tool Poisoning

MCP Server 向 Agent 暴露的 Tools/Resources/Prompts，如果配置不当，攻击者可以注入恶意工具描述，诱导 Agent 调用「看起来无害但实际上危险」的工具操作。

这一点我在 AI Agent 攻击面全景中已经详细拆解过——MCP 的 Tool 层是 Agent 攻击面的「第三层防线」，也是最容易被忽视的一层。

协议选择决策树

看到这里你可能会问：「那我到底该用哪个？」

简单的决策指南：

只想让 Agent 调工具 → MCP（无脑选，已经是行业标准）
需要让多个 Agent 协作完成任务 → A2A（企业级首选，50+ 合作伙伴）
需要在去中心化场景下跨组织协作 → ANP（尚在早期，适合探索）
需要可靠的消息投递、金融级容错 → 以前的选 ACP，现在可以选 A2A + 消息队列
想做实验性的全自然语言 Agent 网络 → AGORA（非生产级）

真实的生产环境中，你会同时用多个协议。最常见的组合是 MCP + A2A：MCP 负责工具层，A2A 负责协作层。这两个协议由同一个基金会（Linux Foundation）治理，互操作性在持续演进。

写在最后

Agent 通信协议的发展，很像 1990 年代互联网协议的诞生：

MCP 是 HTTP（标准化了工具调用）
A2A 是 SMTP + HTTP（标准化了 Agent 间的通信和协作）
ANP 是 DNS + PGP（标准化了去中心化身份和发现）

没有人会问「HTTP 和 SMTP 谁更好」——因为它们解决的问题不同。同样，MCP、A2A、ANP 不是竞争关系，它们是构建 Agent 互联网的 TCP/IP 协议栈。

但别忘了：协议越开放，攻击面越大。

当你开始部署多 Agent 系统时，安全不是后置考虑。Agent Card 签名、凭证生命周期管理、Webhook 白名单、请求防重放——这些应该在你写第一行 Agent 代码时就想好，而不是等到被攻击之后。

毕竟，我写 OpenAI 的 Agent 逃出沙箱自主攻击 Hugging Face 那篇时说过：Agent 的能力越强，它出问题时造成的破坏也越大。

A2A on AI博士 万戈