AG-UI是什么
AG-UI全称Agent User Interaction Protocol，是一套开源的Agent与UI界面之间的交互协议。
前有MCP和A2A，AG-UI又是干啥的？
MCP：定义了 Agent/LLM 去调用外部 Tools 时的协议规范
A2A：定义了 Agent 与 Agent 之间的通信协议规范
AG-UI：补充了 Agent 与 Users（即前端应用）之间的通信规范
当前AI应用开发主要面临的一些挑战
- 协议不统一：每个AI服务商（OpenAI、Anthropic、Google等）都有自己的API格式和交互方式实时性要求：用户期待实时的字符级流式响应，而非等待完整生成状态同步困难：前后端之间的状态管理缺乏标准化方案工具调用复杂：智能体需要与外部系统交互，但缺乏统一的接口规范人机协作不畅：实现Human-in-the-Loop工作流需要大量自定义开发
这种碎片化会导致开发者在和多个AI服务对接或构建复杂AI应用时重写大量代码。
假设有一套通信协议，可以统一前端应用和后端Agent之间的交互格式，做到前后端解耦，让大家各司其职，岂不美哉。AG-UI的出现，就是为了解决这个问题。
AG-UI的核心架构
AG-UI简单来说，就是为前端应用层与后端Agent层之间的通信制定了标准。
Application：直接与用户交互的前端应用层，比如ChatGPT、Cursor等任何AI powered应用。
AG-UI Client：在前端侧负责与后端Agent进行通信，使用AG-UI协议。
Agent：后端Agent通常和AI服务或其他Agent对接，用来处理用户请求。
AG-UI的几个特点
事件驱动通信：Agent需要使用标准的Events向前端通信。
双向交互：Agent接收前端的输入，并支持流式返回，让人和AI无缝交互。
流式交互：无论是文本处理、状态变更、工具调用，Agent都可以使用Events流式向前端发起更新。
传输协议无关：协议本身不要求传输方式，可以使用SSE、webhooks、Websockets等。
事件 Events
AG-UI采用流式事件驱动架构（streaming event-based architecture），支持前端和Agent之间的双向通信。
AG-UI内部制定了16种标准化事件类型
生命周期事件（Lifecycle Events） ：负责管理整个Agent调用的生命周期。
- 包括
RunStarted、StepStarted、StepFinished、RunFinished、RunError。文本事件（Text Message Events） ：文本传输。
- 包括
TextMessageStart、TextMessageContent、TextMessageEnd。工具调用事件（Tool Call Events） ：Agent需要调用工具时发出，前端可清晰的感知到Agent调用了哪些工具，以及参数是什么。
- 包括
ToolCallStart、ToolCallArgs、ToolCallEnd状态管理事件（State Management Events） ：用于同步前端应用和后端Agent之间的状态。
- 包含
StateSnapshot、StateDelta、MessagesSnapshot。特殊事件（Special Events） ：主要负责和外部系统之间做集成。
- 包含
Raw和Custom。例如，一个典型的chatbot产生的事件流如下
RUN_STARTED -> TEXT_MESSAGE_START -> TEXT_MESSAGE_CONTENT -> TEXT_MESSAGE_END -> RUN_FINISHED
[ { "type": "RUN_STARTED", "threadId": "thread_1", "run_id": "run_1" }, { "type": "TEXT_MESSAGE_START", "messageId": "message_1", "role": "assistant" }, { "type": "TEXT_MESSAGE_CONTENT", "messageId": "message_1", "delta": "你好" }, { "type": "TEXT_MESSAGE_END", "messageId": "message_1" }, { "type": "RUN_FINISHED", "threadId": "thread_1", "run_id": "run_1" } ]通过将前端应用与后端Agent之间的交互拆分为不同的事件，前端可着重关注在收到对应事件时，应该向用户展示什么样的交互，而不用关心具体的后端Agent实现。
Agents
Agent是AG-UI里的核心组成部分，负责处理前端发起的请求，和LLM交互并生成响应（响应需遵循Events格式），同时还要管理对话状态和消息历史。在Agent底层可以和其他任意的AI服务连接（比如任意的LLM、定制的AI系统、RAG、其他Agent等等）。
Agent具备丰富的交互能力
基本的文本传输（如上一小节的例子）
工具调用
- 在AG-UI的规范下，Agent可以使用哪些Tools是由前端告知的。当Agent决策需要使用工具时，可以通过一系列事件（
TOOL_CALL_START -> TOOL_CALL_ARGS -> TOOL_CALL_END）通知到前端，前端在收到事件后，可决定是否给用户展示对应交互，告知需要调用哪些工具以及对应参数，由用户决定是否调用。调用结果会通过Message传递给Agent。状态管理
- Agent可以向前端传递最新完整的状态（
STATE_SNAPSHOT）或增量同步状态（STATE_DELTA），可以让前端应用从中断状态恢复。多Agent交互：Agent可以通过A2A等其他协议和其他Agent交互，此过程可以不让前端用户感知（只要不发送Event就行）。
Human-in-the-Loop控制：可以将人在回路的控制能力作为Tool注入给Agent，由Agent决定在必要时候让人进行决策（仍然通过工具调用链路）
...
AG-UI本身并没有限制Agent的能力，只是在需要和前端用户交互的场景下，让Agent可以通过预定义的若干Events通知前端，让前端聚焦在用户行为上。
消息 Messages
传统与LLM通信时，message中的role通常被分为system、user、assistant。在AG-UI中，除了以上三种类型的消息，工具调用的结果也被当成一种消息类型（称为tool）。
// Conversation history [ // User query { id: "msg_1", role: "user", content: "What's the weather in New York?", }, // Assistant response with tool call { id: "msg_2", role: "assistant", content: "Let me check the weather for you.", toolCalls: [ { id: "call_1", type: "function", function: { name: "get_weather", arguments: '{"location": "New York", "unit": "celsius"}', }, }, ], }, // 注意，这里的工具调用其实是由Agent通知给前端，由前端用户决定是否调用工具，并把调用结果传给Agent，让Agent继续后续流程 // Tool result { id: "result_1", role: "tool", content: '{"temperature": 22, "condition": "Partly Cloudy", "humidity": 65}', toolCallId: "call_1", }, // Assistant's final response using tool results { id: "msg_3", role: "assistant", content: "The weather in New York is partly cloudy with a temperature of 22°C and 65% humidity.", }, ]状态管理 State Management
状态管理，除了基本的同步聊天消息之外，你可以同步任意的状态，让人和AI的操作可以衔接操作。
官方提供了一个比较有意思的Demo：让AI优化一份菜谱，菜谱在前端使用富交互展示的，随着AI Agent的优化，前端交互可实时进行更新。
状态同步仍然使用Event
STATE_SNAPSHOT：传递完整的状态，一般用于初始状态同步、中断状态恢复等。
STATE_DELTA：差量更新状态，使用JSON Patch，可以流式快速更新。
有了这个能力，前端应用可以实现更复杂交互的流式更新，给用户更好的交互体验。
工具调用 Tools
在AG-UI中，工具可以
获取更多的信息
操作外部系统
让人进行信息输入或二次确认
前面提到了，在AG-UI中，需要和前端交互的工具需要在前端定义，并通过协议传给Agent，当Agent认为需要使用工具时，会使用Event向前端发消息，前端可向用户展示被调用的工具名称和参数，让用户决定是否继续。
ToolCallStart -> ToolCallArgs -> ToolCallEnd
关于AG-UI的思考
以下仅代表个人观点，欢迎讨论
初看AG-UI这个协议，感觉不就是把AI应用的前后端交互做了解耦，并且定义了一套数据传输格式么。（当然，这就好比说HTTP协议不就是定义了请求和响应的格式么hhh）
细想一下，AG-UI是有一些独特的特点的（具体好不好，要交给历史来决定了）
从“调用AI”到“与AI协作”的转变
- 传统AI集成方式：前端调用大模型，等着大模型给返回与AI协作：大模型在调用过程中，发现需要用户决策交互，会通过TOOL_CALL向前端发起申请
当然，目前Cursor、Claude等在运行第三方工具时，也会向用户发起确认请求。不过这些通信协议都是各大厂商自己实现的，并不互通
给前端提供了“优雅”接入AI的一种方式，解决AI“最后一公里”
- AG-UI的核心定义基本都是面向前端的，前端需要展示文本，AG-UI有Text Message Events，前端需要同步最新状态，AG-UI有State Management Events，前端需要Human in the Loop的二次确认，AG-UI用Tool Call Events把用户二次确认也包装成一种tool调用。至于前端不是很关心的多Agent见的调用，AG-UI没有提供对应的事件，让用户无感底层Agent具体调用的哪些服务。为了让前端交互更流畅，Event基本都设计成可以流式处理的，让AI与人无缝交互。AI应用与Agent之间的交互标准化后，未来会有人专门做炫酷流畅的前端应用，有人专门做高质量的后端Agent，做到应用与Agent自由结合。
工具由前端主导
- 在AG-UI中，Agent可以使用哪些工具，是由前端传入的。我的理解是，前端可以传入需要让用户感知到的工具调用（比如需要获取用户的个人信息、需要用户二次确认等），更多一些无需用户关心的工具，其实可以仍然放到后端Agent配置里，做到用户关心的才让用户感知，并且和用户安全相关的，可以直接由前端用户掌控。
未来可能有哪些发展
以下仅代表个人观点，欢迎讨论
类比MCP的出现，MCP之前，各家AI应用存在重复实现相同能力的情况，MCP出现之后，大家把各种原子化的能力统统包装成MCP服务，可以在Claude、Cursor、Cline等多个AI应用中自由集成。
AG-UI可能也会有类似的发展：
- 原生框架集成
目前AG-UI已经支持了LangGraph、CrewAI等框架，后续可能会有更多AI Agent框架原生集成AG-UI，Agent开发更加标准化。
- Agent生态繁荣可复用
各大厂商和服务商会提供自己的AI Agent，并原生支持AG-UI。同一个Agent可以被不同的AI应用多次使用。智能体市场发展壮大，并可能出现智能体按用量计费的商业模式。
- 专业化分工
AG-UI将前后端交互进一步解耦，交互设计专家可以专注创造最佳的用户体验，AI开发者可以专注提升Agent能力。未来用户可以自由结合喜欢的前端界面+能力强大的Agent，不再会出现喜欢A的交互但是想用B的能力的情况，实现“各取所长”的理想组合。
