Agent 互联协议全景：A2A、ACP、ANP 与 MCP 的互补生态

AI Agent 正从单一的对话助手演变为能够自主规划、协作执行的多智能体系统。当企业开始部署来自不同厂商、基于不同框架构建的 Agent 时，一个根本性问题浮出水面：这些 Agent 如何相互发现、协商能力、安全地交换信息并协同完成任务？

在此之前，每个框架都有自己的内部消息格式和任务模型——LangChain 的 Chain、CrewAI 的 Task、AutoGen 的 Conversation——没有通用的发现机制。一个 Salesforce Agent 无法将子任务委派给一个 ServiceNow Agent，除非手写定制胶水代码。这种 N×N 的集成复杂度 正是协议标准化的原动力。

本文将系统梳理四大 Agent 互联协议——MCP（Model Context Protocol）、A2A（Agent-to-Agent Protocol）、ACP（Agent Communication Protocol）和 ANP（Agent Network Protocol），从设计哲学、技术架构、适用场景到落地实践，为开发者提供一份清晰的技术选型地图。

1. 协议全景：四大协议各解决什么问题？

在深入每个协议之前，先建立全局认知。四大协议并非竞争关系，而是解决不同层次的互操作性问题：

一个形象的比喻：MCP 是 Agent 的"USB-C 接口"——让 Agent 能连接任何工具；A2A 是 Agent 的"电话协议"——让 Agent 能呼叫其他 Agent 并协作；ANP 是 Agent 的"互联网"——让任何 Agent 在开放网络上被发现和交互。

┌───────────────────────────────────────────────────────────────┐
│                    Agent 互联协议层次模型                        │
│                                                               │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  Layer 4: ANP — 去中心化开放网络                          │  │
│  │  DID 身份 · 元协议协商 · Agent 支付 · 开放市场              │  │
│  └─────────────────────────────────────────────────────────┘  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  Layer 3: A2A — 企业级 Agent 协作                         │  │
│  │  Agent Card · Task 生命周期 · SSE 流式 · 推送通知           │  │
│  └─────────────────────────────────────────────────────────┘  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  Layer 2: ACP — 轻量 REST 通信（已合并入 A2A）              │  │
│  │  RESTful API · 离线发现 · 多模态消息                       │  │
│  └─────────────────────────────────────────────────────────┘  │
│  ┌─────────────────────────────────────────────────────────┐  │
│  │  Layer 1: MCP — 工具与数据访问                             │  │
│  │  Resources · Tools · Prompts · Sampling                   │  │
│  └─────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────┘

2. MCP：Agent 连接工具的通用接口

2.1 设计哲学

MCP 由 Anthropic 于 2024 年 11 月开源，2025 年 12 月捐赠给 Linux Foundation 下的 Agentic AI Foundation（AAIF）。其核心理念是：为 LLM 提供标准化的工具接入层，消除每个 AI 平台各自定义 Function Calling 格式的碎片化问题。

MCP 被类比为"AI 的 USB-C"——一个统一的接口标准，让任何 AI 模型都能安全地连接到任何工具和数据源。

2.2 架构与通信模式

MCP 采用 Client-Server 架构，基于 JSON-RPC 2.0 协议：

┌─────────────────┐    JSON-RPC 2.0    ┌──────────────────┐
│                 │  ◄──────────────►  │                  │
│   MCP Client    │  (stdio / SSE /   │   MCP Server     │
│   (AI Agent)    │   HTTP Streaming)  │   (Tool Provider)│
│                 │                    │                  │
│  ┌───────────┐  │   Request:         │  ┌────────────┐  │
│  │ LLM Brain │──┼── tools/call ─────►│  │ Resources  │  │
│  │           │  │                    │  ├────────────┤  │
│  │           │◄─┼── Result/Error ◄───│  │ Tools      │  │
│  └───────────┘  │                    │  ├────────────┤  │
│                 │                    │  │ Prompts    │  │
│                 │                    │  ├────────────┤  │
│                 │                    │  │ Sampling   │  │
│                 │                    │  └────────────┘  │
└─────────────────┘                    └──────────────────┘

