MCP

Model Context Protocol，模型上下文协议，Anthropic于2024年开源的标准协议，旨在统一AI模型与数据源的交互方式，提升数据访问的便捷性和可靠性，提供标准化的工具调用、资源管理和提示词功能。

MCP的基本定义：标准化的通信协议，用于建立AI模型与外部数据源之间的无缝连接。

产生背景

• 传统AI的局限性：传统API集成成本高，不同系统间需定制化接口，开发效率低下；
• AI应用的扩展需求：随着AI向物理世界渗透（如物联网、工业自动化），亟需支持动态扩展、跨平台协作的协议；
• 封闭生态的突破：OpenAI的Function Call功能复杂且依赖特定平台，而MCP作为中间层协议，兼顾开放性与灵活性。

客户端-服务器模型，使用JSON-RPC协议进行通信，兼容OAuth2等企业级安全标准。

三大核心能力

• 上下文数据注入：外部数据能通过标准化接口直接进入模型工作内存，可避免因数据格式不统一而导致的兼容问题；
• 功能路由与调用：工具调用；
• 提示词编排：动态组装上下文，只加载相关信息，省 token、更精准，输出结果自然更靠谱。

对比传统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，最终生成多步骤的连贯响应。

核心是标准化连接，具体包括：

• 连接任何数据源：数据库、个人日历、本地文件…
• 提升效率：通过直接连接数据源，Agent可更快更准确地完成任务；
• 开放和灵活：支持Python和TS编程语言，开发者可轻松创建和分享新的连接方式。

工作流程通常包括以下步骤：

• 初始化：主机应用程序启动并初始化客户端，每个客户端与一个服务器建立连接；
• 功能协商：客户端和服务器之间进行功能协商，确定它们可以相互提供哪些功能和服务；
• 请求处理：客户端根据用户请求或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)：请求响应失败。

MCP支持多种传输机制：

• stdio：使用标准输入/输出进行通信，非常适合本地流程；
• SSE：使用服务器发送事件来发送服务器到客户端的消息；客户端到服务器消息的HTTP POST。
• 流式HTTP：

所有传输都使用JSON-RPC 2.0来交换消息。

ACP

BeeAI和IBM提出的ACP（Agent Communication Protocol，代理通信协议）就是边缘环境的内部通信系统。专为本地设备设计，追求低延迟、少依赖，堪称AI代理的对讲机协议。

架构

• 去中心化设计：每个代理通过本地广播暴露身份和能力，不需要中央服务器协调，大大提高系统的灵活性和抗故障能力。即使某个代理出现故障，也不会影响整个系统的运行。
• 事件驱动通信：用本地总线或进程间通信（IPC）传递消息，比网络传输快得多。当有事件发生时，相关代理能迅速收到消息并做出响应，比如在智能家居中，当有人按下门铃时，门铃代理会通过事件驱动通信将这一事件告知门锁代理和摄像头代理，实现门锁自动解锁和摄像头启动录像的联动。
• 轻量运行时：代理作为无状态服务或容器运行，共享通信基础，适合资源有限的设备。这使得ACP可以在像传感器、小型控制器等资源受限的边缘设备上运行，扩大其应用范围。

适用场景：

• 超低延迟，适合无人机、机器人车队等实时响应场景；
• 无需云依赖，断网也能工作，如工厂车间、偏远矿区；
• 支持能力自动识别，代理间能自主分工，物流仓库机器人。

A2A

2025年4月9日，谷歌推出Agent2Agent开放标准，旨在最大限度地发挥Agent优势，使代理能够跨孤立的数据系统和应用程序，在动态的多代理生态系统中协作。即使代理是由不同的供应商或不同的框架构建的，让它们能够相互操作，也能提升自主性，成倍提高生产力，同时降低长期成本。让不同Agent能够互相通信和协作，一种应用层协议，允许智能体作为智能体（或作为用户）而非作为工具来进行通信。

通过利用HTTP、SSE和JSON-RPC等主流互联网标准，实现通信的标准化和模块化设计。

A2A促进客户端代理与远程代理之间的通信。客户端代理负责制定和传达任务，而远程代理负责执行这些任务，以提供正确的信息或采取正确的行动。涉及几个关键功能：

