一、摘要
本文将介绍支付宝「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 出行助手将不再沿用旧的技术栈或非标的 xUI 版本，而是全面接入并落地 xUI 1.0 标准化协议。这意味着我们不仅要完成出行业务的迁移，还要用复杂的业务场景，率先验证新一代 xUI 版本。
支小宝的技术现状和业务复杂度，决定了迁移之路将充满挑战，以 AQ 进行对比，差异如下：
五、技术方案
综合上述回顾，基于支付宝终端技术已有的沉淀，AI 出行助手决定采用以下技术方案：
1. xUI：端到端智能交互框架
AI 出行助手主对话使用 xUI 作为交互框架，期望实现能力的快速接入与复用，达到降低业务维护成本、享受技术基线优化的效果。
xUI 框架前期支持了 AI 搜和 AQ 业务，借着 AI 出行助手的契机，xUI 将通过标准化建设，解决当下支小宝中 RPC + SYNC 耦合混用的问题，数据协议、渲染协议、控制协议统一走 gRPC 通道。
2. 多技术栈结合：KMP
针对不同的业务场景，采用不同的技术栈来支撑，兼顾用户体验和研发效率。
六、难点与挑战
1. 基础能力迁移
迁移工作不是从零开始，而是将一个逻辑复杂的支小宝出行业务，完整平迁到 xUI 标准化技术栈上来，涉及到多项底层基础能力的迁移，包括数据层适配、消息通道改造、渲染组件迁移等。
2. 卡片生态迁移
出行助手的核心功能由卡片承载，用户可在卡片上进行交互并直接完成功能。将这些卡片迁移过来，有以下几个挑战：
3. 标准框架磨合
AI 搜与 AQ 此前接入 xUI 时积累的经验，可以为我们提供借鉴，帮助提前规避许多基础问题。然而，也存在以下挑战：
七、重构实践
1. 整体架构
2. xUI 实践
各个 AI 对话产品协议定义混乱，理解和对接成本较高，AI 出行助手使用 xUI 1.0 标准化协议，其定义的一套标准的 AI 对话模型输入输出协议，统一了卡片渲染协议、数据协议和控制协议。
支小宝原业务卡片的数据结构，需要转换为全新的标准化结构，对服务端来说是不少的工作量，客户端需重新进行数据的解析，前端也可能针对新协议重新解析和渲染。
迁移原则
复用存量卡片，尽可能不修改存量业务卡片的逻辑。
迁移路径
保持卡片已有的渲染数据不变，调整外层结构以遵循标准协议，实现存量业务卡片无缝迁移到新协议。
templateData部分，每张卡片的渲染数据都不同，为了平迁卡片功能，减少前端工作量，我们需保证templateData复用外，通过这种方式，我们以较小的成本，实现了最大的数据兼容。
在支小宝，一次完整的对话交互，依赖于一套分离的通信模型，用户 Query 通过普通 RPC发送，而 AI 生成的流式数据则依赖独立的SYNC 通道。这种 RPC + SYNC 的混用方案，会导致：
AI 出行助手基于 xUI 的消息通道将通信能力重构，统一使用基于 HTTP/2 的gRPC 流式通信，gRPC 的优势如下：
业务实践：从“关心实现”到“聚焦业务”
xUI 框架对底层 gRPC 的通信能力进行了封装，业务研发的关注点从底层通信细节上升至业务会话层面。
基于 gRPC 协议封装的双向流式 RTS 通信能力，在支付宝 app 端内的五福双人联机打年兽、蚂蚁登山赛、股票行情等业务场景有广泛应用。以 “股票 L2 行情” 为例，相比 SYNC，性能提升 65%，收益明显。
在 AI 出行助手中，我们面临着一个历史遗留问题：从支小宝继承而来的渲染体系，是由 Native、卡片和Native Markdown 组件组成的碎片化架构，维护成本较高：
因此，有必要构建一套统一的会话内容渲染组件，幸运的是，xUI 框架已经拥有一套面向生成式 UI 的端到端解决方案。
生成式 UI
目前对于生成式内容的普遍解法是Markdown + 扩展：即通过在 Markdown 中约定特殊标记，转成一个图表或者通过多个卡片来拼接，这种方案虽灵活，却也导致各业务自定义标记泛滥，缺乏统一标准。
xUI Runtime通过定义一套标准化的模型输出扩展协议（包括标记定义、渲染行为），让不确定的 AI 输出，能够被确定性地渲染成丰富的 UI。
在这套架构下，对于业务研发来说，“不区分内容形式，万物皆为卡片”，统一使用卡片作为渲染组件。
在标准化协议下，渲染行为解耦成了两个独立的概念：
这种设计的好处是，业务层的职责被极大简化。我们只需要关心“挖坑”（创建模板），而不需要关心“填坑”（填充内容）的复杂过程。
为了支撑不同的业务场景，卡片类型抽象为两种：
这种类型区分，对业务研发是透明的，业务在收到template时，并不需要关心这张即将创建的卡片到底是ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.034em;font-style: normal;font-weight: normal;">COMMON还是ingFang SC", system-ui, -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.034em;font-style: normal;font-weight: normal;">FLOW，我们只需要统一地创建卡片容器并填充渲染数据，框架会根据卡片类型，在内部自动选择不同的“填坑”策略。
根据卡片类型的不同，出行助手中的卡片可分为静态卡片、生成式卡片和动态更新的静态卡片，基于上述能力，出行助手实现了所有场景下的卡片渲染：
template(COMMON)template(FLOW)+ 一系列template(COMMON)，但 xUI 框架在内部封装了SYNC轮询能力；3. 卡片生态迁移
出行助手卡片生态异常丰富，包括大大小小40 多张卡片，每张卡都承担着特定的功能，以火车票机票为例，就包括登录卡片、确认订单卡片、支付卡片、订单卡片、选择地址、选择日期、返程卡片、待出发行程卡片等 8 张卡片。
卡片梳理与范围界定：首先对卡片进行全面的梳理，明确属于出行范围的卡片，按照业务场景进行归类，确定改造优先级。
代码考古与运行时分析：深入原支小宝和卡片的代码，并结合运行时动态调试，了解每一张复杂卡片内部的业务逻辑和状态流转，通过时序图的形式将逻辑可视化，方便对每个交互点，逐一进行迁移。
如下图，分别是单车和打车的时序图，可以看到，涉及多张卡片的轮换，数据获取链路非常长，卡片和卡片之间、卡片和原生之间，存在频繁的双向通信，构成了一个非常复杂的交互状态机。
支小宝和出行相关的 JSAPI近 20 个，这些 JSAPI 中封装了大量业务定制的规则，使功能平移变得困难，我们的大量时间，都投入在对这些历史参数的“解码”与适配上。
历史参数适配
最典型的例子是核心的 Query 功能。
定制化交互逻辑兼容
许多 JSAPI 参数，并不仅仅是传递数据，更是用来精细化控制 UI 行为的，比如：
面对这些高度定制化的交互逻辑，我们需要对每一张卡片进行调试，确保历史逻辑在新架构下依然能够工作，从而实现对用户体验的无损迁移。
在整个迁移工程中，面临的最大瓶颈是跨团队的研发依赖：客户端的研发进度严重依赖后端的协议改造进度，为了打破这种依赖，实现真正的并行研发，我们采用以下两个策略来加速：
平移旧有通信链路
构建客户端协议适配器
在构建老链路通信通道后，还需要一个客户端协议适配器，这个适配器在研发阶段临时承担本该由后端负责的协议转换工作：
至此，客户端可提前进行卡片功能的调试，给后续的全链路联调争取了充足时间。
4. KMP 实践
在 AI 出行助手的架构中，除了核心的主会话模块，还有一个重要的智能体模块，智能体模块包含智能体列表页和智能体详情页，在技术选型上，我们根据不同页面的特点，进行了一次战略性、差异化的技术实践，其中KMP（Kotlin Multiplatform）的应用，是本次实践的亮点。
对于相对独立、与主会话关联性较小的智能体列表页，我们果断选择了使用KMP进行开发，旨在探索其在复杂场景下的应用潜力。
面对这些问题，我们积极推动 KMP 框架解决侧滑手势冲突问题、以及卡片与 KMP 模块的兼容问题，这一实践不仅为用户带来流畅的列表滚动体验，更是帮助框架在处理复杂嵌套滚动这类通用问题上，沉淀了解决方案。
与列表页不同，智能体详情页功能已经成熟和稳定，我们直接复用了原支小宝中的现有模块，避免重复建设。
5. 数据建设
进入 AI 对话领域，如何科学度量一个 AI 对话产品的核心体验？ 过去的性能指标，比如页面打开耗时，在生成式的 AI 交互场景下已不适用，比如会话页面秒开，但用户发送问题后需要等待 5 秒才看到第一个字。因此，需要建立一套全新的、能够真实反映 AI 对话流式交互质量的度量体系。
核心思路是：从用户的实际感知出发，将一次 AI 对话的过程，拆解为一系列可度量、可归因的关键节点。 基于此，我们设计并搭建了一套包含「可感知耗时」和「链路稳定性」两大维度的度量体系。
我们定义了 AI 对话中最核心的用户体验指标 ——首 Token 耗时，即从用户发送 Query 到屏幕上出现第一个 AI 生成内容的时间。这个指标直接决定了用户感受到的“快”与“慢”。总耗时可以进一步精细化地拆解为三个核心阶段，用于指导后续优化：
除了用户感知的速度，会话链路的稳定性是 AI 对话体验的生命线。框架自身虽然有其内部监控，但更多是站在框架层的视角，而作为业务方，更关心的是用户体验是否受损。我们与框架深度对齐后，搭建了一套从业务视角出发，能够反映发送链路稳定性的监控指标体系。
业务视角的成功与失败
基于这个共识，我们搭建了业务方视角的稳定性大盘：
八、阶段性结果
我们以较短的研发周期、较少的人力投入，实现了 AI 出行助手的快速上线。目前取得以下阶段性成果：
业务指标
研发效能提升
AI 对话新产品研发周期：数月 → 30天，刷新 AI 对话类业务的交付记录，证明在 xUI + gRPC + KMP 等底层技术基建的支撑下，可以实现较高的研发效率；
九、未来展望
1. 持续探索，打磨极致体验
2. 业务驱动框架完善
十、团队介绍
想让您写的代码影响数亿人？支付宝 2026 届秋季校园招聘已开启！作为蚂蚁集团核心业务板块，我们深度支撑支付宝 App 用户关键链路，每日承载亿级用户高频交互，是数字生活生态的技术基石。在这里，你能获得超级 App 建设的核心机会，亲身推动数亿人使用的产品迭代；与行业前沿的客户端技术梯队共事，和顶尖专家并肩攻克技术难题；投身高频核心项目，在真实业务场景中快速积累经验、实现能力跃迁。加入我们，用技术重塑数字生活体验，让每一行代码都成为改变世界的力量
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |