作者 | 飛豬技術(shù) 石國(guó)偉

導(dǎo)讀：在旅游這個(gè)極度非標(biāo)、決策鏈路極長(zhǎng)且對(duì)實(shí)時(shí)庫(kù)存要求極高的場(chǎng)景下，如何用 AI 解決的不僅僅是“去哪玩”，而是“怎么去、住哪兒、多少錢”的閉環(huán)問題？

飛豬「問一問」是我們交出的一份答卷。從最早的地圖規(guī)劃工具，到如今基于多智能體（Multi-Agent）協(xié)作、直連實(shí)時(shí)價(jià)庫(kù)的 AI 旅行管家，我們將行程規(guī)劃效率提升了 90% 以上。本文將復(fù)盤這一路的技術(shù)演進(jìn)、架構(gòu)決策以及那些我們踩過的“坑”。

1 起心動(dòng)念：為什么我們需要一個(gè)“不只是聊天”的 AI？

用戶想要規(guī)劃一趟完整的行程，對(duì)應(yīng)的決策過程會(huì)很復(fù)雜，從產(chǎn)生“想出去玩”的念頭，到最終下單，需要在攻略、機(jī)酒、景點(diǎn)、交通之間反復(fù)橫跳。傳統(tǒng)的搜索只能解決“點(diǎn)”的問題，而早期的 AI 聊天機(jī)器人往往停留在“咨詢”層面——它們能寫出如詩(shī)如畫的推薦詞，但當(dāng)你問“這張機(jī)票現(xiàn)在多少錢”或者“幫我把這個(gè)行程訂了”時(shí)，它們往往無能為力，甚至?xí)a(chǎn)生嚴(yán)重的幻覺。

我們意識(shí)到，用戶需要的不是一個(gè)陪聊的網(wǎng)友，而是一個(gè)能干活的Agent（智能體）。它需要具備三個(gè)核心素質(zhì)：

• 懂行：擁有高質(zhì)量的行業(yè)數(shù)據(jù)，不亂說話。

• 能算：能基于實(shí)時(shí)庫(kù)存和價(jià)格（價(jià)庫(kù)）做規(guī)劃，而不是基于過期的訓(xùn)練數(shù)據(jù)。

• 能做：能直接掛載商品，實(shí)現(xiàn)交易閉環(huán)。

基于這個(gè)思考，我們開啟了從“行程工具”到“多智能體”的進(jìn)化之路。

2 演進(jìn)之路：從工具到智能體的三次躍遷

回看過去兩年，我們的架構(gòu)經(jīng)歷了三個(gè)明顯的階段。

2.1. 1.0 時(shí)代：行程規(guī)劃工具

最開始的時(shí)候，我們做的是一個(gè)基于地圖的行程規(guī)劃工具，用戶可以從外部導(dǎo)入或者自己從零規(guī)劃一條線路，同時(shí)規(guī)劃出來的線路也支持分享，其中的交通、酒店、景點(diǎn)也支持下單，這就是第一版行程規(guī)劃工具，這里 ai 的切入點(diǎn)在于智能解析行程，即使用大模型解析從外部平臺(tái)導(dǎo)入的行程信息，格式化成 行程規(guī)劃 - 目的地 - 天 - 景點(diǎn) 的樣式，之后用戶可以在導(dǎo)入的數(shù)據(jù)的基礎(chǔ)上進(jìn)行編輯。

痛點(diǎn)：目前還只是在工具的層面，談不上智能推薦，所有的數(shù)據(jù)，包括城市、景點(diǎn)、酒店等信息還是依賴用戶手動(dòng)點(diǎn)選或者導(dǎo)入，用戶的操作鏈路稍長(zhǎng)。

2.2. 2.0 時(shí)代：線路庫(kù) + 智能行程助手（MVP）

為了能夠吸引更多用戶，同時(shí)簡(jiǎn)化用戶操作流程，故開始線路庫(kù)的建設(shè)，期間，我們建立了一條行程規(guī)劃數(shù)據(jù)采集、清洗、鏈接、聚類、審核、落庫(kù)、投放的鏈路。這些信息會(huì)被投放到飛豬 APP 中，用戶如果感興趣，可以保存線路，并在線路的基礎(chǔ)上做調(diào)整。

有了線路庫(kù)作為基礎(chǔ)，我們就開始想要做一些更普適的工作，想要進(jìn)一步簡(jiǎn)化給用戶規(guī)劃行程的鏈路，同時(shí)承接住用戶更多的需求，即支持用戶通過對(duì)話的方式描述訴求，之后我們給出對(duì)應(yīng)的解決方案，也就是智能行程助手。

到這里，我們的方案中就增加了更多的不確定性，答案生成的方式自然就選用了 RAG(Retrieval-augmented generation) 的模式。當(dāng)時(shí)是 2024 年 12 月份，DeepSeek V3 的出現(xiàn)已經(jīng)對(duì)業(yè)界產(chǎn)生了不小的沖擊，我們也對(duì)智能助手的效果有了一定的信心。

