Blog / AI
AI

MCP vs. A2A:2025 年模型协议的实际使用方式

了解 MCP 和 A2A 协议的工作原理、它们的使用时机,以及为什么二者对于构建智能且可扩展的 AI 系统至关重要。
1 分钟阅读
MCP 与 A2A 协议

MCP(Model Context Protocol,模型上下文协议)和 A2A(Agent-to-Agent,代理对代理)正在迅速改变我们对传统软件架构的固有假设。无论你是负责制定战略还是搭建解决方案,我们都会在本文中为你做出清晰解释,以避免在整合新兴技术时出现常见的错误。

在阅读本文完毕后,你将了解:

  • 什么是 MCP,以及为什么要使用它
  • 什么是 A2A,它在你的技术栈中扮演什么角色
  • 什么时候该使用每种协议
  • 为什么未来你可能会同时使用这两种协议

什么是 MCP 和 A2A——以及你为何需要关心?

我们正处在现代史上最大范式转变的前沿。几乎所有人都在日常环境中某种程度上使用人工智能。在工作流程和架构里,用于完成特定任务的模型被称为“代理(agent)”。

目前你使用最多的是 Model Context Protocol(MCP)。而 Agent-to-Agent(A2A)更像是一组不断演进的新功能,而不是一个被严格定义好的协议。

  • MCP:用于管理模型的上下文和内部状态。你几乎每天都在与 MCP 进行交互。像 Grok、ChatGPT、CoPilot 这样的模型都使用 MCP 来管理通用任务和上下文。如果你在创建自己的代理,很可能会从编写自定义的 MCP 开始。
  • A2A:当两个或更多模型互相“对话”时,就发生了 Agent-to-Agent 过程。每个代理都遵循自己的 MCP,但它们之间的通信过程就叫做 A2A。可以把它想象成人类之间的口头或书面语言。

Model Context Protocol——“大脑”

MCP 工作流程示意图

可以将 MCP 理解为机器的“大脑”。MCP 包含了一个任务的所有内部过程——从语言理解到任务完成。

X 上,你会看到大量的帖子,用户回复时使用“@grok”,后面跟着问题或陈述。然后 Grok 解释用户的提示,并回复与线程相关的内容。这就是一个典型 MCP 在真实场景中的使用实例。

1. 查询路由

第一步是“查询路由”(Query Routing)。当你说:“@grok,能帮我核实一下这条帖子内容吗?”,Grok 会执行搜索并阅读相关文本。如果你说:“@grok,请将这条帖子描述成一幅图像。”,Grok 就会将请求路由给另一个 Aurora 模型。关于 Aurora,你可以在这里了解更多。

  • 你发起初始查询。
  • 代理解析查询,并选择合适的模型来处理查询。

2. 工具选择

一旦任务被分配给特定的 AI 模型,该模型就会选择完成任务所需的工具。好比你要挂一个隔板,你可能会拿锤子和钉子,或者电钻和螺丝——模型的行为也是类似的。

这些工具可以是搜索引擎、计算器、Python 解释器……几乎任何东西。如果让 Grok 去做事实核查,它可能会选择两个工具:

  • 搜索引擎:模型会进行搜索并评估“可信”结果。这里并不去评价 Grok 的可信结果,仅作为示例。
  • 计算器:如果帖子中有关于数据夸大或缩小的表述,比如疫情统计数据,Grok 应该用计算器对搜索结果和用户的帖子数据进行加总。

3. 服务器交互

模型在结构化好任务并选择了相应的工具后,需要将任务交给对应的“服务器”去执行。首先,它会告诉搜索引擎要执行什么查询;拿到结果后,再向计算器发送一系列计算指令。

