MCP + A2A：给Agent装手还是装同事？2026协议栈三层架构拆透

Thu, 02 Jul 2026 08:00:00 +0800

作者：varkm

Salesforce的技术架构师在2026年3月的Trailblazer大会上展示了一张架构图——他们的Agentforce平台同时跑着MCP和A2A两个协议。客服Agent通过A2A调用外部的技术支持Agent，技术支持Agent再通过MCP连接内部知识库。

这张图揭示了一个正在发生的事实：单Agent时代结束了，协议栈时代开始了。

先给结论：MCP、A2A、ACP不是竞争关系，而是解决不同维度问题的三层协议栈。垂直方向，MCP负责Agent到工具的连接；水平方向，A2A负责Agent到Agent的协作；基础设施层，ACP负责Agent的注册、发现和生命周期管理。三层叠加，构成企业级多Agent系统的完整通信骨架。

为什么需要协议栈？单Agent时代的终结

过去一年，几乎所有AI框架都在做同一件事：给Agent接MCP。接了数据库、接了文件系统、接了GitHub、接了Slack。一个Agent能力越来越强，能调用的工具越来越多。

但企业里遇到的真实问题不是"一个Agent能调多少工具"，而是"五个不同平台的Agent怎么协作"。

举个例子：客服Agent跑在Salesforce上，技术支持Agent跑在ServiceNow上，工单系统在Jira。用户提了一个技术问题，客服Agent需要判断这个问题该转给谁，然后跟技术支持Agent交接上下文，技术支持Agent解决完还要回写工单。

这个流程里，MCP完全帮不上忙。MCP解决的是"一个Agent怎么调用外部工具"，不解决"Agent之间怎么对话"。就像USB接口标准化了设备连接，但两台电脑之间传输文件还需要网络协议。

这就是A2A和ACP诞生的原因。三个协议各管一层：

协议	解决什么	方向	类比
MCP	Agent调用工具和数据	垂直（Agent→Tool）	USB接口
A2A	Agent之间通信协作	水平（Agent→Agent）	网络协议
ACP	Agent注册、发现、治理	基础设施	DNS+目录服务

MCP层：垂直的「手」（Agent→Tool）

MCP（Model Context Protocol）是Anthropic在2024年底推出的开放协议，目标是标准化大模型与外部工具、数据源的连接方式。

核心数据：截至2026年7月，MCP的TypeScript SDK在npm上月下载量达到1.55亿次，官方servers仓库在GitHub上获得了8.8万颗星。生态数据比半年前翻了一倍。

MCP的核心设计很简单：一个MCP Server暴露一组工具（Tools）、资源（Resources）和提示（Prompts），MCP Client（通常是AI框架）通过标准化的JSON-RPC协议调用它们。任何支持MCP的框架都能直接接入任何MCP Server，不需要为每个工具写定制集成。

主流框架已经全面支持：Claude、Cursor、Windsurf、Cline、Zed、以及各大云厂商的Agent平台。你写一个MCP Server，理论上所有这些平台的用户都能直接用。

MCP的局限也很明确：它只解决"Agent能用什么"，不解决"Agent能找谁"。 一个MCP Server就是一个工具箱，但工具箱之间不能互相调用。如果你的客服Agent需要跟另一个平台的技术支持Agent协作，MCP给不了方案。

A2A层：水平的「同事」（Agent→Agent）

A2A（Agent2Agent Protocol）是Google在2025年4月发布的开放协议，目标是解决跨平台Agent之间的通信和协作问题。2026年3月12日发布v1.0正式版，5月28日发布了v1.0.1维护版本，项目已捐赠给Linux Foundation托管。

核心数据：GitHub上获得24,574颗星，超过150家组织表态支持，包括Google、Microsoft、AWS、Salesforce、SAP、ServiceNow、Atlassian、Box、Cohere等。

A2A的三个核心概念：

AgentCard——每个Agent发布一个能力声明文件（类似OpenAPI Spec），描述自己能做什么、接收什么输入、返回什么输出。其他Agent通过读取AgentCard就知道该不该找你协作。

Task生命周期——A2A不是简单的远程函数调用，而是定义了完整的任务状态机：submitted → working → input-required → completed/failed/canceled。长任务可以中途要求补充信息，可以流式返回进度。

流式通信——基于HTTP + SSE（Server-Sent Events），支持长连接和流式输出。适合需要长时间运行的任务，比如"分析这份100页的财报"。

生产案例已经落地。Salesforce的Agentforce通过A2A实现了跨生态Agent协作：一个跑在Salesforce上的销售Agent可以直接调用跑在ServiceNow上的IT运维Agent，上下文和任务状态在两个平台之间无缝传递。ServiceNow在Zurich版本（2026年Patch 4）中也集成了A2A支持，Now Assist的Agent可以跨平台响应外部请求。

