AI應用標準詳解：A2A MCP AG-UI

"OpenAI接入MCP，Google推出A2A，微軟與OpenAI緊密綁定"標志著云計算競爭焦點已從"算力"和"模型參數"轉向?Agent標準協議控制權?。在AI快速演進的今天，我們不再僅關注單個AI的智能水平，而是探索多個AI如何像團隊一樣協作完成復雜任務。如果說過去的AI是"孤島"，那么隨著A2A和MCP協議的提出，我們正邁入"AI群體智能"時代。

AI時代的三大關鍵標準解析

1. ?MCP協議（Agent-工具交互標準）?

?核心作用?：解決AI Agent與外部工具（如數據庫、API）的交互問題
?典型場景?：
不同天氣預報Agent調用氣象API時遵循統一數據格式
電商客服Agent與庫存系統接口實時同步商品狀態
?行業動態?：OpenAI率先接入該協議，推動其成為工具交互的事實標準

2. ?A2A協議（Agent間通信框架）?

?核心作用?：規范不同Agent之間的協作規則
?實現機制?：
采用類HTTP的請求-響應模式
內置沖突解決和任務分配算法
?案例?：Google的旅行規劃Agent通過A2A協議協調航班預訂、酒店推薦等子Agent

3. ?AG-UI協議（人機交互標準化）?

?創新點?：統一AI Agent與前端應用的交互方式
?價值體現?：
開發者無需為每個AI應用單獨設計UI邏輯
支持多模態交互（語音、文本、AR等）的快速適配

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

添加圖片注釋，不超過 140 字（可選）

MCP的定義

MCP（Model Context Protocol）是為 AI 智能體提供的工具調用規范說明。簡單來說，它定義了：

? AI 可以訪問哪些服務或工具（比如數據庫、接口、第三方 API）；
? 每個服務的調用方式、參數要求、輸入輸出格式；
? 如何描述一個任務的執行流程與能力邊界。

MCP 的核心作用是：讓 AI 能夠像人類操作軟件一樣，獨立調用外部系統資源，完成具體任務。

示例場景：

假設某 AI 負責生成日報，并需要從數據庫中提取銷售數據、調用圖表接口生成可視化圖表、再通過郵件系統發送至管理層。

如果它事先擁有對應系統的 MCP 描述，就可以：

? 明確“銷售數據 API”的調用方式；
? 知道“圖表服務”需要傳入的數據格式；
? 自動組織調用順序，實現完整閉環。

MCP 的價值在于標準化了 AI 與系統之間的“操作語言”，減少定制開發與重復對接成本，使 AI 能更容易擴展自己的“技能樹”。

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

添加圖片注釋，不超過 140 字（可選）

這些細節差異導致開發者需要針對不同模型做適配函數聲明、參數傳遞、響應解析等環節，極大增加了AI開發者對于多模型集成的復雜度。因此，MCP作為一個通用協議被提出，旨為模型提供一個標準化的方式來管理和利用上下文，并提供統一的協議與外部世界（工具、服務、數據）進行交互。以這張經典的示例圖為比如，使用MCP如同電腦插入USB-C接口后，簡化了各種外部設備的適配。AI模型通過MCP可以輕松調用各種數據源和工具。

MCP 架構示例圖來源：Norah Sakal on X https://x.com/norahsakal/status/1898183864570593663

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

什么是 A2A？

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

添加圖片注釋，不超過 140 字（可選）

A2A（Agent-to-Agent Protocol），顧名思義，是定義智能體之間如何溝通與協作的一套協議。

過去，AI 更像“單人作戰”的專家系統。而在越來越多的真實場景中，一個任務往往需要多個智能體協同完成。A2A 協議正是為了解決這些協作問題而生：

? 如何發現其他可用的智能體；
? 如何發起請求、共享上下文、同步進度；
? 如何協商分工、反饋結果，甚至容錯與中斷處理。

示例場景：

假設你對語音助手說：“幫我訂一張下周的去廣州的機票，并提交公司報銷”。

這個任務實際上涉及多個 AI 智能體：

1. 語音助手 AI 負責語義理解和任務分發；
2. 航班搜索 AI 提供航班選項；
3. 票務預訂 AI 完成支付與出票；
4. 報銷流程 AI 向企業系統提交申請單據。

在這個過程中，AI 之間通過 A2A 協議發起交互請求，傳遞上下文，確保每一個子任務能順利銜接。哪怕這些智能體由不同平臺或企業開發，只要遵循相同的 A2A 協議，就能實現互通協作。

舉個例子，我的微信朋友圈中有個業務廣泛的“黃牛總代”，這個黃牛合作了各領域的“黃牛”，比如演唱會和賽事搶票、醫院熱門號、靈隱寺月餅代排等，他們使用專用手段，例如內部渠道、腳本、人肉排隊等方式解決用戶需求。各領域黃牛就是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協議快速發展和普及。

A2A 與 MCP 的區別與協同

添加圖片注釋，不超過 140 字（可選）

特征	MCP (Anthropic)	A2A (Google)
發起方	Anthropic	Google
發布形式	開源	開源
解決的問題	AI 如何操作外部工具	AI 如何與其他 AI 協作
對象	模型 + 數據源（接口層）	Agent 之間（行為層）
架構目標	標準化模型訪問工具 & 數據源	標準化 Agent 間溝通協作
協議基礎	客戶端/服務器協議	HTTP + JSON + AgentCard
開發者參與性	接入工具提供能力	構建完整 Agent 系統

兩者并不沖突，而是相輔相成：

? MCP 讓 AI 能做事，掌握工具使用能力；
? A2A 讓 AI 會協作，具備組隊完成任務的能力。

在一個完整的“多智能體系統”中，MCP 描述每個成員的能力邊界，A2A 定義團隊間的溝通機制。只有兩者結合，AI 才真正具備獨立協作的能力。

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協議的前后端應用：