从 MCP 到 A2A：Agent 如何接入工具、与其他 Agent 协作

上一篇讨论了 Agent 之间如何交接工作。

一个 Agent 完成任务后，可以通过 Message 沟通过程信息，通过 Task 表达正在处理的工作，再通过 Artifact 交付正式结果。

解决了“传什么”，本文继续讨论 Agent 和外部能力之间，以及 Agent 之间，具体应以什么方式协作。

比如，一个 Agent 要查询数据库，可以直接调用 API，也可以通过 MCP 使用数据库工具；如果它无法独立完成任务，还可能把工作交给另一个专业 Agent。

这几种情况看起来都是“调用”，实际面对的问题并不相同。

先看 Agent 系统中最常见的三种情况。

第一种是直接调用已有服务：

01Agent
02  |
03  | REST / RPC
04  v
05业务服务

例如客服 Agent 查询订单：

01GET /orders/{id}

如果服务地址固定、接口明确，直接使用 REST 或 RPC 已经足够。

第二种是 Agent 使用外部工具：

01Agent
02  |
03  | MCP
04  v
05MCP Server
06  |
07  v
08数据库 / 搜索 / 文件 / 业务系统

这里 Agent 关心的是：

01当前有哪些工具
02每个工具有什么用途
03需要哪些参数
04会返回什么结果

这属于 MCP 主要解决的范围。

第三种是两个独立 Agent 之间协作：

01Agent A
02   |
03   | A2A
04   v
05Agent B

Agent A 面对的已经不是一个简单工具，而是另一个可以独立完成任务的 Agent。

它可能有自己的模型、Prompt、工具和运行状态，甚至由另一个团队开发和部署。

此时需要了解的是：

01对方具备哪些能力
02怎样提交任务
03任务当前是什么状态
04最终能够得到什么结果

这属于 A2A 主要解决的范围。

A2A（Agent2Agent Protocol）是由 Google 发起、现由 Agentic AI Foundation 推进的开放标准，用于让不同厂商、框架和语言实现的 AI Agent 能够发现彼此能力、交换消息、委派和跟踪任务，并交付结构化结果，从而实现跨系统的 Agent 协作与互操作。

因此，REST/RPC、MCP 和 A2A 面向的是不同场景，不需要互相替代。

假设我们正在开发一个客服 Agent，它需要：

01查询客户资料
02查询订单
03搜索知识库
04创建工单
05读取退款记录

传统做法通常是分别调用各个系统的 API，再在 Agent 中维护相应的函数和参数定义。

调用工具较少时，这种方式没有问题。

随着工具越来越多，会变得越来越不易维护。

每个工具怎样描述自己的用途？参数格式放在哪里？不同 Agent 是否都要重复开发适配代码？模型怎样知道当前有哪些工具可用？

MCP 为这些问题提供了一套统一方式。

外部系统可以通过 MCP Server 暴露能力，Agent 一侧通过 MCP Client 获取并使用这些能力。

其调用流程如下：

01Agent
02  |
03MCP Client
04  |
05  | MCP
06  v
07MCP Server
08  |
09  +-- Tool A
10  +-- Tool B
11  +-- Tool C

其中最值得关注的是 Tool。

一个 Tool 通常需要说明：

01工具名称
02工具用途
03输入参数
04返回结果

例如，一个查询发票的工具可以描述为：

01{
02  "name": "get_invoice",
03  "description": "根据发票编号查询发票信息",
04  "inputSchema": {
05    "type": "object",
06    "properties": {
07      "invoice_id": {
08        "type": "string"
09      }
10    },
11    "required": ["invoice_id"]
12  }
13}

这里的 name 是工具名称，description 说明用途，inputSchema 定义参数结构。

Agent 获取这些信息后，就能知道当前有哪些工具，以及调用时应该提供什么参数。

因此，MCP 能够让 Agent 以统一方式认识和使用外部能力。

至于 Tool 背后调用 PostgreSQL、REST API，还是企业内部服务，并不是 Agent 必须了解的内容。

假设客服 Agent 收到用户的问题：

我的退款已经申请五天了，为什么还没有到账？

Customer Agent 可以处理普通客服问题，但退款调查由 Billing Agent 负责。

于是任务会转交给 Billing Agent：

01Customer Agent
02      |
03      | A2A
04      v
05Billing Agent

Customer Agent 不需要知道 Billing Agent 使用什么模型，也不需要了解它内部有哪些 Prompt 和工具。

它更关心：

01Billing Agent 是否能处理退款问题
02任务应该怎样提交
03当前处理到哪一步
04结束后会返回什么

A2A 主要解决的正是这类 Agent 之间的协作问题。

其中有几个核心概念：

01Agent Card
02Task
03Message
04Artifact

它们分别解决能力描述、任务状态、过程沟通和结果交付等问题。

A2A 使用 Agent Card 描述 Agent 对外提供的信息和能力。

可以把它理解为 Agent 的服务说明。

例如：

