挑选一次假期，用户要的可能只是把六个套餐并排比较，再点一下日期。聊天式智能体却常把航班、酒店、价格塞成长段文字，最后给出一个跳转链接。谷歌与CopilotKit在10月29日发布的A2UI教程，从这段具体的订票过程切入：把可选择的卡片和输入框放进对话，让用户在原来的界面里继续操作。

界面随请求生成之后，软件团队要交出的东西也发生变化。以前由设计师排好的整个页面，现在可以拆成一组预先定义的组件，再让智能体按任务组合。用户问旅行，出现航班卡片；用户补充座位要求，界面更新对应选项。这套机制把对话推进到可以提交结构化信息的环节。

模型描述意图，客户端决定怎么画

A2UI是谷歌推出的、与应用框架无关的开放标准。智能体用数据描述界面，应用使用已有组件完成绘制。教程把它放在两种常见方式之间解释：开发者可以提前制作完整卡片，也可以让模型直接生成在沙箱里运行的界面代码。A2UI最常用的声明式模式，则让智能体从应用给定的组件目录中组合界面。

这里有一处会改变产品判断的细节：组件目录掌握在客户端。智能体发来的数据要经过这份目录，超出可信集合的组件会被拦下。软件团队因此仍然控制品牌样式、组件能力和允许出现的交互。让模型决定此刻需要哪张卡片，与让模型获得任意执行代码的入口，是两种权限安排。

基础目录提供18种通用组件，覆盖布局、显示、输入和容器。官方同时说明，多数生产应用会定义自己的目录。例如地图组件可以由前端负责绘制，智能体只提供坐标。这样，地图的实现和数据意图就能分开：前端维护稳定能力，智能体处理用户这次想去哪里。

教程里的航班卡片还展示了这一分工怎样落地。应用声明航空公司、起飞时间、到达时间和经停次数等字段，并把它们绑定到自己的渲染组件。组件说明会进入模型提示词，字段规则则验证返回的数据。一次界面生成的质量，既取决于模型是否理解任务，也取决于团队怎样定义这些业务字段。

点下确认，才把选择交回智能体

CopilotKit在这套方案中承担连接工作。智能体发出A2UI操作，AG-UI把操作作为事件传到客户端；用户在界面上作出的选择，也通过同一条事件流返回。谷歌ADK、LangChain和Strands等兼容框架可以参与这条链路。后端框架可以不同，界面描述仍使用共同语言。

更有价值的变化发生在第二轮交互。许多生成式界面只负责画出一次结果，数据变化以后就过时。教程中的A2UI界面把输入绑定到数据路径，把按钮绑定到需要提交的字段。用户选择舱位、填写邮箱，再按确认，应用才将这些值送回智能体，随后更新同一个界面。

邮箱校验在客户端运行。格式有误时，页面可以直接显示提示，无须为这个错误额外调用模型。这个小安排划出了一条实用的成本边界：确定性的检查交给软件，任务理解和下一步组织再交给智能体。对用户而言，错误停在输入框旁边，比在对话中重新解释一遍更容易处理。

对于软件交付，这仍是一套开发集成方案。教程给出了接入端点、注册组件目录和启动示例应用的路径，生产团队还要接上自己的业务操作。订票卡片能收集信息，实际交易怎样授权和执行，仍由具体应用决定。官方的演示把界面往前推进了一步，没有提供所有企业都能直接套用的交易后台。

这种分工会影响企业软件入口的争夺。聊天框吸引用户提出需求，组件目录决定哪些需求能够变成有效操作。掌握目录的团队，可以把自家表单、地图和业务卡片带进智能体会话；接入框架负责把选择传回去。用户少了一次页面跳转，应用方则多了一项需要维护的资产：可被智能体调用、又受自己约束的交互能力。