文 | 多模肽

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

常看點行業(yè)新聞的朋友，應(yīng)該都注意到了一種趨勢，最近基礎(chǔ)模型的訓(xùn)練越來越呈現(xiàn)出寡頭化特征。有能力還有意愿搞基礎(chǔ)大模型的，除開幾家頭部大廠，剩下的創(chuàng)業(yè)公司已經(jīng)是鳳毛麟角了。

AI的前景廣闊是共識，但機會只存在于模型的應(yīng)用而非研發(fā)。

MCP跟A2A兩種協(xié)議，本質(zhì)上都是為AI應(yīng)用鋪開打造的基礎(chǔ)設(shè)施。

AI的應(yīng)用生態(tài)構(gòu)建，可以看作是圍繞三個角色展開的：用戶、Agent和外部世界。

如果要讓這個應(yīng)用生態(tài)發(fā)展壯大，首先要解決的就是這幾類角色之間的互聯(lián)互通。

從這個角度看，很明顯MCP解決的是Agent跟外部世界的互聯(lián)互通，A2A解決的是Agent跟Agent之間的互聯(lián)互通。但你有沒有發(fā)現(xiàn)這里面還差點啥？Agent跟自己，Agent跟外部世界都有了協(xié)議了來規(guī)范溝通互動，那用戶跟Agent之間呢？

今天我們要介紹的新協(xié)議AG-UI，就是針對的這個問題，它規(guī)范了Agent跟前端界面要如何連接、交流和互動。繼MCP和A2A之后，AG-UI補齊了AI應(yīng)用生態(tài)發(fā)展所需的最后一塊協(xié)議拼圖。

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

首先聊聊Agent是什么。

這已經(jīng)是個聊爛了的名詞。

國內(nèi)一般把Agent翻譯成智能體，這個翻譯不能說有問題，但并沒有很準(zhǔn)確地傳達出Agent的本質(zhì)。

英文里Agent原意是代理人，這個代理人接受授權(quán)后，替其他人、公司或者組織完成一些相應(yīng)的工作。

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

AI Agent其實也是類似的作用，在用戶需要實現(xiàn)某個任務(wù)的時候，它們可以主動自覺地采取行動，完成分析拆解、獲取信息、調(diào)用工具、整合響應(yīng)等過程。

比如這兩天出了個新工具叫Lovart，據(jù)稱是首款設(shè)計Agent。

有博主嘗試了下，你給他一句提示語，要求生成一個廣告片，它就能自己去調(diào)用Flux生成分鏡圖、用TTS模型生成旁白、用可靈生成分鏡視頻，最后再調(diào)用剪輯工具出成片。

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

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

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

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

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

而要調(diào)用工具，你肯定要傳遞參數(shù)吧，比如最起碼的工具名稱是啥。這時候就要有MCP這種協(xié)議，不然那么多模型那么多工具，最后都不兼容就很麻煩。

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

類似的，Agent之間要互相協(xié)作也要有個規(guī)范，這個規(guī)范就是A2A協(xié)議。

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

當(dāng)然在實踐中，這種公司內(nèi)部的Agent之間即便沒有A2A規(guī)范也是很容易協(xié)調(diào)打通的，但對于世界上存在的不同個人、企業(yè)和組織開發(fā)的各種不同功能的Agent而言，有一個規(guī)范就很有必要了。

聊完這些，我們下面展開談?wù)凙G-UI協(xié)議要解決的問題。

如上所說，在Agent出現(xiàn)之前，用戶就已經(jīng)存在跟外部世界的互動了。

Agent加進來過后，其實就有三個新的關(guān)系需要協(xié)調(diào)了：Agent跟外部世界，Agent跟Agent，Agent跟用戶。

MCP和A2A解決了前面兩個關(guān)系的協(xié)作，AG-UI要補上的則是最后一塊拼圖。

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

那現(xiàn)在的問題是，為啥非要有個AG-UI協(xié)議呢？

其實跟MCP或者A2A一樣，AG-UI提供的是前端應(yīng)用跟后端Agent之間溝通的一個標(biāo)準(zhǔn)范式和基礎(chǔ)實現(xiàn)。

