How Alipay Built an AI Travel Assistant in Two Months with a 4‑Person Mobile Team

Abstract

This article introduces Alipay’s AI Travel Assistant, describing how a four‑person client team delivered the product from inception to full launch in two months using the Alipay terminal’s xUI + KMP foundation.

Product Introduction

AI Travel Assistant is a conversational travel service that integrates bus/metro QR code scanning, train/flight ticket booking, bike/taxi hailing, route planning and travel‑plan generation, providing a full‑chain travel experience.

It can be accessed in Alipay version 10.7.30 and later via “Alipay Home → Travel Channel → AI Assistant”.

Project Background

Traditional travel services require users to switch between multiple apps, leading to inefficient multi‑step operations that no longer meet personalized user demands. The original travel assistant, built on the legacy “ZhiXiaoBao” platform, needed a new, vertical, extensible technical foundation, prompting the creation of the AI Travel Assistant as a one‑stop intelligent travel concierge.

AI Dialogue Product Exploration and Review

Before this project, Alipay had launched AI assistants such as AI Search and AQ, which explored xUI‑generated cards and gRPC streaming, validating modern AI interaction approaches.

xUI is a reusable AI interaction framework that abstracts common capabilities into modular components.

The goal was to integrate the AI Travel Assistant into this unified architecture while standardising protocols to resolve fragmentation across earlier versions.

Early AI Search and AQ used different xUI versions with inconsistent protocols.

The framework is standardising protocols to eliminate version fragmentation.

The team decided to adopt the xUI 1.0 standardised protocol, migrating all travel‑assistant business logic to this new stack.

Technical Solution

1. xUI – End‑to‑End Intelligent Interaction Framework

The main conversation uses xUI to enable rapid feature integration and reuse, reducing maintenance costs and benefiting from baseline optimisations.

xUI will standardise data, rendering and control protocols via gRPC streaming.

Core: standardised protocol + gRPC streaming + generated cards

2. Multi‑Stack Combination – KMP

For performance‑critical core scenes (main conversation framework, input components) the team uses native implementation; for less demanding pages (e.g., bot list) they explore KMP to improve development efficiency and gain cross‑stack experience.

Challenges and Difficulties

1. Base Capability Migration

Migrating the complex travel business from the legacy stack to the xUI standardised stack involves data‑layer adaptation, message‑channel refactoring, and component migration.

Data layer adaptation: Re‑map legacy data structures to the new protocol, requiring deep understanding of both schemas.

Message channel refactoring: Replace RPC + SYNC with gRPC streaming, requiring full‑chain synchronisation.

Rendering component migration: Consolidate native, card and markdown components into xUI generated cards while preserving 100% functionality.

2. Card Ecosystem Migration

The assistant relies on over 40 cards covering tickets, rides, ETC, etc. Challenges include large card volume, hidden business logic within cards, and complex bidirectional communication (≈20 JSAPI calls per card).

3. Standard Framework Maturation

Adopting the new standard protocol required exploring undocumented details and handling long, difficult debugging chains.

Refactoring Practice

Overall Architecture

xUI Practice – Data Protocol Adaptation

The team unified disparate AI dialogue protocols into the xUI 1.0 standard, keeping the core templateData unchanged while mapping other fields (e.g., chatId, itemId, hasNext) to the new structures.

Migration principles: reuse existing cards without altering their logic.

Message Channel Upgrade – RPC/SYNC → gRPC

Legacy RPC + SYNC required separate handling for queries and streaming AI output, causing high link complexity and latency. Switching to HTTP/2‑based gRPC streaming provides a single bidirectional connection, simplifying the link and improving performance.

Rendering Component Migration – Fragmented → Generated Cards

The legacy rendering stack mixed native components, cards and markdown. xUI provides a unified generated‑card solution, allowing business code to create empty templates while the framework handles dynamic content, flow cards, and sync‑based updates.

KMP Practice

Intelligent Bot List Page

The bot list, relatively independent from the main conversation, was built with KMP and embedded as a MicroPage within the native container. Challenges included nested scrolling and cross‑platform gesture conflicts, which were resolved by enhancing the KMP framework.

Intelligent Bot Detail Page

The detail page re‑used the existing legacy module to avoid duplicate effort.

Data Construction and Metrics

To evaluate AI dialogue experience, the team defined “first‑token latency” (time from user query to first AI token) and broke it down into xUI data callback, client processing, template creation, and rendering stages.

Stability metrics were defined from a business perspective, distinguishing successful completions (generation end, termination, rewrite) from errors and timeouts.

Stage Results

Within a short development cycle and limited manpower, the AI Travel Assistant achieved notable outcomes:

Higher click‑through rates for fulfillment tips compared to standard cards.

Reduced AI dialogue product development time from months to 30 days.

KMP saved one full‑time engineer by enabling cross‑platform reuse.

Future Outlook

Continue embracing new xUI features such as end‑to‑end TTS and ASR.

Deepen KMP adoption across more modules to maximise cross‑platform efficiency.

Improve debugging tools and framework stability to further boost developer productivity.