作者：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协作流程是这样的：
| |
整个流程中，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开始，在真实需求驱动下逐层叠加。