AI 大模型时代，人机交互正迎来一次深刻变革。传统“对话框 + 纯文本”的交互方式，已难以满足用户对 AI 体验的更高期待——用户期待的不只是一段回答，而是一个符合意图、可以交互的界面。基于大模型理解用户意图并动态生成交互界面的生成式 UI 技术，正推动 AI 从“直接给出答案”走向“提供可交互、可操作、可演进的界面体验”。
但生成式 UI 的规模化落地，必须同时回答两个基础问题：如何生成协议，以及如何渲染界面。前者要解决的是如何驱动大模型基于用户意图与业务上下文，低成本、稳定、可控地生成页面描述协议；后者要解决的是端侧如何将协议描述转化为高性能、可交互、跨端一致的原生界面。两者缺一不可。
基于生成式 UI 协议，我们沉淀了一套端云一体的生成式 UI 方案——AGenUI：云侧负责将用户意图与业务上下文转化为可执行的生成式 UI 协议，端侧渲染器负责将协议数据实时渲染为 iOS、Android、HarmonyOS 三端的原生界面。
云侧，我们构建了一套多 Agent 分工、分层收口的可执行卡片生产系统。模型负责它最擅长的开放决策——理解意图、选择布局、提出设计方案；Agent 工程的确定性机制负责内容契约、字段证据、执行计划这些必须稳定的生产事实。这带来三个纯模型直出不具备的能力：
•生成可控：同一输入与知识版本下，系统固化规则引用、契约、需求、绑定计划和执行包，使生产事实可审计、可校验、可回放，而不是每次开盲盒；
•证据可溯：界面上每一处视觉元素都能回溯到内容契约、设计规则、数据来源与算法版本，线上问题可以精确归因；
•发布有界：“能生成”与“可发布”被明确分开——必需信息缺少可信数据来源时，系统阻断并返回缺口，而不是编造展示内容。
端侧渲染器基于共享 C++ 核心引擎 + 三端原生渲染的架构设计，完整实现生成式 UI 协议，是行业首个覆盖 iOS、Android、HarmonyOS 三端的 A2UI 原生渲染引擎，具有三个突出特点：
•原生高性能渲染：三端均采用原生渲染，零中间层性能损耗；
•像素级三端一致性：协议解析、虚拟节点树管理、布局计算、主题样式等核心逻辑统一由 C++ 引擎承载，同一份协议在三端得到完全一致的渲染结果；
•流式渐进渲染：组件级流式解析，首个组件到达即可上屏，无需等待全部生成完毕。
欢迎访问官网和开源仓库体验更丰富的内容和渲染效果
官网https://genui.amap.com
GitHubhttps://github.com/AGenUI/AGenUI
生成式 UI 平台目前已在线支持 30+ 个业务场景，覆盖目的地及沿途推荐、信息展示与出行工具、生活服务交易、内容商业化、出行规划与运力服务等 5 大业务方向。整体在线服务请求量级约 5k QPS，单卡具备小时级上线能力，业务能力已从信息展示扩展到“推荐—决策—交易—出行服务”的完整链路。
问题定义：从“能生成”到“能上线”，生产级卡片还缺什么？
上图展示的是高德内部已上线的生成式 UI 卡片，覆盖酒店推荐、景点购票、沿途天气、餐饮套餐等真实出行场景。要生成并稳定交付这类生产级卡片，核心需要同时解决三个要素：样式、数据绑定和算子。
真正让一张卡从 Demo 走向生产，难点不在“画出来”，而在“好不好用、敢不敢信、能不能跑”：
- 样式解决好不好用——信息是否清晰、体验是否一致；
- 数据绑定解决敢不敢信——页面是否连接真实、可追溯的业务数据；
- 算子解决能不能跑——后端字段与卡片需求不一致时，数据能否被正确转换并执行。
三者缺一，卡片都无法成为真正的生产能力。
样式：规则驱动、生成式 UI 协议与端上渲染
核心思路是将设计规则、端上渲染器能力与生成式 UI 协议结合：规则约束布局和视觉表达，渲染器限定可落地的组件能力，最终生成可跨端渲染的生成式 UI 协议。
数据绑定：知识库召回、精排与真实字段绑定
核心思路是把接口与字段能力沉淀到知识库，围绕卡片语义槽位进行字段级召回、精排和绑定校验，必要时进行同实体多源补全，从而提升召回准确率与绑定质量。
算子：字段转换、版本化与受控执行
核心思路是把格式化、单位换算、过滤、排序等转换逻辑沉淀为可召回的版本化算子；当字段无法直接满足卡片需求时，由 Bind Agent 选择已发布算子并交给 Runtime 受控执行。
三者形成闭环，即样式定义卡片需要什么，数据绑定找到真实字段，算子将字段转换成可直接展示的数据。
端云一体总体架构
一次完整的 AGenUI 卡片交付由两条解耦链路构成：离线生产链路将用户意图收口为内容契约，完成样式生成与数据、算子绑定，并经最终 Gate 发布为版本化执行包；在线执行链路不再重新调用模型或选择接口、算子，而是确定性加载执行包，生成 DataModel，并将样式协议与 DataModel 单向交付给端侧渲染器。
因而，界面不是一次偶然成功的模型输出，而是可发布、可执行、可回放的界面资产。用户后续修改会以新的离线编辑请求进入，通过 Edit Contract 确定变更范围，而不是由端侧运行事件直接改写生产产物。
界面不再是一次性交付的静态产物，而成为 Agent 表达、组织和执行任务的动态载体。
这条链路的两端，正是本文展开的两个主角：云侧的卡片生产体系，要回答“如何把一句自然语言意图，变成一份可执行、可追溯、可发布的可执行卡片包”；端侧的 AGenUI 渲染器，要回答“如何把这份协议，变成三端一致、高性能、流式呈现的原生界面”。
云侧：从用户意图到可执行卡片包
AGenUI 云侧的目标，是把用户意图收口为一份可发布、可执行的卡片包：其中包含样式协议、数据绑定计划、算子引用与版本化执行信息。整条链路以契约生成为起点，围绕样式、数据绑定和算子完成卡片生产，再通过可控演进支持后续修改：先把“要生成什么”说清楚，再把“界面怎么生成、真实数据从哪里来、字段如何转换”逐一落地，最后保证每次修改只影响该改的部分。
以“生成一张终点附近的亲子酒店推荐卡”为例，内容契约先确定图片、酒店名、价格、评分、驾车距离和预订入口等展示需求，再进入样式、数据绑定和算子三条生产链路。
契约生成：先把“要生成什么”说清楚
自然语言请求通常只说“想要什么”，却不会完整说明对象范围、内容优先级、缺失策略和动作语义。如果直接进入样式、数据或算子环节，每一层都会基于自己的上下文重新解释用户意图。
目标漂移｜样式为了画面完整擅自增加内容，数据又可能因为接口里恰好有某个字段，反过来改变卡片要表达的业务语义。
交付失真｜必需内容与可选内容没有边界，关键字段缺失时，系统仍可能生成一张“看起来完整、实际上不能交付”的卡片。
修改失控｜没有稳定基线，后续只改价格或图片时，标题、布局、绑定和动作都可能一起漂移。
因此，主 Agent 先将用户意图收口为 Content Contract，明确任务目标、必需内容、可选内容、动作语义与缺失策略；后续样式、数据绑定和算子都以这份契约为共同输入。它带来三项关键约束：
统一目标｜冻结用户要完成的有限任务、业务对象和场景范围，让所有Agent面对同一个问题。
冻结边界｜明确必需内容、可选内容、动作语义和缺失策略，告诉系统什么不能少、什么可以降级。
稳定引用｜为内容和动作生成稳定ID，样式、数据绑定和算子都引用同一份事实，不再重复猜测。
样式：规则驱动生成可落地的生成式 UI 协议
样式生成由设计规则、端上渲染器能力和生成式 UI 协议共同约束。设计规则决定布局、信息层级、品牌 Token 和元素关系；Renderer Catalog 提供目标端可用组件及其语义能力视图，并用于计算最小 Renderer Gate；生成式 UI 协议作为跨端标准承载最终界面结构。
样式 Agent 根据内容契约召回并精排 Layout 与关联规则，在渲染器能力边界内生成界面，同时为标题、价格、图片和动作等位置声明稳定的语义槽位。产物记录规则版本、哈希和引用证据，使结果可复现、可校验。规则不会整体塞入 Prompt。系统先按内容契约选择布局候选，再通过工具读取关联规则闭包，将布局、元素、原子规则和视觉配方按需注入；每次读取形成带 Revision 与 Hash 的 Receipt。这样既控制上下文规模，也让规则召回、生成结果和后续问题归因共享同一份证据。
数据绑定：通过知识库召回与精排完成真实字段绑定
Requirement Compiler 先将样式中的语义槽位编译为确定的数据需求，并同时产出动作相关的协议约束，明确作用域、类型、必需性和缺失策略，避免绑定层重新猜测用户意图。
Bind Agent 围绕每个需求从字段能力知识库进行召回与精排，综合业务语义、单位口径、实体身份和接口可用性等证据选择真实字段并形成 Binding Plan。单源不能满足时，仅允许一层、并行、同实体补全；必需字段没有可信结果则阻断自动发布，并返回结构化缺口，供设计或产品调整卡片方案。
算子：通过版本化转换能力弥合字段错位
后端字段虽然真实存在，但往往不能直接满足卡片需求，例如米转公里、金额格式化、条件文案、过滤、排序和聚合。算子负责弥合接口字段与卡片展示需求之间的形态差异。
算子以知识资产维护输入输出 Schema、适用语义、参数约束、版本和 Runtime 支持信息。当字段不能直接满足需求时，Bind Agent 召回并精排已发布算子；模型只选择算子和受约束参数，由 Runtime 受控执行并校验结果。我们不把模型生成的临时代码直接带入线上，也不将多接口编排扩展为通用 DAG。数据组合限制为单层、并行、同实体补全；字段转换限制为已发布、带输入输出 Schema 与版本的算子。这样 Runtime 的执行拓扑有界，失败可定位，算子可灰度和回滚；更复杂的依赖则应沉淀为后端聚合能力，而不是交由单卡运行时临场编排。
样式协议、Binding Plan 和算子引用最终被固化为 Card Execution Package，Runtime 只执行已批准的计划。规则版本、字段证据、算子版本与运行结果作为 Artifact 留存，使整张卡能够追踪、回放和局部编辑。
可控修改：只改该改的，其他保持不变
用户更常见的需求不是重新生成一张卡，而是在现有结果上继续调整，例如“图片再大一点”“价格改成含税价”。如果每次都整卡重生成，即使目标改对了，标题、样式、数据绑定和交互也可能发生无关漂移。
目标集｜本轮必须改变的内容，确保用户点名的修改真正发生。
保护集｜未被点名的内容保持不变，防止样式、数据和交互无关漂移。
影响集｜沿依赖关系找出必须重做、重新校验的下游产物。
复用集｜未受影响的 Design、Binding Plan 和 Package 直接沿用，避免整卡重算。
“只改图片大小，其他保持不变”不再只是一句 Prompt，而是一份可执行、可验证的变更计划。
Agent 底座：让多 Agent 生产过程成为可恢复的事实链
多 Agent 并不等于把一个复杂任务拆成多段 Prompt，再让模型自由接力。对于制卡这类需要发布和长期维护的任务，真正需要被管理的是每一步产生的生产事实。
因此，我们以一次离线 Run 作为制卡过程的最小执行单元。内容契约、样式协议、Requirements、Binding Plan、算子引用、Gate 结果等关键产物，都会以带类型、版本、Hash 和来源引用的 Artifact 持久化。下游步骤只消费已确认的上游 Artifact，而不是重新从对话上下文中猜测前序结论。
这带来三项工程收益：
•过程可恢复：模型调用、工具读取或校验过程发生中断时，Run 可以从最近一个可信检查点恢复；已完成且未受影响的产物无需重新生成。
•决策可追溯：一张卡为什么选择某套布局、绑定某个字段、引用某个算子，或为什么被 Gate 拒绝，都能回溯到对应的知识版本、工具读取证据与 Artifact。
•修改可控：多轮编辑不再依赖模型“记住上一轮”。Edit Contract 以既有 Artifact 为基线，声明目标集、保护集和影响集；系统只重算受影响的步骤，并复用其余产物。
在这套机制中，模型负责开放决策，工具负责读取受控知识，系统负责校验、固化和发布。这里的 Run 只属于离线卡片生产过程；在线 Runtime 则只加载已发布的执行包，确定性完成数据获取、算子执行与 DataModel 生成，不承担 Agent 决策。
这样，生成式 UI 的多 Agent 链路才从“多次模型调用”变成了一条可恢复、可审计、可演进的生产事实链。
端侧：从 UI 描述协议到三端原生渲染
AGenUI 完整实现了生成式UI协议，是行业首个覆盖 iOS、Android、HarmonyOS 三端的 A2UI 原生渲染引擎。在高德地图这类对性能和体验高度敏感的超级 App 中，它对自身提出了明确的要求：必须达到高性能、体验流畅的原生页面品质。
为此，AGenUI 采用共享 C++ 核心引擎 + 三端原生渲染引擎的架构设计。C++ 核心引擎统一承载流式协议解析、虚拟组件树管理、布局计算、样式解析与变化 diff 等平台无关的核心逻辑，三端渲染引擎则基于核心引擎下发的组件协议，使用系统原生能力完成绘制。
围绕这一架构的能力建设，AGenUI 具有三大核心技术特点：以原生渲染确立性能基线，以 C++ 共享引擎保证三端一致，以 Streaming-first 设计重塑流式体验。
原生渲染：为生成式 UI 确立性能基线
生成式 UI 是面向用户的交互载体，用户对滑动卡顿、首屏延迟的感知阈值极低——这一点不因界面是“生成的”而改变。为此，AGenUI 坚持纯原生渲染路线：
•零中间层损耗：不同于 WebView 与跨端框架，界面最终以系统原生组件呈现，没有中间抽象层的性能折损，并自然融入宿主 App 的交互、动画、无障碍与手势体系；
•异步渲染 + 差分更新：协议解析、布局计算、节点 diff 等计算密集逻辑全部在工作线程完成，主线程只提交轻量级绘制操作；流式更新支持差量更新变化的节点；
•平台深度优化：各端结合自身能力做深度调优。以 HarmonyOS 为例，AGenUI 基于 ArkUI 原生组件体系，通过 C API 打通高性能渲染链路，绕开脚本语言的运行时开销。
C++ 共享引擎：一次布局计算，三端像素级一致
三端各有不同的布局引擎与渲染机制，如果各自实现协议解析、布局计算与样式管理，“字号差一像素、间距多一点”这类细微差异会在复杂页面中被持续放大，排查与修复成本巨大。AGenUI 的解法是把平台无关逻辑全部下沉到共享 C++ 引擎，三端共享同一份计算结果：
•单一事实源：同一份协议在三端得到完全一致的布局结果，从根源上消除多端差异；三端渲染层只做最后一步——把引擎输出转换为各自平台的原生 View；
•计算性能：流式解析与布局计算都是典型的计算密集型任务，C++ 的性能优势为流式场景下的稳定帧率提供了底层保障；
•可移植性：核心引擎与平台解耦，未来扩展到车机、IoT 等终端时，只需新增对应的原生渲染层。
Streaming-first 渲染：生成过程即呈现过程
AGenUI 的核心架构采用 Streaming-first 设计：组件到达即可挂载，文本到达即可追加，数据到达即可绑定——生成过程本身就是用户可感知的界面呈现过程：
•组件级流式：组件以独立单元逐个到达、逐个解析、逐个上屏；协议数据尚未闭合时，解析自动挂起，并在下一段数据到达后从断点继续，不丢失任何中间状态；
•流式容错：针对 LLM 流式输出可能出现的多余字符、未闭合片段、突然中断等异常，引擎建立了完整的边界保护机制，任何异常输入都不会破坏渲染状态。
渲染品质：组件、样式与主题
生成式 UI 不只是“能画出来”，更要“画得好、画得稳、画得符合品牌”。为此我们内置了丰富的组件体系，并提供完整的样式与主题支持。
•组件体系：内置 22 个组件——18 个 生成式 UI 协议标准组件（文本、图片、卡片、列表、表单控件、媒体播放器等）与 4 个 SDK 扩展组件（表格、轮播、内嵌 Web、富文本）。SDK 在三端统一提供自定义组件注册 API：开发者注册的原生 View 可以像内置组件一样被模型引用，参与流式渲染、数据绑定与端侧事件处理； 
•样式与主题体系：以 DesignToken 为基底，内置 60+ 语义化颜色 token，每个 token 同时携带亮、暗两个色值；支持 45+ CSS 样式属性，覆盖盒模型、Flexbox 布局、文本、背景、边框、圆角等关键视觉要素。整套主题体系对接入方完全开放，可加载自定义配置实现品牌级定制。
•
质量闭环与演进
动态生成的界面直接面向用户，质量标准必须对齐甚至超越静态页面。我们分别从端、云两侧以及知识演进层面进行了系统性的质量体系建设和沉淀。
端侧：三条测试防线
•集成测试以三端自动化流水线覆盖协议解析、组件渲染、事件分发、数据绑定等核心链路。
•稳定性测试覆盖全部接口的极端压力场景，可持续运行数小时并自动监控异常。
•三端一致性验证引入自动化效果对比机制，确保同一协议在 iOS、Android、HarmonyOS 上的渲染结果一致。
云侧：分层门禁与会话级评测
生成式 UI 不存在一个统一“知识库”就能解决所有问题。不同决策需要不同类型的知识、不同的召回方式和不同的质量责任。因此，我们在多个维度对生成协议的质量进行评估。我们围绕以下4个维度建立了质量评测方法。
•样式是否符合规则与视觉目标。
•内容与数据是否真实满足。
•逻辑与协议是否可运行。
•多轮是否保持连续性。
为了避免把“单轮看起来不错”误判为系统可交付，评测会以会话脚本作为最小单元，而不仅是一条 prompt。一个脚本可包含：初始制卡、选择规则、数据预检、局部编辑、补充数据、用户确认、运行中断与恢复。每一步都校验该步应新建、复用或保持不变的 Artifact；尤其是编辑步骤，要同时验证目标集确实变化、保护集没有漂移、影响集完成了重算。
我们也刻意把不同质量问题分开归因。视觉 Judge 的通过不能证明字段绑定正确；Binding Plan 的结构正确不能替代 Runtime 调用成功；Renderer Gate 只确认目标 Catalog 中组件可用，不替 Action、属性路径或业务协议背书。分层 Gate 的价值不在于制造更多拦截，而在于失败后能给出正确的处理者和修复方向。
知识演进：线上反馈不自动改写线上规则
线上 Trace、用户反馈、人工结论与评测失败会形成新的知识候选，但候选必须经过冲突与影响分析、目标集/保护集/边界集的成对评测和发布门禁，才能成为新版本；失败版本不覆盖线上规则，影响报告与来源证据保留给设计、产品与研发查看。我们得到的不是“模型自动自我修改”，而是一条能持续积累且不会失控的工程闭环。
业务落地与框架开源
目前，AGenUI 已在高德地图的多个业务场景落地。以导航规划页为例，用户在规划行程时，系统会结合路线与目的地上下文实时选择推荐卡片；在不同的行程目的地、不同的时间节点，卡片内容随之动态更新。真实数据绑定、三端一致效果、原生高性能渲染等特性都在这条真实业务链路上持续运行。AGenUI 框架也在这个过程中不断吸收业务反馈、打磨细节。
AGenUI 端侧渲染器已正式开源并保持快速迭代，完整能力均在持续演进。
•官网：https://genui.amap.com
•GitHub：https://github.com/AGenUI/AGenUI
结语
生成式 UI 的难点从来不只是让模型画出一个界面。真正的挑战是让它在每次设计、每次数据选择、每次逻辑执行、每次编辑和每次发布中，都能保留清晰边界与可追溯证据。
对此，AGenUI 在端云两侧分别进行了系统性的链路和架构设计。云侧通过明确大模型和 Agent 生成确定性机制的分工，保证生成效果的确定性：模型承担它最擅长的开放决策，确定性机制收口必须稳定的生产事实，让每一次生成都可控、可溯、可发布；端侧以原生渲染和架构创新保证良好体验：以共享 C++ 引擎把布局、样式与流式解析的计算统一为一套单一事实源，以三端原生高性能渲染让界面以系统组件的形态呈现：同一份协议在 iOS、Android、HarmonyOS 上得到像素级一致的结果。
当样式、数据和逻辑都能被分别生成、确定性收口并在运行中验证时，卡片才不再是一段偶然成功的模型输出，而成为可持续交付的界面资产。
我们相信，生成式 UI 代表着人机交互的演进方向：从“提供信息”走向“提供决策服务”，从“人适应软件”走向“软件理解人”。未来，我们将在以下方向持续投入：
•协议能力升级：跟进 生成式 UI 协议新版本，支持更丰富的交互模式与组件类型；
•性能基线建设：建立生成式 UI 渲染的性能度量体系，持续优化首屏渲染与流式帧率表现；
•端云全链路完善：打通从协议生成、效果评测到端侧渲染的完整链路，进一步降低业务接入成本；
•多终端形态扩展：依托 C++ 核心引擎的可移植性，探索车机、IoT 等更多终端形态。
生成式 UI 的规模化落地，需要端与云的协同，也需要生态的共建。我们期待更多开发者和生态伙伴基于 AGenUI 参与共建：一起完善组件体系、扩展端云能力、沉淀 Agentic UI 最佳实践，共同推动生成式 UI 协议从开放标准走向规模化落地。
本文作者@高德技术，原文链接：https://mp.weixin.qq.com/s/ObmgF8prPkn4ioknlHbtAw