这里所谓的“服务器”是广义的。具体取决于你的模型和部署设置,这个“服务器”可能是数据中心中运行的某个服务,也可能是运行在你的 http://localhost:6000 上——或者任何端口。核心思想很简单:工具在监听并等待任务,模型则把任务发送给这些工具。

  • 工具监听端口:模型把任务交给合适的工具“服务器”。它会像HTTP 请求一样,把“1+1=?”发送给该服务器。
  • 服务器返回响应:服务器返回处理完的任务数据,比如“1+1=2”。Grok 接收这个答案,再用到正确的上下文里。

4. 检查点(可由人类完成)

在将结果返回给代理输出之前,需要对模型的输出进行检查。你可能没意识到,模型如今仍存在偏见和错误输出。为了防止“1+1=3”或“1+1=情绪诱导”之类的错误,输出会在一个或多个检查点被审查。

根据任务上下文,这些检查点可能是人工,也可能是跑相同作业的另一个模型。关键点很简单:不要让错误输出到达用户。

  • 检查点:由人类或者另一个模型对任务输出进行二次核对,以防止荒谬输出发布给用户。
  • 修正:如果输出确实不正确,代理需要重新尝试任务——可能继续用相同模型,也可能会转交给另一个模型。
  • 最终输出:经过检查后,Grok 会把最终结果回复给使用“@grok”的那位用户。

Agent-to-Agent 协议——多个“大脑”之间的沟通

A2A 示意图

如果说 MCP 是单个代理“大脑”的全部功能,那么 A2A 就是多个“大脑”之间的对话方式。在现实应用中,多个代理已经在彼此互动了。想象你在和 ChatGPT 对话。

你和 ChatGPT 在讨论猫,这个话题广泛涉及各种大小猫、聪明与否……然后你开始跟 ChatGPT 聊起了“你的猫”,并想要一张你家猫咪统治世界的荒诞图片(毕竟所有猫都暗中想要统治世界)。

ChatGPT 自身无法生成图像,它会将图片生成的工作交给 DALL-E,就像 Grok 会用 Aurora 一样。 运行 ChatGPT 的那个代理会与运行 DALL-E 的代理进行通信,以完成这个任务。

Agent Card:你代理的“README”

Agent Card 用于向他人展示你的 AI 代理能做什么,也说明了如何与它对接,及大致的输出类型。你不必深入技术细节,也没必要详细展示全部代码;只需要提供非常基础的示例和输出说明。看过 API 文档的人一般都知道这里该写什么、不该写什么。

  • 连接方式:明确展示应如何安全地连接该代理。如果你展示的是 REST API,用 HTTPS 示例(带真实域名)而不是裸露的 HTTP;如果用 SDK,则展示如何通过 SDK 进行连接。
  • 简洁用法:如果是 REST API,就给出端点和输出格式;如果是 SDK,就展示核心类和方法如何使用。
  • 示例输出:在每段用法的示例后面,展示一下对应的示例输出。

编写 A2A 应用时,会使用其他代理的 Agent Card 来连接多个代理;当你创建自己的代理时,别人也会通过你的 Agent Card 来使用它。

对待他人要像希望别人对待你一样。

任务系统:任务如何被创建与完成

所谓任务系统,本质上跟一个简单的 CRUD(创建、读取、更新、删除)应用类似。用户(或者其他代理)应该能够创建任务,也应该能够读取任务状态。用户和代理都需要能够更新任务。而删除往往是符合最佳实践的做法——若只是不断新增任务却从不删除,对系统会造成浪费。

  • 创建(Create):用户(此处指其他代理)可以创建新任务。比如 ChatGPT 的代理告诉 DALL-E,需要生成一幅邪恶的猫想要统治世界的图像。
  • 读取(Read):用户(或其他代理)需要能够查询任务的状态。如果 ChatGPT 显示“正在生成图像”,那就是任务的状态为“进行中”。代理应随时能读并传达任务状态。
  • 更新(Update):你忘了告诉 ChatGPT 想让猫戴领结,你应该可以更新提示,以得到更理想的图片。同时,当 DALL-E 在生成时,它也需要随时更新任务进度状态,让 ChatGPT 知道。
  • 删除(Delete):如今很多公司忽视了这个基础功能,更倾向于“数据湖”概念而不是效率。但你的代理应该能删除任务——保留已取消的任务不仅没意义,还浪费存储空间。

