Agent 2.0“三剑客”：MCP协议、A2A协议、AG-UI协议

本文 的 原文 地址

原始的内容，请参考 本文 的 原文 地址

本文 的 原文 地址

本文作者：

• 第一作者 老架构师 肖恩（肖恩 是尼恩团队 高级架构师，负责写此文的第一稿，初稿 ）
• 第二作者 老架构师 尼恩 （45岁老架构师， 负责 提升此文的 技术高度，让大家有一种 俯视 技术、俯瞰技术、 技术自由 的感觉）

三大核心协议：MCP、A2A与AG-UI

在AI应用中，我们通常会遇到三个角色：用户、AI Agent（智能助手）和外部工具。

要让这三者顺畅配合，就需要统一的沟通方式，也就是“协议”。

目前有三个主流协议正在被广泛应用：

（1）MCP协议 —— 让AI能用外部工具

MCP（Model Calling Protocol）解决AI Agent如何调用外部工具的问题。比如AI想查天气或操作数据库，MCP就像一个通用遥控器，让它可以顺利使用各种工具。

（2）A2A协议 —— 让AI之间能对话

A2A（Agent to Agent）是多个AI之间沟通的标准。当多个AI需要合作完成任务时，A2A确保它们能互相理解、协调工作。

（3）AG-UI协议 —— 让AI和界面友好互动

AG-UI（Agent to UI）规范了AI与前端界面之间的交互方式。这样用户通过网页或App使用AI功能时，体验更流畅、一致。

协议”三剑客“的意义

协议的 ”三剑客“

• MCP：AI调用工具的标准；
• A2A：AI之间协作的标准；
• AG-UI：AI与用户界面沟通的标准；

三者结合，构成了现代AI应用系统的通信骨架。

这些协议共同推动AI应用的发展，让开发更高效，用户体验更好。

现在AI基础模型的发展越来越集中，但AI应用层面依然充满机会。

有了这些标准协议，开发者可以更快地构建复杂系统，创造出更多实用的AI产品。

MCP协议

MCP全称是Model Context Protocol（模型上下文协议），由AI公司Anthropic在2024年11月开源推出。

从下图可以看到，从去年3月开始，MCP项目在GitHub上的关注度迅速上升，说明它越来越受到开发者和企业的重视。

MCP GitHub Star增长趋势

数据来源：star-history.com

MCP的发展背景

MCP的出现与“函数调用”功能密切相关。

早在2023年6月，OpenAI就在GPT-4和GPT-3.5中首次引入了Function Calling能力，让AI模型可以执行具体任务，比如查天气、搜索知识库、做数学计算等。

随后，谷歌和Anthropic也推出了类似的功能。

但问题来了：不同厂商的函数调用方式不统一，接口格式、参数设置都不一样。

举个例子：

这导致开发者要为每个模型单独写适配代码，开发成本很高。

MCP的作用

为了解决这个问题，MCP被提出来作为一个通用标准协议，让不同模型都能通过统一的方式访问外部工具和服务。

可以把它想象成电脑上的USB-C接口，不管插什么设备，只要支持这个接口就能直接用。

下图展示了MCP的基本架构，可以看出它如何帮助AI模型连接各种数据源和工具。

技术实现方式

虽然目前最常用的是通过Function Calling来实现MCP，但这不是唯一方式。

只要模型能理解并生成结构化的通信协议（如JSON-RPC、RESTful API等），就可以支持MCP。

Function Calling只是最主流、最推荐的做法。

A2A协议

在2025年3月，随着MCP协议走红，谷歌也推出了一个配套协议：A2A（Agent to Agent）。

虽然A2A和MCP都是为了让AI系统中的不同模块能更好地协作，但它们解决的问题不一样：

• MCP 是让 AI Agent 能连接外部工具和数据，比如调用API、使用数据库等。
• A2A 是让不同的 AI Agent 之间可以互相沟通和合作。

举个例子：就像你朋友圈里有个“黄牛总代”，他手下有很多专门做不同事情的小黄牛，比如抢票、挂号、排队买月饼。

这些小黄牛就是一个个“Agent”。

MCP是他们各自使用的工具（比如抢票脚本），而A2A则是他们之间如何沟通协调，比如你告诉“黄牛总代”要一张演唱会门票，他会去找抢票黄牛来完成任务。

A2A的核心功能

A2A是一个开放协议，主要解决多个AI助手之间的通信问题。它有以下几个关键特性：

• 统一消息格式：所有Agent都用同一种方式说话，避免鸡同鸭讲。
• 发现机制：Agent可以找到其他能帮忙的Agent，就像找朋友一样。
• 任务分配机制：复杂任务可以拆开，分给最擅长的Agent去做。
• 能力展示：每个Agent可以说明自己会做什么，方便别人来找它合作。
• 安全控制：确保只有授权的Agent才能交流，防止信息泄露。

A2A的三个角色

• User（用户）：用于身份验证和权限控制。
• Client Agent（客户端Agent）：发起任务请求的一方。
• Server Agent（服务端Agent）：执行任务的一方。

一个Agent既可以当Client也可以当Server，看具体任务需要。

A2A的工作流程（核心流程图）

多Agent系统的挑战

虽然多个AI助手一起工作能解决更复杂的问题，但目前技术还不成熟：

• 每个Agent只能专注一个小领域，工具不超过10个。
• 如果没有良好的协作机制，成功率还不到50%。
• 比如股票分析团队，一个Agent负责数据分析，另一个负责给出建议。

