Agent 智能体 三大核心协议: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 实现
这是一个前后端配合的 AG-UI 协议演示项目,包含一个后端 Agent 服务和一个前端界面。
文件结构
agui-demo/
├── agent_server.py # 后端服务
├── ui_app.py # 前端应用
└── templates/
└── dashboard.html # 界面页面
(1)后端 Agent 服务 (agent_server.py)
这个文件运行的是一个模拟的智能体服务,它能:
-
接收任务指令(比如开始分析、处理等)
-
模拟执行任务并更新进度
-
实时推送状态和通知给前端
主要功能模块:
-
VirtualAgent
类:模拟一个智能体的状态变化 -
/start-task/<task_type>
接口:接收任务启动请求 -
/agent-events
接口:持续向前端发送事件流(SSE),包括: -
状态更新(state_update)
-
随机通知(notification)
这个服务使用 Flask 框架,运行在 5000 端口。
(2)前端 Web 应用 (ui_app.py)
这个文件负责启动前端网页服务,只做一件事:
-
显示
dashboard.html
页面
使用 Flask 提供静态页面,运行在 8000 端口。
(3)前端界面 (templates/dashboard.html)
这是用户看到的页面,包含:
-
当前 Agent 的状态显示(空闲/工作中/完成)
-
任务进度条
-
开始任务按钮(三种类型)
-
任务结果展示区
-
系统通知区域
-
事件日志记录面板
核心逻辑:
-
使用
EventSource
连接后端 SSE 接口,实时监听事件 -
收到状态更新时,自动刷新 UI
-
收到通知时,在通知栏弹出提示
-
点击按钮发送任务请求给后端
整个项目结构清晰,前后端通过 SSE 实现实时通信,前端根据事件动态更新界面,模拟了一个完整的 AG-UI 协议交互过程。
AG-UI协议的三大亮点
有了 AG-UI 协议,开发智能体应用变得更简单了。它带来了几个明显的好处:
(1) 一套逻辑,多平台通用
你只需要写好后端逻辑,对接 AG-UI 协议,就能在各种框架上运行。不管是用 LangGraph、CrewAI,还是以后换新工具,前端都不需要大改。
(2) 界面自由搭建,随时更换
可以用 CopilotKit 提供的组件快速搭界面,也可以自己用 React 自定义。就算把模型从 GPT-4 换成 Llama-3,前端代码也不用动。
(3) 让 AI 真正变成实用软件
AG-UI 协议让 Agent 不只是“会聊天”的玩具,而是能真正帮你完成任务的实用工具,交互更自然,功能也更强。
AG-UI协议 总结
改写后的内容:
AG-UI协议就像是给AI应用装上了“智能导航”,让前后端之间的沟通更顺畅、更高效。开发者不用再纠结底层通信的问题,可以专心做真正重要的事——设计能帮用户解决问题的功能。对用户来说,AI变得更懂自己,不再是冷冰冰的工具,而是贴心的助手。
不管你是经验丰富的AI开发者,还是刚入门的新手,AG-UI协议都值得你了解一下。它正在带你走进一个更智能的未来,一起探索AI的无限可能。
说明:
-
核心逻辑:AG-UI协议简化了前后端交互,让开发者更容易构建AI应用。
-
流程清晰:从开发者使用协议开始,到最终用户获得更好的体验,整个过程顺畅自然。
如需进一步扩展流程图或结合具体代码生成详细逻辑图,也可以继续补充。
如何学习AI大模型?
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传优快云,朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】
第一阶段: 从大模型系统设计入手,讲解大模型的主要方法;
第二阶段: 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用;
第三阶段: 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统;
第四阶段: 大模型知识库应用开发以LangChain框架为例,构建物流行业咨询智能问答系统;
第五阶段: 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型;
第六阶段: 以SD多模态大模型为主,搭建了文生图小程序案例;
第七阶段: 以大模型平台应用与开发为主,通过星火大模型,文心大模型等成熟大模型构建大模型行业应用。
👉学会后的收获:👈
• 基于大模型全栈工程实现(前端、后端、产品经理、设计、数据分析等),通过这门课可获得不同能力;
• 能够利用大模型解决相关实际项目需求: 大数据时代,越来越多的企业和机构需要处理海量数据,利用大模型技术可以更好地处理这些数据,提高数据分析和决策的准确性。因此,掌握大模型应用开发技能,可以让程序员更好地应对实际项目需求;
• 基于大模型和企业数据AI应用开发,实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能, 学会Fine-tuning垂直训练大模型(数据准备、数据蒸馏、大模型部署)一站式掌握;
• 能够完成时下热门大模型垂直领域模型训练能力,提高程序员的编码能力: 大模型应用开发需要掌握机器学习算法、深度学习框架等技术,这些技术的掌握可以提高程序员的编码能力和分析能力,让程序员更加熟练地编写高质量的代码。
1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集
👉获取方式:
😝有需要的小伙伴,可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