MCP Server 暴露四种能力：

2.3 传输与生态

MCP 支持 stdio（本地进程）与 Streamable HTTP（远程）两类传输。2025 年 OpenAI、Google、Microsoft、AWS 相继接入后，MCP 事实上结束了"各家自定义工具接口"的碎片化时代——写一次 Server，所有支持 MCP 的 Agent 框架都能用。

MCP 的边界：它规范"Agent 如何用工具"，不处理"Agent 如何与 Agent 协作"。任务生命周期、跨 Agent 进度流、多租户身份——超出其 scope，正是 A2A 的地盘。

3. A2A：企业级 Agent 协作协议

3.1 核心对象模型

A2A 的三个一等概念：

• Agent Card：/.well-known/agent.json 处的能力自述（技能、端点、鉴权方式），供调用方发现与路由
• Task：有完整生命周期的工作单元（submitted → working → input-required → completed/failed），长任务可挂起等待补充输入
• Message / Artifact：多模态消息流与最终产出物，通过 SSE 流式或推送通知回传

┌────────────┐   发现(Agent Card)   ┌────────────────┐
│ A2A Client │ ────────────────────►│ Remote Agent A │
│ (主 Agent)  │── task/send/stream ──►│  长任务 · 进度流 │
└────────────┘◄──── SSE / push ─────└────────────────┘

3.2 与 MCP 的关系：互补不竞争

Google 的官方类比：MCP 是 Agent 的工具层，A2A 是 Agent 的协作层。典型生产链路：主 Agent 经 A2A 把"审计上月账单"委派给财务 Agent，财务 Agent 内部用 MCP 连数据库和报表工具。身份模型也互补——MCP 管工具侧凭证，A2A 做端到端鉴权（OAuth2/OIDC、mTLS 可选）。

4. ACP 与 ANP：被合并与做补充的两条路线

4.1 ACP：轻量 REST 派

IBM 的 ACP 以纯 REST 为中心、无需 SSE/WebSocket 即可上手。2025 年中被证明与 A2A 语义高度重叠，8 月正式合并入 A2A（Linux Foundation 统一）。存量 REST Agent 微服务的迁移路径：用 A2A 的 REST binding 兼容层。

4.2 ANP：开放网络的去中心化派

ANP 面向完全不同的问题——没有中心注册方的公网 Agent 互相发现：

• 三层架构：垂直层（协议协商）/ 水平层（Agent 群组）/ 核心层（DID 身份 + 元协议）
• W3C DID：Agent 用去中心化标识符自证身份，无需平台背书
• 元协议协商：两个素未谋面的 Agent 在线交换"如何通信"的协议本身

现状：学术原型与社区实验为主，生产部署远少于 A2A/MCP。适合关注 Agent 开放市场的场景；企业集成短期内仍以 MCP + A2A 为事实标准。

5. 选型与实践建议

四条落地建议：一、先 MCP 后 A2A——工具层不稳就上协作层是自找麻烦；二、Agent Card 按 API 文档治理，带版本与变更日志；三、任务 ID 贯穿两个协议做全链路 trace；四、鉴权分层——Agent 间 mTLS/OAuth、工具侧最小权限凭证，别让一个网关联所有内容。

6. 总结

四大协议在 2025-2026 年完成了一次清晰的分工收敛：MCP 管"手"（工具），A2A 管"嘴"（协作），ANP 管"身份证"（去中心化身份），ACP 已并入 A2A。对工程团队，技术栈可按层拆开选型：工具层锁 MCP（生态压倒性），协作层锁 A2A（LF 背书 + 150+ 组织支持），网络层观察 ANP。协议解决的是"能不能对话"——跨 Agent 的目标一致性、责任归属与失效恢复仍是应用层自己要做的设计。协议标准化把集成的 N×N 降为 N，剩下的那个 N 依然是工程。

(注：文中协议特性与生态数据整理自 MCP/A2A/ANP 官方规范、Linux Foundation 公告及公开文档（截至 2026 年初），协议仍在快速演进，落地前请核对最新版本。)

本文面向授权安全研究与防御建设，未经授权对任何系统实施文中技术属违法行为。