背景

业务背景

机票 OTA 业务已进入复杂出行需求与海量供给匹配的深水区，以商旅出行场景为例，用户既要遵守公司差旅报销的规章要求，又希望在此基础上为自己谋求尽可能多的权益，双倍里程积分、升舱、返现等增值商品应运而生。传统的机票 OTA 产品 GUI 交互形态（首页 -> listing页 -> OTA页 -> 下单页 -> 辅营页）显得笨重而臃肿，既没有让商旅之类的资深用户感到切实便利，又让只是简单的想买一张机票的小白用户感到头疼。

LUI 上的探索

早在 25 年 4 月的飞猪 APP 内，就已经悄然布局了一款基于 AI Agent 的 LUI 形态的 OTA 导购链路，用户可以以聊天对话的形式定制涵盖机、火、酒、门票的旅游攻略，并可直接完成购票、订酒店等动作。随着 26 年春节期间，阿里生态的闪购、淘宝、飞猪等接入千问 APP，普罗大众才第一次真切的感受到，AI Agent 不光像豆包 APP 一样可以用来问答聊天，还可以在上面完成具有一定复杂度的购物及履约动作。然而随着 30 亿补贴的结束，大部分用户的在线消费习惯似乎又回到了原来的淘宝、京东。即便如此，千问 APP 的这次尝试，依然让 AI Agent 行业的从业者们相信，未来已来。

问题诊断

落回到机票 OTA 行业，就目前传统的 GUI 导购链路形态来看，存在着以下问题：

导购记忆有限：以差旅出行场景为例，用户有着相对固定的价格范围、出发/到达城市、起飞/落地时间、舱等、航司等偏好。虽然 GUI 导购链路可以记住用户上次购票的ODD（出发到达城市及时间）及舱等、乘机人等信息，但对于有着相对固定偏好的商旅用户而言，每次购票依然需要从头走一遍完整的 GUI 导购链路，去找到自己的目标商品后下单
商品信息表达固定：当用户在 listing 和 ota 页看到航班/商品卡片的时候，呈现的都是固定的信息，除了必要的出发/到达时间、航站楼、价格等必要信息外，机型、航司、共享航班等更偏向于具有特殊需求的资深用户；且不同场景下用户的关注点也会不一样，如商旅场景下用户会更关注是否可开全额发票
商品货架形式的局限性：listing -> ota 的航班 -> 商品二级货架表达形式，本质上是为顺应供给侧的组织形式而对 C 表达的一种形态，用户为了找到自己所需的商品通常需要反复在 listing 和 ota 来回切换，甚至到最后，找到的商品也不一定是最符合自己需求的商品

目标

从”卖机票”到”卖方案”。通过人群Agent精准识别出行意图，为差旅人群提供场景化方案——将航班、舱位、增值服务、报销重组为完整方案，减少无效浏览，提升转化效率，同时带动高价值商品转化。

选差旅人群为首个样板：高频、偏好固定、非价敏溢价空间大。跑通后泛化至家庭、学生、新用户等其他重点人群。

总体架构

AI差旅Agent系统架构图

查看交互版架构图

核心设计思路

需求识别

在一次出行的过程中，用户的需求非常复杂，核心原因是影响因素太多（时间成本、金钱成本、舒适度、规章要求等），人脑处理起来很难在短时间内给出最优解，甚至就没有所谓的最优解。而这种复杂的综合最优解决策恰好是AI可以发力的地方。

Must Have 与 Better Have

一般而言，用户做出行决策时，会有自己的”底线”，底线之下的航班一定不会选，底线之上的航班会希望”要更多”。

Must Have：当次用户出行的必须要求，比如商旅用户出行会有差标要求，包括航班价格、出行时间（早班）、舱等（经济舱）等，不满足 Must Have 要求的航班，用户一定不会购买。
Better Have：当次用户出行的进阶需求，比如商旅用户希望在差标范围内得到尽量好的出行服务和权益，包括
- 航班：出发/到达时间点、出发/到达机场、航司、舱等、准点率、直达/中转、出行时长、准点率、行李额、退改规则
- 机场：快速安检、贵宾厅
- 接送：接送机
- 增值服务：返现、里程积分、会员积分、保险等。

显性需求、隐形需求与潜在需求

显性需求：用户当次交互实时传递的需求点，十分明确，可算作 Must Have类型。
隐性需求：用户历史交易履约时存在过的需求点，且时间线越近的需求，权重越高。
潜在需求：同类型出行场景下（如商旅出行、家庭出行、旅游、返乡/返工/返校等），目标用户群体所共同表现出来的共性需求，虽然某些共性需求点在当前用户的显性和隐性需求中都未曾出现过，但依然可能是一个潜在需求点。