• Agent Card：智能体卡，相当于公开名片，JSON文档，详细描述身份信息、自身能力（可提供的服务）、接口（端点）、安全认证要求、运行时元数据，使得系统在接到任务时能够迅速找到最合适的Agent来完成协同工作。
• 安全协作：代理可以互相发送消息来传达上下文、回复、工件或用户指令。这些是默认安全的。内置企业级身份验证和加密机制，确保只有经过授权的智能体才能参与数据交换，有效防止恶意入侵和信息泄露。
• 任务管理：客户端与远程代理之间的通信以任务完成为导向，代理负责执行最终用户的请求。此任务对象由协议定义，并具有生命周期。它可以立即完成，也可以长时间运行，每个代理可以进行通信，以彼此保持同步，了解任务的最新完成状态；
• 用户体验协商：每条消息包含部分，即完整形成的内容片段，例如生成的图像。每个部分都有指定的内容类型，允许客户端和远程代理协商所需的正确格式，并明确包含对用户UI功能（例如iframe、视频、Web表单等）的协商；
• 能力发现：代理可使用JSON格式的代理卡来宣传其能力，从而允许客户端代理识别能够执行任务的最佳代理并利用A2A与远程代理进行通信。

A2A是一种开放协议，为代理之间协作提供一种标准方式，不受底层框架或供应商的限制。在与合作伙伴设计该协议时，应遵循五项关键原则：

• 拥抱代理能力：A2A致力于使代理能够以自然、非结构化的模式进行协作，即使它们不共享内存、工具和上下文。我们正在实现真正的多代理场景，而不将代理局限于单一的工具；
• 基于现有标准：该协议建立在现有的流行标准之上，包括HTTP、SSE、JSON-RPC，这意味着它更容易与企业日常使用的现有IT堆栈集成；
• 默认安全：A2A旨在支持企业级身份验证和授权，在启动时与OpenAPI的身份验证方案相同；
• 支持长时间运行的任务：支持各种场景，使其能够出色地完成各种任务，从快速任务到深度研究，这些任务可能需要数小时甚至数天的时间。A2A可为用户提供实时反馈、通知和状态更新；
• 与模态无关：代理世界不仅限于文本。

基于A2A的集成架构

技术组件

组件	描述
代理卡	位于/.well-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发送任务更新

对比ACP

区别：

• ACP：主要用于本地代理之间的实时通信
• A2A：解决不同平台AI代理的语言互通问题

对比MCP

方面	MCP	A2A
主要功能	让AI代理连接到工县和数据源	让AI代理互相通信和协作
关注点	智能体到工具的交互	智能体到智能体的交互
典型场景	代理访问数据库或日历软件	多个代理协同完成任务(如招聘流程)
技术重点	数据源集成、标准接口	代理间消息交换、多模态支持

图片来源：https://x.com/_avichawla/status/1910225354817765752

MCP、ACP、A2A

特性	MCP	ACP	A2A
主要关注点	LLM的上下文注入	代理的本地协调	跨平台代理通信
架构	客户端-服务器（主机/服务器模型）	去中心化，本地运行时	基于HTTP的客户端/服务器，带有代理卡
范围	垂直集成（工具→模型）	本地优先的代理运行时	水平集成（代理↔代理）
发现机制	服务器上的工具注册表	本地广播/运行时注册	通过HTTP(S)的代理卡
传输协议	HTTP(S),JSON	灵活：IPC，ZeroMQ，gRPC	基于HTTPS的JSON-RPC2.0
安全模型	应用层认证、OAuth2、范围化API	运行时沙箱、私有网络安全	OAuth2、范围化端点暴露
最佳适用场景	需要外部数据/工具的LLM应用	边缘AI、嵌入式系统、离线代理	跨平台的多代理工作流
示例用例	将LLM连接到内部API	设备上多个小型代理的协调	分布式企业代理协作

AG-UI

Agent User Interaction Protocol，智能体用户交互协议，一个开源（GitHub，7.9K Star，712 Fork）轻量的基于事件的协议，由CopilotKit公司发布，通过标准HTTP或可选的二进制通道，以流式方式传输一系列JSON事件，主要用来对AI Agent和前端应用程序的交互进行标准化。官方文档。

当前大多数Agent都属于后端自动化工具，执行一些数据迁移、表单填写、内容总结一类的任务，这些Agent在后台运行，对用户不可见。但交互式Agent（如Windsurf、Devin等）已经实现与用户的实时协同工作，它们也将带来海量的应用场景。这种情况下，就需要这些Agent能够具备实时更新、工具编排、可共享的可变状态、安全边界控制以及前端同步等能力。

AG-UI为AI Agent和前端应用程序之间搭建一座桥梁。

讲解：

• Application：用户交互用到的应用程序，如chatbot；
• AG-UI客户端：通用的通信客户端，诸如HttpAgent，或用于连接现有协议的专用客户端；
• Agent：后端用户处理用户请求并生成流式响应的Agent；
• Secure Proxy：能够提供额外能力或作为安全代理的后端服务。

关键特点：

