一、摘要
本文将介绍支付宝「AI 出行助手」从产品立项到全量上线耗时两个月的研发历程。在仅有 4 人的客户端小团队下，我们是如何基于支付宝终端技术的基础框架：xUI + KMP，高效搭建出一款智能助理会话产品的。我们将分享背后的研发实践、面临的挑战与应对策略，并展望未来的发展方向。
二、产品介绍
AI 出行助手是一款基于对话交互的智能出行服务产品，集成公交/地铁刷码、火车票/机票预订、单车/打车、路线规划/旅行方案生成等核心功能，为用户提供全链路的出行服务。
你可以在支付宝 10.7.30 版本及以上版本中，通过“支付宝首页 → 出行频道 → 底部 AI 助手标识”进入 AI 出行助手，进行体验。
三、项目背景
传统的出行服务体验面临严峻挑战，用户在规划行程时，不得不在多个独立的 App 间频繁跳转，执行繁琐、多步骤的操作来考量各种条件。这种低效的模式，已无法满足用户日益增长的个性化需求。
原出行助手基于支小宝构建，为了实现一个更垂直、更具扩展性的智能出行体系，需要构建一个全新的、专为出行场景设计的技术底座。
在这样的背景下，AI 出行助手应运而生，其核心能力是服务思维链 + 高质量数据 + 高质量工具 + 个性化：实现从入口到结果、从单工具到多工具、从提问到伴随，成为用户的“一站式智能出行管家”。
四、AI 对话产品探索与回顾
AI 对话作为一种新的交互范式，在技术和架构选型上缺乏成熟的最佳实践。幸运的是，在 AI 出行助手项目启动前，支付宝内已有多款 AI 助手类产品上线或在研，如 AI 搜、AQ 等，它们作为先行者，率先探索了 xUI 生成式卡片和 gRPC 流式通信，为我们验证了现代 AI 交互方案的可行性。
xUI 框架是支付宝终端技术孵化出的一套可复用的 AI 交互框架，它的核心定位是将 AI 对话式产品中共通的底层能力进行下沉，将其模块化、组件化，形成一套稳定、高效、可复用的 AI 交互框架。
因此，我们的目标是明确的：将 AI 出行助手接入到这套统一的基础架构里。同时，我们也注意到，框架自身也在进行着重要的技术演进：
早期的 AI 搜和 AQ 分别接入了不同版本的 xUI，彼此协议不统一，功能属性也存在差异； 为了解决这一问题，框架在积极推动技术的标准化，通过统一的标准化协议，旨在解决过去版本碎片化的问题；
经过讨论，我们最终决定：AI 出行助手将不再沿用旧的技术栈或非标的 xUI 版本，而是全面接入并落地 xUI 1.0 标准化协议。这意味着我们不仅要完成出行业务的迁移，还要用复杂的业务场景，率先验证新一代 xUI 版本。
支小宝的技术现状和业务复杂度，决定了迁移之路将充满挑战，以 AQ 进行对比，差异如下：
五、技术方案
综合上述回顾，基于支付宝终端技术已有的沉淀，AI 出行助手决定采用以下技术方案：
1. xUI：端到端智能交互框架
AI 出行助手主对话使用 xUI 作为交互框架，期望实现能力的快速接入与复用，达到降低业务维护成本、享受技术基线优化的效果。
xUI 框架前期支持了 AI 搜和 AQ 业务，借着 AI 出行助手的契机，xUI 将通过标准化建设，解决当下支小宝中 RPC + SYNC 耦合混用的问题，数据协议、渲染协议、控制协议统一走 gRPC 通道。
- 核心：标准化协议 + gRPC 流式网络 + 生成式卡片。
2. 多技术栈结合：KMP
针对不同的业务场景，采用不同的技术栈来支撑，兼顾用户体验和研发效率。
对性能和体验要求较高的核心场景，如主会话框架、输入组件，采用 Native 来实现； 对于无需追求极致原生性能的页面，如智能体列表页面，积极探索跨平台技术，例如 KMP 技术，期望在提升研发人效的同时，帮助团队积累跨技术栈经验。
六、难点与挑战
1. 基础能力迁移
迁移工作不是从零开始，而是将一个逻辑复杂的支小宝出行业务，完整平迁到 xUI 标准化技术栈上来，涉及到多项底层基础能力的迁移，包括数据层适配、消息通道改造、渲染组件迁移等。
数据层适配：原支小宝的数据结构自成体系，将原数据结构迁移到标准协议上来，需要我们深刻理新旧两种协议的结构和语义，以及他们之间的区别，然后重新编写数据解析层，按照标准结构进行解析，比简单的字段映射要复杂得多； 消息通道改造：从 RPC + SYNC 切换到 gRPC 流式通信，意味着原有的消息链路彻底重构，从模型定义到通信协议，需要网关、后端、客户端进行全链路同步改造，不仅带来巨大的协同成本，更增加了联调的复杂度； 渲染组件迁移：AI 对话内容以流式形式呈现，我们面对的是一个由 Native 组件、卡片、Markdown 组件构成的碎片化渲染体系，将其统一到 xUI 的统一渲染组件下，需确保原业务场景的功能和展示，在新架构下能得到 100% 的还原和实现。
2. 卡片生态迁移
出行助手的核心功能由卡片承载，用户可在卡片上进行交互并直接完成功能。将这些卡片迁移过来，有以下几个挑战：
卡片体量大、广度深：40 多张卡片，覆盖飞机票、火车票、路径规划、单车打车、ETC 等多个垂直业务，庞大的数量本身就带来巨大的研发和联调工作量； 卡片逻辑挖掘与梳理：卡片并非静态展示，出行相关的卡片内部封装了大量隐性的业务逻辑，如动态内容更新、接口轮询，一个业务功能的完成也可能是由多张卡片协同工作构成的，客户端需要处理卡片的显示、更新和移除，例如，单车卡片的状态流转（扫码中 → 行程中 → 订单完成），这些逻辑并未显式文档化，我们需要进行考古挖掘，从代码和实际交互中梳理完整的业务逻辑； 复杂且频繁的双向通信：卡片功能并非孤岛，而是与客户端 Native 形成深度依赖。存在近 20 个卡片与 Native 通信的 JSAPI，卡片可以直接通过 JSAPI 进行发起查询、停止生成等操作；地铁码、公交码等卡片可通过 JSAPI 唤起 Native 组件；Native 可通过 Notification 下发生命周期事件给卡片，以上所有双向通信能力都需逐项平滑迁移，保证功能与时序一致。
3. 标准框架磨合
AI 搜与 AQ 此前接入 xUI 时积累的经验，可以为我们提供借鉴，帮助提前规避许多基础问题。然而，也存在以下挑战：
标准协议的路径摸索：标准化协议下的诸多细节，如新协议下生成式卡片的全新渲染机制等，缺少现成的最佳实践可供参考，需要我们自行摸索和验证； 问题排查链路长、难度大：当出现功能问题，如流式输出空白、输出中断或渲染失败时，问题可能在业务、xUI 框架、卡片 SDK、前端、网关、业务后端中的任何一环，在初期缺乏成熟的诊断工具的情况下，定位问题链路长、难度大。
七、重构实践
1. 整体架构
2. xUI 实践
1. 数据协议适配，百花齐放 → 大一统
各个 AI 对话产品协议定义混乱，理解和对接成本较高，AI 出行助手使用 xUI 1.0 标准化协议，其定义的一套标准的 AI 对话模型输入输出协议，统一了卡片渲染协议、数据协议和控制协议。
支小宝原业务卡片的数据结构，需要转换为全新的标准化结构，对服务端来说是不少的工作量，客户端需重新进行数据的解析，前端也可能针对新协议重新解析和渲染。
迁移原则
复用存量卡片，尽可能不修改存量业务卡片的逻辑。
迁移路径
保持卡片已有的渲染数据不变，调整外层结构以遵循标准协议，实现存量业务卡片无缝迁移到新协议。
核心渲染数据不变：在支小宝卡片数据中，真正渲染数据相关的是 templateData部分，每张卡片的渲染数据都不同，为了平迁卡片功能，减少前端工作量，我们需保证templateData部分不变；适配标准协议：后端需根据标准协议将旧的小宝数据进行转换，除 templateData复用外，templateId、templateInfo等涉及卡片的部分也保持不变，然后依次将chatId、itemId、hasNext等关键字段装载到新协议的结构体中。
通过这种方式，我们以较小的成本，实现了最大的数据兼容。
2. 底层消息通道升级，RPC/SYNC → gRPC
在支小宝，一次完整的对话交互，依赖于一套分离的通信模型，用户 Query 通过普通 RPC 发送，而 AI 生成的流式数据则依赖独立的 SYNC 通道。这种 RPC + SYNC 的混用方案，会导致：
链路复杂性高：研发需同时关注两个通道的请求构造、状态同步和异常处理； 体验瓶颈：SYNC 存在消息时效性差、高峰期数据积压等问题；
AI 出行助手基于 xUI 的消息通道将通信能力重构，统一使用基于 HTTP/2 的 gRPC 流式通信，gRPC 的优势如下：
单一连接，双向流式：gRPC 天然支持单连接上的多路复用和双向流式通信，符合 AI 对话场景中“一次请求，多次返回”的交互模式； 统一协议，简化链路：解决了 RPC+SYNC 的混用问题，将复杂的通信逻辑统一收敛；
业务实践：从“关心实现”到“聚焦业务”
xUI 框架对底层 gRPC 的通信能力进行了封装，业务研发的关注点从底层通信细节上升至业务会话层面。
基于 gRPC 协议封装的双向流式 RTS 通信能力，在支付宝 app 端内的五福双人联机打年兽、蚂蚁登山赛、股票行情等业务场景有广泛应用。以 “股票 L2 行情” 为例，相比 SYNC，性能提升 65%，收益明显。
3. 渲染组件迁移，碎片化实现 → 生成式卡片
在 AI 出行助手中，我们面临着一个历史遗留问题：从支小宝继承而来的渲染体系，是由 Native、卡片和Native Markdown 组件组成的碎片化架构，维护成本较高：
原生 Native组件：负责渲染简单纯文本； 卡片：业务卡片，承载机票、火车票查询等核心业务功能； Native Markdown 组件：用于解析和渲染富文本内容；
因此，有必要构建一套统一的会话内容渲染组件，幸运的是，xUI 框架已经拥有一套面向生成式 UI 的端到端解决方案。
生成式 UI
目前对于生成式内容的普遍解法是 Markdown + 扩展：即通过在 Markdown 中约定特殊标记，转成一个图表或者通过多个卡片来拼接，这种方案虽灵活，却也导致各业务自定义标记泛滥，缺乏统一标准。
xUI Runtime 通过定义一套标准化的模型输出扩展协议（包括标记定义、渲染行为），让不确定的 AI 输出，能够被确定性地渲染成丰富的 UI。
在这套架构下，对于业务研发来说，“不区分内容形式，万物皆为卡片” ，统一使用卡片作为渲染组件。
3.1. 渲染行为解耦，template & display
在标准化协议下，渲染行为解耦成了两个独立的概念：
template：代表“一个新的卡片需要被创建”，当业务层收到时，无脑地创建一个空的卡片容器； display：代表“具体的渲染内容，需要填到卡片里”，这个行为由框架内部处理，业务层完全不感知；
这种设计的好处是，业务层的职责被极大简化。我们只需要关心“挖坑”（创建模板），而不需要关心“填坑”（填充内容）的复杂过程。
3.2. 内容类型抽象， COMMON & FLOW
为了支撑不同的业务场景，卡片类型抽象为两种：
COMMON：普通卡片， 对应内容一次性下发的静态场景； FLOW：流式卡片，对应内容像水流一样，被拆分成多个小片段，逐一下发的动态场景；
这种类型区分，对业务研发是透明的， 业务在收到template时，并不需要关心这张即将创建的卡片到底是COMMON还是FLOW，我们只需要统一地创建卡片容器并填充渲染数据，框架会根据卡片类型，在内部自动选择不同的“填坑”策略。
3.3. 业务场景统—，三大卡片类型的实现
根据卡片类型的不同，出行助手中的卡片可分为静态卡片、生成式卡片和动态更新的静态卡片，基于上述能力，出行助手实现了所有场景下的卡片渲染：
静态卡片: template(COMMON)
和常规的业务卡片渲染几乎无异，一次性完成；
生成式卡片： template(FLOW)+ 一系列display(流式小组件)
业务只负责渲染一个空壳模板卡片，后续的数据接收、拼接成打字机效果、更新卡片内容等一系列操作，全部由 xUI 内部完成。业务无需关心流式内容是纯文本、图文混排还是 Markdown，真正做到了无感更新；
动态更新的静态卡片: 本质上是 template(COMMON)，但 xUI 框架在内部封装了SYNC轮询能力；
对于需要轮询状态的卡片（如共享单车和打车），业务无需再建立 SYNC 通道，只需像渲染静态卡片一样创建它，而其内容的动态更新，则由 xUI 框架在内部统一处理；
3. 卡片生态迁移
出行助手卡片生态异常丰富，包括大大小小 40 多张卡片，每张卡都承担着特定的功能，以火车票机票为例，就包括登录卡片、确认订单卡片、支付卡片、订单卡片、选择地址、选择日期、返程卡片、待出发行程卡片等 8 张卡片。
1. 代码考古与分析
卡片梳理与范围界定：首先对卡片进行全面的梳理，明确属于出行范围的卡片，按照业务场景进行归类，确定改造优先级。
代码考古与运行时分析：深入原支小宝和卡片的代码，并结合运行时动态调试，了解每一张复杂卡片内部的业务逻辑和状态流转，通过时序图的形式将逻辑可视化，方便对每个交互点，逐一进行迁移。
一张卡片就能完成业务流程吗？若不是，涉及到几张卡片，卡片之间的状态是如何流转的； 卡片内容是否会更新？如何更新？直接和后端交互还是依赖 JSAPI； 依赖哪些原生能力？
如下图，分别是单车和打车的时序图，可以看到，涉及多张卡片的轮换，数据获取链路非常长，卡片和卡片之间、卡片和原生之间，存在频繁的双向通信，构成了一个非常复杂的交互状态机。
2. 数据交互通道构建
双向通信链路梳理：通过静态搜索、运行时调试等方式，对卡片与 Native 双向的通信接口进行梳理；
JSAPI ：卡片主动调用 Native 的接口，如发起查询、停止生成等； 通知：由 Native 主动通知卡片事件，如页面进入，页面退出等；
卡片通信能力搭建：基于上述梳理，优先完成 Native 和卡片通信能力的搭建；
3. JSAPI 功能兼容
支小宝和出行相关的 JSAPI 近 20 个，这些 JSAPI 中封装了大量业务定制的规则，使功能平移变得困难，我们的大量时间，都投入在对这些历史参数的“解码”与适配上。
历史参数适配
最典型的例子是核心的 Query 功能。
在支小宝原有的 RPC 请求链路中，业务方为了实现特定的功能，在标准的请求体之外，自定义了大量的扩展参数，这些参数承载着重要的业务逻辑； 在切换到新的 gRPC 链路后，出行助手不能简单地丢弃这些“历史包袱”，而是要在新链路的协议体中找到合适的位置，将这些扩展参重新封装并传递给服务端。这需要我们理解每个扩展参数的真实意图，确保在新的协议下，服务端依然能正确解析这些参数；
定制化交互逻辑兼容
许多 JSAPI 参数，并不仅仅是传递数据，更是用来精细化控制 UI 行为的，比如：
静默发送：如打车的目的地选择卡片、订单预估卡片，需要用户点击卡片操作后，静默发送 Query ，即在输入框不显示发送的文本； 阅后即焚：比如火车票的日期选择卡片、单车的扫码卡片，要求用户点击卡片上的操作后，关闭卡片自身；
面对这些高度定制化的交互逻辑，我们需要对每一张卡片进行调试，确保历史逻辑在新架构下依然能够工作，从而实现对用户体验的无损迁移。
4. 解耦依赖，迁移提效
在整个迁移工程中，面临的最大瓶颈是跨团队的研发依赖：客户端的研发进度严重依赖后端的协议改造进度，为了打破这种依赖，实现真正的并行研发，我们采用以下两个策略来加速：
平移旧有通信链路
首先将支小宝原有的 RPC+SYNC 整套通信链路，完整地平移到了新的 AI 出行助手工程中。在全新的 gRPC 链路就绪前，就拥有了一条稳定可用的“旧轨道”来获取数据。
构建客户端协议适配器
在构建老链路通信通道后，还需要一个客户端协议适配器，这个适配器在研发阶段临时承担本该由后端负责的协议转换工作：
消费旧数据：直接消费通过 RPC+SYNC 旧链路获取的支小宝数据； 输出新协议：客户端实时地将旧数据转换成标准协议格式；
至此，客户端可提前进行卡片功能的调试，给后续的全链路联调争取了充足时间。
4. KMP 实践
在 AI 出行助手的架构中，除了核心的主会话模块，还有一个重要的智能体模块，智能体模块包含智能体列表页和智能体详情页，在技术选型上，我们根据不同页面的特点，进行了一次战略性、差异化的技术实践，其中 KMP（Kotlin Multiplatform）的应用，是本次实践的亮点。
1. 智能体列表页
对于相对独立、与主会话关联性较小的智能体列表页，我们果断选择了使用 KMP 进行开发，旨在探索其在复杂场景下的应用潜力。
智能体列表在结构上并非一个独立的页面，而是与主会话页面同级。因此，我们采用了 MicroPage 的方案，将 KMP 视图作为一个独立的 UI 模块，嵌入到原生的容器中； 智能体列表页面的交互较为复杂，列表页内部既有横向滚动组件，也有纵向滚动组件，而其底部的容器本身又是一个原生的滚动组件。这种嵌套滚动，引发了侧滑返回等一系列棘手的跨平台手势冲突问题；
面对这些问题，我们积极推动 KMP 框架解决侧滑手势冲突问题、以及卡片与 KMP 模块的兼容问题，这一实践不仅为用户带来流畅的列表滚动体验，更是帮助框架在处理复杂嵌套滚动这类通用问题上，沉淀了解决方案。
2. 智能体详情页
与列表页不同，智能体详情页功能已经成熟和稳定，我们直接复用了原支小宝中的现有模块，避免重复建设。
5. 数据建设
进入 AI 对话领域，如何科学度量一个 AI 对话产品的核心体验？ 过去的性能指标，比如页面打开耗时，在生成式的 AI 交互场景下已不适用，比如会话页面秒开，但用户发送问题后需要等待 5 秒才看到第一个字。因此，需要建立一套全新的、能够真实反映 AI 对话流式交互质量的度量体系。
核心思路是：从用户的实际感知出发，将一次 AI 对话的过程，拆解为一系列可度量、可归因的关键节点。 基于此，我们设计并搭建了一套包含「可感知耗时」和「链路稳定性」两大维度的度量体系。
1. 可感知耗时
我们定义了 AI 对话中最核心的用户体验指标 —— 首 Token 耗时，即从用户发送 Query 到屏幕上出现第一个 AI 生成内容的时间。这个指标直接决定了用户感受到的“快”与“慢”。总耗时可以进一步精细化地拆解为三个核心阶段，用于指导后续优化：
xUI 数据回调耗时：从用户发送 Query 开始，到接收到 xUI 数据回调的耗时，包括了请求建连，数据发送，中间经过网络传输、到达网关、业务后端处理，返回到 xUI 耗时； 端数据处理耗时：客户端收到框架的数据回调后，完成解析、转换，到即将开始创建模板卡片的耗时； 模板卡片创建耗时：创建模板卡片实例的耗时； 模板卡片渲染耗时：卡片实例创建后，将其真正绘制到屏幕上的耗时；
2. 链路稳定性
除了用户感知的速度，会话链路的稳定性是 AI 对话体验的生命线。框架自身虽然有其内部监控，但更多是站在框架层的视角，而作为业务方，更关心的是用户体验是否受损。我们与框架深度对齐后，搭建了一套从业务视角出发，能够反映发送链路稳定性的监控指标体系。
业务视角的成功与失败
成功：只有当客户端收到以下状态回调时，才算一次业务意义上的成功
生成结束
生成终止
重写
异常：下面这些状态被定义为业务异常
错误 超时
基于这个共识，我们搭建了业务方视角的稳定性大盘：
发送成功率/异常率：监控会话链路的整体健康状况； 错误码/错误信息分布：对出现的异常进行聚类分析，可以快速定位是服务端异常、网络问题或其他原因，极大提升排查效率。
八、阶段性结果
我们以较短的研发周期、较少的人力投入，实现了 AI 出行助手的快速上线。目前取得以下阶段性成果：
业务指标
核心履约场景，履约 Tips 点击率明显超过履约卡片点击率，并稳步增长中；
研发效能提升
AI 对话新产品研发周期：数月 → 30天，刷新 AI 对话类业务的交付记录，证明在 xUI + gRPC + KMP 等底层技术基建的支撑下，可以实现较高的研发效率；
- KMP 方案释放 1 端人力，实现跨平台高效复用。
九、未来展望
1. 持续探索，打磨极致体验
全面拥抱 xUI 新特性：AI 出行助手将积极探索并接入更多先进特性，如端到端语音播报（TTS）、端到端语音识别（ASR）等，为用户带来更优秀的交互体验； 深化 KMP 应用：本次 KMP 的实践只是一个开始，未来将继续扩大其应用范围：
旧场景体验打磨：持续优化现有智能体列表页的性能与交互，将其打造成 KMP 在复杂场景下的最佳实践； 新场景探索：尝试在更多业务模块（如会话页面）中应用 KMP，进一步提升研发效能，最大化“一次研发，多端共用”的价值。
2. 业务驱动框架完善
更加完善的基建：当前 xUI 框架在某些方面尚有提升空间，例如问题定位链路长、难度大，Debug 工具不够完善等，未来希望相关基础建设能够继续完善，给业务研发带来更好的体验； 更好用的跨端框架：基于 AI 出行助手的深度实践，我们期望与框架团队携手，共同攻克 KMP 在 Compose 稳定性、与原生代码的混用及上手成本高等问题，让更多业务能享受到跨平台的优势；
十、团队介绍
想让您写的代码影响数亿人？支付宝 2026 届秋季校园招聘已开启！作为蚂蚁集团核心业务板块，我们深度支撑支付宝 App 用户关键链路，每日承载亿级用户高频交互，是数字生活生态的技术基石。在这里，你能获得超级 App 建设的核心机会，亲身推动数亿人使用的产品迭代；与行业前沿的客户端技术梯队共事，和顶尖专家并肩攻克技术难题；投身高频核心项目，在真实业务场景中快速积累经验、实现能力跃迁。加入我们，用技术重塑数字生活体验，让每一行代码都成为改变世界的力量
