作者 | 飞猪技术 石国伟

导读：在旅游这个极度非标、决策链路极长且对实时库存要求极高的场景下，如何用 AI 解决的不仅仅是“去哪玩”，而是“怎么去、住哪儿、多少钱”的闭环问题？

飞猪「问一问」是我们交出的一份答卷。从最早的地图规划工具，到如今基于多智能体（Multi-Agent）协作、直连实时价库的 AI 旅行管家，我们将行程规划效率提升了 90% 以上。本文将复盘这一路的技术演进、架构决策以及那些我们踩过的“坑”。

1起心动念：为什么我们需要一个“不只是聊天”的 AI？

用户想要规划一趟完整的行程，对应的决策过程会很复杂，从产生“想出去玩”的念头，到最终下单，需要在攻略、机酒、景点、交通之间反复横跳。传统的搜索只能解决“点”的问题，而早期的 AI 聊天机器人往往停留在“咨询”层面——它们能写出如诗如画的推荐词，但当你问“这张机票现在多少钱”或者“帮我把这个行程订了”时，它们往往无能为力，甚至会产生严重的幻觉。

我们意识到，用户需要的不是一个陪聊的网友，而是一个能干活的 Agent（智能体）。它需要具备三个核心素质：

• 懂行：拥有高质量的行业数据，不乱说话。

• 能算：能基于实时库存和价格（价库）做规划，而不是基于过期的训练数据。

• 能做：能直接挂载商品，实现交易闭环。

基于这个思考，我们开启了从“行程工具”到“多智能体”的进化之路。

2演进之路：从工具到智能体的三次跃迁

回看过去两年，我们的架构经历了三个明显的阶段。

2.1. 1.0 时代：行程规划工具

最开始的时候，我们做的是一个基于地图的行程规划工具，用户可以从外部导入或者自己从零规划一条线路，同时规划出来的线路也支持分享，其中的交通、酒店、景点也支持下单，这就是第一版行程规划工具，这里 ai 的切入点在于智能解析行程，即使用大模型解析从外部平台导入的行程信息，格式化成 行程规划 - 目的地 - 天 - 景点 的样式，之后用户可以在导入的数据的基础上进行编辑。

痛点：目前还只是在工具的层面，谈不上智能推荐，所有的数据，包括城市、景点、酒店等信息还是依赖用户手动点选或者导入，用户的操作链路稍长。

2.2. 2.0 时代：线路库 + 智能行程助手（MVP）

为了能够吸引更多用户，同时简化用户操作流程，故开始线路库的建设，期间，我们建立了一条行程规划数据采集、清洗、链接、聚类、审核、落库、投放的链路。这些信息会被投放到飞猪 APP 中，用户如果感兴趣，可以保存线路，并在线路的基础上做调整。

有了线路库作为基础，我们就开始想要做一些更普适的工作，想要进一步简化给用户规划行程的链路，同时承接住用户更多的需求，即支持用户通过对话的方式描述诉求，之后我们给出对应的解决方案，也就是智能行程助手。

到这里，我们的方案中就增加了更多的不确定性，答案生成的方式自然就选用了 RAG(Retrieval-augmented generation) 的模式。当时是 2024 年 12 月份，DeepSeek V3 的出现已经对业界产生了不小的冲击，我们也对智能助手的效果有了一定的信心。

智能行程助手的整体链路如下图，基于用户诉求，从线路库中召回关联线路，之后给大模型做总结输出，其中数据召回使用了 QP（Query Predict）的能力，使用算法训练的小模型推测出来查询参数，之后基于查询参数召回关联线路。

痛点：

• 数据能力不足：只召回线路，没有交通和酒店的实时信息

• 结构单一：一个大模型干所有事，逻辑处理能力和扩展性捉襟见肘。

2.3. 3.0 时代：多智能体协作的「问一问」

这种全新的交互形态——不仅能聊，还会以拟人角色的方式把查询结果外化出来，同时还能输出图文并茂的内容——在当时的 OTA 行业里确实是独一份。为了确保上线初期的体验（毕竟多智能体调用真的很耗资源），我们不得不搞了个“限流”策略，推出了邀请码机制。没想到的是，这个“饥饿营销”反而让它火了一把，当时内部甚至出现了一码难求的盛况。

