AG-UI 是什么？它和 MCP、A2A 分别解决什么问题？

知识点详解：前端需要看见的，比最终回答更多

先看一个资料助手的界面

假设用户让助手比较两份产品资料。页面最初显示“任务已接收”，随后显示搜索过程、命中文档，再逐步展示结论。

后端此时正在处理任务，前端则需要回答用户另一个问题：“它现在做到哪里了？”

如果只传最终文本，用户看不到中间过程。如果把所有过程都写进回答正文，工具状态、错误与真正结论又容易混在一起。

AG-UI 的官方概述把这段连接定义为基于事件的交互。前端不必从自然语言里猜“正在搜索”是工具状态还是模型的一句回答，而可以根据明确的事件类别展示。

文本、工具和运行状态为什么要分开？

一段文本可能还在增加，某个工具可能已经失败，整个任务也可能仍在继续。

这三种状态不是同一件事。

前端关心的对象	需要明确的关系
一次运行	开始、完成或失败属于哪次任务
一条消息	哪些增量进入同一条消息
一个工具调用	工具名称、参数与结果属于哪次调用
共享状态	当前页面展示与后端任务状态怎样对应

具体字段和事件类型要按所用 SDK 核对。上表描述的是需要保留的关系，不是自创一套 AG-UI 报文格式。

尤其在并行工具场景里，返回顺序不能代替调用身份。A 工具先开始、B 工具先完成，前端仍应把结果放回对应的调用卡片。

MCP、A2A、AG-UI 放在一张系统图里

用户面对的是页面，页面连接当前 Agent 后端。后端可能调用 MCP Server 提供的工具，也可能把一项任务交给另一个 Agent。

因此，这几条连接的主要职责分别是：

页面与 Agent 交换交互事件；Agent 应用与 MCP 服务交换能力请求；Agent 与其他 Agent 交换任务与协作信息。

采用其中一个，不会自动把其他连接也做好。MCP 工具执行结果可以成为前端要展示的事件，但 MCP Server 并不因此负责整个聊天页面。

也不用为了“协议齐全”全部接入。一个单 Agent 产品可能根本不需要 Agent 间协作；已有前端消息契约稳定时，也需要评估接入 AG-UI 的实际收益。

双向交互，不等于浏览器可以直接执行高风险工具

用户在页面点击确认，前端可以把交互信息交回后端。但这条信息只表达用户刚才做了什么，不能替代业务授权。

假设操作对象在等待期间改变，后端还要核对当前对象、权限和确认范围。不能因为前端发送了“确认”事件，就允许删除另一份文档。

同样，共享状态也要明确谁能修改什么。页面可以选择展示方式，但后台任务是否成功，应来自实际执行结果。

协议接通以后，还需要验证哪几件事？

用固定事件记录回放前端，确认消息、工具和任务状态能正确对应。

然后让连接中断，检查应用是重新查询任务状态、恢复事件，还是只能告诉用户本次连接失败。可靠恢复需要应用保存相应记录，不能因为采用了事件协议就默认已经拥有。

最后检查错误表达：某个工具失败，不一定意味着整次运行已经失败；运行结束，也不代表每项业务结果都成功。

面试官继续追问

AG-UI 和 SSE 是同一层的东西吗？

不是同一层。AG-UI 约定事件表达与交互语义，SSE 是一种服务端推送方式。实际接入可以用相应传输承载协议事件，不能把传输能力等同于业务语义。

后端用 Python，前端用 TypeScript，可以接吗？

可以围绕协议接入，具体依赖相应 SDK 和框架适配。需要核对事件模型和所用版本，不能假设不同语言的类名完全一致。

用自定义协议会不会更简单？

小型产品可能更简单。引入标准协议的价值，通常在于复用适配、明确事件关系和减少多端接入成本；已有稳定契约时，应比较迁移工作与收益。

面试速记卡

• AG-UI：连接 Agent 后端与用户界面。
• MCP：连接应用与外部能力。
• A2A：处理 Agent 之间的任务协作。
• 事件身份：运行、消息、工具调用要分别对应。
• 应用职责：恢复、授权和真实任务状态仍需落实。