需求模版

基于潜在需求场景，目标场景下的人群通常都具备类似的 Must Have。需要注意的是，Must Have 中并不是所有单个需求点的”底线”概率都必须是100%，但 Must Have 中所有需求点的综合概率，对不同模版来说一定有明显的区分；Must Have 中每个需求点的概率也远高于 Better Have 中的需求点。因此可基于 Must Have 总结出不同的需求模版。

需求模版并不局限于前述几个固定场景，应基于已掌握的实际信息，对需求模版的范围和颗粒度进行调整，如商旅场景可进一步细化为普通差旅+高端商旅（老板 vs 员工，规范企业 vs 个体户，Must Have 的定义会不一样），则不同模版的代表性会更强，用户意图匹配的时候就会更精准。

若可在导购链路中，当用户命中某个需求模版（系统推荐+用户主动确认），结合其历史交易履约行为，就可以推测其潜在需求和隐性需求。用户的实时搜索行为和历史交易履约行为，都需要做需求模版匹配，并基于不同权重（实时 > 历史 > 模版），聚合出最终的用户意图（需求点及权重）。

商品信息组织呈现形式

受供给侧货品组织形式的影响，目前主流的OTA都是以listing+ota的货架形式对用户进行商品展示和挑选，尤其是增值服务与航班本身的结合较为固化，无法灵活匹配用户的需求，导致用户需要在listing和ota反复横跳以挑选最适合的商品（经常没有标准答案），极大增加了用户挑选难度。

若能顺着用户的需求，将各货品及服务进行动态组装（展现层是组装、逻辑层是选品），则可以极大满足用户所想即所得的选购体验。需求即商品、商品即需求。

动态组装的商品

在用户表达需求的过程中，需要基于用户细碎的需求点，不断堆叠、组装，最后封装为一个完整的商品，并做实时反馈：

实时反馈当前已组装商品的关键信息和价格
当组装过程中，相关供给缺失时，需要实时反馈用户，避免交易时发现供给缺失
在用户表达需求的过程中，可能出现需求打架的场景（如价格和服务不可兼得），需要实时反馈用户，给出推荐策略，让用户决策。

动态意图识别及人品匹配

用户的需求虽然较为明确，但在与OTA平台的交互过程中，这个需求是被慢慢挖掘出来的；商品的动态组装，也需要结合用户的动态输入，做动态意图识别及人品匹配。

利用Agent和LUI的好处就是可以持续地主动引导用户自由地表达需求，并做实时反馈和商品推荐；在这个过程中，用户意图和组装的商品会同时变得越来越完善和确定，可帮助用户更快、更顺畅地找到最适合自己的商品。

意图识别

信息来源

用户的意图识别，需要包含以下几层信息

信息维度
L1 实时搜索意图	用户当下最真实的需求，应以此为最高优先级
L2 历史成交偏好	记录了用户历史上最真实的选择，如航司、价格、出发时间、开票偏好等
L3 用户资料/身份	用户会在商旅认证、个人资料等地方，留下偏好信息，如航班价格区间、出行时间、舱等、开票抬头、是否需要电子发票或行程单等；身份信息（如白领/学生，88VIP/飞猪会员/航司会员）也会反映用户的价格敏感度及权益敏感度

信息维度

类型	指标	值/标签
航班	航班价格	金额上限
	出行日期	周中：周一至周五晚6点前周末：周五晚6点以后至周日14点
	出发时间	出发时间
	到达时间	到达时间
	舱等	经济舱高端经济舱公务舱头等舱
	出发机场	出发机场
	到达机场	到达机场
	航司	航司
	直达/中转	直达中转
	出行时长	出行时长
	准点率	准点率
	选座	是否需要选座
	行李额	是否含标准行李托运是否含标准登机箱限制
	退改规则	是否免费退（购票当天算）是否免费改（购票当天算）
	开发票	是否
机场	快速安检	是否买了快速安检增值服务
	贵宾厅	是否买了贵宾厅增值服务
接送	接送机	是否买了接送机增值服务
增值服务	返现	是否买了返现增值服务
	里程积分	是否买了里程积分增值服务
	会员积分	是否买了会员积分增值服务
	保险	是否买保险买哪些保险
	辅营	是否买辅营买哪些辅营

需求模版匹配

构建需求模版

