案例复盘 · 生成式 UI 落地：A2UI 协议 + 跨端原生渲染

CHAPTER A

从"点击 → 导航 → 操作"到"AI 生成界面"

本文素材取自一份关于"生成式交互框架"的工程实践分享。技术骨架与设计取舍保持原貌，去掉内部代号 / 平台具体名称 / 具体度量数字，重点在"为什么这两层都不能省"这件事上。

传统交互的几个痛点

过去十年，移动端的交互模式基本固定为「点击 → 导航 → 操作」的固定路径：界面在开发阶段被预先设计、编码、测试、发布；用户只能在已经定义好的 UI 元素上做交互。这种模式有三个反复出现的痛点：

跨平台开发成本高：Android / iOS / 鸿蒙各自一套界面适配 —— 同一套交互需求，工程人力被乘以平台数量。
需求变更必须走完整发布周期：哪怕只调一个文案、动一个跳转，都得过应用商店审核。
交互逻辑无法响应实时意图：当下用户想要什么，UI 不知道；UI 是开发期写死的"静态产物"。

生成式交互（Generative Interaction）想要解决的问题

所谓生成式交互，核心理念是：用户不再需要适应系统预设的界面和流程，而是由 AI Agent 根据用户的实时意图、业务数据和上下文，动态生成最优的交互界面和操作流程。

用一句话概括，这是从"人适应机器"到"机器适应人"的范式跃迁。

但口号容易喊，工程难落地。一个真实可用的生成式 UI 系统不能只是"让大模型输出一段 HTML"，它要在真实 App 里跑稳，需要同时解决两个问题 —— 这两层缺一不可。

CHAPTER B

生成式 UI 落地的两个基础问题：协议层 + 渲染层

问题一：模型怎么"稳定地描述 UI"

这是协议层。一个能落地的生成式 UI 系统，对协议有几个硬要求：

语义化组件 —— 模型输出的不是像素，是有语义的组件（卡片、列表、表单），便于流式生成和差分更新。
结构化表达 —— UI 描述是结构化数据（JSON）而不是自由格式的标记语言，便于增量解析和验证。
UI 与数据分离 —— UI 描述里不直接嵌业务数据，而是引用 + 绑定，便于复用与缓存。
流式友好 —— 协议必须设计成"组件到达即可挂载、文本到达即可追加"，否则首屏体验会等待整页生成。

相比"直接让模型生成 HTML"或"生成复杂私有 DSL"，符合上述特征的协议有两个核心收益：降低 token 成本、减少生成结果的不确定性。模型不必每次重复生成完整视觉细节，只需输出语义化描述。

近期 Google 公开了一个面向 AI 原生场景的 UI 协议（A2UI），定义了模型描述 UI 的标准方式。本文复盘的这套实践就是基于该协议构建端侧渲染。

问题二：端侧怎么把描述变成原生界面

这是渲染层。光有协议不够 —— 协议是"约定"，但能跑出 60/120 fps 的体验是"工程"。在端侧落地有三个硬指标：

高性能：复杂页面滚动 / 长列表 / 流式追加 / 深层嵌套都要稳定流畅。
跨端一致性：iOS / Android / 鸿蒙不能各做一套，否则视觉、交互、维护成本都会失控。
融入宿主能力：原生动画、无障碍、手势、调试体系都要可用，不能成为"嵌在 App 里的孤岛"。

这两层之间的关系是：协议层决定"模型能不能稳定地生成 UI"，渲染层决定"端侧能不能稳定地把 UI 跑起来"。任何一层做偏，整个系统都不可用。

CHAPTER C

六个技术决策：从协议到渲染到接入

下面这六个决策，是这套实践里"从协议到渲染到工程接入"全链路的关键取舍 —— 也是任何要在自家 App 里落地生成式 UI 的团队大概率绕不开的问题。

① 走"开放协议"，不要再造私有 DSL

选择对齐开放标准（如 Google A2UI v0.9），而不是再造一份私有 DSL。这是一个长期收益更大的决策：

