1. 先拆清三个容易被低估的难点再谈技术栈先说结论一个AI旅游Agent表面上是一套用户聊天 → 行程规划 → 下单支付的流程但你真上手做就会发现真正决定项目成败的从来不是大模型API本身而是围绕它铺开的前端交互、上下文管理、工具调用协议和支付回调。很多人以为这就是给GPT套个壳加个天气查询接口再把携程的单子接进来实际上这套东西的复杂度远超想象。我这个项目从零搭建跑完整个链路之后最大的感受是技术选型谁都能抄难的是把对话和业务这两套逻辑真正焊在一起。先把这个Agent要解决的场景说清楚。我做的是一款给自助游用户用的旅游规划Agent用户通过微信小程序或H5页面跟它对话比如帮我规划一份成都四天三晚的行程预算3000不想去网红景点Agent需要自己去查天气、调景区信息、比价酒店最终生成一份可确认的行程单用户点确认后直接走微信/支付宝的H5支付完成预订。整个链路涉及前端、网关、编排引擎、MCP工具服务、订单系统和支付渠道缺一不可。拆解这个技术栈之前先讲三个我踩完坑才明白的难点这决定了后面的所有设计难点一是上下文漂移问题。旅游规划绝不是一次问答就能结束的。用户今天说定了去成都明天可能改口说成都太热了换昆明吧甚至只是改一个预算数字。如果Agent上下文里存的是成都四天三晚改预算后生成的行程可能还带着成都的旧信息。这要求系统必须把对话历史和结构化行程草稿分开管理而不是一股脑塞给大模型。难点二是工具返回的数据结构统一。MCP协议给了Agent调用工具的标准通道但是酒店供应商返回的字段、天气服务的字段、门票系统的字段格式千差万别。Agent也就是大模型非常敏感返回体一旦出现歧义它就会开始瞎猜字段含义。我见过Agent因为一个日期格式不一致把今天理解成明天最后给出错误建议的例子。难点三是支付环节的最后一公里。聊天界面里一切都很美好但要用户真金白银付钱的那一刻体验稍微卡顿流失率就直线上升。而且H5支付的回调机制、并发幂等、掉单处理完全是另一套工程体系跟AI可没什么关系却又是这个产品能活下来的基础。下面我就按实际系统的调用顺序从前端开始一层一层拆解每个环节的技术选择和落地细节。2. 前端对话层为什么我用uniapp而不是原生小程序前端对话层是这个Agent的门面用户所有感知都发生在这里。我最初评估过三种方案微信原生小程序、uniapp跨端框架、纯H5。最终选了uniapp核心原因是一套代码同时覆盖小程序和H5。2.1 选型逻辑跨端覆盖背后的生意逻辑旅游场景的流量分散在微信、支付宝、抖音等多个平台用户分享行程的时候打开链接可能是H5也可能是小程序。如果每个端都写一套原生代码维护成本翻倍而且AI对话界面这种复杂交互双端同步改版非常痛苦。uniapp的好处在于编译期把同一套Vue代码转成各端产物。我的实际经验是微信小程序端走原生渲染H5端走标准浏览器组件用uni-ui的弹层、输入框、按钮对话消息列表自己封装。不需要花里胡哨的图表和动画核心交互就是消息气泡、键盘输入、流式文本渲染、行程卡片展示。唯一的坑是小程序的WebView与H5的DOM差异。比如长按复制、输入框自动滚动、键盘弹起遮挡行程卡片这些细节点在双端表现不一致调试时要扫码真机看效果别信模拟器。2.2 对话状态机前端不只是贴大模型的返回对话层最容易犯的错误是把前端当成一个打印终端——大模型说什么页面就渲染什么。真实场景里用户随时可能打断、修改、确认前端必须维护一个对话状态机。我的前端核心状态是这样一个结构type ChatState { phase: idle | collecting | planning | confirming | payment; currentIntent: createPlan | modifyBudget | changeCity | bookProduct | askWeather; draftPlan: DraftPlan | null; // 结构化行程草稿 selectedPackage: ProductPackage | null; // 用户待确认的产品包 unconfirmedChanges: string[]; // 等待用户确认的修改点 };这个状态机的意义在于前端知道当前对话处于什么阶段就能决定消息列表里展示什么卡片。比如phase是planning时大模型正在调工具查酒店前端就显示正在查询合适房源...的等待动画phase进入confirming时前端直接把行程卡片渲染成可编辑状态用户可以直接改日期、删景点改完前端把变更塞回消息发送而不是让用户重新打字描述。2.3 流式输出与体验细节做出来对话体验上我用WebSocket做全双工通信服务端一边调用大模型一边通过ws推送中间结果。前端收到文本增量就做打字机效果收到Markdown片段就渲染日程卡片收到工具调用状态就显示进度提示。这里有个经验值得分享不要把大模型的原始输出直接推给前端。旅游行程如果以Markdown文本渲染版式会很丑用户也不容易点选。我的做法是Agent编排层在生成回复正文之外额外生成一份结构化的tripPlanJSON前端检测到消息里带JSON字段就渲染成专门的行程卡片组件。卡片上的每个景点、酒店、航班都是可点的条目点击后触发进一步对话。2.4 H5打包与分享的补充方案小程序端顺手解决H5端我额外接了一层Web装包。因为用户可能在朋友圈或搜索引擎里点开一个旅游攻略链接这个链接必须能全屏聊天不需要下载App。H5页面我套了个PWA壳离线时还能看历史对话记录这一招对提升回访率很有帮助。3. 会话与记忆层不能只靠大模型上下文窗口很多人以为把全部对话历史拼成大模型的上下文就行但旅游场景下的对话通常有几十轮几次修改后历史文本就会突破上下文窗口限制。而且token成本也不是开玩笑每轮都塞全部历史一次请求光输入就要几千token价格翻倍。3.1 双层记忆对话摘要 结构化草稿我的会话层采用了双层记忆结构。第一层是结构化行程草稿。任何一轮对话结束后编排层都会提取用户当前确认的目的地、日期、人数、预算、偏好、已排行程写进一个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也行如果只顺着上下文文字看模型可能不知道该听哪句。而结构化草稿是程序直接更新的模型每次只需要基于草稿状态去补充新内容准确率高得多。结构化草稿还有一个额外好处可以做并发控制。用户边聊边改是常态比如同时在两个设备登录这种情况下Redis里的草稿有版本号服务端用乐观锁处理并发更新避免后一次修改覆盖前一次关键信息。提示不要把对话原样全部存进Redis。Redis适合存短小精悍的结构化数据长文本历史归档到MongoDB或MySQL都行Redis里只保留最近5轮原始消息用于兜底生成摘要时参考。3.3 记忆层如何跟前端状态机配合前端的状态机和服务端的记忆层通过一个sessionSync接口同步。前端展示的draftPlan字段就是服务端记忆层Redis草稿的镜像。用户在前端改了一个景点前端发送一个updateDraft消息服务端校验后更新Redis再触发新一轮Agent编排——这比让用户重新描述一遍需求体验强太多了。4. MCP服务层把天气、酒店、门票变成Agent的眼睛和手MCPModel Context Protocol是这儿技术栈的枢纽。如果你还不了解MCP可以这样理解MCP用一个标准协议让大模型Agent能调用外部的工具/数据源。服务商把能力封装成一个个工具注册到MCP Server上Agent通过MCP客户端发现这些工具并调用返回结构化结果。相当于给Agent配了一副能查实时数据的手套。4.1 为什么旅游场景特别适合MCP旅游Agent要接触的数据源极其分散天气接口、航班查询、酒店库存、门票余票、地图POI、甚至当地活动。这些系统各有各的API、鉴权方式和返回格式。要是每一个都让编排层写死适配代码维护量巨大而且每加一个供应商就要改一次编排逻辑。MCP的思路是把数据源封装成工具屏蔽细节。我这边部署了五个MCP ServerMCP Server职责工具暴露weather-server接入聚合天气数据get_forecast(city, date)poi-server景点、美食、文化活动查询search_poi(city, keyword, tags)hotel-server酒店搜索与比价search_hotels(city, date, priceRange)ticket-server景区门票余量与预订check_availability(poiId, date)traffic-server城市间/市内交通方案get_flight_route/get_train_schedule每个MCP Server都是独立进程内部各自处理第三方API的鉴权、缓存、重试、限流。Agent编排层完全不需要关心天气API的AK怎么配、酒店供应商的字段怎么映射它只需要按MCP工具清单发起调用。4.2 工具定义与返回结构设计MCP工具定义使用JSON Schema大模型会根据这个Schema决定要不要调用、传什么参数。工具定义写得清不清楚直接决定Agent能否正确使用。当时我在poi-server里定义了一个搜索接口{ name: search_poi, description: 根据关键词和城市搜索景点或美食列表适合在行程规划中查找候选打卡点, inputSchema: { type: object, properties: { city: { type: string, description: 城市名如成都 }, keyword: { type: string, description: 搜索关键词如熊猫、火锅 }, tags: { type: array, items: { type: string }, description: 筛选标签可选美食/历史文化/自然风光/亲子/网红 } }, required: [city] } }这里有个重要经验description一定要写清楚工具的用途和参数边界。大模型会从description学习什么场景下该用这个工具。我之前在行程规划场景里把ticket-server.check_availability描述写成查询门票余量Agent反而在用户问几点开放时也去查余量。后来我把description改成查询指定景区在某日的门票余量和开放时间模型就再没乱用。返回结构上我统一收口成一个信封格式{ status: success, data: { ... }, // 业务数据字段全部snake_case meta: { source: amap, cached: true, fetchedAt: 2025-06-20T10:30:00Z } }数据字段名统一、嵌套层级清晰模型就不会在JSON路径上纠结。日期格式我全局统一为YYYY-MM-DD别看这点小事模型对06/20/2025和2025-06-20的理解差异极大。4.3 不要把扣款放进MCP工具我踩过最大的一个坑也是最想提醒你的绝对不要把支付扣款直接暴露成MCP工具给Agent调用。有人可能觉得Agent既然能查酒店那让它直接订个房不香吗听起来很美但后果很严重。大模型在工具选择上本来就存在不确定性——用户问预约明天早餐时Agent可能直接调用了hotel-server.book_room把明天的房费都扣了用户改了主意还要走退款流程中间一旦有幻觉运营事故就来了。我的原则是MCP工具只做查询和预占付款和正式下单必须回到业务侧。比如ticket-server.check_availability可以返回还剩多少票但真正的下单动作通过独立的下单接口完成由后端代码校验、生成订单、唤起支付。Agent只能引导用户到确认支付页面绝对碰不了支付执行权。这是安全边界问题也是合规底线。4.4 MCP与排查调试的心得MCP Server这里比较容易踩的坑还包括每个Server的鉴权密钥要用独立的Vault管理不要写死在环境变量里Server之间要用统一的日志追踪ID不然Agent调了三个工具出了问题你都不知道是哪个数据源超时。调试MCP调用链我的建议是给每个工具调用都打日志格式类似[工具调用] traceId9f82, toolsearch_hotels, args{city:成都,date:2025-07-01}, latency312ms, resultCodesuccess这样一旦用户反馈推荐不准你就能回放Agent当时看到了什么数据判断是大模型推理问题还是数据源问题。5. 编排与决策层大模型不是主角工具调用顺序才是很多人以为Agent的核心就是大模型其实编排层才是。编排层决定什么时候调什么工具、拿到结果后怎么取舍、怎么把数据变成最终答案。大模型更像是编排层里的一个推理组件而不是全部。5.1 工具编排的执行流我的编排引擎是这么跑一趟完整规划流程的意图识别与必要槽位提取从用户第一句话中提取destination、dateRange、budget、travelers等。没提全就主动问。天气与时间窗口确认先调weather-server.get_forecast确认行程期间适不适合户外如果下雨Agent会主动建议调整。景点候选集生成调poi-server.search_poi获取一批候选景点按照用户标签过滤。行程草稿编排把候选景点按空间距离和时间窗口拼成日程。这一步不是简单的列表堆叠要处理第二天去都江堰那第一天就得住在离高铁站近的酒店这类空间推理。住宿与门票推荐调hotel-server和ticket-server在预算约束下给用户推荐成组的产品包。用户确认用自然语言回复结构化行程卡片展示等用户拍板。这整个流程里大模型的角色是决策器。它每一步都把当前草稿状态、工具返回数据、用户偏好喂给模型让模型决定下一步调哪个工具。我用的是类似ReActReason-Act的模式模型先写出一段plan说明它现在要做什么然后调用工具拿到结果后决定是继续调下一个工具还是产出回答用户。5.2 延迟优化并行调用代替串行旅行规划的坑在于如果按上面的流程一步步来一次完整规划可能要串行调用5-6个工具每次耗时2-5秒用户等十秒以上才看到行程基本就要流失了。我的优化策略是把互不依赖的查询并行化。比如景点搜索、天气查询、酒店价格这三个互不依赖我用并发发送同一轮MCP请求。前端感知上就变成嗖一下三个进度同时推进总耗时从峰值20秒压到6-7秒。但要注意串行规划里有些依赖是硬性的。先有目的地和日期才能查景点先有景点候选和住宿范围才能查酒店比价。所以我把这一轮并行拆分成了两个阶段中间加一个数据依赖检查。5.3 模型选择的取舍我的编排层用的是对话gpt-4o级别的大模型做复杂推理再加一个小模型做意图分类。复杂推理模型负责多工具调度、行程优化这类高难度任务便宜的小模型做初步识别能省一大笔成本。如果追求更低的token成本可以在工具调用结果的meta字段加一个压缩标记让模型只接收摘要而不是完整JSON。比如酒店搜索结果有5000条Agent只需要前20条做推荐那就让编排层截断后传给模型反正大模型也读不完。6. 支付链路从行程确认到银行回调中间全是细节到了支付环节很多人觉得接个支付SDK就行实际上支付是这个项目里工程复杂度最高的部分之一。这里我从技术角度完整过一遍。6.1 从行程草稿到订单的完整时序用户在前端行程卡片上点确认预订之后链路是这样的前端把行程草稿里的productPackages酒店、门票组合和用户信息提交到后端/api/order/create。后端先生成业务订单状态INIT把订单与session关联防止同一个用户同时支付两个版本行程。后端再调用支付渠道微信H5支付/支付宝手机网站支付创建预支付单拿到paymentParams。前端用拿到的时间戳和签名参数通过SDK唤起收银台页面。微信H5支付的调用核心代码大致是// 服务端先拿到支付参数 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内等环境里打开行程链接微信小程序支付空间受限所以H5的兼容性更好。缺点是微信H5支付会有一层中间页确认增加了一步流失但这是渠道规则没法绕。6.2 回调处理验签别省幂等必须做支付成功之后微信/支付宝会异步回调你的服务器。这一步最容易出事。回调处理我当时落地了三条铁律第一验签必须在业务逻辑之前。微信的签名算法是MD5/RSA用平台公钥验签别只检查回调参数里的return_code为SUCCESS就处理业务。真实攻击里伪造回调是常见手法只验return_code等于没设防。第二幂等处理。同一个订单可能因为网络抖动、渠道重试收到多次回调。我处理时先检查订单状态如果已经是PAID直接返回success不再重复出票。用数据库唯一索引分布式锁双保险。第三先更新余额库存再通知业务侧。回调里一般是先改订单状态为PAID再触发下游动作发放门票凭证、扣减库存、给用户发确认消息。这些动作必须做可靠的异步队列不能硬塞在回调线程里。一旦队列处理失败还需要路由进死信队列人工介入。伪代码大致是async function handlePaymentCallback(rawBody: string): Promisestring { // 1. 验签渠道 SDK 内置方法 const verified payChannel.verifySignature(rawBody); if (!verified) return fail; // 2. 解析回调数据 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(支付回调状态异常 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分钟扫描一次所有状态为INIT且创建时间超过15分钟的订单主动向支付渠道发起/api/pay/query请求比对渠道侧状态。如果渠道侧显示已支付但本地订单还是INIT就走一次补偿逻辑更新本地订单状态、出票。如果渠道侧显示未支付就保持INIT用户重新下单时还能继续支付。这个定时任务我用的是可靠消息表状态都落库重启后能续跑避免JVM内存态丢失订单。6.4 退款与对账给运营留好工具旅游产品经常涉及改期和退款。我的原则是退款不直接用Agent自动处理而是走人工审核系统自动退款两步用户发起退款申请客服在后台审核通过调用退款接口原路退回。因为旅游产品的退款涉不涉及到已经核销的门票、酒店违约金自动化判断容易出错。对账层面每天凌晨跑一次T1账单比对把支付渠道账单和本地订单逐笔核对输出差异表。这个表运营每天早上必看比私下查数据库靠谱多了。7. 性能、并发与安全旅游大促瞬间涌进来怎么办最后一部分重点说一下这个Agent在真实流量压力下会遇到的问题。旅游场景有明显的波峰波谷比如节假日前一周行程咨询量可能平时十倍。大模型接口本身响应慢、成本高编排层又依赖多个外部服务这是性能设计的核心矛盾。7.1 多租户鉴权与限流Agent如果对外开放多租户是标配。每个接入方B端旅行社、C端用户在网关层做独立的API Key或OAuth token鉴权。MCP Server那层同样要做租户隔离不能让一个租户的并发查询把另一个租户的数据也拖垮。限流这块我用的滑动窗口令牌桶混合方案。对话接口限流按用户维度比如每用户每分钟最多50条消息工具调用按租户维度限流比如查酒店QPS上限100。超出直接返回请稍后再试。7.2 语义缓存省大模型token的利器很多人忽视缓存我观察下来旅游对话里大量问题是高度相似的。比如成都四天怎么玩成都三天怎么玩成都周边哪里好本质上都是触发同一套POI搜索流程。对这种问题我用语义缓存对用户的输入向量化后相似度匹配命中缓存直接把上次的规划结果返回不再调用大模型和工具服务。缓存key是{userId的粒度或者全局}:{embedding}TTL设成1小时。这个方案把大模型调用量降了40%左右token成本节省非常可观。代价是缓存可能返回稍过时的信息比如门票价格变了所以价格类数据我不缓存太久只有POI推荐和行程结构可以走缓存。7.3 大模型接口并发控制与容错一次完整规划可能要调用大模型三次以上意图识别、工具选择、最终回答每次都是毫秒级……不开玩笑是秒级。如果同时有20个用户在上头规划后端对上游大模型API的并发一下就顶爆了。我的做法是做了一个大模型网关统一管理供应商API密钥、并发池、重试策略。每个会话的编排请求进入一个队列按用户优先级调度。同时把大模型的温度调低0.2左右避免同样的需求每次都给出不同的规划答案提高确定性和可复现性。7.4 基础设施层面的安全安全并不仅仅指支付回调验签。还有几个日常容易漏的点会话数据脱敏用户聊天的手机号、身份证信息要脱敏后才能进大模型提示词不能明文发给模型。MCP工具返回的数据不能盲信第三方数据源返回的POI可能包含广告推广要用审核层过滤掉违规或低质内容避免Agent推荐出问题。限流和熔断如果某个MCP Server持续超时比如酒店供应商半夜停机维护编排层要能快速熔断跳过该工具降级回答而不是死等拖垮整个Agent。8. 踩坑清单把这些坑提前填平能省一周时间最后把我实际遇到的最有价值的一批坑和对应解法汇总成清单供你直接参考。1. MCP工具Schema描述不准确导致的连锁问题症状Agent在查询天气时调用查门票在推荐美食时调用查路线。根因工具工具描述粒度太大参数边界没写清。解法把每个tool的description写成一个典型使用场景加上参数约束说明比如价格单位、日期格式。2. 前端流式渲染把Markdown表格劈了症状用户看到半个表格在动态刷新。根因SSE消息按token推流前端把不完整的Markdown直接渲染。解法前端先把完整消息暂存只在句子/段落级别断点触发渲染表格结构完整后再一次性显示。3. 订单状态在支付回调里被并发覆盖症状支付成功后订单变成已关闭用户钱付了东西没落地。根因没有幂等锁两个线程同时魔法更新同一个订单状态。解法Redis锁数据库状态CAS更新。4. 大模型上下文注入了缓存旧数据症状用户问今天成都几点日出Agent回答的是缓存里昨天的结果。根因查询结果meta里的fetchedAt没传给模型模型不知道数据新旧。解法编排层在给模型的数据前显式标注数据时间并要求模型如果数据时间超过24小时请声明可能不准确。5. 会话层草稿和聊天记录过期策略不一致症状用户隔三天回来App发现行程卡还在但对话记录全没了。根因草稿存Redis没设TTL聊天记录存MySQL按30天清理。解法统一TTL策略草稿和记录过期时间对齐同时草稿表留一个用户主动保存入口。6. 旅游旺季支付回调延迟特别高症状用户付完钱15分钟没收到确认消息焦躁投诉。根因渠道回调本来就有分钟级延迟遇到高峰期更慢。解法除了回调主动加一条前端轮询链路用户支付页返回App后前端每3秒查一次订单状态查到已支付就立刻出票提醒不等回调。7. 并发规划时大模型API报429症状白天正常晚上一过8点报错量飙升。根因晚高峰对话量大但大模型API的限流配额是按QPS算的没预留缓冲。解法大模型网关加平滑限流排队高峰期自动降级为异步回复行程正在排队生成稍后查看。做完整套技术栈之后我最大的体会是AI旅游Agent不是大模型API的组合它是一个完整的软件工程系统。前端要当好状态机管家编排层要当好工具调度员MCP是数据源的标准插座支付则是整个体验的最后一道闸门。每个环节单独看都能找到成熟方案难的是它们之间的衔接缝隙——那些传感器失灵、缓存过期、回调重复、模型幻觉的时刻才是最考验工程能力的地方。如果你正准备上手类似项目建议先把支付和会话记忆这两块地基打牢再谈AI功能。毕竟用户不会因为你的Agent能画漂亮行程单就不骂你但一定会因为支付一直不回调而卸载你。