高德这次没只在自家 App 里玩 AI，而是把底层那套东西掏出来给所有人用了。
5 月 13 日，高德联合阿里千问 C 端应用团队开源了 AGenUI，定位是行业首个覆盖 iOS、Android、HarmonyOS 三端的端云一体原生 A2UI 框架。一句话翻译：以后做 AI Agent 的客户端 UI，不用再 iOS 写一遍 Swift、安卓写一遍 Kotlin、鸿蒙再补一遍 ArkTS，写一次，三端原生跑。
这个时间点放出来挺微妙。去年到今年，Agent 这条线在国内基本已经从 "概念验证" 跨到 "要真上线给用户用" 的阶段，但凡做过的人都知道，模型那一头反而是相对舒服的部分——真正难受的是前端。Agent 输出是动态的、结构是不固定的、还要支持流式渲染、还要能调用本地能力，每多一个平台就要再受一次罪。AGenUI 想解决的，就是这一段的工程债。
A2UI 是什么，为什么需要一个新框架
先把名词捋清楚。A2UI 全称 Agent-to-UI，指的是 Agent 把意图、数据、交互逻辑下发到客户端，由客户端动态生成原生界面的一整套协议加渲染机制。它和我们熟悉的 React Native、Flutter 这类跨端方案根本不在一个层面——后者是"开发者写好的 UI 跨端运行"，前者是"模型动态决定 UI 长什么样、客户端实时渲染"。
为什么需要这么一层？因为传统 App 的 UI 是预先写死的，按钮在哪、卡片长什么样、表单几个字段，发版才能改。但 Agent 的输出本质上是不可预测的：用户问"帮我规划一个三天两夜的杭州行程"，返回的可能是路线卡片+酒店列表+天气+预算汇总；问"附近哪家川菜评分高"，返回的就是地图+店铺榜单+优惠券。如果每种返回形态都靠产品经理排期、客户端写死页面，AI 那点灵活性立马就被前端框死了。
业内此前的做法大致两条路。一条是用 WebView+H5 渲染，灵活但性能拉胯，动效一上来就卡，跟原生 App 的体感差好几个档次；另一条是 DSL 加自研渲染引擎，性能能保住，但每个平台得各做一套，鸿蒙出来后这事更麻烦——多一个端就多一份维护成本。
AGenUI 选的是第三条路：统一的 A2UI 协议描述 + 三端原生渲染器。云端 Agent 输出一份标准化的 UI 描述，三端 SDK 各自把它翻译成 SwiftUI、Jetpack Compose、ArkUI 的原生组件。理论上保留了原生性能，又把跨端成本压到了一份描述。
高德为什么是这个框架的合适出品方
这事其实得往回倒一点。去年 8 月高德发了"高德地图 2025"，把整个 App 改造成了 AI 原生应用，背后是和千问联合搭的主-从 Agent 架构：主 Agent 小高老师负责拆解用户意图，下发给导航、生活、跨场景等若干从 Agent，从 Agent 再去匹配工具层执行。
这套东西要在 10 亿用户的体量上跑起来，UI 这一层就不可能用 WebView 凑合。高德的工程师等于是被业务推着先把 A2UI 这条路在自家踩通了——iOS、安卓、鸿蒙三端 + 数十种 Agent 输出形态 + 复杂的地图叠加图层，跑通之后再抽象出来开源，这个顺序比纯实验室出框架要扎实得多。
这也是 AGenUI 跟那些 PPT 框架的区别：它先在一个超级 App 里日活验证过，然后再开源。
三端原生是怎么做到的
看公开材料，AGenUI 的架构大致拆成几块：
- 协议层：定义 A2UI 描述格式，包括组件、布局、事件、数据绑定
- 三端 SDK：iOS、Android、HarmonyOS 各自一份，把协议翻译成原生 UI 树
- 端云通道：支持流式下发，Agent 一边推理一边出 UI，不用等全部生成完再渲染
- 能力扩展：允许业务方注册自定义组件，比如高德自己的地图卡片、路线卡片
流式这个细节很关键。现在用户被 ChatGPT 那种一字一字蹦的体验养出习惯了，Agent UI 如果还是"转圈圈三秒，啪一下整页出来"，会显得很笨。AGenUI 把流式做到了 UI 这一层，组件可以按段落、按卡片、按区块逐步出现，跟模型推理的节奏对上。
鸿蒙这一端值得单说。今年鸿蒙 NEXT 的渗透速度比预期快，大厂 App 不上鸿蒙原生版基本不行，但鸿蒙的 ArkUI 跟 iOS、安卓的差异不小，很多团队卡在这里要么直接放弃要么用兼容层凑合。AGenUI 把鸿蒙作为一等公民支持，相当于帮中小团队把这块硬骨头啃了。
对开发者意味着什么
务实地说，AGenUI 不是给所有人的。它的目标用户很明确：正在做 AI Agent 类产品、且需要三端原生体验的团队。如果你只做 Web，或者只做单端，这个框架的吸引力一般。
但凡是做 AI 助手类 App、AI 搜索 App、AI 工具 App、特别是想从 H5 套壳升级到原生体验的团队，这个框架可以省掉的工作量是肉眼可见的。粗算一下，三端各做一套 Agent UI 渲染系统，假设每端两个工程师三个月，那就是 18 人月起步，还不算后续维护和新组件适配。
几个值得关注的问题：
- 协议的开放度：A2UI 协议如果只服务高德自家场景，那对外部开发者价值有限；如果做成真正通用的 Agent UI 描述标准，潜力才打开。这一点要等社区反馈
- 自定义组件成本：业务总有自己特殊的 UI 形态，注册自定义组件是不是顺滑，决定了框架能不能从"能用"走到"好用"
- 和模型侧的配合：Agent 这一端怎么稳定输出符合协议的 UI 描述，需要 prompt 工程或者 function calling 层面的配套，框架会不会一起给方案
国内 Agent 工程化进入实操期
把视角拉远一点看，AGenUI 是国内今年这一波 Agent 落地的一个典型信号：大家不再讨论"Agent 能不能做"，而是在卷"Agent 怎么做得又快又好"。
之前能看到的开源 Agent 项目，大多集中在编排层(LangChain、AutoGen 那一类)和执行层(各种 tool use、code interpreter)，UI 这一层一直是缺失的。原因也好理解——做 UI 框架太苦，要碰平台、要碰渲染、要碰兼容性，研究机构和模型厂商都不太愿意干。高德这种从 C 端业务里逼出来的方案，正好补上了这一段。
A2UI 这个方向接下来大概率会更热闹。Google 那边的 Project Mariner、Anthropic 的 Computer Use 都在做"Agent 操作 UI"的反方向，而 A2UI 是"Agent 生成 UI"的正方向，两条路都通向同一个终点：UI 不再是产品经理排期的产物，而是模型实时决策的输出。
对开发者来说，现在比较实际的动作就是把 AGenUI 拉下来跑一遍 demo，看看协议设计、看看渲染体感、看看跟自家 Agent 链路怎么对接。开源项目的好处就是不用看 PPT 猜，代码摆在那儿，能不能用一晚上就有答案。
顺带一提，做 Agent 应用如果还在为模型接入头疼，OpenAI Hub 这类聚合平台可以省掉一些事——一个 Key 调 GPT、Claude、Gemini、DeepSeek、千问这些主流模型，OpenAI 兼容格式，国内直连，前端框架解决了，后端模型这头也别再卡时间。
参考来源
- 高德如何造出全球首个地图 AI - 知乎专栏：高德 AI 化转型的背景资料，理解 AGenUI 出处的上下文