在围绕特定场景人群构建需求模版时，除了需要对需求点做 Must Have 和 Better Have 聚类外，还需要给各需求点计算权重。以”普通差旅”为例，需求模版如下：

需求维度	航班	机场	接送	增值服务
Must Have （权重大于0.5）	航班价格 - 0.95 出行时间（早班） - 0.8 舱等（经济舱） - 0.9 开发票 - 0.99 出发/到达时间点（上午出发） - 0.8 直达/中转（直达）- 0.8 出行时长（前30%） - 0.8 准点率（前30%） - 0.8	-	-	-
Better Have （权重小于0.5）	出发/到达机场 - 0.4 航司 - 0.3 选座 - 0.1 行李额 - 0.1 退改规则 - 0.3	快速安检 - 0.1 贵宾厅 - 0.1	接送机 - 0.05	返现 - 0.2 里程积分 - 0.2 会员积分 - 0.2 保险 - 0.3

表格中概率/权重数值为demo示意，理想状态应由模型自主计算得出
出发/到达机场等OD强相关信息需针对不同OD做动态映射
出行/到达时间、出行时长、准点率等非枚举类信息，需要简化为可枚举值，如出行/到达时间-早、中、晚；出行时长/准点率：前30%、中间40%、后30%
若构建模版的过程中，计算出的 Must Have 权重数据方差较大，则说明该模版设定的粒度太粗，需要再做细化；或模版所覆盖群体用户数据量太少。

需求模版匹配

基于实时用户意图偏好，与各需求模版进行匹配，若 Must Have 匹配率超过阈值，则给用户推荐相应的需求模版；确认需求模版后，再进一步匹配用户的隐性需求（历史行为）。

匹配需求模版：用户实时意图 ∩ 需求模版 > 阈值时，取最大概率模版
若命中多个模版超过阈值，需要按照匹配度排序，在C端让用户进行确认
匹配隐性需求：用户历史订单 ∩ 需求模版 > 阈值，取时间最近的一次
合成用户意图：用户意图 = 用户实时意图（实时） + 隐性需求（历史） + 需求模版（实时 > 历史 > 模版，冲突时按优先级覆盖）

商品组装

基于用户意图，将各维度的需求点与具体货品进行匹配、组合。系统找到符合匹配条件的商品后，按照匹配度进行打分，基于打分优先级排序，给用户进行推荐。匹配过程依然需要参考 Must Have 和 Better Have两个维度，以及各个信息的权重。

除了商品自身所携带的信息外，也可关注一些场外信息，如天气（影响准点率、甚至航班取消）、地图（影响接驳便利性）等。

产品交互方案

核心交互流程

以下为用户从进入机票首页到交易成功的核心交互逻辑

首页
用户进入机票首页选择ODD及乘机人（可选）
基于初步意图识别决策是否展示【AI商旅】入口
1. 因将商旅需求模版确认前置到了首页入口，需要提高意图匹配的门槛，减少对非目标用户的打扰
用户点击弹出Agent对话框
Agent对话
意图识别及商品推荐
1. 给出用户需求模版判断（若依然缺少判断信息，继续引导用户补充）
2. 给出用户推荐商品（打包方案）
1. 基于多维度综合考量，推荐3个不同视角下最优的商品
2. 兜底进入传统listing/ota货架链路
  1. 引导用户补充完善意图
  2. 进入兜底链路
用户选择商品，给出下单卡片
1. 引导用户完善下单必要信息
完成支付
后续履约跟进

原型demo

AI 差旅 Agent Demo

遗留问题

虽然这一版本已经考虑了在用户不适应 LUI 链路的情况下可以顺利回退到传统的 GUI 链路。但为了实现 LUI 的产品终态，需要着重考虑以下问题：

基于系统推荐的结果，用户最终是否买单，需要反哺回模型继续进行训练，不断提升推荐的准确性。
系统推荐得再准，用户也不一定认可，原因在于用户会认为 AI “杀熟”。在交互上，可以在各推荐方案纬度（最省钱、最准时、最性价比）上，引入其它落选项的可参考、可对比性，但依然无法从源头解决此信任问题，有问题的用户永远都会有问题（现在的 GUI 链路也会有问题），机票价格的波动性及供给侧的复杂性，决定了用户只能在自己能掌控的范围内拿到最便宜的机票。
本篇章重点阐述的是导购链路的 LUI 产品化形态问题，而机票作为重履约行业，也需要把交易后的出票、值机、退改等服务场景也结合进来
demo 示例可能并非最理想的交互形态，随着整个 AI Agent 行业的发展，会逐步形成更强大、更友好、用户心智更普及的交互方案。