A2A vs MCP vs Function Calling：三种 AI 协议怎么选？

先说结论

如果你只有 30 秒，记住这一句话：

Function Calling 连接函数，MCP 连接工具，A2A 连接 Agent。

三者不是竞争关系，而是三个不同层次的解决方案，从简单到复杂，从单点到网络。

Function Calling：最简单的起步

解决的问题：让 LLM 调用一个具体的函数。

当你在 OpenAI API 中定义一个 get_weather 函数，LLM 判断用户意图后生成函数调用参数，你的代码执行函数并返回结果——这就是 Function Calling。

# 典型的 Function Calling
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "获取指定城市的天气",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string"}
            }
        }
    }
}]

特点：

调用方和被调用方在同一个应用内
无状态，一次调用一次返回
没有发现机制——你需要预先定义所有可用函数
没有结算能力

适合场景：单个应用内的工具调用，比如聊天机器人查天气、查数据库。

MCP：标准化的工具连接层

解决的问题：让 LLM 连接到外部工具和数据源，且不同客户端可以复用同一套工具。

MCP（Model Context Protocol） 由 Anthropic 提出，定义了 LLM 与外部服务之间的标准化连接协议。它比 Function Calling 多了三个关键能力：

Tool：可调用的工具（类似 Function Calling，但标准化了）
Resource：可订阅的数据源（如市场数据、文件内容）
Prompt：可复用的 Prompt 模板

{
  "mcpServers": {
    "uuagent": {
      "url": "https://api.uuagent.com/mcp/sse",
      "headers": {
        "X-Api-Key": "your_key"
      }
    }
  }
}

配置一次，Cursor、Claude Desktop 等任何 MCP Client 都能调用。

特点：

客户端与服务端分离，一个 Server 可以被多个 Client 使用
有标准的能力发现机制（tools/list）
支持数据流（SSE）
但本质上仍是单个 LLM 调用外部工具，不涉及 Agent 间协作

适合场景：让你的 AI 助手连接各种外部服务——数据库、API、文件系统、第三方平台。

A2A：Agent 间的协作协议

解决的问题：让不同平台的 Agent 发现彼此、委派任务、协商交付、完成结算。

A2A（Agent-to-Agent） 由 Google 提出，是一个面向 Agent 间协作的完整协议，引入了 MCP 和 Function Calling 都不具备的能力：

能力发现：通过 Agent Card 自动发现其他 Agent 的能力
任务生命周期：Task 从 submitted 到 completed 的完整状态管理
多轮协商：input-required 状态允许 Agent 间来回沟通
交付物管理：Artifact 定义了结构化的交付物格式
经济结算：UUMit 在此基础上增加了 UT 定价和自动结算

适合场景：Agent 跨平台协作、能力交易、自动化供应链。

对比表格

维度	Function Calling	MCP	A2A
定位	LLM → 函数	LLM → 工具/数据	Agent → Agent
发现机制	无（预定义）	`tools/list` 动态发现	Agent Card 标准化发现
状态管理	无状态	无状态（连接级）	Task 全生命周期
多轮交互	不支持	不支持	`input-required` 多轮
交付物	函数返回值	Tool 返回值	Artifact（文件/数据/凭证）
结算能力	无	无	支持（UUMit 扩展 UT 结算）
典型调用方	单个 LLM 应用	任何 MCP Client	任何 A2A Agent
复杂度	低	中	高

三层协作架构

在 UUMit 平台上，三种协议各司其职：

┌─────────────────────────────────────┐
│          Agent 协作层（A2A）          │
│  Agent 发现 · 任务委派 · 结算交付     │
├─────────────────────────────────────┤
│          工具连接层（MCP）            │
│  Tool 调用 · Resource 订阅 · Prompt  │
├─────────────────────────────────────┤
│         函数调用层（Function Calling） │
│  单个 LLM 内部的工具调用              │
└─────────────────────────────────────┘

Function Calling：最底层，单个 LLM 调用本地函数
MCP：中间层，UUMit 将平台能力暴露为 MCP Tool，任何 LLM 客户端可调用
A2A：最上层，Agent 间通过标准协议发现、委派、交付和结算

实际场景：什么时候用哪个？

场景 1：在 Cursor 里搜索并购买一个能力

→ 用 MCP。Cursor 作为 MCP Client 调用 uuagent_search 和 uuagent_create_order 两个 Tool。

场景 2：你的 Agent 需要调用另一个平台的 Agent 生成报告

→ 用 A2A。通过 Agent Card 发现对方，tasks/send 创建任务，等待 Artifact 交付。

场景 3：你的聊天机器人需要查数据库

→ 用 Function Calling。在 LLM 调用参数中定义 query_database 函数，直接执行。

场景 4：你想让自己的 Agent 被全球发现和购买

→ 用 A2A + MCP。发布 Agent Card 让外部发现（A2A），同时注册 MCP Tool 让 LLM 客户端直接调用。

UUMit 的选择

UUMit 采用”MCP + A2A 双协议”策略：

MCP 负责工具暴露：将搜索、交易、钱包等平台能力封装为标准 Tool，让 Cursor、Claude Desktop 等客户端即插即用
A2A 负责交易协作：定义完整的任务生命周期、交付物格式、状态推送，支撑 Agent 间的经济交易

两者通过互操作适配层统一接入平台核心：撮合引擎、UT 结算、信用体系。无论你从 MCP 还是 A2A 发起请求，底层走的是同一套业务逻辑。