所以，A2A协议目前更多用于研究，还没有像MCP那样广泛应用。

A2A应用案例：天气与行程规划

我们来看一个简单例子，两个独立的AI助手通过A2A协议协作：

• WeatherAgent（天气助手）：提供天气信息。
• TripAgent（行程助手）：根据天气安排活动。

工作流程如下：

示例代码（模拟A2A通信）

（1）启动天气助手（WeatherAgent）

运行下面的Python代码，启动天气服务：

from flask import Flask, request, jsonify

app = Flask(__name__)

weather_data = {
    "2025-07-15": {"temperature": 25, "condition": "Sunny"},
    "2025-07-16": {"temperature": 18, "condition": "Rainy"},
    "2025-07-17": {"temperature": 22, "condition": "Cloudy"}
}

@app.route('/weather', methods=['GET'])
def get_weather():
    date = request.args.get('date')
    return jsonify(weather_data.get(date, {"error": "No data"}))

if __name__ == '__main__':
    app.run(port=5000)

（2）启动行程助手（TripAgent）

运行下面的代码，启动行程服务：

from flask import Flask, request, jsonify
import requests

app = Flask(__name__)
WEATHER_AGENT_URL = "http://localhost:5000/weather"

@app.route('/plan-trip', methods=['POST'])
def plan_trip():
    data = request.json
    date = data.get('date')
    activity = data.get('activity')

    weather_info = requests.get(WEATHER_AGENT_URL, params={"date": date}).json()

    if "error" in weather_info:
        return jsonify({"error": "Failed to get weather"}), 500

    condition = weather_info["condition"]
    if condition == "Sunny":
        plan = f"Great weather for {activity} on {date}!"
    elif condition == "Rainy":
        plan = f"It's going to rain on {date}. Consider indoors."
    else:
        plan = f"The weather is {condition} on {date}. Proceed with caution."

    return jsonify({"trip_plan": plan})

if __name__ == '__main__':
    app.run(port=5001)

（3）测试运行

在终端运行测试命令：

curl -X POST http://localhost:5001/plan-trip \
     -H "Content-Type: application/json" \
     -d '{"date": "2025-07-15", "activity": "hiking"}'

你会看到类似这样的回复：

{
    "trip_plan": "Great weather for hiking on 2025-07-15!"
}

这个例子展示了两个独立的AI助手如何通过A2A协议进行协作。未来这种模式可以扩展到更复杂的系统中，实现跨平台、跨生态的智能协作。

AG-UI协议

比如，MCP协议规范了Agent和工具之间的通信方式，Agent2Agent协议则让多个Agent之间可以顺畅对话。

但一直有个问题没解决好：用户和Agent之间该怎么沟通才更标准、更高效？

AG-UI协议的出现，就是为了解决这个问题。

AG-UI协议由CopilotKit推出，是一个开源的标准协议，专门用来统一后端Agent和前端界面之间的交互方式。

为什么需要 AG-UI 协议？

在开发智能体（Agent）时，我们已经有了一些标准化的“规则”，比如怎么调用工具、怎么让多个Agent协作。

但到了用户这一端，大家的做法五花八门，没有统一标准。这就导致：

• 想让用户看到Agent一步步思考的过程（比如像打字一样逐字输出），却要自己搭WebSocket服务。
• 想显示工具执行进度（如“生成表格中，已完成50%”），还要支持暂停确认，但实现起来麻烦。
• 要同步大量数据（比如代码或表格），每次都传全量数据效率低。
• 用户想打断Agent说“停一下”，结果流程被打乱，上下文也丢了。

而且不同Agent框架（如LangGraph、CrewAI）的输出格式、状态管理都不一样，前端适配起来特别费劲。

AG-UI 协议：简单又高效的解决方案

AG-UI协议就像是给Agent和用户界面之间架了一座“高速公路”。

它使用一种叫 Server-Sent Events (SSE) 的技术，把Agent的状态和动作变成一串结构化的JSON事件流，实时发给前端。

每个事件都有明确的类型标签，告诉前端这是什么内容。

举几个例子：

• TEXT_MESSAGE_CONTENT：文本一句句输出，就像直播打字。
• TOOL_CALL_START：表示某个工具开始运行，可以在界面上显示进度条。
• STATE_DELTA：只传变化的数据，比如改了一行代码，就只发那一行。
• AGENT_HANDOFF：让多个Agent之间顺利交接任务，像接力跑一样。

你可以把它理解成：如果REST是点菜下单的标准，那AG-UI就是厨房做菜过程的直播标准——你不仅知道菜好了，还知道现在是在切菜还是炒菜。

更方便的是，AG-UI提供了TypeScript和Python的SDK，接入项目就像搭积木一样简单。

不管你的后端是LangGraph、CrewAI还是Mastra，只要接上AG-UI，前端就能轻松“听懂”后端的消息，不需要为每个框架单独定制逻辑。

AG-UI 协议的核心优势

AG-UI 协议是一种连接后端Agent和前端界面的标准化通信方案，解决了传统前后端交互中的几个关键痛点。

核心特点：

(1) 单向实时推送：后端主动向前端发送更新，无需频繁轮询

(2) 结构化事件流：所有消息都是标准JSON格式

(3) 事件驱动：每个事件有明确类型，便于前端识别处理

(4) 状态同步：能实时反映Agent当前状态和操作进展

AG-UI 协议 Python 实现

由于平台的字数限制，这里请参见原文

本文 的 原文 地址

原始的内容，请参考 本文 的 原文 地址

本文 的 原文 地址