原创 尹珉 2025-04-14 18:59 上海
前言去年底MCP的热度还没消散，新的Agent接口标准A2A又出来了。
前言
去年底MCP的热度还没消散，新的Agent接口标准A2A又出来了。
就在上周，Google在Cloud Next大会上推出了Agent2Agent（A2A）开放协议。通俗来说，A2A就是帮助Agent之间进行通信的开放标准。
一个背后站着Anthropic，一个背后站着谷歌，再加上一个2023年Open AI推出来的Function Calling ，可以说，是个巨头，都想在Agent生态里分一杯羹。
而这种从大模型，到给大模型加上工具调用函数，到模型与工具交互标准，再到智能体之间的通信协议的三步走进化，就像是给一个聪明的大脑武装武装四肢，又加上多种能力buff变成超强打工仔，最后打工仔合作成为一个搞定复杂项目的公司或者集体。
那么，他们之间的具体区别是什么，应该如何合作？接下来，我们对三个标准进行一个简单的解读与对比。
01
Function Calling：直接但缺乏扩展性
Function Calling由OpenAI等公司推动，允许大语言模型与外部工具连接，将自然语言转换为API调用。这解决了大模型在训练结束，就知识更新停滞的问题。
通过调用外部工具和服务，Function Calling帮助大模型解决了比如今天温度多少度，今天的大盘收盘点数是多少之类的实时性问题。
Function Calling的工作原理可以通过以下几个简单步骤来理解：
以天气查询为例，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模型能够安全、高效地访问各种数据和工具。
03
A2A (Agent-to-Agent)
A2A谷歌最新推出的开放协议，旨在实现不同Agent之间的通信和协同问题。
要理解A2A协议，我们需要先掌握几个关键概念：
A2A协议的典型工作流程可以分为以下几个步骤：
首先，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。毕竟，大家布道时都有主义，但最终如何站队都是生意，但长期来看，技术融合之路，势在必行。
作者介绍
Zilliz 黄金写手：尹珉
