去年年底我把一个挺恼火的需求丢给AI助手帮我把下周在成都出差住的酒店订了预算600以内。结果它列了七八家候选每家都说得头头是道最后却落在同一句“你可以去XX平台下单”。那一刻我就意识到在酒店预订这个场景里大模型还只是个参谋当不了管家。之所以会有这种感觉是因为我一直在关注MCP也就是模型上下文协议而RollingGo酒店MCP最近正好把内置工具扩容到了7个把酒旅全流程能力补齐了。这篇文章不聊虚的就讲这次更新到底多了哪些能力以及我在支持MCP的客户端里实际把它跑起来的过程。1. 更新前的“半自动”现状为什么AI订房始终差一脚1.1 模型会说话但不会执行多数人第一次尝试“AI订酒店”体验基本是同一套剧本问它杭州西湖边有哪些酒店它能流畅回答甚至给出评分、价格范围和历史评价。但一旦要求“帮我订一个下周五入住的湖景大床房”它就开始含糊或者把用户引导到某个OTA平台上手动操作。这不是大模型本身笨而是它的能力边界里根本没有“可执行动作”。在MCP出现之前如果要让AI真正操作酒店业务系统平台方得为每个AI客户端单独开发适配层不同模型又要维护各自的插件协议两边都在做重复劳动。MCPModel Context Protocol模型上下文协议就是来解决这个问题的它定义了一套标准的工具调用规范AI客户端只需实现MCP Client端业务方只需提供一个MCP Server两边就能自动握手。理解MCP最简单的方式是把它类比成USB-C接口——过去大模型就像一台全是专用口的设备想连打印机、连显示器、连网线都要各找各的线现在统一成一个标准口谁都能插。1.2 酒店MCP的价值把“读操作”升级成“写操作”如果只用一句话概括这次RollingGo更新的价值我认为是把AI在酒旅场景里的能力从“读操作”扩展到了“写操作”。上一版工具不是没用而是集中在“读”上。比如城市酒店搜索、酒店详情查询这类能力做行程推荐已经够用AI可以告诉你哪家评分高、哪家离景区近、哪家早餐好。但用户看完推荐之后还得自己跳回预订网站下单因为AI没法生成订单。再往后订单变更、取消、退款这类售后场景更是完全没有接进来。而酒旅用户的需求从来不是“查一查”就完事。它是一条连续的决策链先搜索再比价再看房型政策然后下单之后还要面对改期、取消、开发票这些事。任何一环断开AI的实际价值都会大打折扣。这次把内置工具做到7个正是沿着这条决策链把缺口一个个堵上。2. 内置工具扩容至7个一张表看清酒旅能力版图2.1 7个工具的职能总览我按自己的接入理解把这7个工具的职责梳理成下面的表格。工具的具体命名以官方文档为准但能力边界大致就是这样工具对应环节核心能力hotel_search目的地搜索按城市、商圈、关键词、星级、价格区间等条件检索酒店返回候选列表与基础可订状态hotel_detail决策参考查询指定酒店的房型矩阵、设施服务、位置评分、用户评价标签、入住政策等完整画像rate_plan_query报价比价针对指定日期查询可售房型、含税房价、早餐政策、取消规则支持连住试算booking_create下单交易提交入住人、联系方式、特殊需求创建订单并返回订单号与确认状态booking_detail履约跟踪查询订单详情、当前状态、确认号、入住凭证信息booking_modify售后变更在政策允许范围内修改入住日期、房型、入住人信息等cancellation_refund退款售后查询取消政策、提交取消申请、跟踪退款进度一看这张表就能明白前三个是“行前决策”工具第四个是“临门一脚”的交易工具后三个是“售后保障”工具。三个阶段加起来才真正称得上全流程。2.2 为什么是7个而不是更多和做MCP服务的朋友聊天时我们有个一致的看法MCP工具的数量不是越多越好。每多一个工具模型需要理解的函数签名就多一组选错工具的概率也更高上下文消耗还会上升。RollingGo选择7个更多是从“决策链路的最小必要集”来考虑的每个阶段只保留最高频、最核心的动作而不是把点评、社区、接送机、门票全部塞进来。这种克制对落地是有利的。我实测下来工具少且职责清晰的服务调用成功率明显高于大而全的接口池。很多时候给AI一把功能明确的小刀比给它一把什么都干的瑞士军刀更可靠。另外也要留意“内置”这个词——它意味着这些工具开箱即用不需要用户再去折腾额外的插件挂载。3. 从检索到退改7个工具各自解决什么问题3.1 搜索与详情让AI学会“看”酒店先说hotel_search。这个工具表面是关键词搜索真正价值在于它接收的筛选参数。我在客户端里一般会引导模型优先使用这个参数组合{ city: 杭州, check_in: 2025-08-15, check_out: 2025-08-17, keyword: 西湖 亲子, star_rating: 4, price_min: 400, price_max: 800, sort_by: default }把入住日期和离店日期放进搜索条件是很容易被新手忽略的点。酒店行业的可订状态是按日期变化的不带日期的搜索只能在“城市里有哪些酒店”这个层面打转根本没法回答“这周五还有没有房”。第二件要做的事是hotel_detail它负责回答“候选里的这家到底行不行”。比如用户关心儿童早餐是免费还是半价、酒店有没有停车场、最近的差评集中在什么方面这些信息都藏在详情工具里。为什么要把搜索和详情拆成两个工具因为职责差异太大。搜索结果返回的是候选列表数据量大模型一次消化不了太多详情数据是单个对象信息更重。拆开之后模型可以先粗筛再细看调用链路和token消耗都更可控。3.2 报价与预订从“看看”到“锁房”的跨越rate_plan_query是我认为这次更新里含金量很高的一个工具。酒店价格不是固定数同一家酒店、同一天不同房型、不同渠道政策、不同取消规则价格能差出不少。通过这个工具AI能拿到指定入住日期的可售房型和对应价位关键是它还会带出早餐政策与取消规则。在AI自动下单之前这些信息直接决定后面这笔交易稳不稳。再往后就是booking_create这是从读操作跨到写操作的关键一步。它需要提交的信息大致是这样{ hotel_id: HZ-000123, check_in: 2025-08-15, check_out: 2025-08-17, room_type_id: RT-2931, guest_name: 张三, guest_phone: 13800000000, special_requests: 高楼层无烟房婴儿床 }这一步执行完订单就真实进入酒旅系统了并且会返回一个订单号。很多朋友问我AI下单会不会下错我的经验是模型选错参数的概率比人想象的低很多真正的高风险在于“取消政策理解错”。所以我的习惯是让rate_plan_query先把取消规则返回出来由用户在对话里确认过后再调booking_create不默认替用户做最后决定。3.3 订单、改期、退款把售后搬进对话booking_detail、booking_modify、cancellation_refund这三个工具补齐了传统AI无法触达的售后环节。booking_detail本身不复杂就是查订单履约状态适合用来跟踪“订单确认了没、确认号是多少、凭证怎么拿”。booking_modify是做得有门槛的工具因为酒店订单能不能改、改期要不要补差价完全取决于订单本身的售卖条款。正确的交互方式应该是先调booking_detail看原订单条件再调rate_plan_query试算改期后的差价最后执行booking_modify中间任何一步发现政策不允许模型就该老老实实告诉用户原因而不是强行执行。cancellation_refund也是同样的逻辑先查取消政策再提交取消申请再跟踪退款进度。这套“先查后改、先算后订”的交互顺序是我反复在系统提示词里调教模型才稳定下来的。4. 接入MCP实操配置、连接与避坑记录4.1 远程WebSocket服务的接入方式RollingGo这次提供的MCP服务走的是远程WebSocket协议服务地址形如wss://api.xiaozhi.me/mcp/?token你的完整token这个token一般比较长是鉴权凭证。和本地stdio方式的MCP不同远程MCP服务不需要你在自己电脑上启动任何进程直接填地址就能连。由于走的是wss加密WebSocket传输层的安全性不需要额外操心重点是管理好token的时效和权限。4.2 客户端配置参考在主流支持MCP的客户端里通常都有一个统一的MCP Servers配置区核心字段是{ mcpServers: { rollinggo: { type: http, url: wss://api.xiaozhi.me/mcp/?tokenYOUR_FULL_TOKEN, transport: websocket } } }不同客户端的命名和位置略有区别有的叫Connection有的直接要求粘贴JSON字段本质是一致的。填完之后客户端会自动发现服务端暴露的这7个工具并在对话里按需调用。4.3 实测遇到的坑几轮用下来踩坑不少挑几个有共性的说一下。第一个坑是token复制不全。长token在手机和网页之间来回复制特别容易缺位一缺位就是鉴权失败。建议用“导入配置”而不是“手打复制”粘贴后也顺手核对一下尾部字符。第二个坑是WebSocket空闲断开。AI会话挂久了服务端连接会断开这本身正常模型通常会在下一次调用时重新握手。但如果客户端没做好自动重连就会卡在“工具调用中”半天不动遇到这种情况重启会话就好。第三个坑是模型并行调用带来的数据不一致。我遇到过模型同时发起hotel_search和rate_plan_query结果返回的酒店列表和报价不是同一批数据。解决办法是在系统提示词里明确写“先完成搜索和详情确认再进行报价试算”把调用顺序约束住。第四个坑是本地小参数模型的行为不稳定。小模型在函数调用时偶尔会忽略工具返回的“部分失败”字段把错误当成功。我的建议是重要订单完成后强制再调一次booking_detail核实状态。提示交易类工具调用之后永远补一次状态查询。这不是重复是防错。5. 把工具串起来三个真实场景的调用推演5.1 场景A两周后杭州亲子周末用户指令“帮我在杭州西湖附近找一家适合带5岁孩子的酒店周六入住周日退房预算700左右含早餐优先。”AI的实际工具调用顺序是这样的第一轮hotel_search用城市杭州、关键字“西湖 亲子”、日期和预算条件筛出5家候选紧接着hotel_detail逐家确认儿童早餐政策和亲子设施评价锁定其中一家再调rate_plan_query确认周六当晚的可售房价发现某个含早房型只比基础房贵40元而且支持免费取消于是向用户解释差价后推荐含早房型。用户回复“就订它”AI执行booking_create提交入住人和联系电话拿到订单号后再调用booking_detail确认状态为“已确认”。整个过程没有一步跳错。放在以前同样的需求至少要打开三四个页面搜索、比价、翻政策、下单、截图保存。现在全在对话里完成了。5.2 场景B出差连住改期另一种常见场景是行中变更。我朋友出差订了三晚第二天临时要改期一晚。传统做法是自己打开App翻半天找到订单再跟在线客服沟通改期和补差价。换成这套MCP工具后AI先调booking_detail查出原始订单条款发现这个订单支持免费改期但可能有差价再调rate_plan_query试算新日期的价格确认差价之后由用户在对话里确认最后执行booking_modify返回更新后的凭证信息。整个过程不超过四轮工具调用。这里最关键的步骤是“先试算再修改”如果跳过试算直接改用户很可能会收到一笔意料之外的差价账单。5.3 场景C团队多间房的统一确认还有一个我很看好的场景是公司行政订房。一个需求“下周北京培训给团队订5间房入住人名单我发你”AI会用同一家酒店执行多次booking_create每次为不同入住人生成独立订单之后按订单列表逐一调booking_detail核对状态。这种重复性批量操作人工做起来又烦又容易漏反而是AI的强项。一次会话里连续处理5个订单出错点主要在入住人信息和房型匹配上只要参数传对效率比人工高一个量级。6. 全流程补齐后我更关心的事6.1 规则的结构化程度决定“全流程”成色工具齐了但真正称得上“全流程”还要看业务规则有没有结构化暴露出来。比如取消政策是“入住前3天免费取消之后收首晚房费”这应当作为一个明确字段返回给模型而不是塞在一大段网页文案里。政策不能算AI就没法帮用户做成本决策。这次更新把“取消规则”放进rate_plan_query和cancellation_refund是正确方向但后续能不能做到不同房型、不同渠道政策的细粒度拆解才是真正拉开体验差距的地方。6.2 连接的稳定性是远程MCP的生死线远程WebSocket服务带来的最大变数是网络。用户在高铁上、电梯间里、境外网络环境下发起调用一次断线重连就可能拖垮整个会话。交易类工具尤其需要做幂等控制不能因为网络超时重试就给用户重复下两单。希望这种远程MCP服务在服务端持续加强这一层毕竟酒店预订对“重复扣款”的容忍度非常低。6.3 人工闸门仍然必要这是我唯一的坚持无论工具多完善我始终会在提示词里给AI划一条界线搜索、详情、报价、订单查询这类读操作可以完全自动执行下单、改期、取消这类写操作必须先列清楚关键信息和后果等用户明确回复确认后再执行。AI的价值是节省重复劳动而不是替用户承担决策责任。把“建议权”和“决定权”分开体验和风险控制才能同时兼顾。从这次RollingGo把内置工具做到7个的动作来看酒店行业的AI落地已经在往“完整交易闭环”走了。我个人的下一步打算是把这个MCP服务挂到我自己的差旅Agent工作流里让它和行程安排、报销单生成这些环节联动起来。工具链越长越考验编排能力但也正是这种“标准协议垂直业务”的组合才是MCP真正开始产生价值的地方。