如果说MCP是AI智能体的USB口，那A2A就是以太网

几乎万事万物都离不开协议和标准，这也是就技术问题达成沟通一致的前提。而随着AI智能体的迅猛发展，与之配套的协议出现也只是时间问题。

Anthropic提出的MCP（模型上下文协议）就是其中最知名的方案之一。MCP于去年正式亮相，帮助模型轻松接入外部数据存储、API乃至其他功能及工具，但同时也为新一波安全威胁打开了大门。

然而，MCP并非唯一发展势头迅猛的AI中心协议。在今年四月的Google I/O开发者大会上，谷歌发布了其智能体到智能体（A2A）协议。从表面上看，MCP与A2A似乎高度重合，采用类似的客户端-服务器架构，使用大量相同的底层消息传递与传输协议，而且同样在相对不太成熟的情况下获得了业界的大力支持。

很多朋友都以为这将是又一场针尖对麦芒的比拼。但实际上，MCP与A2A打算解决的问题截然不同，由它们引发的误解大多源自AI智能体在定义上的模糊不清。所以下面咱们来具体聊聊。

宏观来讲，智能体的定义非常简单：通常依托于某种模型，负责解读信息并决定如何处理信息。底层模型可以访问各种函数或工具，以检索或执行这些任务。

例如，日志智能体可能使用某种工具定期轮询API端点以获取日志。一旦检测到异常，它会使用另一工具生成支持工单，以供人工操作员审核。只要智能体足够可靠，它们就能通过工资、医疗福利和病假情况等指标淘汰掉那些偷奸耍滑的员工。

而要想达成这一目标，智能体间的通信协议必须更加完善，这正是MCP和A2A的意义所在。先说MCP，简言之它是“一个用于连接AI系统与数据源的通用开放标准”。

换句话说，MCP为模型提供一种标准化方式，使其能够与现有资源（例如SQL数据库、Kubernetes集群或现有API）进行交互。该协议遵循客户端-服务器架构，信息交换使用JSON-RPC，并根据具体用例通过Stdio、HTTP或SSE等形式进行传输。

MCP架构概览

MCP的核心是以标准化方式开放模型与工具功能，促进它们间的通信。因此Anthropic将MCP描述为AI版的USB接口。但如前所述，MCP只是众多实现方式之一，比如LangChain也提供类似的功能。

如果说MCP就是USB口，那么A2A的定位更接近于以太网。A2A同样使用JSON-RPC、HTTP与SSE，但目的却在促进智能体之间的通信。

Google A2A协议工作原理分解图

这些通信遵循一条可预测路径，从发现阶段起，系统中的智能体间就会交换名牌，具体包含名称、功能、联系位置以及如何进行身份验证。这些智能体名牌还包含可选功能的详细信息，例如通过SSE传输数据、能够提取或返回的格式类型（如文本、图像、音频或视频）等。

在了解了彼此之后，智能体间即可互发任务，其中一个智能体充当客户端、另一智能体充当服务器。但需要注意的是，这些角色并非固定不变，每个智能体可以根据具体情况在客户端与服务器间灵活切换。

任务创建之后，智能体服务器会返回一条消息和一个任务ID，用于跟踪任务进度。这对需要长时间运行的作业来说非常重要。客户端会定期轮询服务器，而当二者均支持SSE时，服务器端也可自动提供进度更新。

如此一来，任务就能标记出缺失信息，例如用户电子邮件地址或者支持工单的严重程度，供下游智能体作为执行参考。任务完成后，结果将以工件形式从服务器发送至客户端，工件中则可包含文本、图像及结构化JSON等内容。

回到之前日志的例子，记录智能体可以通过A2A向另一智能体发送支持工单，再由后者执行诊断、评估问题、判断可以自动解决或者需要人工介入。

A2A背后的一大关键驱力，在于实用性智能体系统将由多个各具专业知识的智能体组合而成。其中一部分智能体可由内部开发，另一些则可由软件供应商提供。

就协议而言，A2A并不关心智能体是否使用MCP来实现目标，它只关心各智能体间是否使用相同语言，能否清晰传达各自的能力、局限性与执行进度，确保任务顺利完成。

自从谷歌在今年春季的I/O大会上公布A2A以来，该协议得到模型开发商、云服务商以及软件提供商的广泛支持。

在亚马逊、微软、思科、Salesforce、SAP以及ServiceNow等大厂的支持下，谷歌于6月宣布计划将A2A协议捐赠给Linux基金会。

尽管MCP与A2A协议均已得到科技巨头的大力支持，但整个AI生态仍处于起步阶段，而这项技术的发展也毫无放缓迹象。考虑到标准机构向来行动缓慢，相信由特性定义及底层逻辑等问题引发的分歧，必将催生出更多新的标准和协议。