去年 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 应用生态发展所需的最后一块协议拼图。
首先聊聊 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 连接的。
其实跟 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 就可以了。
RUN_STARTED，
RUN_FINISHED，
RUN_ERROR，
STEP_STARTED，
STEP_FINISHED。
一个标准的 Agent 调用会由 RunStarted 事件开始，中间可能包含很多个步骤，这些步骤用 StepStarted/StepFinished 来标识，最后由 RunFinished（成功）或者 RunError（失败）事件结束。
由于有这样一个模式，这样前端就可以跟踪 Agent 执行进度，按照事件发生情况调整 UI 界面向用户呈现信息，或者在发生错误的时候针对性地处理。用流程图表示如下 ：
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 事件发生了，前端就可以取消渲染、移除 " 正在加载 " 相关的指示图标，自动向下翻页呈现完整内容等等。
本文来自微信公众号：多模肽，作者：多模肽