智能行程助手的整體鏈路如下圖，基于用戶訴求，從線路庫(kù)中召回關(guān)聯(lián)線路，之后給大模型做總結(jié)輸出，其中數(shù)據(jù)召回使用了 QP（Query Predict）的能力，使用算法訓(xùn)練的小模型推測(cè)出來查詢參數(shù)，之后基于查詢參數(shù)召回關(guān)聯(lián)線路。

痛點(diǎn)：

• 數(shù)據(jù)能力不足：只召回線路，沒有交通和酒店的實(shí)時(shí)信息

• 結(jié)構(gòu)單一：一個(gè)大模型干所有事，邏輯處理能力和擴(kuò)展性捉襟見肘。

2.3. 3.0 時(shí)代：多智能體協(xié)作的「問一問」

簡(jiǎn)單的 RAG 無法承接復(fù)雜的旅游場(chǎng)景，于是，我們構(gòu)建了一套意圖識(shí)別 Agent + N 個(gè)場(chǎng)景 Agent（行程、交通、酒店、講解等）的多智能體架構(gòu)。同時(shí)在 Agent 框架中充分運(yùn)用 COT（Chain-of-Thought Prompting）、Prompt Chaining 等編排方式，充分發(fā)掘 LLM 的潛力。

當(dāng)用戶提出問題，首先是意圖識(shí)別 Agent 會(huì)對(duì)問題進(jìn)行分流，執(zhí)行抽槽和意圖分類的工作；之后問題會(huì)被分配到對(duì)應(yīng)場(chǎng)景的 Agent，在具體處理問題的 Agent 中，會(huì)按需要執(zhí)行對(duì)應(yīng)的工具調(diào)用（線路庫(kù)、交通、酒店等），同時(shí)查詢結(jié)果會(huì)以線路定制師、智能交通顧問、酒店顧問等角色的形式外化出來。之后，經(jīng)過對(duì)數(shù)據(jù)的裁剪、校驗(yàn)之后，輸出最終答案。

這種全新的交互形態(tài)——不僅能聊，還會(huì)以擬人角色的方式把查詢結(jié)果外化出來，同時(shí)還能輸出圖文并茂的內(nèi)容——在當(dāng)時(shí)的 OTA 行業(yè)里確實(shí)是獨(dú)一份。為了確保上線初期的體驗(yàn)（畢竟多智能體調(diào)用真的很耗資源），我們不得不搞了個(gè)“限流”策略，推出了邀請(qǐng)碼機(jī)制。沒想到的是，這個(gè)“饑餓營(yíng)銷”反而讓它火了一把，當(dāng)時(shí)內(nèi)部甚至出現(xiàn)了一碼難求的盛況。

3 核心架構(gòu)設(shè)計(jì)：讓 AI 像專家一樣思考

3.1. 意圖識(shí)別與上下文管理：聽懂“弦外之音”

• 意圖分發(fā)：用戶的 Query 首先進(jìn)入意圖識(shí)別 Agent。我們會(huì)結(jié)合LBS 信息、常駐地、歷史訂單以及當(dāng)前對(duì)話歷史進(jìn)行綜合判斷。

• Query 改寫：用戶往往惜字如金。如上面的 case，我們會(huì)將“昆明”結(jié)合上文“為我找便宜機(jī)票”，改寫為“我想要去昆明玩，出發(fā)地是錦州，請(qǐng)為我推薦機(jī)票”，從而讓后續(xù)鏈路更精準(zhǔn)。

• 記憶裁剪：歷史消息太長(zhǎng)會(huì)干擾模型。我們引入了一個(gè)專門的 LLM 節(jié)點(diǎn)對(duì)歷史消息做“總結(jié)”，存入數(shù)據(jù)庫(kù)。下次帶入上下文時(shí)，優(yōu)先使用總結(jié)后的精簡(jiǎn)信息。

3.2. 數(shù)據(jù)召回：從 QP 到 Function Call

在 2.0 時(shí)代，我們基于 QP（Query Prediction）來決定怎么查詢數(shù)據(jù)，即首先查詢的數(shù)據(jù)類型是固定的，只會(huì)查詢行程規(guī)劃數(shù)據(jù)，同時(shí)查詢參數(shù)基于 QP 的結(jié)果來確定，例如要查詢的目的地有哪些、要查詢幾天的行程。

在 3.0 時(shí)代，我們?nèi)孓D(zhuǎn)向了Function Call。把“查詢線路”、“查詢機(jī)票”、“查詢酒店庫(kù)存”等功能封裝成工具，讓模型自己決定：“為了回答這個(gè)問題，我現(xiàn)在需要調(diào)用哪個(gè)工具？需要什么參數(shù)？”。

3.3. 雙輪工具調(diào)用：先畫骨架，再填血肉

這是我們?cè)谛谐桃?guī)劃場(chǎng)景下的思路，我們發(fā)現(xiàn)，如果讓模型一次性生成帶交通、景點(diǎn)、酒店的完整行程，幻覺率很高且速度慢。于是我們對(duì) React 模式做了調(diào)整，分兩步調(diào)用工具：

