OCT. 29, 2026 (英语).
Agent-用户交互现在从文本交换发展到丰富的UI. 直到最近，大多数谈话都这样：
用户："给我找一个3月去巴厘岛的度假包裹".
Agent:(6套散文，每套有日期，酒店，航班，价格)
用户："五夜一带早餐".
Agent:"这里的链接。 你可以在运营商的网站上预订".
Agents可以计划这次旅行，但一切都作为文字墙而回来。 他们没有标准的方法来制作一个可以选择的包裹列表，一个目的地的地图，或者一个采枣者来载你通过其他的预订，在对话本身中。
Generative UI是让agents在运行时构建接口的层，由每个请求需要的来塑造——给用户丰富，互动的经验。 执行它需要两块：一种描述UI的方法和一个代理堆栈，将您的 agent 与您的应用程序连接起来，并使之成为UI.
- A2UI(Agent-to-UI)是Google的Generative UI框架不可知的开放标准。 agent将一个接口描述为数据，您的应用程序用已经拥有的组件来绘制它。 由设计而成的交通不可知论。
- CopilotKit提供agent-集成堆栈与agent框架融合，例如“LangChain”、“AWS Strands”、“Google ADK”等，用于构建用户造型代理应用程序。 它为用A2UI协议构建丰富的应用程序提供了工具包，包括聊天表面，运行时间，以及杠杆A2UI渲染器，跨越React和Angular. CopilotKit还为Vue和Slack提供定制的A2UI渲染器。
Generative UI涵盖一系列方法，从使用预先定义的更高顺序组件，到使你的AI agent能够灵活决定如何构建UI.
在控制端，您提前构建每个组件，agent 选择要渲染哪个组件，并使用哪些数据。 虽然这很安全，在开端，agent返回一个用HTML,Javascript和/或达特写成的原始UI程序，在沙盒式的iframe内制成。 这涵盖了任何你没有计划的东西，代价是表面从你的设计系统漂移并执行一个模型写的代码。
A2UI通过整个光谱工作。 它与Typesafe's Jev等决策模型一起参与可控生成，并参与可输出A2UI JSON消息的开放式代码生成。 agents 组装预声明组件和功能的宣示模式最为流行。 A2UI是宣布UI意图的框架不可知标准，所以本地或远程的agents可以使用通用语言从现有的组件目录中生成你的UI.
- 警卫先 A2UI是一种声明数据格式，而不是可执行代码。 客户端保留了可信任组件的目录，因此agent以外的任何发明在到达屏幕之前都会被捕获。
-LLM友好和流畅。 有效载荷是一份通过ID互相参照的JSON小消息的平面列表，因此agent递增地释放出来，客户端在到达时会生成组件。
- 框架不可知和便携式。 同样的反应通过React,Lit,Angular,SwiftUI,Jetpack Compose(Android)或Flustter(多平台)，并通过Vue的社区渲染器，甚至终端。
前端开发者现在可以将构件运送一次，agent为每个请求作曲。
Basic Catalog号飞船有18种通用原始物，跨越布局，显示，输入和容器。 agent可以根据请求需要，从同一个18个原始人中完全不同地组成接口。
Basic Catalog 刻意稀少，因此大多数生产应用都定义了自己的定制目录。 自定义组件可以是您前端已经制作的任意内容，包括一个在您的渲染器绘制路由时充满坐标的活地图agent.
副驾驶Kit是建立在AG-UI(Agent-User Interactive Protocol)上，它支持A2UI有效载荷，并跨越许多代理后端提供Agent SDK.
你的agent发射A2UI操作。 AG-UI 把它们作为输入事件带给客户端。 当用户采取任何动作时，这些值会沿着同一流返回。
A2UI与任何AG-UI兼容的agent合作。 Google ADK,LangChain,Mastra和Strands等框架都是AG-UI兼容的，因此，无论您的agent运行在哪个位置，设置都是相同的。
设置降为两件事：将您的 agent 连接到 CopilotKit，并定义 agent 允许使用的组件。
以Google ADK为例，ag ui adk包包装任何ADK agent，并作为FastAPI上的AG-UI端点：
从 fastapi 导入 FastAPI
从 google.adk.agents 导入 LlmAgent
从 ag ui adk 导入 ADKAgent，添加 adk fastapi 端点
root agent = LlmAgent( 转录)
名称="飞行 agent"
型号="gemini-3.8-flash"
指令="帮助用户查找并预订航班。 呼叫生成 a2ui以显示结果".
)
adk_agent = ADKAgent(
adk agent=root agent 页面存档备份，存于互联网档案馆
app name="飞行"
用户 id=“demo user”
使用 in memory service=true
)
应用=FastAPI()
添加 adk fastapi 端点(app, adk agent, path="/").
Python
复制
在应用方面，您用 /api/ copirokit 的 CopiroKit 运行时间来注册端点。 这是几行标准设置，覆盖在Google ADK快速启动中，它不需要A2UI特异性。
A2UI 本身从客户端打开，您的组件已经在那里。 定义 agent 允许绘制什么，将每个定义映射到一个渲染器，并将目录传递给 CopilotKit 提供者。
从“ @copilotkit/react-core/v2” 导入{copilotKit,CopilotChat};
导入 {
创建目录
类型目录定义
类型目录生成器
由@copilotkit/a2ui-lander提供；
从“ z ” 导入{ z };
定义={
飞行卡：{
说明：“航空、时间和停留的飞行结果。”
道具：z.object({)
航空公司：z.string()
离开：z. string ()
到达：z. string ()
停止：z. 数字( )
}),
},
满足目录定义；
Const 目录显示器 = {
飞行卡：MyFlightCard, //你的React组件
满足目录编制者<目录类型定义>;
const目录 = 创建Catalog(目录定义，目录编制者，{
编目："飞行目录"
包含 BasicCatalog：真
});
/ api/copirokit) a2uiQQ目录 QQ
< 副驾驶聊天 />
</CopilotKit> (英语).
Java 脚本
描述进入了agent的提示，因此模型知道何时可以到达FlightCard，而不是通用卡。 佐德计划验证它发回的道具。
A2UI配置可以提前在服务器上设置，也可以被动态创建，随请求从客户端运至服务器。 上面的 ADK 代码使用动态配置，所以它使用生成 a2ui而不定义它。 文件涵盖两种办法。
这是副驾驶Kit的路径。 您也可以直接使用@ag-ui/客户端消耗事件流，并将 A2UI 操作交给任何符合要求的渲染器：@a2ui/react，或Flutter,Lit，或Angular等效。
大多数agent生成的UI是一发。 agent画一些东西，你读它，它会停止任何改变的时刻。
A2UI表面是双向的，组件是反应性的，这使得多步流成为可能。 用户在界面上采取的任何行动(选择日期、选择航班、输入乘客详细信息)都沿着同一溪流返回，agent利用这些值重新从那里吸收表面。
以下是一款端到端的预订流程的高层次架构实例，在Cloud Run上有一个AG-UI agent将A2UI浮出水面到一个CopilotKit前端。
有两件事使往返成功：输入绑定在数据路径上，以及一个带一个动作的按钮，命名哪些路径可以发送回路。
{"id":"cabin","组件":"ChoicePicker","变体":"相互排斥"
"选项": [{"标签":"经济","价值":"eco"]
{"标签":"商业","价值":"biz"}
"价值":{"路径":"/订/cabin"}}
{"id":"确认","组件":"按钮","孩子":"确认 label"
"行动": {"事件":{"姓名":"确认"
"通典": {"嘉宾":{"路径":"/订/嘉宾"〕
"电子邮件":{"路径":"/订/电子邮件"}}}}}}
贾森
验证运行在客户端上，因此一个糟糕的电子邮件显示是一个没有模型调用的错误内置。 在扣子起火前，agent没有到达。
然后客户端发送绑定值，agent则针对同一表面Id重现。 这就是整个流体在一个表面生活的方式：飞行搜索，结果，乘客细节，以及确认。
每个AG-UI的整合都包含着这些好处，所以你不必自己建造：
- 最小服务器侧设置：目录在设置上达到agent，所以在客户端上注册就是它所需要的。
- 生成在专用的子 agent中：目录和协议规则不包含在您主的 agent 上下文窗口中，当子 agent 生成时，表面流到客户端。
——自愈输出：无效的世代被抓住，具体错误被退回更正，所以没有破损到屏幕。
- Graceful fail：当重试耗尽时，表面会决定一个短信息，对话会继续，而不是在错误状态下死去。
创建一个完整的 A2UI + CopilotKit 应用程序。 这创造了一个带有Copilotkit Agent集成的启动器A2UI应用程序。
npx 副驾驶 kit@latest 创建 --name my- app -- framework a2ui
贝壳
CopilotKit Dojo有可运行的 A2UI 演示：固定服务器侧图，动态图针对自定义目录，以及一个无效先将愈合成有效目录的错误恢复实例。
探索如何用 CopilotKit 构建 Generative UI Agents，或潜入 A2UI 文档，学习如何将 A2UI 与您选择的任何框架整合。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
OCT. 29, 2026
Agent-User Interactions are now evolving from text exchanges to rich UIs. Until recently, most conversations looked like this:
User: "Find me a holiday package to Bali in March."
Agent: (six packages in prose, each with dates, hotel, flights, price)
User: "The five-night one with breakfast."
Agent: "Here's the link. You can book it on the operator's site."
Agents could plan the trip, but everything came back as walls of text. They had no standard way to render a selectable list of packages, a map of the destinations, or a date picker to carry you through the rest of the booking, inside the conversation itself.
Generative UI is the layer that lets agents build interfaces at runtime, shaped by what each request needs - giving users a rich, interactive experience. Implementing that takes two pieces: a way to describe the UI and an agentic stack that connects your agent to your application and renders that UI.
- A2UI (Agent-to-UI) is Google's framework-agnostic open standard for Generative UI. The agent describes an interface as data, and your application draws it with the components you already have. It's transport-agnostic by design.
- CopilotKit provides the agent-integration stack to integrate with agent frameworks like “LangChain”, “AWS Strands”, “Google ADK”, etc. for building user-facing agentic apps. It provides a toolkit for building rich applications with A2UI protocol, including the chat surface, runtime, and leverages A2UI renderer, across React and Angular. CopilotKit also provides custom A2UI renderers for Vue and Slack.
Generative UI covers a spectrum of approaches, from using predefined higher order components, to enabling your AI agent to have the flexibility to decide how to build the UI.
At the controlled end, you build each component ahead of time, and the agent picks which one to render and with what data. It's brand-safe but it does not allow for deep customization and personalization based on the user’s intent. At the open end, the agent returns a raw UI program written in HTML, Javascript and/or Dart that renders inside a sandboxed iframe. That covers anything you did not plan for, at the cost of a surface that drifts from your design system and executes code a model wrote.
A2UI works through the entire spectrum. It participates in controlled generation with decision models like Typesafe’s Jev and also open-ended code generation that may output A2UI JSON messages. The declarative mode, where agents assemble pre-declared components and functions, is the most popular. A2UI is the framework-agnostic standard for declaring UI intent, so local or remote agents can generate your UI from your existing component catalog using a common language.
- Security first. A2UI is a declarative data format rather than executable code. The client keeps a catalog of trusted components, so anything the agent invents outside that set is caught before it reaches the screen.
- LLM-friendly and streaming. The payload is a flat list of small JSON messages that reference each other by ID, so the agent emits it incrementally and the client renders components as they arrive.
- Framework-agnostic and portable. The same response renders through React, Lit, Angular, SwiftUI, Jetpack Compose (Android) or Flutter (multi-platform), and through community renderers for Vue, or even the terminal.
Frontend developers can now ship the building blocks once, and the agent composes them for each request.
The Basic Catalog ships 18 general-purpose primitives across layout, display, input, and containers. The agent can compose entirely different interfaces from the same 18 primitives, depending on what the request needs.
The Basic Catalog is deliberately sparse, so most production apps define their own custom catalog. A custom component can be anything your frontend already renders, including a live map the agent fills with coordinates while your renderer draws the route.
CopilotKit is built on AG-UI (Agent-User Interaction Protocol), which supports A2UI payload and provides Agent SDKs across many agentic backends.
Your agent emits A2UI operations. AG-UI carries them to the client as typed events. When the user takes any action, the values are sent back along the same stream.
A2UI works with any AG-UI compatible agent. Frameworks like Google ADK, LangChain, Mastra and Strands are all AG-UI compatible, so the setup is identical whichever one your agent runs on.
Setup comes down to two things: connecting your agent to CopilotKit, and defining which components the agent is allowed to use.
Using Google ADK as the example, the ag_ui_adk package wraps any ADK agent and serves it as an AG-UI endpoint on FastAPI:
from fastapi import FastAPI
from google.adk.agents import LlmAgent
from ag_ui_adk import ADKAgent, add_adk_fastapi_endpoint
root_agent = LlmAgent(
name="flight_agent",
model="gemini-3.8-flash",
instruction="Help users find and book flights. Call generate_a2ui to show results.",
)
adk_agent = ADKAgent(
adk_agent=root_agent,
app_name="flights",
user_id="demo_user",
use_in_memory_services=True,
)
app = FastAPI()
add_adk_fastapi_endpoint(app, adk_agent, path="/")
Python
Copied
On the app side, you register that endpoint with the CopilotKit runtime at /api/copilotkit. It's a few lines of standard setup, covered in the Google ADK quickstart, and it needs nothing A2UI-specific.
A2UI itself turns on from the client, where your components already are. Define what the agent is allowed to draw, map each definition to a renderer, and pass the catalog to the CopilotKit provider.
import { CopilotKit, CopilotChat } from '@copilotkit/react-core/v2';
import {
createCatalog,
type CatalogDefinitions,
type CatalogRenderers,
} from '@copilotkit/a2ui-renderer';
import { z } from 'zod';
const catalogDefinitions = {
FlightCard: {
description: 'A flight result with airline, times, and stops.',
props: z.object({
airline: z.string(),
departs: z.string(),
arrives: z.string(),
stops: z.number(),
}),
},
} satisfies CatalogDefinitions;
const catalogRenderers = {
FlightCard: MyFlightCard, // your React component
} satisfies CatalogRenderers<typeof catalogDefinitions>;
const catalog = createCatalog(catalogDefinitions, catalogRenderers, {
catalogId: 'flight-catalog',
includeBasicCatalog: true,
});
<CopilotKit runtimeUrl="/api/copilotkit" a2ui={{ catalog }}>
<CopilotChat />
</CopilotKit>
JavaScript
The description goes into the agent's prompt, so the model knows when to reach for FlightCard instead of a generic card. The Zod schema validates the props it sends back.
The A2UI configuration can be set up ahead of time on the server, or it can be created dynamically, shipped from the client to the server with the request. The ADK code above used dynamic configuration which is why it used generate_a2ui without defining it. The docs cover both approaches.
That’s the CopilotKit path. You can also consume the event stream directly with @ag-ui/client and hand the A2UI operations to any compliant renderer: @a2ui/react, or the Flutter, Lit, or Angular equivalent.
Most agent-generated UI is one-shot. The agent draws something, you read it, and it goes stale the moment anything changes.
A2UI surfaces are bi-directional and the components are reactive, which makes multi-step flows possible. Any action the user takes on the interface (picking dates, choosing a flight, entering passenger details) travels back along the same stream, and the agent re-emits the surface from there using those values.
Here is a high-level architecture example of an end-to-end booking flow, with an AG-UI agent on Cloud Run streaming A2UI surfaces to a CopilotKit frontend.
Two things make the round trip work: inputs bound to a data path, and a button carrying an action that names which paths to send back.
{ "id": "cabin", "component": "ChoicePicker", "variant": "mutuallyExclusive",
"options": [ { "label": "Economy", "value": "eco" },
{ "label": "Business", "value": "biz" } ],
"value": { "path": "/booking/cabin" } },
{ "id": "confirm", "component": "Button", "child": "confirm_label",
"action": { "event": { "name": "confirmBooking",
"context": { "cabin": { "path": "/booking/cabin" },
"email": { "path": "/booking/email" } } } } }
JSON
Validation runs on the client, so a bad email shows an error inline without a model call. Nothing reaches the agent until the button fires.
Then the client sends the bound values, and the agent re-emits against the same surfaceId. That is how the whole flow lives on one surface: flight search, results, passenger details, and confirmation.
Every AG-UI integration inherets these benefits, so you don't have to build them yourself:
- Minimal server-side setup: the catalog reaches the agent on setup, so registering it on the client is all it takes.
- Generation in a dedicated sub-agent: the catalog and protocol rules stay out of your main agent's context window, and the surface streams to the client as the sub-agent produces it.
- Self-healing output: invalid generations are caught and the specific errors go back for a correction, so nothing broken reaches the screen.
- Graceful failure: when retries are exhausted, the surface resolves to a short message and the conversation continues instead of dying in an error state.
Create a complete A2UI + CopilotKit application. This creates a starter A2UI application with Copilotkit Agent integration.
npx copilotkit@latest create --name my-app --framework a2ui
Shell
The CopilotKit Dojo has runnable A2UI demos: fixed server-side schema, dynamic schema against a custom catalog, and an error-recovery example where an invalid first render heals into a valid one.
Explore how to build Generative UI Agents with CopilotKit, or dive into A2UI documentation to learn how to integrate A2UI with any framework of your choice.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.