A2A 与 MCP：为新兴智能体生态系统提供的两种互补协议

AI 智能体的日益普及——代表用户进行推理和行动的自主或半自主软件实体——正在应用架构中引入一个新层。

2025 年初，为了解决这一问题，出现了两种不同的协议——A2A（智能体对智能体） 和 MCP（模型上下文协议）。理解它们角色的一种简单方法是：

A2A：智能体之间如何互动

MCP：智能体如何与工具或外部上下文互动

参考资料：https://google.github.io/A2A/#/topics/a2a_and_mcp

它们解决了构建多个智能体、多个 LLM 和多个上下文来源系统的核心挑战 ——所有这些都需要协作。

一种看待它们的方式是：“MCP 提供垂直集成（应用到模型），而 A2A 提供水平集成（智能体到智能体）

无论你是否是开发者，构建 AI 产品或智能系统的人都应该理解这一基础架构 —— 因为它影响我们设计产品、用户交互、生态系统和长期增长的方式。

这篇文章以简单、易懂的方式介绍了这两个协议，并强调了开发者和 AI 产品构建者需要关注的关键点。

什么是 A2A（智能体对智能体）？#

A2A（智能体对智能体） 是由谷歌和超过 50 个行业合作伙伴开发的开放协议。其目的是实现智能体之间的互操作性——无论是谁构建的、托管在哪里、使用什么框架。

A2A 协议机制#

A2A 使用 JSON-RPC 2.0 over HTTP(S) 作为通信机制，并支持 Server-Sent Events (SSE) 来流式传输更新。

A2A 通信模型#

A2A 为两个智能体之间的交互定义了一个结构化模型。一个智能体充当 “客户端” 智能体，发起请求或任务，另一个则充当 “远程” 智能体，接收请求并尝试完成任务。客户端智能体首先可能会进行 能力发现 以确定哪个智能体最适合执行某个任务。

这引出了一个问题，智能体如何彼此发现。每个智能体可以发布一个 智能体卡片（通常托管于标准 URL，如 /.well-known/agent.json 的 JSON 元数据文档），描述其能力、技能、API 端点和认证要求。

通过阅读智能体卡片，客户端智能体可以识别出适合当前任务的合作智能体——本质上是一个该智能体所知、能做什么的目录。一旦选定目标智能体，客户端智能体便可发送任务对象。

参考资料：https://google.github.io/A2A/#/

任务管理#

A2A 中的所有交互都围绕执行任务展开。任务是一个结构化的对象（由协议的模式定义），包括请求的详细信息并跟踪其状态。

在 A2A 中，每个智能体扮演以下两个角色之一：

• 客户端智能体：发起任务
• 远程智能体：接收并处理任务

任务可以包括任何形式的工作：生成报告、检索数据、启动工作流。结果作为 工件 返回，智能体在执行期间可以发送结构化的 消息 以进行协调或澄清。

协作和内容协商#

A2A 不仅支持简单的任务请求——智能体可以交换包含文本、JSON、图像、视频或交互内容的丰富、多部分消息。这使得能够根据每个智能体能够处理或显示的内容进行格式协商。

例如，远程智能体可以以原始数据或图像的形式返回一个图表，或者请求打开一个交互表单。此设计支持灵活的、模态无关 的通信，而不需要智能体分享内部工具或记忆。

用例示例#

以下是 A2A 在企业场景中使用的一个真实例子：

一名新员工在一家公司被录用。多个系统和部门参与入职流程：

• 人力资源需要创建记录并发送欢迎邮件
• IT 需要提供笔记本电脑和公司账户
• 设施部门需要准备办公桌和通行证

传统上，这些步骤是手动处理或通过内部系统之间的紧耦合集成处理。

而不是在每个系统之间拥有自定义 API，每个部门都使用 A2A 协议公开其自己的智能体：

一个多智能体系统——我们称之为 OnboardingPro （例如 onboarding-agent.company.com）——协调整个入职工作流程。

1. 发现：它读取每个智能体的 .well-known/agent.json 以了解能力和认证。
2. 任务委派：
   • 向 HR 智能体发送 createEmployee 任务。
   • 向 IT 智能体发送 setupEmailAccount 和 orderHardware 任务。
   • 向设施智能体发送 assignDesk 和 generateBadge 任务。
