【6G新技术探索】AG-UI(Agent User Interaction Protocol) 协议介绍
博主未授权任何人或组织机构转载博主任何原创文章,感谢各位对原创的支持!
博主链接
本人就职于国际知名终端厂商,负责modem芯片研发。
在5G早期负责终端数据业务层、核心网相关的开发工作,目前牵头6G技术研究。
博客内容主要围绕:
5G/6G协议讲解
高级C语言讲解
Rust语言讲解
文章目录
- AG-UI 协议介绍
- 一、架构概述
- 二、AG-UI 中的事件
- 2.1 生命周期事件
- 2.2 文本消息事件
- 2.3 工具调用事件
- 2.4 状态管理事件
- 2.5 特殊事件
- 三、AG-UI中的Agent
- 四、AG-UI基础消息结构
- 五、AG-UI中的工具调用
- 5.1 工具结构
- 5.2 Frontend-Defined工具
- 六、与其它Agent协议的关系
- 总结
AG-UI 协议介绍
AG-UI:Agent User Interaction Protocol
HomePage
一、架构概述
AG-UI 建立在一个灵活的、事件驱动的架构上,使前端应用程序和AI Agent之间能够无缝、高效地通信。AG-UI遵循客户端-服务器架构:
- Application:面向用户的应用程序(例如聊天或任何支持AI的应用程序);
- AG-UI客户端:通信客户端,如HttpAgent或用于连接到现有协议的专用客户端;
- Agent:处理请求并生成流响应的后端AI Agent;
- Secure Proxy:提供额外功能并充当安全代理的后端服务;
二、AG-UI 中的事件
AG-UI 使用基于流事件的架构,事件是Agent和前端之间通信的基本单元,支持实时、结构化的交互。支持的事件类型如下所示:
事件类型 | 说明 |
---|---|
生命周期事件 | 监测Agent的运行进度 |
文本消息事件 | 处理流文本内容 |
工具调用事件 | 通过Agent管理工具执行 |
状态管理事件 | Agent与UI间状态同步 |
特殊事件 | 支持用户自定义事件 |
2.1 生命周期事件
表示Agent运行的生命周期。一个典型的Agent运行遵循下面的状态机模式:它以一个RunStarted
事件开始,可能包含多个可选的StepStarted
和StepFinished
对,并以一个RunFinished
事件(成功)或一个RunErrorevent
(失败)结束。
生命周期事件为Agent运行提供了关键的结构,使前端能够跟踪进度,适当地管理UI状态,并优雅地处理错误。它们创建了一个统一的框架,用于理解操作何时开始和结束,使实现加载指示器、进度跟踪和错误恢复机制等功能成为可能。
RunStarted
和RunFinished
或RunError
事件是强制性的,是Agent运行的整体状态机框架。Step事件是可选的,可以在一次运行中多次发生,允许结构化的、可观察的进度跟踪。
RunStarted
:是Agent开始处理请求时发出的第一个事件,此事件作为前端初始化UI元素(如进度指示器或加载状态)的标记。它还提供了关键的标识符,可用于将后续事件与此特定运行关联起来;RunFinished
:表明Agent已成功完成当前运行的所有工作。接收到此事件后,前端应该完成等待Agent完成的所有UI状态。此事件标记了一个干净的终止点,并指示除非显式请求,否则在此运行中不会发生进一步的处理;RunError
:表明Agent遇到了无法恢复的错误,导致运行提前终止。此事件提供有关发生错误的信息,允许前端显示适当的错误消息,并可能提供恢复选项。在发生RunError事件后,在此运行中不会发生进一步的处理;StepStarted
:指示Agent正在开始其处理的特定子任务或阶段。提供了对代理进程的细粒度可见性,从而在UI中实现更精确的跟踪和反馈。步骤是可选的,但强烈建议将复杂操作分解为可观察的阶段。stepName可以是当前正在执行的节点或函数的名称;StepFinished
:表明Agent已经完成了特定的子任务或阶段。当与相应的StepStarted事件配对时,它将为离散的工作单元创建有界上下文。前端可以使用这些事件来更新进度指示器,显示完成动画,或者显示特定于该步骤的结果。stepName必须匹配相应的StepStarted事件,以正确配对步骤的开始和结束;
2.2 文本消息事件
表示对话中文本消息的生命周期。文本消息事件遵循流模式,内容是增量交付的。消息以TextMessageStart
事件开始,接着是一个或多个TextMessageContent
事件,在文本块可用时传递它们,并以TextMessageEnd
事件结束。
这种流式处理方法支持在消息内容生成时实时显示消息内容,与等待整个消息完成后再显示任何内容相比,可以创建响应更快的用户体验。
2.3 工具调用事件
表示Agent进行的工具调用的生命周期。工具调用遵循类似于文本消息的流模式。当代理需要使用工具时,它会发出一个ToolCallStartevent
,随后是一个或多个ToolCallArgs
事件,这些事件以流的形式将参数传递给工具,并以一个ToolCallEnd
事件结束。
这种流式方法允许前端实时显示工具执行进度,使Agent的操作更加透明,并提供关于正在调用哪些工具以及使用哪些参数的即时反馈。
2.4 状态管理事件
用于管理和同步Agent与前端的状态。协议中的状态管理遵循一种高效的snapshot-delta 模式,其中完整的状态快照会在初始时或者不频繁地周期发送,而增量更新会在进行中动态发送。这种方法对完整性和效率都进行了优化:快照确保前端具有完整的状态上下文,而增量最小化更新的数据传输。它们一起使前端能够准确及时的维护代理状态。快照作为同步点,将状态重置为已知基线,而增量在快照之间提供轻量级更新。
StateSnapshot
:完整表示Agent当前的状态。此事件通常在交互开始时或需要同步时发送。它包含与前端相关的所有状态变量,允许它完全重建其内部表示。前端应该用这个快照的内容替换它们现有的状态模型,而不是试图将它与以前的状态合并;StateDelta
:事件以JSON Patch操作(如RFC 6902中定义)的形式包含对代理状态的增量更新。每个增量表示应用于当前状态模型的特定更改。这种方法具有带宽效率,只发送已更改的内容,而不是整个状态。前端应该按顺序应用这些补丁,以保持准确的状态表示。如果前端在应用补丁后检测到不一致,它可能会请求一个新的 StateSnapshot;MessagesSnapshot
:事件提供当前会话中消息的完整历史记录。与一般状态快照不同,它特别关注对话记录。此事件可用于初始化聊天历史记录、在连接中断后进行同步,或在用户加入正在进行的对话时提供全面视图。前端应该使用它来建立或刷新显示给用户的会话上下文;
2.5 特殊事件
特殊事件通过允许特定于系统的功能和与外部系统的集成,为协议提供了灵活性。这些事件不遵循其他事件类型的标准生命周期或流模式,而是用于特殊目的。
三、AG-UI中的Agent
Agent 是 AG-UI 协议中处理请求和生成响应的核心组件。它们为前端应用程序建立了一种标准化的方式,通过一致的接口与AI服务进行通信,而不考虑底层实现。在AG-UI中,Agent完成下面的工作:
- 管理会话状态和历史消息记录;
- 处理传入消息和上下文;
- 通过事件驱动的流接口生成响应消息;
- 遵循标准化的通信协议;
Agent可以实现与任何AI服务的连接,包括:
- 大型语言模型(llm),如GPT-4或Claude;
- 自定义AI系统;
- 检索增强生成(RAG)系统;
- 多Agent系统;
四、AG-UI基础消息结构
在AG-UI协议中,消息构成了通信的主干。它们代表了用户和AI Agent之间的对话历史,并提供了一种标准化的方式来交换信息,而不管正在使用的底层AI服务是什么。
AG-UI消息遵循供应商中立的格式,确保不同AI提供商之间的兼容性,同时保持一致的结构。这允许应用程序在不更改客户端实现的情况下在AI服务(如OpenAI、Anthropic或自定义模型)之间切换。基本消息结构如下所示:
interface BaseMessage {id: string // Unique identifier for the messagerole: string // The role of the sender (user, assistant, system, tool)content?: string // Optional text content of the messagename?: string // Optional name of the sender
}
五、AG-UI中的工具调用
工具是AG-UI协议中的一个基本概念,它使AI Agent能够与外部系统交互,并将人类判断纳入其工作流程。通过在前端定义工具并将其传递给Agent,开发人员可以创建复杂的人机交互体验,将人工智能功能与人类专业知识相结合。在AG-UI中,工具是Agent可以调用的函数:
- 请求特定信息
- 在外部系统中执行操作
- 要求人工输入或确认
- 访问特定功能
工具是人工智能推理和现实世界行为之间的桥梁,允许Agent完成仅通过对话无法完成的任务。
5.1 工具结构
工具遵循一致的结构,定义了它们的名称、用途和预期参数:
interface Tool {name: string // Unique identifier for the tooldescription: string // Human-readable explanation of what the tool doesparameters: {// JSON Schema defining the tool's parameterstype: "object"properties: {// Tool-specific parameters}required: string[] // Array of required parameter names}
}
·parameters·字段使用JSON Schema定义工具接受的参数结构。Agent(生成有效的工具调用)和前端(验证和解析工具参数)都使用该模式。
5.2 Frontend-Defined工具
AG-UI工具系统的一个关键是工具在前端定义,并在执行期间传递给Agent:
// Define tools in the frontend
const userConfirmationTool = {name: "confirmAction",description: "Ask the user to confirm a specific action before proceeding",parameters: {type: "object",properties: {action: {type: "string",description: "The action that needs user confirmation",},importance: {type: "string",enum: ["low", "medium", "high", "critical"],description: "The importance level of the action",},},required: ["action"],},
}// Pass tools to the agent during execution
agent.runAgent({tools: [userConfirmationTool],// Other parameters...
})
这种方法有几个优点:
- 前端控制:前端决定Agent可以使用哪些功能;
- 动态功能:可以根据用户权限、上下文或应用程序状态添加或删除工具;
- 关注点分离:Agent专注于推理,而前端处理工具实现;
- 安全性:敏感操作由应用程序控制,而不是Agent;
六、与其它Agent协议的关系
AG-UI主要关注的是Agent与用户间的交互,与A2A (Agent-to-Agent protocol)和MCP (Model Context protocol)等协议是互补的关系。例如,同一Agent代理可以通过A2A与另一个Agent通信,同时通过AG-UI与用户通信,并调用MCP服务器提供的工具。这些协议在智能体生态系统中起到互补作用:
- AG-UI:处理人机协同交互(human-in-the-loop)和流式UI更新;
- A2A:促进Agent之间的通信和协作;
- MCP:标准化不同模型间的工具调用和上下文处理;
总结
AG-UI标准化了前端应用程序如何通过开放协议连接到AI Agent。可以将其视为人工智能驱动系统的通用翻译器,无论代理说什么语言:AG-UI都确保了流畅的通信。AG-UI帮助开发人员构建需要实时交互、实时状态流和人机协同交互的下一代AI工作流。AG-UI的优势:
- 可以通过类似CopilotKit等框架直接将AI Agent与前端集成;
- 为人类与Agent间的通信构建高效的协议模块;
- 适用于聊天、流式状态更新、人机协同交互(human-in-the-loop)和共享状态的场景;