MCP
Model Context Protocol,模型上下文协议,Anthropic于2024年开源的标准协议,旨在统一AI模型与数据源的交互方式,提升数据访问的便捷性和可靠性,提供标准化的工具调用、资源管理和提示词功能。
MCP的基本定义:标准化的通信协议,用于建立AI模型与外部数据源之间的无缝连接。
产生背景
- 传统AI的局限性:传统API集成成本高,不同系统间需定制化接口,开发效率低下(企业需投入30%资源用于接口适配);
- AI应用的扩展需求:随着AI向物理世界渗透(如物联网、工业自动化),亟需支持动态扩展、跨平台协作的协议;
- 封闭生态的突破:OpenAI的Function Call功能复杂且依赖特定平台,而MCP作为中间层协议,兼顾开放性与灵活性。
客户端-服务器模型,使用JSON-RPC协议进行通信。
MCP和传统的API接口相比
维度 | 传统API | MCP |
---|---|---|
交互模式 | 静态、预定义请求-响应 | 动态发现、双向通信 |
适用场景 | 确定性高、需严格控制的场景 | 灵活性高、上下文依赖强的场景 |
开发效率 | 需为每个工具单独编码 | 通过协议标准化实现即插即用 |
安全机制 | 依赖独立权限管理 | 内置沙箱和细粒度权限控制 |
生态扩展性 | 碎片化 | 统一协议促进工具互操作性 |
技术优势:
- 标准化接口:统一JSON-RPC协议,支持跨语言(Python、TypeScript)和跨平台(本地/云端)集成,降低开发成本;
- 模块化架构:将AI系统拆分为独立模块(数据处理、推理服务等),实现即插即用,动态扩展效率提升60%;
- 安全与弹性:通过加密会话ID(Mcp-Session-Id)、细粒度权限控制,保障数据安全;支持断线重连(Last-Event-ID)和消息重传,提升稳定性;
- 高效通信:新增Streamable HTTP传输机制,结合HTTP POST与SSE流,延迟降低40%,带宽利用率提升35%;
- 简化集成:通过统一接口降低AI与外部工具集成复杂性,避免碎片化问题;
- 安全性与可控性:MCP支持双向连接,确保数据安全,并提供细粒度控制;
- 灵活性与扩展性:MCP支持自主工作流的决策和编排,适用于多种跨平台场景。
架构
组成:
- Host:主机,发起连接的LLM应用程序;负责初始化和管理客户端、处理用户授权、管理上下文聚合等。
- Client:客户端,主要在主机应用程序内负责与服务器保持一对一连接。是主机与服务器的桥梁,负责消息路由、能力管理、协议协商和订阅管理等。
- Server:服务器,以标准化协议向客户端提供外部数据和工具,为AI模型提供额外的上下文和功能:
- 工具:Tools,可执行函数,如发送邮件、调用API,;
- 资源:Resources,静态数据,如文件、数据库记录,为AI模型提供实时或历史数据;
- 提示词:Prompts,预定义模板,标准化LLM交互流程,确保模型执行过程中的连贯性和一致性。
- Local/Remote Services:包括本地资源,如文件系统和远程服务,如GitHub、Google Maps API。
工作流程中,MCP Server通过分层定义能力,如数据读取、函数调用、提示模板,使AI Agent根据任务需求自动匹配工具,并通过Function Calling执行操作,例如查询数据库或调用API,最终生成多步骤的连贯响应。
MCP的核心是标准化连接,具体包括:
- 连接任何数据源:无论是公司的销售数据库、你的个人日历,还是一个文件文件夹,MCP 都能让 AI Agent 通过标准接口访问这些资源。
- 提升效率:通过直接连接数据源,AI Agent 可以更快、更准确地完成任务。比如,一个聊天机器人可以用 MCP 实时获取最新的客户信息,而不是让用户等半天。
- 开放和灵活:MCP 是开源的,支持 Python 和 TypeScript 编程语言,开发者可以轻松创建和分享新的连接方式。
工作流程通常包括以下步骤:
- 初始化:主机应用程序启动并初始化客户端,每个客户端与一个服务器建立连接;
- 功能协商:客户端和服务器之间进行功能协商,确定它们可以相互提供哪些功能和服务;
- 请求处理:客户端根据用户请求或AI模型的需要,向服务器发送请求。服务器处理这些请求,并可能与本地或远程资源进行交互;
- 响应返回:服务器将处理结果返回给客户端,客户端再将信息传递回主机应用程序。
核心执行流程如下:
- 客户端(如Claude Desktop/Cursor)从服务器获取可用的工具列表;
- 用户的查询连同工具描述一起发送给LLM(如Claude);
- LLM决定使用哪些工具(如果有的话);
- 客户端通过服务器执行任何请求的工具调用;
- 结果被发送回LLM;
- LLM提供自然语言响应;
- 响应显示给用户。
LLM如何能够选择恰当的工具呢?客户端通过将工具的具体使用描述以文本的形式传递给大模型,供大模型了解有哪些工具可以进行选择。LLM是通过Prompt来确定执行工具,核心Prompt代码如下:
system_message = (
"You are a helpful assistant with access to these tools:\n\n"
f"{tools_description}\n"
"Choose the appropriate tool based on the user's question. If no tool is needed, reply directly.\n\n"
"IMPORTANT: When you need to use a tool, you must ONLY respond with the exact JSON object format below, nothing else:\n"
"{\n"
' tool": "tool-name",\n'
' "arguments": {\n'
' "argument-name": "value"\n'
" }\n"
"}\n\n"
"After receiving a tool's response:\n"
"1. Transform the raw data into a natural, conversational response\n"
"2. Keep responses concise but informative\n"
"3. Focus on the most relevant information\n"
"4. Use appropriate context from the user's question\n"
"5. Avoid simply repeating the raw data\n\n"
"Please use only the tools that are explicitly defined above."
)
messages = [{"role": "system", "content": system_message}]
协议定义4种类型的消息:
- 请求(Request):需要响应的消息;
- 通知(Notification):不需要回复的消息;
- 结果(Result):成功响应请求;
- 错误(Error):请求响应失败。
Transport
MCP支持多种传输机制:
- 标准传输:使用标准输入/输出进行通信;非常适合本地流程。
- 带有SSE传输的HTTP:使用服务器发送事件来发送服务器到客户端的消息;客户端到服务器消息的HTTP POST。
所有传输都使用JSON-RPC 2.0来交换消息。
开源MCP服务器
https://github.com/punkpeye/awesome-mcp-servers
MCPHub
MCPHub,GitHub,一个统一的MCP服务器聚合平台,可以根据场景将多个服务器聚合到不同的流式 HTTP(SSE)端点。它通过直观的界面和强大的协议处理能力,简化AI工具集成流程。
功能:
- 开箱即用的 MCP 服务器支持:无缝集成 amap-maps、playwright、fetch、slack 等常见服务器;
- 集中式管理控制台:在一个简洁的 Web UI 中实时监控所有服务器的状态和性能指标;
- 灵活的协议兼容:完全支持 stdio 和 SSE 两种 MCP 协议;
- 热插拔式配置:在运行时动态添加、移除或更新服务器配置,无需停机;
- 基于分组的访问控制:自定义分组并管理服务器访问权限;
- 安全认证机制:内置用户管理,基于 JWT 和 bcrypt,实现角色权限控制;
- Docker 就绪:提供容器化镜像,快速部署。
安装
Docker命令行方式:
docker run -d \--restart unless-stopped \--name mcphub \-p 3535:3000 \samanhappy/mcphub:latest-full
docker-compose安装,docker-compose.yml
文件:
version: '3'
services:mcphub:image: samanhappy/mcphub:latest-fullcontainer_name: mcphubrestart: unless-stoppedports:- 3535:3000
执行docker-compose up -d
完成安装。
在浏览器中输入http://localhost:3535
就能看到登录界面,默认用户名/密码为admin/admin123
:
如上图所示,当前最新版是0.6.2,默认自带4个服务:
- amap:有12个Tools
- playwright:25个
- fetch:1个
- slack:8个
Server操作页面
点击某个Server可看到具体的Tools
Server Market界面:
添加Server:
- 从Market市场添加
- 添加其他自定义
分组功能
MCPHub支持sse和mcp两种协议,
A2A
2025年4月9日,谷歌推出Agent2Agent开放标准,旨在最大限度地发挥代理型人工智能的优势,使代理能够跨孤立的数据系统和应用程序,在动态的多代理生态系统中协作。即使代理是由不同的供应商或不同的框架构建的,让它们能够相互操作,也能提升自主性,成倍提高生产力,同时降低长期成本。简单来说,让不同的Agent能够互相通信和协作,一种应用层面的协议,允许智能体作为智能体(或作为用户)而非作为工具来进行通信。
A2A 促进客户端代理与远程代理之间的通信。客户端代理负责制定和传达任务,而远程代理负责执行这些任务,以提供正确的信息或采取正确的行动。涉及几个关键功能:
- 安全协作 :代理可以互相发送消息来传达上下文、回复、工件或用户指令。这些是默认安全的。与MCP相比,A2A确实安全考虑得比较多;
- 任务管理 :客户端与远程代理之间的通信以任务完成为导向,代理负责执行最终用户的请求。此“任务”对象由协议定义,并具有生命周期。它可以立即完成,也可以长时间运行,每个代理可以进行通信,以彼此保持同步,了解任务的最新完成状态;
- 用户体验协商:每条消息包含“部分”,即完整形成的内容片段,例如生成的图像。每个部分都有指定的内容类型,允许客户端和远程代理协商所需的正确格式,并明确包含对用户 UI 功能(例如 iframe、视频、Web 表单等)的协商;
- 能力发现:代理可以使用 JSON 格式的“代理卡”来宣传其能力,从而允许客户端代理识别能够执行任务的最佳代理并利用 A2A 与远程代理进行通信。
设计原则
A2A 是一种开放协议,它为代理之间协作提供一种标准方式,不受底层框架或供应商的限制。在与合作伙伴设计该协议时,应遵循五项关键原则:
- 拥抱代理能力:A2A 致力于使代理能够以自然、非结构化的模式进行协作,即使它们不共享内存、工具和上下文。我们正在实现真正的多代理场景,而不将代理局限于单一的工具;
- 基于现有标准:该协议建立在现有的流行标准之上,包括 HTTP、SSE、JSON-RPC,这意味着它更容易与企业日常使用的现有 IT 堆栈集成;
- 默认安全:A2A 旨在支持企业级身份验证和授权,在启动时与 OpenAPI 的身份验证方案相同;
- 支持长时间运行的任务:我们设计 A2A 时就考虑到了灵活性,并支持各种场景,使其能够出色地完成各种任务,从快速任务到深度研究,这些任务可能需要数小时甚至数天的时间(如果人工参与)。在此过程中,A2A 可以为用户提供实时反馈、通知和状态更新;
- 与模态无关:代理世界不仅限于文本。
技术组件
组件 | 描述 |
---|---|
代理卡 | 位于/.we11-known/agent.json ,描述能力、技能、端点URL和认证要求,用于发现 |
A2A服务器 | 暴露HTTP端点,实现A2A协议方法,管理任务执行,GitHub规范 |
A2A客户端 | 消费A2A 服务的应用或代理,发送请求如tasks/send 或tasks/sendSubscribe |
任务 | 工作单位,有唯一ID,状态包括submitted、working 等,支持即时和长期任务。任务具有唯一 ID ,tasks/sendSubscribe并会经历不同的状态(submitted、working、input-required、completed、failed、cancled |
消息 | 通信轮次,角色为user或agent,包含部分(Part) |
部分 | 消息或工件的内容单位,类型包括TextPart、FilePart(内联或URI)、DataPart(JSON) |
工件 | 任务输出,如文件或结构化数据,包含部分 |
流式处理 | 长期任务使用SSE事件更新,客户端通过tasks/sendSubscribe 接收 |
推送通知 | 服务器通过客户端webhook URL发送任务更新 |
A2A对比MCP
方面 | MCP | A2A |
---|---|---|
主要功能 | 让AI代理连接到工县和数据源 | 让AI代理互相通信和协作 |
关注点 | 智能体到工具的交互 | 智能体到智能体的交互 |
典型场景 | 代理访问数据库或日历软件 | 多个代理协同完成任务(如招聘流程) |
技术重点 | 数据源集成、标准接口 | 代理间消息交换、多模态支持 |
图片来源:https://x.com/_avichawla/status/1910225354817765752
AG-UI
Agent User Interaction Protocol,智能体用户交互协议,是一个开源的、轻量的、基于事件的协议,由CopilotKit公司发布,它通过标准HTTP或可选的二进制通道,以流式方式传输一系列JSON事件,主要用来对AI Agent和前端应用程序的交互进行标准化。官方文档。
CopilotKit公司的人员解释,当前大多数Agent都属于后端自动化工具,执行一些数据迁移、表单填写、内容总结一类的任务,这些Agent在后台运行,对用户不可见。但是交互式Agent(如Cursor、Windsurf、Devin等)已经实现与用户的实时协同工作,它们也将带来海量的应用场景。这种情况下,就需要这些Agent能够具备实时更新、工具编排、可共享的可变状态、安全边界控制以及前端同步等能力。为此他们构建并发布AG-UI协议。
AG-UI 为 AI Agent和前端应用程序之间搭建了一座桥梁,让这两者之间的交互更加友好,为用户带来更好体验。示意图如下:
讲解:
- Application:用户交互用到的应用程序(如chat或其他任何AI应用);
- AG-UI 客户端:通用的通信客户端,诸如HttpAgent,或用于连接现有协议的专用客户端;
- Agent:后端用户处理用户请求并生成流式响应的Agent;
- Secure Proxy:能够提供额外能力或作为安全代理的后端服务。
核心组件
AG-UI 的核心组件包括协议层(Protocol Layer)、标准化HTTP客户端(Standard HTTP Client)、消息类型(Message Type)、运行智能体(Running Agent)、状态管理(State Management)、工具交接(Tools and Handoff)以及事件(Events)。
- 协议层(Protocol Layer):主要为Agent通信提供一个灵活的基础。协议的核心让应用程序能够运行Agent并且接受到事件流。
- 标准HTTP客户端:HttpAgent,可用于连接任何支持POST请求的端点,接收RunAgentInput类型的请求体,并返回BaseEvent对象的数据流。HttpAgent支持HTTP SSE(Server-Sent Events)和HTTP binary protocol两种模式。
- 消息类型:AG-UI为Agent通信的不同方面定义一些事件策略,主要包括:
- Lifecycle events:监控Agent的运行情况。Agent的运行状态可能包含RunStarted、StepStarted/StepFinished、RunFinished(成功)、RunError(失败);
- Text message events:用于处理文本流式内容的事件。这些事件遵循流模式,并以增量的方式交付内容。文本消息可能以TextMessageStart开始,然后用TextMessageContent事件来交付文本,最后以TextMessageEnd事件结束;
- Tool call events:管理Agent对工具的执行。当Agent想要使用某个tool时,会触发一个ToolCallStart事件,随后会有ToolCallArgs事件,用于流式传输传递给工具的参数,最后以一个ToolCallEnd事件结束;
- State management events:同步Agent和UI之间的状态。协议中的状态管理采用高效的快照-增量模式:初始或偶尔发送完整的状态快照,而持续的变更则通过增量更新(delta)来传递。快照能够确保前端有完整的状态上下文,而delta最小化需要频繁更新的数据传输。两者的有效结合,可以使前端不进行不必要数据传输的情况下,保持对Agent状态的准确呈现。包括的事件有StateSnapshot和StateDelta。
- Special events:支持自定义功能,比如和外部系统集成。包括的事件由Raw和Custom。
- 运行 Agent:创建Agent客户端实例并启用Agent。
- 状态管理:AG-UI通过专用事件对状态进行管理,目前提供的事件有:
- STATE_SNAPSHOT:某一时刻的完整状态表示;
- STATE_DELTA:使用JSON补丁格式(RFC 6902)的增量状态变更;
- MESSAGES_SNAPSHOT:表示完整的对话历史;
- 工具和交接:通过标准化事件来提供Agent之间的任务移交的和工具的使用。
- 事件:AG-UI中的所有通信都是基于类型事件。每一个事件都继承自BaseEvent,其接口如下:
interface BaseEvent {type: EventTypetimestamp?: numberrawEvent?: any
}
目前官方已经提供TypeScript和Python SDK来对协议进行开发使用。
MCP vs A2A vs AG-UI
相比于MCP和A2A,AG-UI主要聚焦在智能体和用户(Agent-user)的交互层上。它和MCP、A2A并不是竞争关系。这三者在AI生态中的作用不同:
- AG-UI:主要处理由用户参与的交互以及流式更新用户界面;
- A2A:主要促进智能体(Agent-to-Agent)之间的通信和协作;
- MCP:主要解决跨不同模型之间工具调用的标准化和上下文处理问题;
这三者互为补充。举个简单的例子:相同的Agent可通过A2A来跟其他的Agent进行通信,同时又使用AG-UI来跟用户进行交互,另外还能通过MCP来进行工具的调用(tool call)。这三个协议,完成用户-Agent-LLM之间交互的标准化。
三个协议构成的Agent协议栈: