推荐语

支付宝4人小团队如何用两个月打造智能出行管家？揭秘AI出行助手的高效研发实践。

核心内容：
1. 传统出行服务痛点与AI出行助手的创新解决方案
2. 基于xUI+KMP框架的终端技术架构迁移实战
3. 小团队快速迭代的研发经验与未来规划

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

本文将介绍支付宝「AI 出行助手」从产品立项到全量上线耗时两个月的研发历程。在仅有 4 人的客户端小团队下，我们是如何基于支付宝终端技术的基础框架：xUI + KMP，高效搭建出一款智能助理会话产品的。我们将分享背后的研发实践、面临的挑战与应对策略，并展望未来的发展方向。

AI 出行助手是一款基于对话交互的智能出行服务产品，集成公交/地铁刷码、火车票/机票预订、单车/打车、路线规划/旅行方案生成等核心功能，为用户提供全链路的出行服务。

你可以在支付宝 10.7.30 版本及以上版本中，通过“支付宝首页 → 出行频道 → 底部 AI 助手标识”进入 AI 出行助手，进行体验。

传统的出行服务体验面临严峻挑战，用户在规划行程时，不得不在多个独立的 App 间频繁跳转，执行繁琐、多步骤的操作来考量各种条件。这种低效的模式，已无法满足用户日益增长的个性化需求。

原出行助手基于支小宝构建，为了实现一个更垂直、更具扩展性的智能出行体系，需要构建一个全新的、专为出行场景设计的技术底座。

在这样的背景下，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 出行助手决定采用以下技术方案：

AI 出行助手主对话使用 xUI 作为交互框架，期望实现能力的快速接入与复用，达到降低业务维护成本、享受技术基线优化的效果。

xUI 框架前期支持了 AI 搜和 AQ 业务，借着 AI 出行助手的契机，xUI 将通过标准化建设，解决当下支小宝中 RPC + SYNC 耦合混用的问题，数据协议、渲染协议、控制协议统一走 gRPC 通道。

• 核心：标准化协议 + gRPC 流式网络 + 生成式卡片。

针对不同的业务场景，采用不同的技术栈来支撑，兼顾用户体验和研发效率。

• 对性能和体验要求较高的核心场景，如主会话框架、输入组件，采用 Native 来实现；
• 对于无需追求极致原生性能的页面，如智能体列表页面，积极探索跨平台技术，例如 KMP 技术，期望在提升研发人效的同时，帮助团队积累跨技术栈经验。

迁移工作不是从零开始，而是将一个逻辑复杂的支小宝出行业务，完整平迁到 xUI 标准化技术栈上来，涉及到多项底层基础能力的迁移，包括数据层适配、消息通道改造、渲染组件迁移等。

• 数据层适配：原支小宝的数据结构自成体系，将原数据结构迁移到标准协议上来，需要我们深刻理新旧两种协议的结构和语义，以及他们之间的区别，然后重新编写数据解析层，按照标准结构进行解析，比简单的字段映射要复杂得多；
• 消息通道改造：从 RPC + SYNC 切换到 gRPC 流式通信，意味着原有的消息链路彻底重构，从模型定义到通信协议，需要网关、后端、客户端进行全链路同步改造，不仅带来巨大的协同成本，更增加了联调的复杂度；
• 渲染组件迁移：AI 对话内容以流式形式呈现，我们面对的是一个由 Native 组件、卡片、Markdown 组件构成的碎片化渲染体系，将其统一到 xUI 的统一渲染组件下，需确保原业务场景的功能和展示，在新架构下能得到 100% 的还原和实现。

出行助手的核心功能由卡片承载，用户可在卡片上进行交互并直接完成功能。将这些卡片迁移过来，有以下几个挑战：

• 卡片体量大、广度深：40 多张卡片，覆盖飞机票、火车票、路径规划、单车打车、ETC 等多个垂直业务，庞大的数量本身就带来巨大的研发和联调工作量；
• 卡片逻辑挖掘与梳理：卡片并非静态展示，出行相关的卡片内部封装了大量隐性的业务逻辑，如动态内容更新、接口轮询，一个业务功能的完成也可能是由多张卡片协同工作构成的，客户端需要处理卡片的显示、更新和移除，例如，单车卡片的状态流转（扫码中 → 行程中 → 订单完成），这些逻辑并未显式文档化，我们需要进行考古挖掘，从代码和实际交互中梳理完整的业务逻辑；
• 复杂且频繁的双向通信：卡片功能并非孤岛，而是与客户端 Native 形成深度依赖。存在近 20 个卡片与 Native 通信的 JSAPI，卡片可以直接通过 JSAPI 进行发起查询、停止生成等操作；地铁码、公交码等卡片可通过 JSAPI 唤起 Native 组件；Native 可通过 Notification 下发生命周期事件给卡片，以上所有双向通信能力都需逐项平滑迁移，保证功能与时序一致。

