1. 为什么我要拆这个AI旅游Agent的技术栈去年下半年开始身边做旅游、做本地生活、做SaaS的朋友几乎都在问同一个问题能不能做一个AI旅游助手用户说一句话就帮他规划行程、比价、下单、付款全程不用跳来跳去听起来像个聊天机器人加几个API的事但真动手做过的都知道这里面藏着的坑比想象中多得多。我自己前后参与过两个类似项目的架构设计一个偏C端轻量助手一个偏B端旅行社内部工具踩过的坑从对话状态丢失到支付回调对不上账几乎每一层都翻过车。这篇文章我想把这类系统的完整技术栈从头到尾拆一遍重点讲清楚四件事前端对话层怎么设计才能既流畅又不丢上下文MCPModel Context Protocol模型上下文协议在中间扮演什么角色、为什么它比传统函数调用更适合旅游这种多工具场景支付环节怎么接才能既合规又稳定以及整条链路上那些文档里不会写、只有真跑过才会遇到的坑。适合正在做AI Agent的开发者、想给现有旅游产品加AI能力的团队以及单纯想搞明白一个能下单的AI助手到底怎么搭的技术爱好者。读完你至少能拿到一套可以直接抄的架构骨架以及一份避坑清单。我先把整体链路用一句话概括用户在对话框里说需求前端把这句话连同会话状态打包发给后端AgentAgent通过MCP去调用行程规划、库存查询、价格计算、下单、支付等一系列工具最后把支付链接或二维码返回给前端完成闭环。听起来线性但每一环都有讲究下面逐层拆。2. 整体架构设计与分层思路2.1 四层架构的划分逻辑我习惯把这类系统拆成四层交互层、编排层、工具层、交易层。这个划分不是为了好看而是因为每层的技术选型、迭代节奏、故障影响面完全不同混在一起做后期维护会非常痛苦。交互层负责对话UI、流式渲染、多轮上下文管理迭代最快可能一周改三次文案和交互编排层是Agent的大脑负责意图识别、任务拆解、工具调度逻辑最复杂改动风险最高工具层是各种能力的具体实现比如查航班、查酒店、算价格很多是对接第三方API交易层专门处理下单和支付涉及资金稳定性和合规要求最高几乎不允许频繁改动。这么分层的好处是支付出问题不会影响对话体验工具换供应商不用动Agent逻辑前端改版不用碰后端。我见过一个项目把所有逻辑塞在一个Node服务里结果改个支付回调要重新测整个对话流程上线一次提心吊胆一次。2.2 为什么中间要引入MCP而不是直接函数调用这是很多人第一个疑问OpenAI的函数调用Function Calling已经能用了为什么还要引入MCP我的答案很直接当工具数量超过10个、且需要跨会话复用、跨模型迁移时函数调用的维护成本会指数级上升。传统函数调用是把所有工具定义塞进每次请求的prompt里工具一多token消耗暴涨而且每个模型厂商的格式还不一样换模型就要重写一遍。MCP的核心价值在于它把工具的定义和工具的调用标准化了——工具以独立的Server形式存在Agent通过标准协议去发现和调用工具的描述、参数schema、返回格式都是自描述的。旅游场景天然是多工具场景查天气、查航班、查酒店、查门票、算预算、下单、支付随便一数就七八个而且未来还会加。用MCP新增一个工具只需要部署一个新的ServerAgent侧几乎不用改代码。提示MCP不是银弹。如果你的Agent只有两三个固定工具且不打算换模型直接用函数调用更简单。MCP的收益在工具多、变化快、多模型复用的场景才明显。2.3 技术选型对照表下面这张表是我在两个项目里实际用过的组合供参考层级轻量方案生产方案选择理由交互层原生WebSocket 简单DOMReact SSE流式 状态机生产环境需要断线重连、消息去重编排层单文件Agent循环LangGraph或自研状态机多轮任务需要显式状态管理工具层直接HTTP调用MCP Server集群工具解耦、独立部署、独立扩缩容交易层第三方托管页自建订单系统 聚合支付需要订单状态可控、对账清晰轻量方案适合验证想法一周能跑通demo生产方案是我建议真正上线时用的尤其是交易层千万别图省事直接用第三方托管页后期对账和对退款的处理会让你怀疑人生。3. 前端对话层流式、状态与上下文管理3.1 流式渲染为什么是刚需旅游Agent的回复往往很长——一份三天行程可能几百字如果等全部生成完再显示用户要盯着转圈十几秒体验极差。流式渲染SSE或WebSocket能让文字像打字一样逐字出现首字延迟从十几秒降到一两秒感知速度提升非常明显。实现上我推荐SSE而不是WebSocket原因有三SSE基于HTTP穿透代理和网关更省心SSE天然单向服务端推客户端对话场景够用SSE断线重连是浏览器原生支持的WebSocket要自己写心跳和重连。唯一要注意的是SSE默认不支持POST而对话请求往往带很长的上下文URL放不下。我的做法是先用一个POST请求创建会话并拿到session_id再用SSE的GET请求带着session_id去订阅流这样既绕开了长度限制又能复用原生重连。// 第一步POST创建会话 const res await fetch(/api/chat/session, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ message: userInput, history: context }) }); const { sessionId } await res.json(); // 第二步SSE订阅流式结果 const es new EventSource(/api/chat/stream?sessionId${sessionId}); es.onmessage (e) { const chunk JSON.parse(e.data); appendToBubble(chunk.delta); // 逐字追加 if (chunk.done) es.close(); };3.2 多轮上下文到底存什么新手最容易犯的错是把整个对话历史一股脑塞回去几轮之后token就爆了。我的经验是分层存储最近3轮完整保留更早的对话做摘要压缩同时单独维护一个结构化槽位slot记录关键信息比如出发地、目的地、日期、人数、预算、已选中的航班和酒店。槽位这个东西特别重要。旅游规划是个填槽过程用户可能先说我想去三亚过几轮才说两个人下个月初如果只靠对话历史让模型自己提取很容易漏或者串。我一般用一个JSON对象显式维护{ destination: 三亚, origin: 上海, date_range: [2025-06-01, 2025-06-04], travelers: 2, budget: null, selected_flight: null, selected_hotel: null, stage: collecting }每次请求把槽位和最近对话一起发给AgentAgent返回时也更新槽位。这样即使用户中途说算了改成两个人槽位一改后续所有工具调用都基于新值不会出现前后矛盾。3.3 对话状态机的必要性纯靠模型自由发挥多轮任务很容易跑偏——用户问了个无关问题回来之后Agent忘了刚才规划到哪了。我强烈建议在编排层加一个轻量状态机把旅游规划拆成几个明确阶段需求收集 → 方案生成 → 方案确认 → 下单 → 支付 → 完成。每个阶段允许的操作和工具是有限的模型只能在当前阶段的工具集里选。这样做的好处是可控。比如在需求收集阶段Agent只能调用查询类工具绝对不能触发下单到了支付阶段只允许调用支付相关工具。我踩过的坑就是没做阶段限制测试时模型在用户还没确认行程的情况下直接调了下单接口虽然没造成实际损失但吓出一身冷汗。4. MCP层工具标准化与调度实战4.1 MCP的核心概念用大白话讲MCP你可以理解成AI世界的USB接口。以前每个工具都要为每个AI应用单独适配一次就像以前每个设备都有自己专用的充电口MCP定义了一套标准协议工具方只要实现一次MCP Server任何支持MCP的Agent都能直接插上用。它主要包含三个东西Resources资源只读数据比如酒店列表、Tools工具可执行动作比如下单、Prompts提示模板预置的对话模板。旅游场景里查库存、查价格属于Resources或Tools下单、退款属于Tools行程模板属于Prompts。4.2 旅游场景的MCP Server拆分我一般按业务域拆Server而不是按技术类型拆。具体是这么分的行程规划Server负责根据槽位生成行程草案内部可能调用大模型或规则引擎库存Server对接航班、酒店、门票的库存查询接口价格Server负责比价、优惠计算、总价汇总订单Server负责创建订单、查询订单状态、取消订单支付Server负责生成支付链接、查询支付结果、处理退款每个Server独立部署独立扩缩容。库存查询是高频只读可以多开实例支付是低频但关键单独部署并加更严格的监控。这种拆分让故障隔离变得清晰——库存接口挂了用户至少还能看行程和下单不至于整个系统瘫痪。4.3 工具描述怎么写才不容易被模型误用MCP工具的描述description直接决定模型会不会正确调用。我总结了几条实战经验第一描述里必须写清楚什么时候用和什么时候不用。比如查询航班这个工具描述里要写当用户已明确出发地、目的地、日期时调用若缺少任一信息先向用户询问不要猜测。第二参数schema要严格。日期用ISO格式人数用整数并设最小值枚举值列全。模型看到严格的schema乱填的概率会低很多。第三返回结果要结构化且带状态码。不要返回一大段自然语言返回JSON包含success、data、error_code。这样Agent能根据error_code决定是重试、换工具还是告诉用户失败。{ name: search_flights, description: 查询指定航线的航班。仅当出发地、目的地、日期三者齐全时调用。缺少信息时先询问用户。, inputSchema: { type: object, properties: { origin: { type: string, description: 出发城市三字码或中文名 }, destination: { type: string }, date: { type: string, format: date }, passengers: { type: integer, minimum: 1 } }, required: [origin, destination, date, passengers] } }4.4 工具调用的超时与降级第三方接口不稳定是常态。我给每个MCP工具调用都设了超时一般3到5秒超时后不是直接报错而是走降级逻辑。比如库存查询超时就返回缓存里的最近一次结果并标注数据可能不是最新价格计算超时就用估算公式给个区间价让用户先看方案确认时再实时算。注意降级返回的数据一定要带标记前端要明确告诉用户这是预估/缓存数据否则用户按缓存价下单实际价格对不上投诉就来了。5. 支付层从下单到回调的完整闭环5.1 支付为什么是整条链路最容易出事的地方对话和工具调用出错用户顶多觉得这AI不太聪明支付出错那是真金白银的问题轻则用户付了钱订单没生成重则重复扣款、对不上账。我见过最离谱的案例是回调没做幂等用户网络抖动重试了一次结果扣了两笔。支付层的核心原则就三条订单先于支付、回调必须幂等、状态以服务端为准。展开说就是用户点支付前服务端必须先创建订单并落库拿到订单号支付回调可能重复到达处理逻辑必须用订单号做幂等前端展示的支付状态永远以服务端查询结果为准不能信前端传回来的我付好了。5.2 支付流程的时序拆解完整的支付闭环我拆成六步用户在对话里确认行程Agent调用订单Server创建订单状态为pending_payment订单Server调用支付Server生成支付单拿到支付链接或二维码支付链接通过对话流返回给前端用户点击或扫码用户在支付渠道完成付款支付渠道异步回调支付Server支付Server验签、幂等处理后更新支付单状态并通知订单Server订单Server把订单状态改为paid触发后续履约发确认短信、通知供应商这里第5步的验签和幂等是重中之重。验签是确认回调真的来自支付渠道而不是伪造的幂等是防止同一笔回调被处理多次。我的做法是用支付单号做唯一索引回调进来先尝试插入一条回调记录插入成功才继续处理插入冲突说明已处理过直接返回成功。def handle_payment_callback(payload, signature): # 1. 验签 if not verify_signature(payload, signature): return {code: FAIL, msg: invalid signature} # 2. 幂等以支付单号回调流水号做唯一约束 try: db.insert(payment_callbacks, { payment_no: payload[out_trade_no], channel_trade_no: payload[transaction_id], raw: json.dumps(payload) }) except DuplicateKeyError: return {code: SUCCESS, msg: already processed} # 3. 更新支付单与订单状态 update_payment_status(payload[out_trade_no], paid) update_order_status_by_payment(payload[out_trade_no]) return {code: SUCCESS}5.3 支付渠道选型与聚合实际项目里很少只接一个渠道通常要支持多种支付方式。我的建议是接一个聚合支付层把不同渠道的差异屏蔽掉上层订单系统只跟聚合层打交道。聚合层负责统一的下单接口、统一回调格式、统一对账文件解析。选型时重点看三件事费率、结算周期、对账能力。费率差零点几个点量大了一年差不少钱结算周期影响现金流对账能力最容易被忽略但真出问题时能不能快速拉出平台订单 vs 渠道流水的差异明细决定了你要花一小时还是三天去查账。5.4 支付状态查询与补偿回调不是100%可靠的网络问题、渠道侧故障都可能导致回调丢失。所以必须有一个主动查询补偿机制对于状态还是pending_payment但创建超过一定时间比如5分钟的订单定时任务主动去渠道查询真实状态查到已支付就补上状态更新。这个补偿任务我一般5分钟跑一次查最近24小时内未完成的订单。跑之前一定要加分布式锁避免多实例重复处理。补偿逻辑和回调逻辑要复用同一套状态更新函数保证行为一致。6. 常见问题与排查技巧实录6.1 对话层典型问题问题一流式输出到一半断了用户看到半句话。排查思路先看是SSE连接被网关超时切断还是后端生成异常。网关超时一般设60秒如果单次生成超过这个时间就会被切。解决办法是把长任务拆成多段或者用心跳包保持连接。我遇到过Nginx默认proxy_read_timeout是60秒改成300秒后问题消失。问题二多轮对话上下文串了。典型表现是用户换了话题Agent还在回答上一个话题。根因通常是session_id复用错误或者槽位没清空。排查时打印每次请求带的session_id和槽位快照一眼就能看出问题。6.2 MCP层典型问题问题一模型不调用工具直接编答案。这是最常见的。原因通常是工具描述不够明确或者系统提示词没强调必须基于工具返回作答。我的做法是在系统提示里明确写涉及价格、库存、订单状态的信息必须调用对应工具获取禁止凭记忆回答。问题二工具调用参数格式错误。比如日期传成下个月而不是ISO格式。解决办法是在schema里加format约束同时在工具实现里做一层参数清洗能自动纠正的自动纠正纠正不了返回明确错误让模型重试。问题三工具调用死循环。模型反复调用同一个工具因为返回结果它不满意。必须设最大调用轮数我一般设8轮超过就强制结束并告诉用户暂时无法完成请稍后重试。6.3 支付层典型问题速查表现象可能原因排查方向解决用户付了钱订单还是待支付回调丢失查渠道回调日志、查补偿任务是否运行手动触发查询补偿同一订单扣了两次回调未幂等查回调记录表是否有重复加唯一索引补退款回调验签失败密钥配置错误或编码问题对比渠道文档的验签规则修正密钥和编码支付链接打不开链接过期或域名被拦检查链接有效期和域名重新生成链接对账金额对不上手续费计算差异或退款未同步拉渠道对账文件逐笔比对修正对账逻辑6.4 几条用血换来的避坑经验第一支付相关的所有操作都要有日志且日志要能串起来。订单号、支付单号、渠道流水号三个号在每条日志里都要有出问题时才能快速定位。第二测试环境一定要能模拟回调。很多渠道的测试环境回调不稳定我一般自己写一个模拟回调的工具能手动触发各种场景成功、失败、重复、验签失败这样测试覆盖才全。第三金额一律用整数分存储不要用浮点数。0.1加0.2不等于0.3这种事在支付里是灾难。数据库存分展示时再除以100。第四退款逻辑要提前设计。很多人只想着收款上线后用户要退款才发现没做。退款涉及原路退回、部分退款、退款状态查询复杂度不比支付低一定要在架构阶段就留好位置。7. 我对这套技术栈的一点个人体会做AI旅游Agent这两年我最大的感受是难的不是AI是工程。模型能力已经足够支撑这类场景真正决定项目成败的是那些不性感的部分——上下文管理、工具调度、支付幂等、异常补偿。我见过太多团队把精力全花在调prompt上结果上线后栽在支付回调上。如果让我给正在做类似项目的朋友一句建议那就是先把交易链路跑通跑稳再回头优化对话体验。因为对话体验差用户会吐槽但还会用支付出问题用户直接流失还可能投诉。架构上把交易层独立出来、把MCP工具标准化、把状态管理显式化这三件事做扎实了后面加功能会越来越顺反之前期图快堆在一起后期每加一个功能都是牵一发动全身。最后分享一个我最近在用的调试小技巧给Agent的每一次工具调用都打上trace_id前端、编排层、工具层、支付层的日志都用这个trace_id串起来配合一个简单的日志查询页面排查问题时输入trace_id就能看到完整链路。这个投入不到一天但省下的排查时间是以周计的。