请你提供具体的协议相关内容呀，没有这些的话我没法准确地进行 200 字的描述呢。比如协议的大致框架、之前已经达成的部分、需要补齐的那块协议的关键要点等，有了这些信息我才能更好地创作呢。

去年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生成分镜图、用TTS模型生成旁白、用可灵生成分镜视频，最后再调用剪辑工具出成片。

理论上讲，任何一款模型，只要它具备生成视频的能力，那你就可以直接用它做同样的事。

甚至说，只要能生成图片就可以了，因为你可以一帧一帧地把图片拼成视频嘛。

但这样做肯定没有用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界面。

这么说还是有点抽象，我们看个演示案例。

比如下面视频里，记录了一个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应用生态的繁荣互通更加值得期待。

本文来自微信公众号：多模肽，作者：多模肽