AI Agent MCP及A2A协议浅析

01

—

MCP深入了解

（本章内容参考官方文档 https://modelcontextprotocol.io/docs/getting-started/intro）

1、MCP架构中的核心参与方：

MCP Host：协调与管理一个或多个 MCP 客户端的 AI 应用程序

MCP Client：维护与 MCP 服务器的连接，并从服务器获取上下文信息供 MCP Host使用的组件

MCP Server：向 MCP 客户端提供上下文信息的程序

2、MCP分层：数据层和传输层

a、数据层：定义了基于JSON-RPC的客户端-服务器通信协议，包括生命周期管理及核心基础组件，例如工具、资源、提示词和通知。

• 生命周期管理：处理客户端与服务器之间的连接初始化、能力协商及连接终止流程
• 服务端功能：使服务器能够提供核心功能，包括供AI执行操作的工具、提供上下文数据的资源，以及用于客户端交互的提示模板
• 客户端功能：使服务器能够要求客户端对宿主大语言模型进行采样、向用户获取输入信息，并将日志消息记录至客户端
• 实用功能：支持实时更新通知、长时操作进度追踪等附加能力

b、传输层：定义客户端与服务器之间的数据交换通信机制和通道，包括传输特定的连接建立、消息帧处理及授权认证。

MCP支持两种传输机制：

• 标准输入输出传输（Stdio）：通过标准输入/输出流实现同一台机器上本地进程间的直接进程通信，提供无网络开销的最优性能。
• 可流式HTTP传输（Streamable HTTP）：使用HTTP POST传输客户端到服务器的消息，并可选配服务器发送事件（Server-Sent Events）实现流传输能力。此传输机制支持远程服务器通信，兼容标准HTTP认证方式（包括承载令牌、API密钥和自定义标头）。MCP推荐使用OAuth获取认证令牌。

传输层将对通信细节的处理抽象化，使协议层能够在所有传输机制中使用统一的JSON-RPC 2.0消息格式。

3、MCP Server 核心组件

• 提示词（Prompts）：用于构建与语言模型交互的可复用模板（如系统提示词、少样本示例）。后端的程序员可以公开特定的提示词（适用于与后端服务公开的数据交互），这些提示词可以注入到使用 LLM 的应用程序中，并暴露给给定应用程序的用户。服务端提供的提示词查询方法及提示词样例如下图：

• 资源（Resources）：为AI应用程序提供上下文信息的数据源（如文件内容、数据库记录、API响应），服务端提供的资源查询方法及样例如下图：

• 工具（Tools）：MCP Server 公开一个端点，可以列出所有可用 Tools 工具及其描述和所需参数，应用程序可以将此列表传递给 LLM，以便它决定哪些 Tools 工具适用于手头的任务以及如何调用它们。服务端提供的工具查询及调用方法及样例如下图：

4、MCP 通知机制（Notifications）

MCP协议支持实时通知功能，借助服务器与客户端之间的动态更新机制。例如，当服务器可用工具发生变化时（如新增功能或修改现有工具），服务器可向已连接的客户端发送工具更新通知以告知这些变更。这些通知以JSON-RPC 2.0通知消息形式发送（不要求响应），使MCP服务器能够为连接的客户端提供实时更新。

5、MCP SDK介绍

首先介绍下SDK的概念。

SDK的全称是Software Development Kit（软件开发工具包）。

一个典型的 SDK 通常包含：库/API 封装、文档、代码样例、调试工具、编译器/其他工具等。

简单比喻：如果你想组装一个乐高模型，乐高公司给你的那一盒特定的积木块、说明书和特殊工具，就是一个“SDK”。它让你不必自己去雕刻木头做积木，而是直接用现成的部件快速搭建。

MCP官网建议实现MCP Server 和 MCP Client使用官方提供的SDK。所有的SDK提供的是同样的核心功能模块以及全协议支持。

目前可用的SDK如下，基本覆盖了主流的编程语言。Python现在比较多使用的Fastapi-mcp和FastMCP这两个框架，也都是基于MCP官网提供的Python SDK来实现的。

6、MCP总结

MCP由Anthropic提出，本质是连接LLM与外部工具的应用层协议，其核心价值在于建立标准化的Agent工具集成生态，就像大家目前主流在用的Restful。

