本文 的 原文 地址
原始的内容，请参考 本文 的 原文 地址
本文作者：
- 第一作者 老架构师 肖恩（肖恩 是尼恩团队 高级架构师，负责写此文的第一稿，初稿 ）
- 第二作者 老架构师 尼恩 （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 实现
由于平台的字数限制，这里请参见原文
