MCP 与 A2A 在基于大语言模型的系统中智能体间协调的对比研究

📊 论文图表(共 2 张)

展开查看 2 张图

‹ ›

TL;DR

本文对比了 MCP 与 A2A 两种智能体间协调协议在多智能体系统中的实现差异。研究发现，MCP 以更轻量的实现模型降低了协调复杂度，但要求开发者在应用层显式处理会话状态与任务生命周期；A2A 则通过协议级抽象原生支持有状态、多轮协调，使开发者无需自行实现状态管理，但整体实现复杂度和协调负担显著更高。这项工作揭示了协议抽象如何塑造协调职责在协议层与应用层之间的分配。

研究背景与动机

随着 [[大语言模型]] 技术在软件系统中的深度应用，由异构的、工具介导的智能体组件所组成的[[智能体系统]]迅速兴起。这些系统中的多个智能体需要相互协作完成复杂任务——例如在软件工程场景中，一个智能体负责代码审查，另一个负责测试生成，它们之间必须进行高效的信息交换与任务协调。然而，当这些智能体来自不同技术栈、具有不同能力时，如何设计它们之间的通信协议就成了一个关键的工程问题。

在这一背景下，业界涌现出两种具有代表性的协调协议：MCP（Model Context Protocol，模型上下文协议）与 A2A（Agent2Agent，智能体对智能体协议）。MCP 起源于 Anthropic，最初设计用于扩展大语言模型与外部工具的交互能力，后来被应用于智能体间通信；A2A 则由 Google 等厂商提出，专门面向多智能体场景，强调任务协作与会话状态管理。两种协议在设计上有着不同的取舍，但此前缺乏基于同一场景、统一实现的系统性对比研究，这正是本文的切入点。

方法

研究者选取了一个典型的软件工程任务场景——涉及多个基于大语言模型的智能体协作完成代码相关的开发工作——并分别基于 MCP 与 A2A 实现了两套功能等价的多智能体系统。这种「同一任务、双套实现」的设计使得对比评估能够隔离协议本身的差异，而非被具体业务逻辑所混淆。

评估围绕七个核心需求维度展开：智能体可发现性（系统如何找到可用的智能体）、多部分消息传递（智能体能否发送包含多种内容类型的复合消息）、多轮对话（持续的上下文交互能力）、异步通信（不阻塞等待的通信模式）、可观测性（系统状态的可见程度）、互操作性（跨技术栈的兼容能力）以及访问控制（通信权限的管理机制）。这些维度既来源于学术文献中多智能体协调研究的经典议题，也整合了与行业合作伙伴讨论中提炼的实践需求。

研究者对两种协议在每个维度上的实现表现进行了详细记录，特别关注了开发者在构建系统时必须处理的协调问题——包括会话状态的维护方式、任务生命周期的管理策略、以及通信失败时的恢复机制等。

实验与结果

对比结果呈现出清晰的分化格局。在实现复杂度层面，MCP 方案的总代码量、依赖数量以及配置项数量均显著低于 A2A 方案，这得益于 MCP 采用的轻量级消息模式——它本质上是一套结构化的请求-响应协议，智能体之间的交互更接近于函数调用，而非复杂的对话管理。

然而，轻量化的代价是协调职责向应用层转移。在 MCP 实现中，会话状态的维护（如「这是第几轮对话」「当前任务进展到哪一步」）必须由开发者自行设计与实现，任务生命周期的管理（从创建、进行中、到完成或失败）同样需要在业务代码中显式编码。这使得 MCP 非常适合协调模式相对简单、参与者角色固定的多智能体系统；但当系统需要处理动态的任务分配、长时间的等待恢复、或复杂的上下文继承时，应用层的复杂度会迅速累积。

A2A 则选择了另一条路径。它在协议层内置了任务抽象与状态机语义，智能体之间的交互被建模为任务的协作过程，协议本身定义了任务的创建、推进、完成等生命周期事件的规范格式与处理流程。这意味着开发者无需在应用层重复实现这些通用模式，系统天然支持有状态、多轮、可能跨越长时间周期的协调场景。但协议层面的丰富抽象也带来了更高的学习成本与实现门槛——开发者需要理解协议定义的状态机模型，并在实现中正确处理各种状态转换事件。

