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