3. 持续更新：智能体使用服务器发送事件流回进度（例如“笔记本电脑已发货”，“桌子已分配”）。
4. 工件收集：最终结果（例如 PDF 通行证，确认电子邮件，账户凭证）作为 A2A 工件返回。
5. 完成：OnboardingPro 通知招聘经理入职完成。

什么是 MCP（模型上下文协议）？#

MCP（模型上下文协议），由 Anthropic 开发，解决了一个不同的问题：外部应用程序如何在运行时向基于语言模型的智能体提供结构化的上下文和工具。

MCP 专注于 上下文窗口 —— LLM 的工作记忆。其目标是：

• 动态注入相关工具、文档、API 功能或用户状态到模型的推理会话中
• 让模型调用功能或获取文档，而无需硬编码提示或逻辑

MCP 的关键架构#

要理解 MCP，你首先需要了解整体架构——各部分如何协同工作。

MCP 主机：“你正在与之对话的 AI”#

可以将 MCP 主机 视为 AI 应用本身——比如 Claude Desktop 或你的编码助手。

这是你正在使用的接口——你打字或交谈的地方。

它希望引入工具和数据，以帮助模型给出更好的答案。

MCP 客户端：“连接器”#

MCP 客户端 是将 AI 主机（如 Claude）连接到外部世界的软件部分。它像一个总机 —— 管理与不同 MCP 服务器的安全、一对一连接。当 AI 需要访问某物时，它通过客户端。

可以将像 ChatGPT、Claude 聊天 或 Cursor IDE 这样的工具视为 MCP 主机 ——它们提供你交互的界面。在幕后，它们使用 MCP 客户端 通过 MCP 服务器连接不同的工具和数据源。

参考资料：https://modelcontextprotocol.io/introduction

MCP 服务器：“工具提供者”#

MCP 服务器 是一个小的、专用的程序，公开一个特定的工具或能力 —— 例如：

• 搜索你计算机上的文件
• 查找本地数据库中的数据
• 调用外部 API（如天气、金融、日历）

每个服务器遵循 MCP 协议，因此 AI 可以理解它能做什么以及如何调用它。

本地数据源：“你自己的文件和服务”#

一些 MCP 服务器连接到你自己的机器上的东西 —— 比如：

• 文档和文件夹
• 代码项目
• 数据库或本地应用

这允许 AI 在不上传你的数据到云的情况下搜索、检索或计算内容。

远程服务：“API 和在线工具”#

其他 MCP 服务器连接到互联网 —— 它们与以下内容通信：

• API（例如 Stripe、Notion、GitHub）
• SaaS 工具
• 云端的公司数据库

因此，AI 可以说，例如：“调用 GitHub 服务器并获取开放的 PR 列表。”

MCP 现在支持连接到**远程 MCP 服务器。这意味着 MCP 客户端可以获得更强大的能力。**理论上，

拥有一套合适的 MCP 服务器，用户可以将每个 MCP 客户端变成“万能 APP”。

参考资料：https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

综合一切#

现在让我们用一张图来看看一切如何协同工作。

1. 你向 AI 提出复杂请求
2. AI（主机）请求 客户端 提供帮助
3. 客户端调用正确的 MCP 服务器 —— 可能是检查文件或调用 API 的那一个
4. 服务器返回数据或运行一个功能
5. 结果流回模型以帮助其完成任务

A2A 与 MCP 的比较#

他们如何协同工作#

而不是替代品，A2A 和 MCP 是互补的。在许多系统中，这两者将一起使用。

示例工作流程#

1. 用户在企业智能体界面提交复杂请求。
2. 协调智能体使用 A2A 将子任务分配给专业智能体（例如，分析、人力资源、金融）。
3. 其中一个智能体在内部使用 MCP 调用搜索功能、获取文档或使用模型计算某物。
4. 结果作为工件通过 A2A 返回，实现端到端智能体协作和模块化工具访问。

这种架构将**智能体间通信（A2A）与智能体内能力调用（MCP）**分开——使得系统更易于组装、扩展和保护。

结论#