在可观测性方面，A2A 的任务模型使得系统状态的追踪更为自然，协议内嵌了任务进度的表达机制；而 MCP 方案的观测能力完全取决于应用层是否实现了相应的日志与监控组件。互操作性与访问控制方面，两种协议都提供了基础机制，但具体实现策略有所不同，A2A 由于面向更复杂的协作场景，在权限模型的粒度与表达力上略胜一筹。

讨论与可借鉴点

这项研究最核心的启示在于协调职责的分配问题。协议的选择本质上是在「协议复杂度」与「应用复杂度」之间做权衡：把协调逻辑下沉到协议层，可以降低应用层的实现负担，但会提高协议本身的复杂度与学习成本；反之，保持协议的简洁性，则意味着开发者需要在应用层承担更多的协调实现工作。

对于资源受限或协调模式简单的多智能体系统，MCP 的轻量化优势更为突出；但当系统需要处理动态、复杂的长程协作时，A2A 的协议级抽象能够有效避免应用层的重复造轮子。研究者特别指出，这一发现是对「哪种协议更好」这一问题的补充而非回答——答案取决于具体场景的协调需求。

研究的局限主要在于评估场景的覆盖范围有限，所测试的协调模式偏向典型的软件工程任务，其结论在更广泛的多智能体系统类别上的外推性需要谨慎解读。此外，协议本身仍在快速演进中，本文基于的协议版本可能与最新实现存在差异。

对于从事[[智能体系统]]开发的工程师而言，这项研究的实践意义在于：在设计多智能体架构时，应根据协调需求的复杂度预期来选择合适的协议抽象——既要避免过度设计（为简单场景引入复杂的协议负担），也要警惕过度简化（为复杂场景选择能力不足的协议导致应用层噩梦）。协议是基础设施，它的选择会影响整个系统后续的演化路径。

摘要

近期业界实践中，由异构的、工具和大语言模型介导的智能体组件所组成的智能体系统迅速涌现，引发了关于智能体间协调与协议设计方面的实践性问题。本文从多智能体系统工程视角出发，基于一个涉及基于大语言模型的智能体的智能体间协调场景，对模型上下文协议（Model Context Protocol, MCP）与智能体对智能体（Agent2Agent, A2A）协议进行了以实现为依据的对比研究。我们依据既有文献及与行业合作伙伴讨论中所提炼的一系列需求，对同一软件工程任务的基于 MCP 与基于 A2A 的两种多智能体实现进行了评估，这些需求包括智能体可发现性、多部分消息传递、多轮对话、异步通信、可观测性、互操作性以及访问控制。结果表明，MCP 能够通过相对轻量的实现模型与较低的协调复杂度，支持受限的基于大语言模型的系统中的智能体间协调，尽管诸如会话状态管理与任务生命周期处理等协调问题必须在应用层显式实现。相比之下，A2A 通过面向任务与生命周期管理的协议级抽象，为有状态、多轮协调提供了更丰富的原生支持，但这也带来了显著更大的实现复杂性与协调复杂性。鉴于所评估的协调模式范围较窄，这些发现以经验性经验报告中设计观察的形式呈现，而非针对更广泛多智能体系统（MAS）类别的协议适用性或优越性的一般性论断，旨在凸显其中的权衡取舍，以及协议抽象如何塑造当代智能体系统中协调职责的分配。

Abstract

Recent industry practice has seen the rapid emergence of agentic systems composed of heterogeneous, tool- and LLM-mediated agent components, raising practical questions about inter-agent coordination and protocol design. This paper presents an implementation-grounded comparison of the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol, from a multi-agent systems engineering perspective, using an inter-agent coordination scenario involving LLM-based agents. We evaluate an MCP-based and an A2A-based multi-agent implementation of the same software engineering task against a set of requirements derived from prior literature and discussions with industry partners, including agent discoverability, multi-part messaging, multi-turn conversations, asynchronous communication, observability, interoperability, and access control. The results evidence that MCP can support inter-agent coordination in constrained LLM-based systems through a comparatively lightweight implementation model with lower coordination complexity, although coordination concerns such as conversational state management and task lifecycle handling must be implemented explicitly at the application layer. In contrast, A2A provides richer native support for stateful, multi-turn coordination through protocol-level abstractions for tasks and lifecycle management, but this comes with substantially greater implementation and coordination complexity. Given the narrow scope of the evaluated coordination pattern, these findings are presented as design observations from an empirical experience report rather than general claims of protocol suitability or superiority across broader classes of MAS, highlighting trade-offs and how protocol abstractions shape the distribution of coordination responsibilities in contemporary agentic systems.