3核心架构设计：让 AI 像专家一样思考

• Query 改写：用户往往惜字如金。如上面的 case，我们会将“昆明”结合上文“为我找便宜机票”，改写为“我想要去昆明玩，出发地是锦州，请为我推荐机票”，从而让后续链路更精准。

• 记忆裁剪：历史消息太长会干扰模型。我们引入了一个专门的 LLM 节点对历史消息做“总结”，存入数据库。下次带入上下文时，优先使用总结后的精简信息。

3.2. 数据召回：从 QP 到 Function Call

在 2.0 时代，我们基于 QP（Query Prediction）来决定怎么查询数据，即首先查询的数据类型是固定的，只会查询行程规划数据，同时查询参数基于 QP 的结果来确定，例如要查询的目的地有哪些、要查询几天的行程。

在 3.0 时代，我们全面转向了 Function Call。把“查询线路”、“查询机票”、“查询酒店库存”等功能封装成工具，让模型自己决定：“为了回答这个问题，我现在需要调用哪个工具？需要什么参数？”。

3.3. 双轮工具调用：先画骨架，再填血肉

这是我们在行程规划场景下的思路，我们发现，如果让模型一次性生成带交通、景点、酒店的完整行程，幻觉率很高且速度慢。于是我们对 React 模式做了调整，分两步调用工具：

• 第一步：调工具，查询关联线路库

• 第二步：结合线路库数据，输出行程骨架（第几天、去哪里、玩什么）。

• 第三步：基于骨架，再次调用工具，精准查询具体的交通班次、酒店实时价格、景点门票。

• 总结输出：最后将骨架与实时数据结合，生成最终回复。

这样既保证了行程的合理性，又确保了价格和库存的真实性。

4交互与体验：突破大模型的“慢”与“呆”

大模型生成内容通常较慢，且默认是 Markdown 文本，这对于需要展示丰富图文卡片的旅游场景来说体验很差。我们做了三点重要优化：

4.1. 双通道渲染协议

我们定义了一套并行双通道渲染协议。模型输出的不仅仅是文本，还包含特殊的 XML 占位符（如 ...）。

• 文本流：前端流式渲染 Markdown 文本，用户能立刻看到文字回复。

• 卡片流：服务端异步解析占位符，通过隐藏 Token 获取卡片 ID 和类型，异步推送结构化数据给前端渲染。实现了“图文混排”的流式输出。

4.2. 极致的并行处理

在设计每个 Agent 的时候，我们充分拆解了输出内容，对于没有前后依赖的部分，全部使用并行的方式生成，保证用户体验的流畅性。

4.3. 弱网下的“断点续传”

旅途中的用户常处于弱网环境（如电梯、高铁）。如果生成到一半断网，体验是灾难性的。我们设计了一套 序号化续接机制：每一次流式输出的内容都带有递增序号，并缓存起来。当用户网络恢复重新连接时，前端会携带当前的序号请求，服务端校验后，从缓存中取出后续内容继续下发。这大大提升了移动端的鲁棒性。

5实战成果与反思

5.1. 我们拿到了什么结果？

• 效率革命：相比传统手动规划，AI 辅助下的行程规划效率提升了 90% 以上。

• 用户买单：生成方案的用户满意度达到 95%。

• 生态开放：目前这套能力不仅服务于飞猪 App，还接入了 荣耀 YOYO、VIVO 蓝心小 V等手机厂商的智能体生态。

5.2. 踩过的坑与经验

1. 模型选型不能“一刀切”：规划节点需要强推理能力，适合用大参数模型；而最终的总结输出节点，更看重指令遵循（格式化输出）和速度。因此，我们在输出节点对小模型进行了 指令微调（SFT），在保证格式准确的同时，大幅降低了时延。

2. 评测不能只靠人：早期我们强依赖人工评测，效率低且反馈慢。现在我们正在构建自动化评测体系，让“评测 - 调整 - 优化”的飞轮自动转起来。