MCPA2A之后，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生成成分镜图，用TTS模型生成旁白，用灵性生成成分镜视频，最后调用编辑工具生成电影。

从理论上讲，任何一个模型，只要它有生成视频的能力，那么你就可以直接使用它。

即使是这样，也可以生成图片，因为你可以把图片一帧一帧地拼成视频。

但是这样做肯定没有像Lovart这样的Agent那样省力，更不用说视频了。即使是一张海报，你使用通用模型的结果也可能跟不上这些专业设计Agent的几十次提示。

理解了Agent的概念，MCP和A2A的作用就显而易见了。

为了实现目标，Agent往往不能只使用背后的大模型，还需要一些外部世界的资源和工具。

要调用工具，你必须传递参数，比如最起码的工具名称是什么。这个时候就要有MCP协议了，不然这么多模型和工具最后都不兼容就很麻烦了。

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

类似地，Agent之间要相互合作也要有一个规范，这个规范就是A2A协议。

举例来说，当新员工进入HR时， Agent负责入职流程，HR 你可以告诉ITAgent 在通知Adminn的同时，Agent开通了OA帐户。 Agent分配过程和门禁。

当然，在实践中，即使没有A2A规范，这家公司内部的Agent也很容易协调开放。然而，对于世界上不同功能的个人、企业和组织开发的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最终以TEXT__CONTENT事件结束。MESSAGE结束了_END。

为什么有多个TEXT？MESSAGE_CONTENT事件怎么样？由于这种方式，前端UI不需要等待Token全部生成，才能一次打包传输文本信息，它可以分几次传输。

基于这一事件的驱动过程，在处理文本响应时，前端UI可以做很多事情来改善用户体验，比如TextMessageStart事件发生时，就会弹出一个显示“加载”的消息气泡；TEXT_MESSAGE当_END事件发生时，前端可以取消渲染，删除与“加载”相关的指示图标，自动更换页面，呈现完整的内容等。

当然，总的来说，和MCP和A2A一样，并不是一个突破性的创新。然而，它统一了Agent与UI沟通的标准，并提供了良好的实践。MCP和A2A给行业带来了兴奋，AI应用生态的繁荣和互通更值得期待，因为AG-UI补充了最后一个协议拼图。

本文来自微信公众号“多模肽”，作者：多模肽，36氪经授权发布。

本文仅代表作者观点，版权归原创者所有，如需转载请在文中注明来源及作者名字。

免责声明：本文系转载编辑文章，仅作分享之用。如分享内容、图片侵犯到您的版权或非授权发布，请及时与我们联系进行审核处理或删除，您可以发送材料至邮箱：service@tojoy.com