MCP/A2A之後，Agent補齊最後一塊協議拚圖

文 | 多模肽

去年12月Anthropic推出MCP協議後，MCP的熱度就一直居高不下。然後上個月，Google的A2A協議也出來了，連帶著又引發了一波討論。這兩個協議之所以火，有它的時代背景。

常看點行業新聞的朋友，應該都注意到了一種趨勢，最近基礎模型的訓練越來越呈現出寡頭化特徵。有能力還有意願搞基礎大模型的，除開幾家頭部大廠，剩下的創業公司已經是鳳毛麟角了。

AI的前景廣闊是共識，但機會只存在於模型的應用而非研發。

MCP跟A2A兩種協議，本質上都是為AI應用鋪開打造的基礎設施。

AI的應用生態構建，可以看作是圍繞三個角色展開的：用戶、Agent和外部世界。

如果要讓這個應用生態發展壯大，首先要解決的就是這幾類角色之間的互聯互通。

從這個角度看，很明顯MCP解決的是Agent跟外部世界的互聯互通，A2A解決的是Agent跟Agent之間的互聯互通。但你有沒有發現這裡面還差點什麼？Agent跟自己，Agent跟外部世界都有了協議了來規範溝通互動，那用戶跟Agent之間呢？

今天我們要介紹的新協議AG-UI，就是針對的這個問題，它規範了Agent跟前端界面要如何連接、交流和互動。繼MCP和A2A之後，AG-UI補齊了AI應用生態發展所需的最後一塊協議拚圖。

在介紹AG-UI之前，我們先對一些背景概念做個簡單梳理。

首先聊聊Agent是什麼。

這已經是個聊爛了的名詞。

國內一般把Agent翻譯成智能體，這個翻譯不能說有問題，但並沒有很準確地傳達出Agent的本質。

英文里Agent原意是代理人，這個代理人接受授權後，替其他人、公司或者組織完成一些相應的工作。

比如最常見的，房屋中介就是agent的一種，房屋主人把房子委託給他們，他們代理完成房子出租或者出售的工作，這樣房屋主人就不必自己費勁巴拉去阿找租戶或者買家。

AI Agent其實也是類似的作用，在用戶需要實現某個任務的時候，它們可以主動自覺地採取行動，完成分析拆解、獲取信息、調用工具、整合響應等過程。

比如這兩天出了個新工具叫Lovart，據稱是首款設計Agent。

有博主嘗試了下，你給他一句提示語，要求生成一個廣告片，它就能自己去調用Flux生成分鏡圖、用湯臣S模型生成旁白、用可靈生成分鏡影片，最後再調用剪輯工具出成片。

理論上講，任何一款模型，只要它具備生成影片的能力，那你就可以直接用它同樣的事。

甚至說，只要能生成圖片就可以了，因為你可以一幀一幀地把圖片拚成影片嘛。

但這樣做肯定沒有用Lovart這種Agent來得省力，不要說影片，就算是一張海報，你用通用模型生成的結果，可能換幾十遍提示詞都趕不上這些專業設計Agent直出來得好。

理解了Agent的概念，MCP和A2A起到的作用就很顯然了。

Agent要完成任務，很多時候都不能只用到背後的大模型，還需要用到外部世界的一些資源和工具。

而要調用工具，你肯定要傳遞參數吧，比如最起碼的工具名稱是什麼。這時候就要有MCP這種協議，不然那麼多模型那麼多工具，最後都不兼容就很麻煩。

之前大家搞Function Calling，工具名OpenAI放在 tools 字段里，Claude又放在的 tool_use 字段里，就是各做各的不兼容。

類似的，Agent之間要互相協作也要有個規範，這個規範就是A2A協議。

比如，新員工入職的時候，由HR Agent負責入職流程，HR Agent可以告訴IT Agent開通OA帳號，同時告知Admin Agent分配工位和門禁。

當然在實踐中，這種公司內部的Agent之間即便沒有A2A規範也是很容易協調打通的，但對於世界上存在的不同個人、企業和組織開發的各種不同功能的Agent而言，有一個規範就很有必要了。

聊完這些，我們下面展開談談AG-UI協議要解決的問題。

如上所說，在Agent出現之前，用戶就已經存在跟外部世界的互動了。

Agent加進來過後，其實就有三個新的關係需要協調了：Agent跟外部世界，Agent跟Agent，Agent跟用戶。

MCP和A2A解決了前面兩個關係的協作，AG-UI要補上的則是最後一塊拚圖。

在官方給出的示意圖中，可以看出來AG-UI這個協議，就是嵌在應用和後端Agent之間的。如果沒有AG-UI協議支持，在下圖中應用就是直接跟AI Agent連接的。

那現在的問題是，為什麼非要有個AG-UI協議呢？