安全通信

代理之间的消息应当是安全的。换个角度讲,计算机科学中有 SSL 和 HTTPS。在 HTTPS/SSL 请求中,请求体是加密的,只有服务器能读;响应返回时同理,也只有客户端能解密。

代理之间也应当遵循同样原则。当涉及多个 AI 代理时(很可能会替代人类去执行整套任务流程),往往会处理敏感信息。这些代理之间也应使用某种加密协议。

  • 加密:当代理之间通信时,应当端到端加密。任何截获信息的人只能看到乱码。
  • 身份验证:通过数字签名等身份验证技术,代理可以确认对方的身份。当与特定指纹绑定时,任务信息仅限于有权限访问的一方。

长时间任务的支持

有些任务并不能即时完成,可能耗费数小时甚至数天!在这种情况下,代理必须具备良好的沟通能力。尤其是在多个代理协同的任务中,用户应当收到相应状态更新。

  • 实时更新:代理应实时更新它们的任务状态,方便用户随时查询。
  • 通知与邮件:代理还应该在任务进度节点上发送通知或邮件。任务完成时,发送邮件或推送通知。

你的代理应当让用户随时掌握进度,而不是不停轰炸通知。用户使用 A2A 是为了方便——在长时间任务场景,务必让体验更顺畅。

多模态通信

A2A 流程中往往需要处理多模态任务。再回想一下 ChatGPT 和 DALL-E 的例子:ChatGPT 处理文本对话,而 DALL-E 负责图像生成。

  • 自由文本和逻辑:通常由擅长自然语言处理的 LLM 完成。
  • 图像和视频生成:由 DALL-E、Sora 等专门的模型完成。

很多任务需要多模态数据。当面对多模态任务时,应让 A2A 协议把不同的任务分配给适合的模型。

应该在何时使用每种协议?

这两种协议分别适用于不同的场景。MCP 负责代理的内部——也就是它的“大脑”;A2A 则用于让多个代理彼此通信。

使用场景 MCP A2A 范围 通信方式 最佳用途 主要关注点 示例
防止错误和早期误差 ✔️ 单个代理 内部 任务安全 & 验证 避免过早采取错误行动 ChatGPT 验证提示
控制单个代理的上下文 ✔️ 单个代理 内部 上下文感知决策 记忆 + 工具选择 CoPilot 编写代码
跨代理通信或任务移交 ✔️ 多代理 外部 工作流委派 代理间的互操作 GPT 交给 DALL·E
第三方代理协作 ✔️ 多代理 外部 跨厂商工作流程协调 协议标准化 Alexa Skills 集成
构建多代理生态系统 ✔️ 多代理 外部 分布式代理系统 任务路由 + 发现 内部 LLM 流水线
维护完整审计记录(单代理) ✔️ 单个代理 内部 日志和可追溯性 可观测性 财务自动化代理
跨多模态(文本、图像、视频)的灵活性 ✔️ 多代理 外部 多模态处理 任务分段 GPT + DALL·E 或 Sora

结论:未来你会同时使用这两者

MCP 和 A2A 并不是竞争关系,而是互补的体系。MCP 代表了代理的所有内部处理,而 A2A 则规定了代理之间如何通信。

  • MCP 让你的代理具备“智慧”。
  • A2A 则让这些“智慧”彼此交流。

如果你打算训练自己的 AI 模型,Bright Data 提供了具有历史数据的定制数据集,让你的代理能够识别趋势。需要实时数据?可以看看爬虫工具 API——只要代理需要就能获取数据,保证你的代理始终做好准备。使用Agent Browser,你的代理可以像人一样浏览网页——配合代理(Proxy)集成和验证码(CAPTCHA)破解。

支持支付宝等多种支付方式