01{
02  "name": "Billing Resolution Agent",
03  "description": "处理账单和退款相关问题",
04  "skills": [
05    {
06      "name": "refund_investigation"
07    },
08    {
09      "name": "invoice_query"
10    }
11  ]
12}

其中，skills 表示这个 Agent 对外提供的能力。

真实的 Agent Card 还可以包含访问地址、支持的交互方式和安全相关信息。

这样，系统面对一个新任务时，可以先确认：

01有哪些 Agent
02各自擅长什么
03哪个 Agent 能处理当前任务

确定目标之后，再进入具体的任务交互。

在 Agent 内部，Tool 调用通常比较直接：

01get_invoice("INV-1001")
02        ↓
03返回发票信息

但 Agent 接到的往往是一项需要持续处理的工作。

例如：

01调查这笔退款为什么迟迟没有到账，
02检查支付记录、退款状态和客服历史，
03最后给出处理结果。

Billing Agent 可能需要连续访问多个系统，中途还可能等待新的信息。

因此，A2A 使用 Task 表示一项正在处理的任务。

一个 Task 可能经历类似这样的状态变化：

01submitted
02    |
03    v
04working
05    |
06    v
07completed

有些任务还可能进入等待输入、失败或取消等状态。

这里体现了 Agent 与普通函数调用的一个明显区别。

函数通常关注：

01请求
02  ↓
03结果

Agent 协作还需要知道：

01任务是否已经开始
02当前进行到哪一步
03是否需要额外信息
04最终是否完成

对于耗时较长的任务，系统还可以通过 Streaming、订阅状态变化或通知机制持续获得进展，而不必一直等待一个同步请求返回。

任务完成之后，还需要交付结果。

如果只是简单回复：

01退款正在处理中

Message 已经足够。

但 Agent 的正式产出可能是一份报告、一段结构化数据，甚至一个文件。

例如 Billing Agent 最终生成：

01Refund Investigation Report
02
03- 退款申请时间
04- 支付渠道状态
05- 当前退款状态
06- 异常原因
07- 建议处理方式

这类可以继续被其他系统使用的正式结果，可以通过 Artifact 表达。

因此，上述几个概念的职责如下：

01Agent Card
02描述“我具备什么能力”
03
04Task
05表示“当前正在处理什么工作”
06
07Message
08承载任务过程中的沟通
09
10Artifact
11保存任务产生的正式结果

这也与上一篇中介绍的 Agent 交付内容完全一致。

上一篇关注 Agent 之间交接什么，这里进一步关注这些内容怎样在独立 Agent 之间流转。

MCP 和 A2A 并不冲突。

它们很可能同时出现在一个系统中。

继续使用前面的客服场景：

01Customer Agent
02
03      |
04      | A2A
05      v
06
07Billing Resolution Agent
08
09      |
10      +---- MCP ----> CRM
11      |
12      +---- MCP ----> Invoice Database
13      |
14      +---- MCP ----> Ticket System

用户询问退款问题后，Customer Agent 判断自己无法完成完整调查，于是通过 A2A 把任务交给 Billing Resolution Agent。

Customer Agent 关心：

01Billing Agent 擅长什么
02怎样提交 Task
03当前处理到哪一步
04最终返回什么 Artifact

Billing Agent 接到任务后，需要查询客户资料、发票和客服工单。

这时它通过 MCP 使用对应工具：

01get_customer()
02get_invoice()
03search_tickets()

Billing Agent 关心：

01有哪些 Tool
02每个 Tool 需要哪些参数
03调用后返回什么数据

所以，同一个系统中，两种协议承担的是不同职责：

01Agent
02  |
03  | A2A
04  | Agent 之间的任务协作
05  v
06Agent
07  |
08  | MCP
09  | Agent 对外部能力的使用
10  v
11Tool / Data / API

实际工程中，我们应根据不同场景选择不同的调用方式。

如果当前对象提供一个明确、清晰的能力，例如：

01查询订单
02搜索文档
03创建工单
04读取数据库

它应该以 Tool 的方式实现。

如果当前对象能够：

01接收完整任务
02自行组织执行过程
03调用多个工具
04维护任务状态
05返回完整结果

它应以 Agent 形式实现。

Agent 系统中常见三种交互方式：直接调用 API、通过 MCP 使用工具，以及通过 A2A 与另一个 Agent 协作。

MCP 更关注工具和资源接入。它让 Agent 知道有哪些能力、需要哪些参数，以及调用后能够得到什么结果。

A2A 面向独立 Agent 之间的协作。Agent Card 描述能力，Task 表示正在处理的工作，Message 负责过程沟通，Artifact 承载正式结果。

在完整的 Multi-Agent 系统中，两者往往同时存在：

01Agent A
02   |
03  A2A
04   |
05Agent B
06   |
07  MCP
08   |
09Tools / Data / APIs

因此，系统设计中首先需要分清的是：当前对象是供 Agent 使用的一项能力，还是一个能够独立接收并完成任务的 Agent。边界确定后，就能够确定适合的交互方式。