• 第一步：調(diào)工具，查詢關(guān)聯(lián)線路庫(kù)

• 第二步：結(jié)合線路庫(kù)數(shù)據(jù)，輸出行程骨架（第幾天、去哪里、玩什么）。

• 第三步：基于骨架，再次調(diào)用工具，精準(zhǔn)查詢具體的交通班次、酒店實(shí)時(shí)價(jià)格、景點(diǎn)門票。

• 總結(jié)輸出：最后將骨架與實(shí)時(shí)數(shù)據(jù)結(jié)合，生成最終回復(fù)。

這樣既保證了行程的合理性，又確保了價(jià)格和庫(kù)存的真實(shí)性。

4 交互與體驗(yàn)：突破大模型的“慢”與“呆”

大模型生成內(nèi)容通常較慢，且默認(rèn)是 Markdown 文本，這對(duì)于需要展示豐富圖文卡片的旅游場(chǎng)景來說體驗(yàn)很差。我們做了三點(diǎn)重要優(yōu)化：

4.1. 雙通道渲染協(xié)議

我們定義了一套并行雙通道渲染協(xié)議。模型輸出的不僅僅是文本，還包含特殊的XML 占位符（如 ...）。

• 文本流：前端流式渲染 Markdown 文本，用戶能立刻看到文字回復(fù)。

• 卡片流：服務(wù)端異步解析占位符，通過隱藏 Token 獲取卡片 ID 和類型，異步推送結(jié)構(gòu)化數(shù)據(jù)給前端渲染。實(shí)現(xiàn)了“圖文混排”的流式輸出。

4.2. 極致的并行處理

在設(shè)計(jì)每個(gè) Agent 的時(shí)候，我們充分拆解了輸出內(nèi)容，對(duì)于沒有前后依賴的部分，全部使用并行的方式生成，保證用戶體驗(yàn)的流暢性。

4.3. 弱網(wǎng)下的“斷點(diǎn)續(xù)傳”

旅途中的用戶常處于弱網(wǎng)環(huán)境（如電梯、高鐵）。如果生成到一半斷網(wǎng)，體驗(yàn)是災(zāi)難性的。我們?cè)O(shè)計(jì)了一套序號(hào)化續(xù)接機(jī)制：每一次流式輸出的內(nèi)容都帶有遞增序號(hào)，并緩存起來。當(dāng)用戶網(wǎng)絡(luò)恢復(fù)重新連接時(shí)，前端會(huì)攜帶當(dāng)前的序號(hào)請(qǐng)求，服務(wù)端校驗(yàn)后，從緩存中取出后續(xù)內(nèi)容繼續(xù)下發(fā)。這大大提升了移動(dòng)端的魯棒性。

5 實(shí)戰(zhàn)成果與反思

5.1. 我們拿到了什么結(jié)果？

• 效率革命：相比傳統(tǒng)手動(dòng)規(guī)劃，AI 輔助下的行程規(guī)劃效率提升了90% 以上。

• 用戶買單：生成方案的用戶滿意度達(dá)到95%。

• 特色場(chǎng)景：我們的“拍照講解”功能（基于多模態(tài)識(shí)別），平均能為用戶節(jié)省50 元的講解設(shè)備租賃費(fèi)，滿意度同樣高達(dá) 95%。

• 生態(tài)開放：目前這套能力不僅服務(wù)于飛豬 App，還接入了榮耀 YOYO、VIVO 藍(lán)心小 V等手機(jī)廠商的智能體生態(tài)。

5.2. 踩過的坑與經(jīng)驗(yàn)

1. 模型選型不能“一刀切”：規(guī)劃節(jié)點(diǎn)需要強(qiáng)推理能力，適合用大參數(shù)模型；而最終的總結(jié)輸出節(jié)點(diǎn)，更看重指令遵循（格式化輸出）和速度。因此，我們?cè)谳敵龉?jié)點(diǎn)對(duì)小模型進(jìn)行了指令微調(diào)（SFT），在保證格式準(zhǔn)確的同時(shí)，大幅降低了時(shí)延。

2. 評(píng)測(cè)不能只靠人：早期我們強(qiáng)依賴人工評(píng)測(cè)，效率低且反饋慢?，F(xiàn)在我們正在構(gòu)建自動(dòng)化評(píng)測(cè)體系，讓“評(píng)測(cè) - 調(diào)整 - 優(yōu)化”的飛輪自動(dòng)轉(zhuǎn)起來。

6 寫在最后

AI Agent 的核心不在于 Prompt 寫得有多好，而在于上下文工程師（Context Engineering）做得有多細(xì)。

在飛豬「問一問」的實(shí)踐中，我們最大的體會(huì)是：只有給模型提供高質(zhì)量的行業(yè)專有數(shù)據(jù)（Context），并讓它具備調(diào)用真實(shí)世界工具的能力（Function Call），大模型才能真正從“玩具”變成“工具”。

未來，我們將繼續(xù)打磨這套多智能體框架，并在更多垂類場(chǎng)景中進(jìn)行 SPI 插拔式擴(kuò)展。