• 事件驱动的实时交互：AG-UI定义标准化的事件模型，支持前后端之间保持持续的事件流通信。代理的一举一动（发送消息、调用工具、状态更新等）都会以事件形式推送给前端；用户的操作（输入消息、点击按钮等）也作为事件发送给后端。协议规范了十余种事件类型（例如文本消息事件、工具调用开始事件、状态更新事件等），涵盖了常见的交互场景。前端通过订阅事件流可以实时获取AI的进展，不用频繁轮询；后端通过监听事件可以即时响应用户输入。
• 双向协作：AG-UI支持真正的双向协同。智能体能够连续输出内容给用户，也能根据用户反馈调整自己的行为（Humain-in-the-Loop）；而前端也可根据智能体的状态实时渲染UI（比如显示处理进度、工具调用的结果等），或把UI上的动作实时反馈给智能体。这使得AI更像一个随时互动的助手而非被动回答的机器。

核心组件

包括Protocol Layer、Standard HTTP Client、Message Type、运行智能体(Running Agent)、状态管理(State Management)、工具交接(Tools and Handoff)、Events。

• 协议层：主要为Agent通信提供一个灵活的基础。协议的核心让应用程序能够运行Agent并且接受到事件流。
• 标准HTTP客户端：HttpAgent，可用于连接任何支持POST请求的端点，接收RunAgentInput类型的请求体，并返回BaseEvent对象的数据流。HttpAgent支持HTTP SSE和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: EventType
  timestamp?: number
  rawEvent?: any
}

目前官方已经提供TypeScript和Python SDK来对协议进行开发使用。

MCP、A2A、AG-UI

相比于MCP和A2A，AG-UI主要聚焦在智能体和用户（Agent-user）的交互层上。它和MCP、A2A并不是竞争关系。这三者在AI生态中的作用不同：

• AG-UI：主要处理由用户参与的交互以及流式更新用户界面；
• A2A：主要促进智能体（Agent-to-Agent）之间的通信和协作；
• MCP：主要解决跨不同模型之间工具调用的标准化和上下文处理问题；

这三者互为补充。举个简单的例子：相同的Agent可通过A2A来跟其他的Agent进行通信，同时又使用AG-UI来跟用户进行交互，另外还能通过MCP来进行工具调用。这三个协议，完成用户-Agent-LLM之间交互的标准化。

三个协议构成的Agent协议栈：

ANP

Agent Network Protocol，代理网络协议，GitHub，开源（GitHub，1K Star，67 Fork）

最符合主动推理和空间网络的要求。建立在分布式标识符(distributed identifiers，DIDs)和JSON-LD链接数据之上，它允许智能体在语义上描述自己，在全局范围内发现彼此，并进行对等通信。ANP采用去中心化的身份安全通信，基于关联数据的语义建模，通过开放注册表或搜索索引智能体的描述进行发现。

架构

核心概念是Interface，包括自然语言接口和结构化接口，将智能体交互方式的定义下放到了Interface中，支持自主发现、去中心化身份验证和语义推理，虽然 ANP 目前不支持像 rgm 这样的预测或分层推理体系结构，但是它的基础设施可以提供传输和发现层的智能体。

智能体描述则是基于JSON-LD和语义网，其目的是提高两个智能体对信息理解的一致性。ANP语义网Linked-Data技术，目标是构建一个便于AI访问和理解的AI原生数据网络。

ANP可能缺乏共享的全局上下文和空间网络提供的事务性知识图谱，能够连接智能体，但不连接它们的环境。这或许是空间网络开始接管的地方。

MCP、ACP、A2A、ANP

特性	MCP	ACP	A2A	ANP
功能聚焦	面向大模型的上下文注入	智能体的本地协作	跨平台的智能体通信	跨平台跨网络的智能体通信
通信模型	客户机/服务器（host/server模型）	去中心化的本地运行时	基于HTTP的客户机/服务器，采用智能体Cards	基于HTTP的客户机/服务器，采用JSON-LD
应用范围	垂直集成（模型调用工具）	本地优先的智能体运行时	智能体之间的水平集成	开放网络中智能体之间的水平集成
发现机制	在服务器上的工具注册	本地广播/运行时注册	HTTP上的A2A.json	HTTP上的智能体-descriptions
传输协议	HTTP(s),JSON	IPC,ZeroMQ,gRPC(灵活)	HTTP(s),JSON-RPC20	HTTP(s),JSON-LD
安全模型	App层验证，OAuth2，有范围的API	运行时沙箱，私有网络的安全性	OAuth2，受限的开放端点	W3CDID技术构建去中心化的身份认证
适用场景	大模型应用访问外部数据或外部工具	边缘智能，嵌入式系统，离线智能体	跨平台多智能体工作流	跨网络跨平台的多智能体工作流
用例	大模型连接一组内部的API	设备内的多个小智能体协调	企业级分布式智能体的协作	互联网分布式智能体的协作

推荐阅读

• 从语义网到知识图谱