讨论｜谁能统一Agent 接口？MCP 对比 A2A 、Function Calling

前言

去年底MCP的热度还没消散，新的Agent接口标准A2A又出来了。

就在上周，Google在Cloud Next大会上推出了Agent2Agent（A2A）开放协议。通俗来说，A2A就是帮助Agent之间进行通信的开放标准。

一个背后站着Anthropic，一个背后站着谷歌，再加上一个2023年Open AI推出来的Function Calling ，可以说，是个巨头，都想在Agent生态里分一杯羹。

4.14-1.svg

而这种从大模型，到给大模型加上工具调用函数，到模型与工具交互标准，再到智能体之间的通信协议的三步走进化，就像是给一个聪明的大脑武装武装四肢，又加上多种能力buff变成超强打工仔，最后打工仔合作成为一个搞定复杂项目的公司或者集体。

那么，他们之间的具体区别是什么，应该如何合作？接下来，我们对三个标准进行一个简单的解读与对比。

01

Function Calling：直接但缺乏扩展性

Function Calling由OpenAI等公司推动，允许大语言模型与外部工具连接，将自然语言转换为API调用。这解决了大模型在训练结束，就知识更新停滞的问题。

通过调用外部工具和服务，Function Calling帮助大模型解决了比如今天温度多少度，今天的大盘收盘点数是多少之类的实时性问题。

Function Calling的工作原理可以通过以下几个简单步骤来理解：

4.14-2.png

以天气查询为例，Function Calling的工作流程大致如下：

第一步，识别需求：这是一个关于实时天气的问题，需要调用外部天气API。

第二步，选择函数：从可用函数中选择get_current_weather函数。

第三步，准备参数：

{
  "location": "北京",
  "unit": "celsius"
}

第四步，调用函数：系统使用这些参数调用实际的天气API，获取北京的实时天气数据。

第五步，整合回答： "根据最新数据，北京今天的天气晴朗，当前温度23°C，湿度45%，微风。今天的最高温度预计为26°C，最低温度为18°C。"

对开发者来说，使用LLM的Function Calling起步相对容易，只需按照API要求定义函数规格（通常JSON模式）并将其随请求发送，模型就可能按照需要调用这些函数，逻辑较直观。

因此，对于单一模型、少量功能的简单应用，Function Calling 实现起来非常直接，几乎“一键”将模型输出对接到代码逻辑中。

然而，它的局限在于缺乏跨模型的一致性：每个LLM供应商的接口格式略有差异，开发者若想支持多个模型，需要为不同API做适配或使用额外框架处理。

02

MCP：全新大模型接口标准

MCP (Model Context Protocol)是Anthropic提出的协议，旨在解决不同大模型与不同外部工具集成的标准化问题。

目前，Anthropic的Claude系列，Open AI的GPT系列、Meta的Llama系列，deepseek、阿里的通义系列，Anysphere的Cursor，各种主流模型均已接入MCP生态。

从架构上来说，MCP采用了客户端-服务器架构，主要包括以下几个核心组件：

1. MCP主机(Hosts) ：这是需要访问数据的程序，如Claude Desktop、各种IDE或AI工具。它们是MCP生态系统的入口点，负责向用户提供AI功能。

2. MCP客户端(Clients) ：这些是协议客户端，负责维持与MCP服务器的1:1连接。它们处理通信细节，确保主机和服务器之间的数据传输顺畅。

3. MCP服务器(Servers) ：这些是轻量级程序，每个服务器都通过标准化的Model Context Protocol暴露特定功能。服务器是MCP的核心，它们连接AI模型与实际数据源。

4. 数据源 ：包括两类：

• 本地数据源 ：您计算机上的文件、数据库和服务，MCP服务器可以安全访问这些资源

• 远程服务 ：通过互联网可用的外部系统(如通过API)，MCP服务器可以连接这些系统

这些组件共同工作，形成了一个完整的生态系统，让AI模型能够安全、高效地访问各种数据和工具。

4.14-3.png

03

A2A (Agent-to-Agent)

A2A谷歌最新推出的开放协议，旨在实现不同Agent之间的通信和协同问题。

要理解A2A协议，我们需要先掌握几个关键概念：

4.14-4.png

A2A协议的典型工作流程可以分为以下几个步骤：

4.14-5.png

首先，A2A Client（就像点餐的顾客）向A2A Server发送请求，启动一个任务。接着，服务器处理请求并返回响应，告知任务的状态。任务在执行过程中可能会经历多个状态，如已提交、处理中、需要输入等，最终完成或失败。

04

MCP vs Function Calling vs A2A

都是提供外部工具与大模型的交互，MCP与Function Calling在设计理念和应用场景上存在明显差异，这主要体现在可扩展性上:

Function Calling 由于缺乏统一标准，不同LLM需要各自的函数定义格式：如果有M个不同LLM应用和N个不同工具/服务，理论上可能需要实现M×N次重复的对接工作。此外，对于函数的链式调用，Function Calling本身并不直接支持多步调用组合，模型只能一次调用一个函数，获取结果后如果需调用下一个函数，需要由应用逻辑将结果馈入模型下一轮对话，再触发下一个函数调用。虽然在原理上可以实现函数输出作为输入形成链条，但这一切需要开发者在应用层精心编排，模型自身缺乏对跨调用流程的全局观。

MCP 的扩展性，则通过统一的接口标准，将复杂的M（个模型）×N（个外部工具对接）问题转化为M+N的问题：工具创建者只需为每个工具/系统实现一次MCP Server，应用开发者只需为每个应用实现一次MCP Client，各自遵循通用协议即可协同工作，扩展新功能的边际成本大幅降低。

这里可能有人会有个问题，直接通过MCP把Agent做的足够全能就好，为什么需要A2A 来协作不同Agent呢？

对比MCP与A2A，则可以发现，两者的关系，更多是一种能力的互补：MCP让代理能够使用工具，而A2A让Agent能够与其他Agent协作。一个解决"做什么"，一个解决"与谁合作"。

这背后的逻辑就像上班，有的同事（Agent）擅长研发汽车发动机，有的同事（Agent）擅长组装；所有人通过一个流水线串联共同完成一个项目，一定比一个同事（Agent）独自研发汽车，然后再组装并营销的效率更高。

长期来看，我们可能会看到三大通信机制逐渐融合的趋势。

不过一个有意思的现象是，目前OpenAI和Anthropic尚未支持A2A。毕竟，大家布道时都有主义，但最终如何站队都是生意，但长期来看，技术融合之路，势在必行。