Agent框架協議“三部曲”：MCP、A2A、AG-UI

近期關注AI行業動態的人士應該能觀察到一個趨勢，基礎模型訓練領域正日益呈現出寡頭壟斷的特徵，而AI應用創新的前景和空間依然開闊，令人興奮的AI應用層出不窮。一個完整的AI應用系統中常常包括三個主要角色：使用者、AI Agent、外部工具，AI互動系統的核心之一是解決這三個角色之間的通訊問題。

本文針對Agent框架的三個主流協議進行介紹，包括MCP協議——解決AI Agent和外部工具互動問題；A2A協議——解決Agent間通訊問題；AG-UI協議——解決AI Agent與前端應用之間的互動標準化問題。隨著AI應用的蓬勃發展，AI相關的規範和標準如協議開始出現在大眾眼前，本文主要介紹其產生背景、實現思路、在AI應用中實踐。

Agent 應用協議棧

來源：https://github.com/ag-ui-protocol/ag-ui

MCP協議

MCP全稱是Model Context Protocol（模型上下文協議），由Claude母公司Anthropic於24年11月開源釋出，以下是MCP開源專案近期的Star數增長趨勢，可以看到自今年3月以來，MCP迎來了井噴式的發展和關注量。今年3月27日，OpenAI宣佈在Agent SDK中支援MCP，4月4日，谷歌宣佈在Gemini的官方API文件中新增MCP的使用範例，海外三大AI巨頭已經全部投入MCP懷抱。

MCP Github Star History

來源：https://star-history.com

MCP協議的出現離不開Function Calling的使用，2023年6月，OpenAI 在 GPT-4-0613 和 GPT-3.5-turbo-0613 模型中首次引入Function Calling功能，賦予Agent執行具體任務的能力。透過Function Calling，模型能夠根據上下文理解並執行特性函式呼叫，比如搜尋知識庫、搜尋天氣地理等即時資訊、執行數學計算等。之後，谷歌、Anthropic也陸續推出模型的Function Calling能力。但是不同的模型的廠商在Function Calling的能力上的介面、格式、細節上存在諸多不相容，舉例如下：

這些細節差異導致開發者需要針對不同模型做適配函式宣告、引數傳遞、響應解析等環節，極大增加了AI開發者對於多模型整合的複雜度。因此，MCP作為一個通用協議被提出，旨為模型提供一個標準化的方式來管理和利用上下文，並提供統一的協議與外部世界（工具、服務、資料）進行互動。以這張經典的示例圖為比如，使用MCP如同電腦插入USB-C介面後，簡化了各種外部裝置的適配。AI模型透過MCP可以輕鬆呼叫各種資料來源和工具。

MCP 架構示例圖

來源：Norah Sakalon Xhttps://x.com/norahsakal/status/1898183864570593663

值得注意的是，支援 MCP的模型通常需要支援 Function Calling，但Function Calling不是唯一實現方式。理論上，只要模型能理解和生成結構化的呼叫協議，比如 JSON-RPC、gRPC、RESTful API等，就可以實現 MCP能力。Function Calling是最主流、最推薦的實現 MCP 的方式。

開發者想要快速體驗一下MCP服務僅需三個步驟：

準備MCP Host：目前市面上已有不少MCP的客戶端，用的比較多的工具包括Cursor、Windsurf、Cline等，本文以Cursor為例，介紹MCP的使用;
環境配置：MCP Server 本質上就是Node.js或者Python程式，所以在配置 MCP 前，使用者需要安裝 Node.js（包含 npm 或 npx）和 Python 環境;
MCP配置：可以在MCP官方選擇一個熱門的MCP Server，比如本地系統檔案操作filesystem，在Cursor中的MCP配置中新增配置如下，具體Server列表和配置可以從官方地址獲取：

Model Context Protocol servers：https://github.com/modelcontextprotocol/servers;

MCP Server 配置

完成上述配置後，在Cursor中選擇Agent模式，即可透過自然語言進行本地檔案操作。對於和檔案系統相關的query，Agent自動呼叫filesystem的MCP Server工具，過程中會詢問使用者授權操作，呼叫MCP Server Tool如 create_directory、write_file、search_files等：

MCP 操作效果

除此之外，還有大量可用的MCP Server服務，熱門的比如 Git、Playwright、Times，國內各個網際網路產品也推出了自己的MCP Server，比如支付寶、高德地圖、阿里雲無影AgentBay、12306等。以無影AgentBay為例，公測期間申請服務Apikey並按照官網指導進行MCP Server配置後，即可透過自然語言操作雲電腦，其覆蓋 Linux、Windows、Android、瀏覽器等映象環境。

AgentBay MCP Server使用示例

隨著MCP生態的快速發展，也衍生出MCP的“集散地”如 mcp.so 和 smithery.ai，目前已釋出了數千個MCP Server。MCP 讓Agent中對外部世界的工具“即插即用”，大量減少重複造輪子的工作，AI應用開發者可以使用開源的MCP Server或者定義自己的MCP Server，提高接入工具的效率。

A2A協議

25年3月，在MCP出圈的同時，谷歌也推出了MCP的“補充”：A2A（Agent2Agent）協議。雖然A2A和MCP都是透過開放和標準化的方式，解決AI系統中不同單元的整合和互動問題，但是A2A和MCP的目標和作用域有本質區別。MCP解決的是Agent和外部工具/資料的整合，是Agent的“家務事”；而A2A致力於促進獨立Agent間的通訊，幫助不同生態系統的Agent溝通和協作。

Agentic Application 示例

來源：https://a2aprotocol.ai/