任何符合开放协议的模型输出，都可以被这套渲染框架消费。
任何遵循该协议的 Agent，都可以接入这套端侧能力。
团队的工程投入聚焦在"移动端原生渲染、跨端一致性、性能保障"这些工程能力上，而不是花在维护一套自家协议的解析器上。

② 纯 Native 渲染 + C++ 异步渲染核心

渲染路径选了"纯原生"而不是"内嵌 WebView"。生成式 UI 最终以系统原生组件的形式呈现 —— 这样可以自然融入宿主 App 的交互、动画、无障碍、手势和调试体系。

性能保障来自三层机制：

Streaming-first：组件到达即可挂载，文本到达即可追加，数据到达即可绑定。首屏体验不再等待完整页面生成完成，而是让生成过程本身成为用户可感知的界面呈现过程。
差分更新：在 C++ Core 中实现差分更新机制，对流式生成过程中的 UI 树变化做最小化更新。长页面、深层嵌套、持续追加场景下，端侧只更新变化节点，不整页重建。
异步渲染：协议解析、状态管理、布局计算、节点 Diff 等核心逻辑在独立线程完成，主线程只负责提交轻量级 UI 操作 —— 复杂 JSON、深层嵌套、高频增量更新对交互流畅度的影响被压到最低。

对各端原生能力做深度优化也是工程必须做的事。例如在鸿蒙系统上，基于 ArkUI 原生组件体系并通过 C API 打通高性能渲染链路，能进一步降低跨语言调用与组件操作开销。

③ 跨平台 C++ Core 统一承载核心逻辑

移动端生成式 UI 最大的工程挑战之一，是多端一致性。如果 iOS / Android / 鸿蒙各自实现一套协议解析、布局计算和状态管理逻辑，长期维护成本会失控，视觉和交互也容易偏。

这套实践用"架构解题"来回答：

           ┌──────────────────────────────────┐
           │       跨平台 C++ Core            │
           │  协议解析 / 状态管理 / 布局计算  │
           │     节点 Diff / 事件分发         │
           └──────┬─────────┬─────────┬───────┘
                  │         │         │
              Obj-C++       JNI      NAPI
                  │         │         │
              ┌───▼──┐  ┌───▼──┐  ┌──▼──┐
              │ iOS  │  │Andro.│  │鸿蒙 │
              │UIView│  │ View │  │ArkUI│
              └──────┘  └──────┘  └─────┘

核心逻辑统一在 C++ Core 里，三端通过 Objective-C++ / JNI / NAPI 接入同一套内核，最终渲染仍由各平台原生能力完成 —— 跨端一致性 + 原生体验，两个看起来矛盾的要求被同时满足。

④ 完善的 Styles + Theme 体系

生成式 UI 不只是"能画出来"，更要"画得好、画得稳、画得符合品牌"。在协议标准之上，需要建立完整的样式与主题体系，覆盖颜色、字体、圆角 / 间距 / 阴影、布局、日夜间模式、RTL 国际化等关键视觉要素。

具体做法是在云侧把"按协议生成卡片或页面"沉淀为可复用的 Agent Skill，配合 UI 与数据分离 + 主题系统 + 组件复用机制 —— 模型无需每次重复生成完整视觉细节，而是通过语义化描述 + 主题映射完成高质量 UI 生成。这一步直接降低 token 成本、提升生成稳定性，并让输出结果更接近设计规范。

这背后还有一个工程含义：UI 设计规范从"PSD / Figma 文档"变成了"运行时可消费的配置"。Theme 系统就是设计语言的代码化形态。

⑤ 三维扩展：组件 / FunctionCall / 主题都可定制

一个生成式 UI 框架只有内置组件远远不够 —— 业务总会有自己的原生能力要接进来。这套实践提供三个维度的扩展能力：

扩展维度	能力	解决的问题
UI 组件扩展	把自定义 Native View 注册为框架组件，注册后即可像内置组件一样被模型引用，参与流式渲染、数据绑定、事件回流和生命周期管理	让业务专属能力（地图、播放器、专有图表）平滑接入生成式 UI
FunctionCall 扩展	按钮动作、输入校验、字符串插值、事件回流等能力，通过统一路径注册和调用	避免"内置组件能用、业务组件用不了"的割裂
主题定制	支持 Design Token，模型只输出语义化描述，端侧基于 Theme 映射为颜色、字体、圆角、间距、阴影等具体视觉参数	同一份 Agent 输出在不同 App / 品牌 / 终端形态下保持结构稳定，呈现差异化视觉

