1. 先拆清三個(gè)容易被低估的難點(diǎn)再談技術(shù)棧先說結(jié)論一個(gè)AI旅游Agent表面上是一套用戶聊天 → 行程規(guī)劃 → 下單支付的流程但你真上手做就會(huì)發(fā)現(xiàn)真正決定項(xiàng)目成敗的從來不是大模型API本身而是圍繞它鋪開的前端交互、上下文管理、工具調(diào)用協(xié)議和支付回調(diào)。很多人以為這就是給GPT套個(gè)殼加個(gè)天氣查詢接口再把攜程的單子接進(jìn)來實(shí)際上這套東西的復(fù)雜度遠(yuǎn)超想象。我這個(gè)項(xiàng)目從零搭建跑完整個(gè)鏈路之后最大的感受是技術(shù)選型誰都能抄難的是把對話和業(yè)務(wù)這兩套邏輯真正焊在一起。先把這個(gè)Agent要解決的場景說清楚。我做的是一款給自助游用戶用的旅游規(guī)劃Agent用戶通過微信小程序或H5頁面跟它對話比如幫我規(guī)劃一份成都四天三晚的行程預(yù)算3000不想去網(wǎng)紅景點(diǎn)Agent需要自己去查天氣、調(diào)景區(qū)信息、比價(jià)酒店最終生成一份可確認(rèn)的行程單用戶點(diǎn)確認(rèn)后直接走微信/支付寶的H5支付完成預(yù)訂。整個(gè)鏈路涉及前端、網(wǎng)關(guān)、編排引擎、MCP工具服務(wù)、訂單系統(tǒng)和支付渠道缺一不可。拆解這個(gè)技術(shù)棧之前先講三個(gè)我踩完坑才明白的難點(diǎn)這決定了后面的所有設(shè)計(jì)難點(diǎn)一是上下文漂移問題。旅游規(guī)劃絕不是一次問答就能結(jié)束的。用戶今天說定了去成都明天可能改口說成都太熱了換昆明吧甚至只是改一個(gè)預(yù)算數(shù)字。如果Agent上下文里存的是成都四天三晚改預(yù)算后生成的行程可能還帶著成都的舊信息。這要求系統(tǒng)必須把對話歷史和結(jié)構(gòu)化行程草稿分開管理而不是一股腦塞給大模型。難點(diǎn)二是工具返回的數(shù)據(jù)結(jié)構(gòu)統(tǒng)一。MCP協(xié)議給了Agent調(diào)用工具的標(biāo)準(zhǔn)通道但是酒店供應(yīng)商返回的字段、天氣服務(wù)的字段、門票系統(tǒng)的字段格式千差萬別。Agent也就是大模型非常敏感返回體一旦出現(xiàn)歧義它就會(huì)開始瞎猜字段含義。我見過Agent因?yàn)橐粋€(gè)日期格式不一致把今天理解成明天最后給出錯(cuò)誤建議的例子。難點(diǎn)三是支付環(huán)節(jié)的最后一公里。聊天界面里一切都很美好但要用戶真金白銀付錢的那一刻體驗(yàn)稍微卡頓流失率就直線上升。而且H5支付的回調(diào)機(jī)制、并發(fā)冪等、掉單處理完全是另一套工程體系跟AI可沒什么關(guān)系卻又是這個(gè)產(chǎn)品能活下來的基礎(chǔ)。下面我就按實(shí)際系統(tǒng)的調(diào)用順序從前端開始一層一層拆解每個(gè)環(huán)節(jié)的技術(shù)選擇和落地細(xì)節(jié)。2. 前端對話層為什么我用uniapp而不是原生小程序前端對話層是這個(gè)Agent的門面用戶所有感知都發(fā)生在這里。我最初評估過三種方案微信原生小程序、uniapp跨端框架、純H5。最終選了uniapp核心原因是一套代碼同時(shí)覆蓋小程序和H5。2.1 選型邏輯跨端覆蓋背后的生意邏輯旅游場景的流量分散在微信、支付寶、抖音等多個(gè)平臺(tái)用戶分享行程的時(shí)候打開鏈接可能是H5也可能是小程序。如果每個(gè)端都寫一套原生代碼維護(hù)成本翻倍而且AI對話界面這種復(fù)雜交互雙端同步改版非常痛苦。uniapp的好處在于編譯期把同一套Vue代碼轉(zhuǎn)成各端產(chǎn)物。我的實(shí)際經(jīng)驗(yàn)是微信小程序端走原生渲染H5端走標(biāo)準(zhǔn)瀏覽器組件用uni-ui的彈層、輸入框、按鈕對話消息列表自己封裝。不需要花里胡哨的圖表和動(dòng)畫核心交互就是消息氣泡、鍵盤輸入、流式文本渲染、行程卡片展示。唯一的坑是小程序的WebView與H5的DOM差異。比如長按復(fù)制、輸入框自動(dòng)滾動(dòng)、鍵盤彈起遮擋行程卡片這些細(xì)節(jié)點(diǎn)在雙端表現(xiàn)不一致調(diào)試時(shí)要掃碼真機(jī)看效果別信模擬器。2.2 對話狀態(tài)機(jī)前端不只是貼大模型的返回對話層最容易犯的錯(cuò)誤是把前端當(dāng)成一個(gè)打印終端——大模型說什么頁面就渲染什么。真實(shí)場景里用戶隨時(shí)可能打斷、修改、確認(rèn)前端必須維護(hù)一個(gè)對話狀態(tài)機(jī)。我的前端核心狀態(tài)是這樣一個(gè)結(jié)構(gòu)type ChatState { phase: idle | collecting | planning | confirming | payment; currentIntent: createPlan | modifyBudget | changeCity | bookProduct | askWeather; draftPlan: DraftPlan | null; // 結(jié)構(gòu)化行程草稿 selectedPackage: ProductPackage | null; // 用戶待確認(rèn)的產(chǎn)品包 unconfirmedChanges: string[]; // 等待用戶確認(rèn)的修改點(diǎn) };這個(gè)狀態(tài)機(jī)的意義在于前端知道當(dāng)前對話處于什么階段就能決定消息列表里展示什么卡片。比如phase是planning時(shí)大模型正在調(diào)工具查酒店前端就顯示正在查詢合適房源...的等待動(dòng)畫phase進(jìn)入confirming時(shí)前端直接把行程卡片渲染成可編輯狀態(tài)用戶可以直接改日期、刪景點(diǎn)改完前端把變更塞回消息發(fā)送而不是讓用戶重新打字描述。2.3 流式輸出與體驗(yàn)細(xì)節(jié)做出來對話體驗(yàn)上我用WebSocket做全雙工通信服務(wù)端一邊調(diào)用大模型一邊通過ws推送中間結(jié)果。前端收到文本增量就做打字機(jī)效果收到Markdown片段就渲染日程卡片收到工具調(diào)用狀態(tài)就顯示進(jìn)度提示。這里有個(gè)經(jīng)驗(yàn)值得分享不要把大模型的原始輸出直接推給前端。旅游行程如果以Markdown文本渲染版式會(huì)很丑用戶也不容易點(diǎn)選。我的做法是Agent編排層在生成回復(fù)正文之外額外生成一份結(jié)構(gòu)化的tripPlanJSON前端檢測到消息里帶JSON字段就渲染成專門的行程卡片組件。卡片上的每個(gè)景點(diǎn)、酒店、航班都是可點(diǎn)的條目點(diǎn)擊后觸發(fā)進(jìn)一步對話。2.4 H5打包與分享的補(bǔ)充方案小程序端順手解決H5端我額外接了一層Web裝包。因?yàn)橛脩艨赡茉谂笥讶蛩阉饕胬稂c(diǎn)開一個(gè)旅游攻略鏈接這個(gè)鏈接必須能全屏聊天不需要下載App。H5頁面我套了個(gè)PWA殼離線時(shí)還能看歷史對話記錄這一招對提升回訪率很有幫助。3. 會(huì)話與記憶層不能只靠大模型上下文窗口很多人以為把全部對話歷史拼成大模型的上下文就行但旅游場景下的對話通常有幾十輪幾次修改后歷史文本就會(huì)突破上下文窗口限制。而且token成本也不是開玩笑每輪都塞全部歷史一次請求光輸入就要幾千token價(jià)格翻倍。3.1 雙層記憶對話摘要 結(jié)構(gòu)化草稿我的會(huì)話層采用了雙層記憶結(jié)構(gòu)。第一層是結(jié)構(gòu)化行程草稿。任何一輪對話結(jié)束后編排層都會(huì)提取用戶當(dāng)前確認(rèn)的目的地、日期、人數(shù)、預(yù)算、偏好、已排行程寫進(jìn)一個(gè)JSON對象存Rediskey是session:{userId}:draft。{ city: 成都, days: 4, travelers: 2, budget: 3000, preferences: [美食, 歷史文化], avoid: [網(wǎng)紅景點(diǎn)], timeline: [ { day: 1, spots: [武侯祠, 錦里], hotel: null }, { day: 2, spots: [都江堰], hotel: null } ], history: 用戶原計(jì)劃去都江堰因下雨改成熊貓基地 }第二層是對話摘要。每輪對話結(jié)束后服務(wù)端調(diào)用一次大模型把這一輪用戶新表達(dá)的關(guān)鍵信息概括進(jìn)摘要替代原始消息。比如用戶說預(yù)算從3000提到4500酒店可以住好一點(diǎn)摘要里就只記預(yù)算更新為4500偏好中高檔酒店。3.2 為什么要這么設(shè)計(jì)理由是控制模型幻覺。大模型讀純對話歷史時(shí)容易在用戶到底改了什么上產(chǎn)生混淆。比如用戶第一次說預(yù)算3000第二次說不超過4000第三次又說其實(shí)4500也行如果只順著上下文文字看模型可能不知道該聽哪句。而結(jié)構(gòu)化草稿是程序直接更新的模型每次只需要基于草稿狀態(tài)去補(bǔ)充新內(nèi)容準(zhǔn)確率高得多。結(jié)構(gòu)化草稿還有一個(gè)額外好處可以做并發(fā)控制。用戶邊聊邊改是常態(tài)比如同時(shí)在兩個(gè)設(shè)備登錄這種情況下Redis里的草稿有版本號(hào)服務(wù)端用樂觀鎖處理并發(fā)更新避免后一次修改覆蓋前一次關(guān)鍵信息。提示不要把對話原樣全部存進(jìn)Redis。Redis適合存短小精悍的結(jié)構(gòu)化數(shù)據(jù)長文本歷史歸檔到MongoDB或MySQL都行Redis里只保留最近5輪原始消息用于兜底生成摘要時(shí)參考。3.3 記憶層如何跟前端狀態(tài)機(jī)配合前端的狀態(tài)機(jī)和服務(wù)端的記憶層通過一個(gè)sessionSync接口同步。前端展示的draftPlan字段就是服務(wù)端記憶層Redis草稿的鏡像。用戶在前端改了一個(gè)景點(diǎn)前端發(fā)送一個(gè)updateDraft消息服務(wù)端校驗(yàn)后更新Redis再觸發(fā)新一輪Agent編排——這比讓用戶重新描述一遍需求體驗(yàn)強(qiáng)太多了。4. MCP服務(wù)層把天氣、酒店、門票變成Agent的眼睛和手MCPModel Context Protocol是這兒技術(shù)棧的樞紐。如果你還不了解MCP可以這樣理解MCP用一個(gè)標(biāo)準(zhǔn)協(xié)議讓大模型Agent能調(diào)用外部的工具/數(shù)據(jù)源。服務(wù)商把能力封裝成一個(gè)個(gè)工具注冊到MCP Server上Agent通過MCP客戶端發(fā)現(xiàn)這些工具并調(diào)用返回結(jié)構(gòu)化結(jié)果。相當(dāng)于給Agent配了一副能查實(shí)時(shí)數(shù)據(jù)的手套。4.1 為什么旅游場景特別適合MCP旅游Agent要接觸的數(shù)據(jù)源極其分散天氣接口、航班查詢、酒店庫存、門票余票、地圖POI、甚至當(dāng)?shù)鼗顒?dòng)。這些系統(tǒng)各有各的API、鑒權(quán)方式和返回格式。要是每一個(gè)都讓編排層寫死適配代碼維護(hù)量巨大而且每加一個(gè)供應(yīng)商就要改一次編排邏輯。MCP的思路是把數(shù)據(jù)源封裝成工具屏蔽細(xì)節(jié)。我這邊部署了五個(gè)MCP ServerMCP Server職責(zé)工具暴露weather-server接入聚合天氣數(shù)據(jù)get_forecast(city, date)poi-server景點(diǎn)、美食、文化活動(dòng)查詢search_poi(city, keyword, tags)hotel-server酒店搜索與比價(jià)search_hotels(city, date, priceRange)ticket-server景區(qū)門票余量與預(yù)訂check_availability(poiId, date)traffic-server城市間/市內(nèi)交通方案get_flight_route/get_train_schedule每個(gè)MCP Server都是獨(dú)立進(jìn)程內(nèi)部各自處理第三方API的鑒權(quán)、緩存、重試、限流。Agent編排層完全不需要關(guān)心天氣API的AK怎么配、酒店供應(yīng)商的字段怎么映射它只需要按MCP工具清單發(fā)起調(diào)用。4.2 工具定義與返回結(jié)構(gòu)設(shè)計(jì)MCP工具定義使用JSON Schema大模型會(huì)根據(jù)這個(gè)Schema決定要不要調(diào)用、傳什么參數(shù)。工具定義寫得清不清楚直接決定Agent能否正確使用。當(dāng)時(shí)我在poi-server里定義了一個(gè)搜索接口{ name: search_poi, description: 根據(jù)關(guān)鍵詞和城市搜索景點(diǎn)或美食列表適合在行程規(guī)劃中查找候選打卡點(diǎn), inputSchema: { type: object, properties: { city: { type: string, description: 城市名如成都 }, keyword: { type: string, description: 搜索關(guān)鍵詞如熊貓、火鍋 }, tags: { type: array, items: { type: string }, description: 篩選標(biāo)簽可選美食/歷史文化/自然風(fēng)光/親子/網(wǎng)紅 } }, required: [city] } }這里有個(gè)重要經(jīng)驗(yàn)description一定要寫清楚工具的用途和參數(shù)邊界。大模型會(huì)從description學(xué)習(xí)什么場景下該用這個(gè)工具。我之前在行程規(guī)劃場景里把ticket-server.check_availability描述寫成查詢門票余量Agent反而在用戶問幾點(diǎn)開放時(shí)也去查余量。后來我把description改成查詢指定景區(qū)在某日的門票余量和開放時(shí)間模型就再?zèng)]亂用。返回結(jié)構(gòu)上我統(tǒng)一收口成一個(gè)信封格式{ status: success, data: { ... }, // 業(yè)務(wù)數(shù)據(jù)字段全部snake_case meta: { source: amap, cached: true, fetchedAt: 2025-06-20T10:30:00Z } }數(shù)據(jù)字段名統(tǒng)一、嵌套層級清晰模型就不會(huì)在JSON路徑上糾結(jié)。日期格式我全局統(tǒng)一為YYYY-MM-DD別看這點(diǎn)小事模型對06/20/2025和2025-06-20的理解差異極大。4.3 不要把扣款放進(jìn)MCP工具我踩過最大的一個(gè)坑也是最想提醒你的絕對不要把支付扣款直接暴露成MCP工具給Agent調(diào)用。有人可能覺得Agent既然能查酒店那讓它直接訂個(gè)房不香嗎聽起來很美但后果很嚴(yán)重。大模型在工具選擇上本來就存在不確定性——用戶問預(yù)約明天早餐時(shí)Agent可能直接調(diào)用了hotel-server.book_room把明天的房費(fèi)都扣了用戶改了主意還要走退款流程中間一旦有幻覺運(yùn)營事故就來了。我的原則是MCP工具只做查詢和預(yù)占付款和正式下單必須回到業(yè)務(wù)側(cè)。比如ticket-server.check_availability可以返回還剩多少票但真正的下單動(dòng)作通過獨(dú)立的下單接口完成由后端代碼校驗(yàn)、生成訂單、喚起支付。Agent只能引導(dǎo)用戶到確認(rèn)支付頁面絕對碰不了支付執(zhí)行權(quán)。這是安全邊界問題也是合規(guī)底線。4.4 MCP與排查調(diào)試的心得MCP Server這里比較容易踩的坑還包括每個(gè)Server的鑒權(quán)密鑰要用獨(dú)立的Vault管理不要寫死在環(huán)境變量里Server之間要用統(tǒng)一的日志追蹤ID不然Agent調(diào)了三個(gè)工具出了問題你都不知道是哪個(gè)數(shù)據(jù)源超時(shí)。調(diào)試MCP調(diào)用鏈我的建議是給每個(gè)工具調(diào)用都打日志格式類似[工具調(diào)用] traceId9f82, toolsearch_hotels, args{city:成都,date:2025-07-01}, latency312ms, resultCodesuccess這樣一旦用戶反饋推薦不準(zhǔn)你就能回放Agent當(dāng)時(shí)看到了什么數(shù)據(jù)判斷是大模型推理問題還是數(shù)據(jù)源問題。5. 編排與決策層大模型不是主角工具調(diào)用順序才是很多人以為Agent的核心就是大模型其實(shí)編排層才是。編排層決定什么時(shí)候調(diào)什么工具、拿到結(jié)果后怎么取舍、怎么把數(shù)據(jù)變成最終答案。大模型更像是編排層里的一個(gè)推理組件而不是全部。5.1 工具編排的執(zhí)行流我的編排引擎是這么跑一趟完整規(guī)劃流程的意圖識(shí)別與必要槽位提取從用戶第一句話中提取destination、dateRange、budget、travelers等。沒提全就主動(dòng)問。天氣與時(shí)間窗口確認(rèn)先調(diào)weather-server.get_forecast確認(rèn)行程期間適不適合戶外如果下雨Agent會(huì)主動(dòng)建議調(diào)整。景點(diǎn)候選集生成調(diào)poi-server.search_poi獲取一批候選景點(diǎn)按照用戶標(biāo)簽過濾。行程草稿編排把候選景點(diǎn)按空間距離和時(shí)間窗口拼成日程。這一步不是簡單的列表堆疊要處理第二天去都江堰那第一天就得住在離高鐵站近的酒店這類空間推理。住宿與門票推薦調(diào)hotel-server和ticket-server在預(yù)算約束下給用戶推薦成組的產(chǎn)品包。用戶確認(rèn)用自然語言回復(fù)結(jié)構(gòu)化行程卡片展示等用戶拍板。這整個(gè)流程里大模型的角色是決策器。它每一步都把當(dāng)前草稿狀態(tài)、工具返回?cái)?shù)據(jù)、用戶偏好喂給模型讓模型決定下一步調(diào)哪個(gè)工具。我用的是類似ReActReason-Act的模式模型先寫出一段plan說明它現(xiàn)在要做什么然后調(diào)用工具拿到結(jié)果后決定是繼續(xù)調(diào)下一個(gè)工具還是產(chǎn)出回答用戶。5.2 延遲優(yōu)化并行調(diào)用代替串行旅行規(guī)劃的坑在于如果按上面的流程一步步來一次完整規(guī)劃可能要串行調(diào)用5-6個(gè)工具每次耗時(shí)2-5秒用戶等十秒以上才看到行程基本就要流失了。我的優(yōu)化策略是把互不依賴的查詢并行化。比如景點(diǎn)搜索、天氣查詢、酒店價(jià)格這三個(gè)互不依賴我用并發(fā)發(fā)送同一輪MCP請求。前端感知上就變成嗖一下三個(gè)進(jìn)度同時(shí)推進(jìn)總耗時(shí)從峰值20秒壓到6-7秒。但要注意串行規(guī)劃里有些依賴是硬性的。先有目的地和日期才能查景點(diǎn)先有景點(diǎn)候選和住宿范圍才能查酒店比價(jià)。所以我把這一輪并行拆分成了兩個(gè)階段中間加一個(gè)數(shù)據(jù)依賴檢查。5.3 模型選擇的取舍我的編排層用的是對話gpt-4o級別的大模型做復(fù)雜推理再加一個(gè)小模型做意圖分類。復(fù)雜推理模型負(fù)責(zé)多工具調(diào)度、行程優(yōu)化這類高難度任務(wù)便宜的小模型做初步識(shí)別能省一大筆成本。如果追求更低的token成本可以在工具調(diào)用結(jié)果的meta字段加一個(gè)壓縮標(biāo)記讓模型只接收摘要而不是完整JSON。比如酒店搜索結(jié)果有5000條Agent只需要前20條做推薦那就讓編排層截?cái)嗪髠鹘o模型反正大模型也讀不完。6. 支付鏈路從行程確認(rèn)到銀行回調(diào)中間全是細(xì)節(jié)到了支付環(huán)節(jié)很多人覺得接個(gè)支付SDK就行實(shí)際上支付是這個(gè)項(xiàng)目里工程復(fù)雜度最高的部分之一。這里我從技術(shù)角度完整過一遍。6.1 從行程草稿到訂單的完整時(shí)序用戶在前端行程卡片上點(diǎn)確認(rèn)預(yù)訂之后鏈路是這樣的前端把行程草稿里的productPackages酒店、門票組合和用戶信息提交到后端/api/order/create。后端先生成業(yè)務(wù)訂單狀態(tài)INIT把訂單與session關(guān)聯(lián)防止同一個(gè)用戶同時(shí)支付兩個(gè)版本行程。后端再調(diào)用支付渠道微信H5支付/支付寶手機(jī)網(wǎng)站支付創(chuàng)建預(yù)支付單拿到paymentParams。前端用拿到的時(shí)間戳和簽名參數(shù)通過SDK喚起收銀臺(tái)頁面。微信H5支付的調(diào)用核心代碼大致是// 服務(wù)端先拿到支付參數(shù) const payParams { appId: wx..., timeStamp: 1710000000, nonceStr: random, package: prepay_idwx..., signType: RSA, paySign: ... }; // H5端跳轉(zhuǎn)微信收銀臺(tái) window.location.href https://wx.tenpay.com/cgi-bin/mmpayweb/bin/checkoutpage.js;用H5跳轉(zhuǎn)而不是小程序支付是因?yàn)檫@條鏈路的用戶可能在瀏覽器、朋友圈、App內(nèi)等環(huán)境里打開行程鏈接微信小程序支付空間受限所以H5的兼容性更好。缺點(diǎn)是微信H5支付會(huì)有一層中間頁確認(rèn)增加了一步流失但這是渠道規(guī)則沒法繞。6.2 回調(diào)處理驗(yàn)簽別省冪等必須做支付成功之后微信/支付寶會(huì)異步回調(diào)你的服務(wù)器。這一步最容易出事?；卣{(diào)處理我當(dāng)時(shí)落地了三條鐵律第一驗(yàn)簽必須在業(yè)務(wù)邏輯之前。微信的簽名算法是MD5/RSA用平臺(tái)公鑰驗(yàn)簽別只檢查回調(diào)參數(shù)里的return_code為SUCCESS就處理業(yè)務(wù)。真實(shí)攻擊里偽造回調(diào)是常見手法只驗(yàn)return_code等于沒設(shè)防。第二冪等處理。同一個(gè)訂單可能因?yàn)榫W(wǎng)絡(luò)抖動(dòng)、渠道重試收到多次回調(diào)。我處理時(shí)先檢查訂單狀態(tài)如果已經(jīng)是PAID直接返回success不再重復(fù)出票。用數(shù)據(jù)庫唯一索引分布式鎖雙保險(xiǎn)。第三先更新余額庫存再通知業(yè)務(wù)側(cè)?；卣{(diào)里一般是先改訂單狀態(tài)為PAID再觸發(fā)下游動(dòng)作發(fā)放門票憑證、扣減庫存、給用戶發(fā)確認(rèn)消息。這些動(dòng)作必須做可靠的異步隊(duì)列不能硬塞在回調(diào)線程里。一旦隊(duì)列處理失敗還需要路由進(jìn)死信隊(duì)列人工介入。偽代碼大致是async function handlePaymentCallback(rawBody: string): Promisestring { // 1. 驗(yàn)簽渠道 SDK 內(nèi)置方法 const verified payChannel.verifySignature(rawBody); if (!verified) return fail; // 2. 解析回調(diào)數(shù)據(jù) const data parseCallback(rawBody); const orderId data.out_trade_no; const tradeStatus data.trade_state; // 3. 冪等檢查訂單已處理則直接返回成功 const exists await orderRepo.get(orderId); if (exists.status OrderStatus.PAID) { return success; } if (exists.status ! OrderStatus.INIT) { // 訂單已關(guān)閉或已退款這里要告警 logger.warn(支付回調(diào)狀態(tài)異常 orderId${orderId}, status${exists.status}); return success; } // 4. 冪等鎖用 Redis SET NX 超時(shí) const lockAcquired await redis.set(order:${orderId}:lock, 1, NX, EX, 5); if (!lockAcquired) return success; // 5. 更新訂單為已支付、出票等 await orderRepo.markPaid(orderId); await inventoryService.releaseStock(orderId); // 真正出票/占位 await notifyService.sendOrderConfirmed(orderId); return success; }6.3 掉單問題主動(dòng)查單是必須的異步回調(diào)畢竟不可靠掉單情況必然存在。我的策略是定時(shí)查單任務(wù)每5分鐘掃描一次所有狀態(tài)為INIT且創(chuàng)建時(shí)間超過15分鐘的訂單主動(dòng)向支付渠道發(fā)起/api/pay/query請求比對渠道側(cè)狀態(tài)。如果渠道側(cè)顯示已支付但本地訂單還是INIT就走一次補(bǔ)償邏輯更新本地訂單狀態(tài)、出票。如果渠道側(cè)顯示未支付就保持INIT用戶重新下單時(shí)還能繼續(xù)支付。這個(gè)定時(shí)任務(wù)我用的是可靠消息表狀態(tài)都落庫重啟后能續(xù)跑避免JVM內(nèi)存態(tài)丟失訂單。6.4 退款與對賬給運(yùn)營留好工具旅游產(chǎn)品經(jīng)常涉及改期和退款。我的原則是退款不直接用Agent自動(dòng)處理而是走人工審核系統(tǒng)自動(dòng)退款兩步用戶發(fā)起退款申請客服在后臺(tái)審核通過調(diào)用退款接口原路退回。因?yàn)槁糜萎a(chǎn)品的退款涉不涉及到已經(jīng)核銷的門票、酒店違約金自動(dòng)化判斷容易出錯(cuò)。對賬層面每天凌晨跑一次T1賬單比對把支付渠道賬單和本地訂單逐筆核對輸出差異表。這個(gè)表運(yùn)營每天早上必看比私下查數(shù)據(jù)庫靠譜多了。7. 性能、并發(fā)與安全旅游大促瞬間涌進(jìn)來怎么辦最后一部分重點(diǎn)說一下這個(gè)Agent在真實(shí)流量壓力下會(huì)遇到的問題。旅游場景有明顯的波峰波谷比如節(jié)假日前一周行程咨詢量可能平時(shí)十倍。大模型接口本身響應(yīng)慢、成本高編排層又依賴多個(gè)外部服務(wù)這是性能設(shè)計(jì)的核心矛盾。7.1 多租戶鑒權(quán)與限流Agent如果對外開放多租戶是標(biāo)配。每個(gè)接入方B端旅行社、C端用戶在網(wǎng)關(guān)層做獨(dú)立的API Key或OAuth token鑒權(quán)。MCP Server那層同樣要做租戶隔離不能讓一個(gè)租戶的并發(fā)查詢把另一個(gè)租戶的數(shù)據(jù)也拖垮。限流這塊我用的滑動(dòng)窗口令牌桶混合方案。對話接口限流按用戶維度比如每用戶每分鐘最多50條消息工具調(diào)用按租戶維度限流比如查酒店QPS上限100。超出直接返回請稍后再試。7.2 語義緩存省大模型token的利器很多人忽視緩存我觀察下來旅游對話里大量問題是高度相似的。比如成都四天怎么玩成都三天怎么玩成都周邊哪里好本質(zhì)上都是觸發(fā)同一套POI搜索流程。對這種問題我用語義緩存對用戶的輸入向量化后相似度匹配命中緩存直接把上次的規(guī)劃結(jié)果返回不再調(diào)用大模型和工具服務(wù)。緩存key是{userId的粒度或者全局}:{embedding}TTL設(shè)成1小時(shí)。這個(gè)方案把大模型調(diào)用量降了40%左右token成本節(jié)省非?？捎^。代價(jià)是緩存可能返回稍過時(shí)的信息比如門票價(jià)格變了所以價(jià)格類數(shù)據(jù)我不緩存太久只有POI推薦和行程結(jié)構(gòu)可以走緩存。7.3 大模型接口并發(fā)控制與容錯(cuò)一次完整規(guī)劃可能要調(diào)用大模型三次以上意圖識(shí)別、工具選擇、最終回答每次都是毫秒級……不開玩笑是秒級。如果同時(shí)有20個(gè)用戶在上頭規(guī)劃后端對上游大模型API的并發(fā)一下就頂爆了。我的做法是做了一個(gè)大模型網(wǎng)關(guān)統(tǒng)一管理供應(yīng)商API密鑰、并發(fā)池、重試策略。每個(gè)會(huì)話的編排請求進(jìn)入一個(gè)隊(duì)列按用戶優(yōu)先級調(diào)度。同時(shí)把大模型的溫度調(diào)低0.2左右避免同樣的需求每次都給出不同的規(guī)劃答案提高確定性和可復(fù)現(xiàn)性。7.4 基礎(chǔ)設(shè)施層面的安全安全并不僅僅指支付回調(diào)驗(yàn)簽。還有幾個(gè)日常容易漏的點(diǎn)會(huì)話數(shù)據(jù)脫敏用戶聊天的手機(jī)號(hào)、身份證信息要脫敏后才能進(jìn)大模型提示詞不能明文發(fā)給模型。MCP工具返回的數(shù)據(jù)不能盲信第三方數(shù)據(jù)源返回的POI可能包含廣告推廣要用審核層過濾掉違規(guī)或低質(zhì)內(nèi)容避免Agent推薦出問題。限流和熔斷如果某個(gè)MCP Server持續(xù)超時(shí)比如酒店供應(yīng)商半夜停機(jī)維護(hù)編排層要能快速熔斷跳過該工具降級回答而不是死等拖垮整個(gè)Agent。8. 踩坑清單把這些坑提前填平能省一周時(shí)間最后把我實(shí)際遇到的最有價(jià)值的一批坑和對應(yīng)解法匯總成清單供你直接參考。1. MCP工具Schema描述不準(zhǔn)確導(dǎo)致的連鎖問題癥狀A(yù)gent在查詢天氣時(shí)調(diào)用查門票在推薦美食時(shí)調(diào)用查路線。根因工具工具描述粒度太大參數(shù)邊界沒寫清。解法把每個(gè)tool的description寫成一個(gè)典型使用場景加上參數(shù)約束說明比如價(jià)格單位、日期格式。2. 前端流式渲染把Markdown表格劈了癥狀用戶看到半個(gè)表格在動(dòng)態(tài)刷新。根因SSE消息按token推流前端把不完整的Markdown直接渲染。解法前端先把完整消息暫存只在句子/段落級別斷點(diǎn)觸發(fā)渲染表格結(jié)構(gòu)完整后再一次性顯示。3. 訂單狀態(tài)在支付回調(diào)里被并發(fā)覆蓋癥狀支付成功后訂單變成已關(guān)閉用戶錢付了東西沒落地。根因沒有冪等鎖兩個(gè)線程同時(shí)魔法更新同一個(gè)訂單狀態(tài)。解法Redis鎖數(shù)據(jù)庫狀態(tài)CAS更新。4. 大模型上下文注入了緩存舊數(shù)據(jù)癥狀用戶問今天成都幾點(diǎn)日出Agent回答的是緩存里昨天的結(jié)果。根因查詢結(jié)果meta里的fetchedAt沒傳給模型模型不知道數(shù)據(jù)新舊。解法編排層在給模型的數(shù)據(jù)前顯式標(biāo)注數(shù)據(jù)時(shí)間并要求模型如果數(shù)據(jù)時(shí)間超過24小時(shí)請聲明可能不準(zhǔn)確。5. 會(huì)話層草稿和聊天記錄過期策略不一致癥狀用戶隔三天回來App發(fā)現(xiàn)行程卡還在但對話記錄全沒了。根因草稿存Redis沒設(shè)TTL聊天記錄存MySQL按30天清理。解法統(tǒng)一TTL策略草稿和記錄過期時(shí)間對齊同時(shí)草稿表留一個(gè)用戶主動(dòng)保存入口。6. 旅游旺季支付回調(diào)延遲特別高癥狀用戶付完錢15分鐘沒收到確認(rèn)消息焦躁投訴。根因渠道回調(diào)本來就有分鐘級延遲遇到高峰期更慢。解法除了回調(diào)主動(dòng)加一條前端輪詢鏈路用戶支付頁返回App后前端每3秒查一次訂單狀態(tài)查到已支付就立刻出票提醒不等回調(diào)。7. 并發(fā)規(guī)劃時(shí)大模型API報(bào)429癥狀白天正常晚上一過8點(diǎn)報(bào)錯(cuò)量飆升。根因晚高峰對話量大但大模型API的限流配額是按QPS算的沒預(yù)留緩沖。解法大模型網(wǎng)關(guān)加平滑限流排隊(duì)高峰期自動(dòng)降級為異步回復(fù)行程正在排隊(duì)生成稍后查看。做完整套技術(shù)棧之后我最大的體會(huì)是AI旅游Agent不是大模型API的組合它是一個(gè)完整的軟件工程系統(tǒng)。前端要當(dāng)好狀態(tài)機(jī)管家編排層要當(dāng)好工具調(diào)度員MCP是數(shù)據(jù)源的標(biāo)準(zhǔn)插座支付則是整個(gè)體驗(yàn)的最后一道閘門。每個(gè)環(huán)節(jié)單獨(dú)看都能找到成熟方案難的是它們之間的銜接縫隙——那些傳感器失靈、緩存過期、回調(diào)重復(fù)、模型幻覺的時(shí)刻才是最考驗(yàn)工程能力的地方。如果你正準(zhǔn)備上手類似項(xiàng)目建議先把支付和會(huì)話記憶這兩塊地基打牢再談AI功能。畢竟用戶不會(huì)因?yàn)槟愕腁gent能畫漂亮行程單就不罵你但一定會(huì)因?yàn)橹Ц兑恢辈换卣{(diào)而卸載你。