舉個例子，我的微信朋友圈中有個業務廣泛的“黃牛總代”，這個黃牛合作了各領域的“黃牛”，比如演唱會和賽事搶票、醫院熱門號、靈隱寺月餅代排等，他們使用專用手段，例如內部渠道、指令碼、人肉排隊等方式解決使用者需求。各領域黃牛就是Agent，MCP是將這些Agent與它們的結構化工具（例如搶票指令碼）連線起來的協議。而A2A是使用者或者黃牛總代Agent與黃牛Agent合作的協議，例如“我要一張周杰倫演唱會的門票”。基於A2A協議，Agent間可以進行雙向溝通，不斷最佳化計劃，例如“我要6月23日門票”、“江浙滬地域任何價位都可以接受”，最終實現目標。

A2A作為一個開放協議，主要考慮Agent間通訊在使用者、企業互動上的主要問題挑戰，官方介紹其主要功能特性如下：

A2A 協議示例

來源：https://a2aprotocol.ai/

標準化訊息格式（Standardized Message Format）：就像人們交流需要共同的語言，A2A為AI Agent們建立了一種統一的"語言"，讓它們能夠清晰地表達“我需要什麼”、“這是我的回答”等資訊
發現機制（Discovery Mechanism）：在社交網路中，AI Agent可以“搜尋”並瞭解其他AI Agent能做什麼，然後決定與誰“交朋友”。
任務委派框架（Task Delegation Framework）：類似於專案經理分配工作，一個AI Agent面對複雜問題時，可以把不同部分分給最擅長處理這些問題的其他AI Agent。
能力廣告（Capability Advertisement）：就像在招聘網站上釋出簡歷，每個AI Agent可以“宣傳”自己的特長，形成一個服務市場。
安全和訪問控制（Security and Access Control）：相當於門禁系統，確保只有獲得授權的AI助手才能互相交流，防止資訊洩露或未經授權的操作。

A2A中包含三個核心者：User，存在於協議中，主要的作用是用於認證&授權；Client Agent，任務發起者；Server Agent，任務的執行者。Client和Server之間通訊是以任務的粒度進行，每個Agent既可以是Client，也可以是Server。A2A的典型工作流程如下：

A2A 典型工作流

值得關注的是，多Agent系統（Multi-Agent System, MAS）是Agent系統的發展趨勢，因為它更適用於解決複雜問題求解、分散式任務、模擬社會系統等問題，在多Agent系統中，每個Agent 專注單一領域，工具少於10個，團隊協作需推理支援否則成功率低（目前成功率<50%）。以股票分析團隊為例，需要一個Agent專注分析股票資料，另一個Agent提供股票操作建議。

但是，2025年MAS系統仍不成熟，業內對於單Agent還是多Agent仍存在大量爭論，MAS系統的設計和協調機制複雜度高，行為難以預測和控制，目前更適合研究而非生產，所以A2A協議沒有像MCP協議快速發展和普及。

AG-UI 協議

AG-UI（Agent-User Interaction Protocol，智慧體使用者互動協議）是2025年5月由 CopilotKit 團隊發起並開源的協議，旨在解決AI Agent與前端應用之間的互動標準化問題，提供一個輕量級、事件驅動的開放協議，實現AI Agent與使用者介面的即時雙向通訊。AG-UI 協議的出現主要是為了解決智慧體與前端應用之間的互動以下標準化問題，其工作流如下：

客戶端透過 POST 請求發起一次 AI Agent 會話；
建立 HTTP 流，如 SSE 或 WebSocket 等協議，實現事件的即時監聽與傳輸；
每個事件都包含型別和元資訊 Metadata，用於標識和描述事件內容；
AI Agent 持續以流式方式將事件推送至 UI 端；
UI 端根據收到的每條事件，即時動態更新介面；
同時，UI 端也可以反向傳送事件或上下文資訊，供 AI Agent 即時處理和響應；

AG-UI 工作流示例

圖來源：https://webflow.copilotkit.ai

在AG-UI 協議中最核心的部分在於事件的定義：

文字訊息事件（TEXT_MESSAGE_）用於即時流式文字生成，類似AI Copilot的打字效果；
工具呼叫事件（TOOL_CALL）用於完整的工具呼叫生命週期管理；
狀態管理事件（STATE）用於狀態同步，確保客戶端和服務端狀態一致；
生命週期事件（RUN* / STEP_）進行執行控制，管理整個代理執行的生命週期；

AG-UI 協議的事件型別定義體現了 AI Agent 系統的核心需求：流式處理、狀態管理、工具整合、錯誤處理、可擴充套件性。協議的設計既考慮了技術實現的效率，也兼顧了使用者體驗的流暢性，是現代 AI 應用系統設計的重要參考。

目前AG-UI 協議官方推出了Python SDK和TypeScript SDK。筆者親測使用 AG-UI 協議實現服務端和客戶端的互動。以Python為例，可以使用ag-ui-protocol 包的 from ag_ui.core 相關能力來生成 AG-UI 協議事件，而不是手寫 JSON。ag-ui-protocol 的核心事件定義在 ag_ui.core.events，它支援透過用 TextMessageStartEvent、TextMessageContentEvent、TextMessageEndEvent 這些類來構造事件，然後用 .model_dump_json() 輸出。

可以使用Cursor 基於AG-UI 協議實現服務端和客戶端程式碼。在進行服務端和客戶端程式碼除錯時，可使用瀏覽器BrowserTools的外掛，並且為Cursor配置 BrowserTools MCP Server，這樣透過 Call MCP Tool 讓 Cursor可以快速定位和除錯瀏覽器行為如下圖，幾輪對話互動後即可實現一個簡單的AG-UI協議的前後端應用：