AG-UI相當(dāng)于是個磚廠，建房子的時候本來你要自己從零開始選土-和泥-制坯-燒磚，現(xiàn)在你可以直接用現(xiàn)成的，質(zhì)量還比你自己做的更好。AG-UI是事件驅(qū)動的工作模式。

對于沒有編程經(jīng)驗的讀者，可能會覺得有點難懂。

我們掰開講講。對于一個應(yīng)用而言，它的前端UI是面向用戶的，用戶不關(guān)心你后端Agent是怎么實現(xiàn)的，他只在乎自己在使用產(chǎn)品時的用戶體驗。

AI Agent在接受用戶輸入后，它可能需要做很多工作，比如調(diào)用大模型生成響應(yīng)、規(guī)劃任務(wù)執(zhí)行步驟、向用戶申請調(diào)用某些外部工具等。

這種情況下用戶肯定不希望自己在前面傻傻等著，他更希望前端UI能夠及時調(diào)整，向他呈現(xiàn)相關(guān)Agent的狀態(tài)信息：比如任務(wù)執(zhí)行到哪一步了、調(diào)用工具的時候使用哪些參數(shù)、工具調(diào)用請求執(zhí)行到哪了（是準(zhǔn)備開始執(zhí)行、已經(jīng)確認參數(shù)、還是說請求已經(jīng)發(fā)送完畢了）等等。

每當(dāng)任務(wù)在后臺產(chǎn)生進度，就會產(chǎn)生一個事件信息，前端就根據(jù)這個事件信息調(diào)整UI界面。

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

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

這些功能是怎么實現(xiàn)的呢？前端UI和后端的Copilot共享一個文件狀態(tài)，當(dāng)Copilot生成內(nèi)容的時候，更新會被傳輸?shù)角岸薝I，前端UI不會等所有更新傳輸完畢才開始重新渲染頁面，而是根據(jù)收到的更新內(nèi)容即時呈現(xiàn)變化。最終所有的修改，在視覺上都能非常直觀地看見。

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

Lifecycle Events，

Text Message Events，

Tool Call Events，

State Management Events，

Special Events。

我們挑一些說一下，完整的內(nèi)容可以去官網(wǎng)上看。

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

STATE_SNAPSHOT,

STATE_DELTA,

MESSAGES_SNAPSHOT。

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

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

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

RUN_STARTED,

RUN_FINISHED,

RUN_ERROR，

STEP_STARTED,

STEP_FINISHED。

一個標(biāo)準(zhǔn)的Agent調(diào)用會由RunStarted事件開始，中間可能包含很多個步驟，這些步驟用StepStarted/StepFinished來標(biāo)識，最后由RunFinished（成功）或者RunError（失敗）事件結(jié)束。

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

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

TEXT_MESSAGE_START,

TEXT_MESSAGE_CONTENT,

TEXT_MESSAGE_END。

文本信息的生成和響應(yīng)是現(xiàn)階段大語言模型最普遍的模式，我們這里再看下AG-UI協(xié)議對這一模式提供了什么樣的支持。

當(dāng)Agent要生成并傳遞文本信息的時候，首先以TEXT_MESSAGE_START事件開始，中間是一個或多個TEXT_MESSAGE_CONTENT事件，最后以TEXT_MESSAGE_END結(jié)束。

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

基于這個事件驅(qū)動流程，在處理文本響應(yīng)的時候，前端UI能做很多事情改善用戶體驗，比如TextMessageStart事件發(fā)生了，就彈出一個顯示“正在加載”的消息氣泡；TEXT_MESSAGE_END事件發(fā)生了，前端就可以取消渲染、移除“正在加載”相關(guān)的指示圖標(biāo)，自動向下翻頁呈現(xiàn)完整內(nèi)容等等。

當(dāng)然，總的來說，跟MCP和A2A一樣，并談不上有突破性的創(chuàng)新。但它統(tǒng)一了Agent跟UI溝通的標(biāo)準(zhǔn)，并提供了最佳實踐。MCP和A2A給行業(yè)帶來過興奮，而隨著AG-UI補齊最后一塊協(xié)議拼圖，AI應(yīng)用生態(tài)的繁榮互通更加值得期待。