其實跟MCP或者A2A一樣，AG-UI提供的是前端應用跟後端Agent之間溝通的一個標準範式和基礎實現。

AG-UI相當於是個磚廠，建房子的時候本來你要自己從零開始選土-和泥-製坯-燒磚，現在你可以直接用現成的，質量還比你自己做的更好。AG-UI是事件驅動的工作模式。

對於沒有編程經驗的讀者，可能會覺得有點難懂。

我們掰開講講。對於一個應用而言，它的前端UI是面向用戶的，用戶不關心你後端Agent是怎麼實現的，他只在乎自己在使用產品時的用戶體驗。

AI Agent在接受用戶輸入後，它可能需要做很多工作，比如調用大模型生成響應、規劃任務執行步驟、向用戶申請調用某些外部工具等。

這種情況下用戶肯定不希望自己在前面傻傻等著，他更希望前端UI能夠及時調整，向他呈現相關Agent的狀態信息：比如任務執行到哪一步了、調用工具的時候使用哪些參數、工具調用請求執行到哪了（是準備開始執行、已經確認參數、還是說請求已經發送完畢了）等等。

每當任務在後台產生進度，就會產生一個事件信息，前端就根據這個事件信息調整UI界面。

這麼說還是有點抽像，我們看個演示案例。

比如官方有個demo，記錄了一個AI文件編輯器在使用時的UI界面變化，它後端連接的Agent是Copilot。當你讓Copilot生成一個故事的時候，前端UI會像打字一樣，一個字符一個字符地更新。當你要求把故事的主人公名字換一下，UI界面也會呈現出Copilot的修改過程。

這些功能是怎麼實現的呢？前端UI和後端的Copilot共享一個文件狀態，當Copilot生成內容的時候，更新會被傳輸到前端UI，前端UI不會等所有更新傳輸完畢才開始重新渲染頁面，而是根據收到的更新內容即時呈現變化。最終所有的修改，在視覺上都能非常直觀地看見。

AG-UI協議提供了五類事件，包括：

Lifecycle Events，

Text Message Events，

Tool Call Events，

State Management Events，

Special Events。

我們挑一些說一下，完整的內容可以去官網上看。

像上面這個案例，就用到了狀態管理事件（State Management Events），包括：

STATE_SNAPSHOT, 

STATE_DELTA, 

MESSAGES_SNAPSHOT。

STATE_SNAPSHOT提供Agent在某個瞬間的完整狀態，如果狀態有更新，就用STATE_DELTA傳遞更新的部分狀態。

這種做法的好處是頻繁的小更新不需要傳輸整個狀態數據，既保證了狀態的完整性，又實現了效率。平常只需要傳遞STATE_DELTA，如果確實需要全部同步，那按需偶爾傳遞一些狀態快照STATE_SNAPSHOT就可以了。

生命週期事件（Lifecycle events）包含以下五種：

RUN_STARTED, 

RUN_FINISHED, 

RUN_ERROR，

STEP_STARTED, 

STEP_FINISHED。

一個標準的Agent調用會由RunStarted事件開始，中間可能包含很多個步驟，這些步驟用StepStarted/StepFinished來標識，最後由RunFinished（成功）或者RunError（失敗）事件結束。

由於有這樣一個模式，這樣前端就可以跟蹤Agent執行進度，按照事件發生情況調整UI界面向用戶呈現信息，或者在發生錯誤的時候針對性地處理。用流程圖表示如下 ：

文本信息事件（Text message events）包含以下三種：

TEXT_MESSAGE_START, 

TEXT_MESSAGE_CONTENT, 

TEXT_MESSAGE_END。

文本信息的生成和響應是現階段大語言模型最普遍的模式，我們這裏再看下AG-UI協議對這一模式提供了什麼樣的支持。

當Agent要生成並傳遞文本信息的時候，首先以TEXT_MESSAGE_START事件開始，中間是一個或多個TEXT_MESSAGE_CONTENT事件，最後以TEXT_MESSAGE_END結束。

為什麼可能有多個TEXT_MESSAGE_CONTENT事件呢？因為這樣前端UI就不需要等所有Token生成完了，才能一次性打包傳送文本信息，它可以分多次傳送。

基於這個事件驅動流程，在處理文本響應的時候，前端UI能做很多事情改善用戶體驗，比如TextMessageStart事件發生了，就彈出一個顯示「正在加載」的消息氣泡；TEXT_MESSAGE_END事件發生了，前端就可以取消渲染、移除「正在加載」相關的指示圖標，自動向下翻頁呈現完整內容等等。

當然，總的來說，跟MCP和A2A一樣，並談不上有突破性的創新。但它統一了Agent跟UI溝通的標準，並提供了最佳實踐。MCP和A2A給行業帶來過興奮，而隨著AG-UI補齊最後一塊協議拚圖，AI應用生態的繁榮互通更加值得期待。