AG-UI：为什么 Agent 需要一套面向前端的交互协议？

当 Agent 进入一个真实产品，用户看到的往往不只是最终答案。界面还要显示它正在检索、调用了哪个工具、是否需要用户确认、状态是否发生变化，以及中途生成的内容应该放到哪一块区域。很多团队一开始用 SSE 或 WebSocket 把事件传到前端，后来却发现：通道统一了，事件含义仍然各说各话。

AG-UI，即 Agent-User Interaction Protocol，关注的正是这层语义。它把 Agent 后端和面向用户的应用连接起来，提供一套事件驱动的交互约定。它不要求所有 Agent 使用同一个模型或框架，也不绑定某一种传输协议，而是试图让前端知道“发生了什么”。

SSE 只负责传输，不负责解释

假设后端发来一串 JSON。第一条表示开始生成文本，第二条表示工具调用，第三条是工具结果，第四条请求用户确认。即使它们都能通过 SSE 送达，前端仍然需要自己猜字段、维护状态机和处理异常。不同 Agent 框架如果定义不同事件格式，前端组件就很难复用。

AG-UI 把这件事拆成事件类型、输入参数和状态语义。后端发出兼容的 Agent 事件，前端根据事件更新消息、工具卡片、进度、上下文和人工介入状态。传输层仍然可以是 SSE、WebSocket 或 webhook，协议关注的是事件代表什么，而不是字节如何抵达。

它在 Agent 协议栈里处于哪一层

可以把几类协议放在不同位置理解。MCP 主要解决 Agent 如何获得工具和上下文；A2A 主要解决 Agent 如何与另一个 Agent 协作；AG-UI 则解决 Agent 如何进入用户正在使用的前端应用。它们可以组合，但没有谁能替代谁。

例如，一个旅行规划 Agent 可以通过 MCP 查询航班和酒店，通过 A2A 把酒店比价委派给另一个 Agent，再通过 AG-UI 把搜索进度、候选卡片和待确认的预算展示给用户。前端不需要知道后端到底用了哪个模型，只需要理解“搜索开始”“候选结果更新”“需要确认”和“任务完成”等事件。

事件协议不等于组件库

AG-UI 不会替你决定界面一定要长什么样。它可以让不同应用收到相同的状态变化，但具体是显示成聊天气泡、时间线、表格还是侧边栏，仍然属于产品设计。这个边界很重要：协议负责互操作，组件库负责视觉和交互表达。

同样，AG-UI 也不等于把所有后端日志原样暴露给用户。生产系统需要区分模型思考过程、可展示的进度、工具调用摘要和内部调试信息。一个事件可以服务于前端状态同步，但不代表其中每个字段都适合直接显示给用户。

人在回路中的关键是可恢复

用户介入不是简单弹出一个“确定/取消”按钮。前端还要知道当前 Agent 处于什么状态，用户输入会补充哪个步骤，确认后是否继续原任务，以及页面刷新后能否恢复上下文。事件协议如果没有清晰的生命周期，用户一旦离开页面，Agent 就容易变成一个无法解释的后台进程。

因此，采用 AG-UI 这类协议时，团队应先设计事件的幂等标识、顺序、重放和错误语义，再讨论动画和卡片样式。前端需要能够处理重复事件、乱序消息、断线重连和后端取消；后端则要明确哪些状态对用户可见，哪些数据只能留在内部审计中。

AG-UI 的价值可以用一句话概括：SSE 和 WebSocket 解决“怎么把消息送到浏览器”，AG-UI 试图解决“浏览器应该如何理解这些消息”。当 Agent 从聊天框走进真正的产品界面，这一层共享语义会比单纯增加一个传输协议更重要。

来源：AG-UI 官方仓库