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協議棧：