ACP层：生命周期管理（Agent注册/发现/治理）

ACP（Agent Communication Protocol）由IBM发起，i-am-bee组织维护，目标是解决Agent生态的"基础设施"问题：Agent在哪里注册、怎么被发现、生命周期怎么管理。

GitHub仓库i-am-bee/acp目前有1,014颗星，已经发布到v1.0.3版本。相比MCP和A2A的热度，ACP关注者少得多，但它解决的问题是绕不开的。

想象一下：企业内部部署了50个Agent，分别跑在不同平台上。现在要找一个"能处理中文合同审查"的Agent——你怎么找？没有统一的注册中心，只能靠人去问、靠文档去翻。

ACP的设计思路是建立一个Agent注册表（Registry），每个Agent在部署时向注册中心注册自己的元信息：名称、能力描述、端点地址、认证方式、SLA等级。其他Agent或应用通过查询注册表来发现和定位目标Agent。

ACP还定义了Agent的生命周期管理：注册、上线、下线、版本更新。当Agent的能力发生变化时，注册表自动更新，确保调用方拿到的永远是最新信息。

ACP和A2A的关系是互补而非竞争。A2A定义了Agent之间怎么说话，ACP定义了怎么找到对方、怎么管理对方的生命周期。就像HTTP协议和DNS的关系——HTTP负责传输，DNS负责寻址。

三层协议栈如何协同工作

把三层叠起来，一个完整的多Agent协作流程是这样的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


用户请求: "帮我查一下客户A上个月的订单异常原因"

┌─────────────────────────────────────────────┐
│ 客服Agent (Salesforce Agentforce) │
│ 1. ACP查询: 找一个能做"订单分析"的Agent │
│ 2. ACP返回: 技术支持Agent @ ServiceNow │
│ 3. A2A调用: 发送Task到技术支持Agent │
└──────────────────┬──────────────────────────┘
 │ A2A (Agent→Agent)
 ▼
┌─────────────────────────────────────────────┐
│ 技术支持Agent (ServiceNow Now Assist) │
│ 1. 接收A2A Task, 状态=working │
│ 2. MCP调用: 连接ERP数据库查询订单记录 │
│ 3. MCP调用: 连接日志系统拉取异常日志 │
│ 4. 分析完成, A2A返回结果 │
└─────────────────────────────────────────────┘

整个流程中，ACP负责"找到人"，A2A负责"交代任务"，MCP负责"使用工具"。三层各司其职，没有重叠。

MCP和A2A正在走向融合。2026年以来，两个社区已经组建了联合工作组（Joint Working Groups），讨论如何在协议层面实现更好的互操作。一个可能的方向是：A2A的AgentCard中直接嵌入MCP工具声明，让Agent在发现彼此时就能看到对方提供了哪些MCP工具。两层架构（MCP + A2A）正在快速成为事实标准，ACP作为可选的治理层，在企业级场景中逐步渗透。

开发者该怎么做？

三层协议的成熟度差异很大，投入优先级也不同：

协议	成熟度	生态规模	开发者优先级
MCP	生产就绪	1.55亿月下载 / 8.8万星	最高——现在就该用
A2A	快速成长	2.5万星 / v1.0.1 / 150+组织	关注——多Agent场景必上
ACP	早期阶段	1千星 / v1.0.3	观望——企业级治理场景再考虑

场景一：单Agent + 工具调用。 只需要MCP。你有一个Agent，需要连接数据库、文件系统、外部API——写几个MCP Server，用任何支持MCP的框架直接接入。不需要A2A，更不需要ACP。这是目前90%的场景。

场景二：多Agent跨平台协作。 MCP + A2A。你有多个Agent跑在不同平台上，需要互相调用——用MCP连接各自的工具，用A2A实现Agent间通信。这是企业级场景的主流方向，Salesforce和ServiceNow已经在这么做了。

场景三：大规模Agent治理。 MCP + A2A + ACP。你有几十上百个Agent需要统一管理——加上ACP做注册发现和生命周期管理。目前只有极少数大型企业在探索这个阶段。

避坑提醒：不要过度设计。如果你的场景是"一个Agent调用几个工具"，上A2A是杀鸡用牛刀。A2A的Task生命周期、流式通信、AgentCard机制都增加了复杂度，单Agent场景完全不需要。协议栈的每一层都有成本，只在你真正遇到对应问题时才引入。

三层协议栈不是噱头，是企业级多Agent系统的必经之路。但路要一步一步走，从MCP开始，在真实需求驱动下逐层叠加。