AI 搜与 AQ 此前接入 xUI 时积累的经验，可以为我们提供借鉴，帮助提前规避许多基础问题。然而，也存在以下挑战：

• 标准协议的路径摸索：标准化协议下的诸多细节，如新协议下生成式卡片的全新渲染机制等，缺少现成的最佳实践可供参考，需要我们自行摸索和验证；
• 问题排查链路长、难度大：当出现功能问题，如流式输出空白、输出中断或渲染失败时，问题可能在业务、xUI 框架、卡片 SDK、前端、网关、业务后端中的任何一环，在初期缺乏成熟的诊断工具的情况下，定位问题链路长、难度大。

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 框架在内部统一处理；

出行助手卡片生态异常丰富，包括大大小小 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 旧链路获取的支小宝数据；
• 输出新协议：客户端实时地将旧数据转换成标准协议格式；

至此，客户端可提前进行卡片功能的调试，给后续的全链路联调争取了充足时间。

在 AI 出行助手的架构中，除了核心的主会话模块，还有一个重要的智能体模块，智能体模块包含智能体列表页和智能体详情页，在技术选型上，我们根据不同页面的特点，进行了一次战略性、差异化的技术实践，其中 KMP（Kotlin Multiplatform）的应用，是本次实践的亮点。

1. 智能体列表页

对于相对独立、与主会话关联性较小的智能体列表页，我们果断选择了使用 KMP 进行开发，旨在探索其在复杂场景下的应用潜力。

• 智能体列表在结构上并非一个独立的页面，而是与主会话页面同级。因此，我们采用了 MicroPage 的方案，将 KMP 视图作为一个独立的 UI 模块，嵌入到原生的容器中；
• 智能体列表页面的交互较为复杂，列表页内部既有横向滚动组件，也有纵向滚动组件，而其底部的容器本身又是一个原生的滚动组件。这种嵌套滚动，引发了侧滑返回等一系列棘手的跨平台手势冲突问题；

面对这些问题，我们积极推动 KMP 框架解决侧滑手势冲突问题、以及卡片与 KMP 模块的兼容问题，这一实践不仅为用户带来流畅的列表滚动体验，更是帮助框架在处理复杂嵌套滚动这类通用问题上，沉淀了解决方案。

2. 智能体详情页

与列表页不同，智能体详情页功能已经成熟和稳定，我们直接复用了原支小宝中的现有模块，避免重复建设。

进入 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 端人力，实现跨平台高效复用。

• 全面拥抱 xUI 新特性：AI 出行助手将积极探索并接入更多先进特性，如端到端语音播报（TTS）、端到端语音识别（ASR）等，为用户带来更优秀的交互体验；
• 深化 KMP 应用：本次 KMP 的实践只是一个开始，未来将继续扩大其应用范围：

• 旧场景体验打磨：持续优化现有智能体列表页的性能与交互，将其打造成 KMP 在复杂场景下的最佳实践；
• 新场景探索：尝试在更多业务模块（如会话页面）中应用 KMP，进一步提升研发效能，最大化“一次研发，多端共用”的价值。

• 更加完善的基建：当前 xUI 框架在某些方面尚有提升空间，例如问题定位链路长、难度大，Debug 工具不够完善等，未来希望相关基础建设能够继续完善，给业务研发带来更好的体验；
• 更好用的跨端框架：基于 AI 出行助手的深度实践，我们期望与框架团队携手，共同攻克 KMP 在 Compose 稳定性、与原生代码的混用及上手成本高等问题，让更多业务能享受到跨平台的优势；

想让您写的代码影响数亿人？支付宝 2026 届秋季校园招聘已开启！作为蚂蚁集团核心业务板块，我们深度支撑支付宝 App 用户关键链路，每日承载亿级用户高频交互，是数字生活生态的技术基石。在这里，你能获得超级 App 建设的核心机会，亲身推动数亿人使用的产品迭代；与行业前沿的客户端技术梯队共事，和顶尖专家并肩攻克技术难题；投身高频核心项目，在真实业务场景中快速积累经验、实现能力跃迁。加入我们，用技术重塑数字生活体验，让每一行代码都成为改变世界的力量