这一层的设计哲学是"统一注册路径" —— 内置组件和业务自定义组件走同一套生命周期、同一套事件系统、同一套渲染管线。这避免了"内置 vs 自定义"的割裂，扩展才真的可用。

⑥ 极简接入：分钟级跑通第一个生成式 UI 页面

一个框架的"工程化成熟度"很大程度看接入门槛。这套实践把开发者接入效率作为核心设计目标之一，做了三件事：

端侧 SDK：统一 API，三端接入逻辑保持高度一致。开发者通过统一入口（SurfaceManager）创建渲染容器、加载协议 JSON、监听事件回流，几行代码跑通第一个页面。
云侧 Agent Skill：面向 Agent 工作流设计，把业务意图、上下文信息、结构化数据组织为符合协议的 UI 描述 —— 端到端从 Agent 生成到 Native 渲染的闭环链路。
Playground：在仓库里直接提供示例工程，能即时看到协议 JSON 的生成、解析、渲染效果，调试链路完整。

"分钟级上手"听起来像营销词，但工程上的差别非常具体：从拿到 SDK 到看见第一个生成式 UI 页面，超过 30 分钟的接入流程，多数开发者就放弃了。SDK 的质量在这个分钟数里。

CHAPTER D

这个方向对 Agent Harness 意味着什么

这套实践本身是"前端 / 移动端工程"，但放到 Agent Harness 的视角看，它在补一根支柱 —— 那就是「生成式 UI / 渲染层」。

把"输出形态"从文本扩到界面

主流 Agent 框架（包括我们博客之前几篇文章拆过的工业级 Harness）讨论的核心是：规划 / 工具 / 上下文 / 评估 / 反馈 —— 它们的共同前提是"Agent 的输出是文本或工具调用"。

而生成式 UI 在补的是另一件事：当 Agent 的输出形态从"文本 / 工具调用"扩展到"UI 描述"，端侧需要一整套对应的协议和渲染基础设施才能真正"跑出"用户能用的界面。这不是 prompt 工程能解决的问题，是工程问题。

生成式 UI 和"Agent 工具调用"是镜像关系

把这件事放到 Agent 架构里看其实有一个很有意思的对称性：

方向	形态	基础设施
从世界 → 模型	用户意图、业务数据、传感器输入	Tool Use / Function Call / MCP
从模型 → 世界	动作（写文件、调 API）和界面（生成式 UI）	Tool Use 协议 + UI 协议（A2UI 等）

"Tool Use" 给 Agent 打开了"动作侧"的世界 —— 它能改外部状态。"生成式 UI" 在打开"呈现侧"的世界 —— 它能动态产出和用户协作的界面。两者合起来，才是一个完整的"从模型到世界"的双向接口。

给前端 / 移动端工程师的启示

对前端 / 移动端工程师来说，这个方向最值得关注的工程含义是：

UI 工程的边界正在被重写。过去 UI 工程的核心是"实现设计稿"；未来一段时间，会增加一个新方向：实现"渲染协议"和"运行时主题系统"，让 Agent 的输出能被稳定渲染。
设计系统会代码化。Theme 系统 / Design Token 不再只是"设计师的术语"，而是要变成运行时可消费的配置 —— 这是设计语言被 Agent 消费的前提。
端侧性能仍然重要，且重要性更高。生成式 UI 流式追加、深层嵌套、高频增量更新这些场景，对差分更新和异步渲染的要求比传统页面更苛刻。把核心逻辑下沉到 C++ / 跨平台核心，而非各端各做一套，会变成一个普遍模式。

归根结底：当 Agent 越来越能"做事"，它就越来越需要"生成自己的工作界面"。生成式 UI 是 Agent Harness 的下一个工程边界。

← 返回最佳实践