A2A 是关于智能体通过网络相互通信——安全、异步且以任务为中心。

MCP 是关于在模型会话中注入结构化能力，让 LLM 在工具和数据上下文中进行推理。

结合使用，它们支持可组合、多智能体系统，既可扩展又可互操作。

MCP + A2A 基础设施如何塑造智能体产品市场的未来#

最后，我想谈谈这一核心技术基础设施如何塑造 AI 市场的未来——以及这对构建 AI 产品的人意味着什么。

人机交互的变化#

在开发者和服务工作流程中，可以清楚地看到这一变化的例子。MCP 服务器现在已集成到 IDE 和编码智能体中，开发者与工具的交互方式正发生根本改变。

过去，一个典型的工作流程包括寻找合适的服务、设置托管、阅读文档、手动集成 API、在 IDE 中编写代码，以及通过低代码仪表板配置功能。这是一个分散的体验，在每一步都需要切换上下文和技术开销。

现在，借助 MCP 连接的编码智能体，许多复杂性可以被抽象化掉。开发者可以通过对话提示更自然地发现和使用工具。API 集成正在成为编码流程本身的一部分——通常不需要单独的 UI 或手动设置。（想想 AWS 或微软仪表板的复杂性）。这种交互变得更加流畅——更多是引导行为而不是组装功能。

在这个模型中，用户或开发者交互从配置功能转向编排行为。这也改变了产品设计的角色。

不再使用 UI 来“修补”技术挑战（例如“这太难编码了，让我们做一个配置面板”），我们现在需要：

• 考虑端到端体验
• 设计如何以及何时AI + 用户交互应该结合起来
• 让 AI 处理逻辑，并通过意图和流程引导用户

挑战在于决定 AI 和用户输入何时以及如何结合，让 AI 处理逻辑，并在合适的时间引入正确的交互。

我用开发者服务和 API 产品作为例子来展示用户交互如何改变——但同样适用于商业软件。长期以来，商务工具复杂且难以使用。自然语言交互有潜力简化这些工作流程。

智能体产品范式及其对 SaaS 的影响#

我们开始看到越来越多 MCP 服务器 的出现。想象一下，Airbnb 提供一个 预定 MCP 服务器，或 Google Maps 公开一个 地图 MCP 服务器。一个智能体（做为 MCP 客户端）可以一次连接到许多这样的服务器——解锁以前需要自定义集成或紧密绑定应用的工作流程。

相比于 SaaS 时代，集成通常是手动的且僵硬的，这种模型实现了更自主的工作流程和服务之间的流动连接。这里有两个例子：

1. 从文档中设计

   你在 Notion 中撰写 PRD。一个 Figma 智能体读取文档并自动创建草图，布局核心概念——无需手动移交。

2. 从头到尾的竞争对手研究

   你要求进行竞争对手分析。一组智能体在网上搜索，代表你注册相关服务（通过安全认证），收集结果，并以已在你的 Notion 工作区中组织好的方式交付工件。

身份验证和授权边界的挑战#

随着智能体到智能体连接、MCP 客户端到 MCP 服务器连接的兴起，关于身份验证和授权有许多潜在需求，因为智能体将代表人类和用户行动，凭证必须在这过程旅途中保持安全。

到目前为止，有几个案例是针对智能体到智能体和 MCP 的新兴起的：

1. 智能体 vs SaaS & 网站应用
2. MCP 客户端（智能体）vs MCP 服务器
3. 用户 vs 智能体
4. 智能体 vs 智能体

谷歌提到的一个有趣的用例是多身份联合 Google：

例如，用户 U 正在与要求 A 系统标识符的智能体 A 一起工作。如果智能体 A 依赖于需要 B 系统标识符的工具 B 或智能体 B，用户可能需要在单个请求中为 A 系统和 B 系统提供身份。（假设 A 系统是企业 LDAP 身份而 B 系统是 SaaS 提供者身份）。

Logto 是一个 OIDC 和 OAuth 提供商，非常适合未来 AI 集成。

凭借其灵活的基础设施，我们正在积极扩展其能力，并发布了一系列教程以帮助开发者快速入门。

有问题吗？

联系我们 —— 或深入探索你可以用 Logto 构建的内容。