笔者在线上有看到华为云大佬对MCP目前对局限性做了一些说明，觉得总结的还挺有道理的，此处引用过来给大家参考下：

a、对比传统接口：缺少对响应字段的类型定义、数据校验等治理能力。

b、工具爆炸问题：协议未提供工具筛选、优先级排序等机制。当接入工具数量激增时，LLM难以高效选择合适工具。

c、文档语义鸿沟：依赖人工编写的API描述（如"get weather from a given city"），LLM可能因描述模糊或技术术语理解偏差导致调用错误。

02

—

A2A介绍以及和MCP的关系

1、A2A协议简介

2025 年 4 月 9 日，Google 推出了Agent2Agent (A2A) 协议。Agent2Agent (A2A) 协议是一种开放标准，旨在实现 AI 代理之间的无缝通信和协作。这使得使用不同框架和由不同供应商构建的代理能够以通用语言相互通信，从而打破孤岛并促进互操作性。

A2A 可让代理执行以下操作：

• 发现：使用标准化的智能体卡片查找其他智能体并了解其技能 (AgentSkill) 和功能 (AgentCapabilities)。
• 通信：安全地交换消息和数据。
• 协作：委派任务并协调行动，以实现复杂的目标。

2、 A2A 协议的核心概念解析

a、智能体卡片 (Agent Card)：智能体的“数字名片”

想象一下，当你第一次遇到一个人时，你会交换名片来了解对方的基本信息和联系方式。智能体卡片 (Agent Card)在 A2A 协议中扮演着类似的角色。

A2A 协议通过“代理卡片”等机制促进了这种通信，代理卡片充当数字名片，代理可以使用它来宣传自己的功能和连接信息。

通过 Agent Card，一个发起请求的智能体（客户端）就能主动发现并识别网络上的其他智能体，这是实现任何协作的第一步。

b、智能体技能 (Agent Skill)：智能体的“服务接口”

如果 Agent Card 是名片，那么智能体技能 (Agent Skill)就是名片上列出的、你能够提供的具体服务及其使用说明。它精确定义了智能体的一项特定能力。

有了 Agent Skill，智能体就能够“理解”彼此的能力，从而知道如何正确地构造请求来调用对方的服务。

c、智能体执行器 (Agent Executor)：智能体的“大脑与行动中心”

智能体执行器 (Agent Executor)是 A2A 智能体内部的核心逻辑处理器，它是智能体真正的“大脑”和“行动中心”。

Agent Executor 是 A2A 智能体最核心的实现部分，它连接了标准化的 A2A 协议与智能体内部的独特智能。

3、 A2A 通信流：从发现到协作

4、A2A和MCP的比较

MCP（模型上下文协议）本质上是一个工具访问协议。它定义了大型语言模型与各种工具、数据和资源交互的标准方式。简而言之，MCP 使 AI 能够使用各种功能，就像程序员调用函数一样。

A2A（Agent2Agent 协议）专注于代理协作，它建立了智能代理之间相互发现、通信和合作的方式，使不同的 AI 系统能够像人类团队一样协同工作。

A2A 与 MCP并非竞争技术，而是互补技术。

在实际应用中，它们通常需要一起使用：

• MCP 为代理提供了访问工具的标准方式
• A2A 为座席协作提供了标准方式

在实践中，完整的AI系统架构通常需要：

• 使用MCP将AI与各种工具和数据源连接起来
• 使用A2A实现多Agent间的协作和任务委托

03

—

总结

之前的两篇文章主要着重介绍MCP Server搭建以及实际调用，没有细致了解MCP协议以及核心组件，实战中实现的demo也是最基础的，应该只有实现了最基础的Tools功能，没有涉及到Resource和Prompt。

今天去翻看了MCP官网文档，还是有不少收获的，让自己对MCP有了更深入的了解。

除了MCP以外，本周工作中也一直有在了解A2A协议，所以本文也对A2A做简单介绍，快够打车原CTO沈剑老师说的一句话印象特别深刻“任何脱离业务的架构设计都是耍流氓”，所以基于MCP也好，A2A也好，关键还是需要去实践，去解决实际的业务场景。

笔者后续会继续尝试基于A2A和MCP做企业故障诊断及根因分析场景落地探索，会先去搭建相关demo，然后持续分析相关文档，敬请期待。