夜雨聆风花了一个下午，给AI助手接上了全球200万家酒店
事情是这样的：想做一个出行规划类的AI Agent，功能已经搭得差不多了——能理解用户意图、能规划行程、能推荐景点。但有一个致命的短板：它不会订酒店。
不是"订不好"，是"完全不会"。问它"杭州西湖附近有什么五星酒店"，它会给你写一篇小作文，告诉你"杭州酒店选择丰富，建议考虑西湖周边区域"——大家都知道选择丰富，要的是具体哪家、多少钱、能不能订。
问题的根源很简单：大模型的训练数据里没有实时酒店库存。它知道"杭州大概有什么酒店"，但不知道"这家酒店今天还有没有房、多少钱"。
要让Agent真正能订酒店，需要接一个真实的酒店数据源。想从零到跑通第一个真实订单，总共花了不到三个小时。下面是完整的实操记录。
如果你也在做类似的事，可以↓一起讨论
建议是先明确场景——是给个人用户用，还是给企业差旅用，还是做行程规划工具？场景不同，对数据源的要求不同。
优先选MCP原生支持的方案——省掉大量adapter开发工作测试交易闭环——不要只测搜索，一定要走一遍下单流程，确认数据真实性。关注定价权——如果你想做商业化，这个权限比API费用更重要。
调研：为什么这事这么难
在动手之前，先花半小时理清了一个问题：为什么之前一直没搞定？
答案很简单：传统的酒店API不是给个人开发者用的。
国内几家大OTA的开放平台，接入门槛是企业资质+商务对接+保证金。我查了一下流程：注册企业账号 → 提交商务申请 → 等审核 → 签合同 → 交保证金 → 拿API文档 → 开始开发。快的话两三周，慢的话一两个月。而且保证金从几万到几十万不等。
国际GDS系统（Amadeus、Sabre）更不现实，文档几百页，按查询次数收费，还不一定覆盖得到国内酒店。
在GitHub上搜了一圈"hotel MCP"，出来十几个项目，点进去一看——大部分是Demo，返回的是假数据，价格是编的，不能下单。能用的极少。
而道旅科技的项目，star数不算特别高，200万+全球酒店，11万+直签酒店（实时库存，非缓存），500+全球供应商，支持MCP协议这几条优势却特别突出。最后一条是关键。MCP（Model Context Protocol）是2024年底Anthropic提出的开放协议，现在已经是AI Agent连接外部工具的事实标准。如果这个项目原生支持MCP，意味着我不需要写任何adapter代码，直接配置就能用。
申请Key：3分钟拿到，申请入口在 rollinggo.store/apply。整个过程不需要营业执照，不需要商务对接，不需要保证金。自动审核，即时下发。
配置Cursor：2分钟搞定
用Cursor做开发，它原生支持MCP协议。配置方式很简单，在项目的.cursor/mcp.json里加一段即可，把mcp_your_key_here换成邮件里收到的实际Key。保存，重启Cursor。官方文档有每个平台的具体步骤。
配置完之后，在Cursor的对话窗口里试了一句：
搜一下杭州西湖附近后天入住的五星酒店，Cursor思考了两秒，自动调用了searchHotels工具。返回了5家酒店，每家都带名称、星级、最低价、到西湖的距离、设施标签。一个真实的酒店数据，跑通了。
深入测试：搜索能力到底怎么样。跑通之后，开始测一些更复杂的场景。
场景1：多条件组合搜索
7月15日到17日，东京站附近步行10分钟以内，预算600元以内，含早餐，4星以上
Agent把这段自然语言拆解成了结构化参数：城市=东京、地标=东京站、距离=800米、价格上限=600、星级=4-5、标签=含早餐、入住日期=2026-07-15、住宿天数=2。返回了3家符合条件的酒店。
说实话，这个结果让我有点惊讶。不是惊讶AI能理解需求——这是大模型的基本能力——而是惊讶数据源真的有这些酒店。东京站步行10分钟以内的酒店，是一个很具体的地理范围，能精确到这个粒度，说明底层的位置数据是结构化的，不是随便填的城市中心点。
场景2：查房型和实时报价
搜索结果里每家酒店都有一个hotelId。拿这个ID调getHotelDetail，就能看到这家酒店在指定日期的所有房型、价格、退改政策。其中一家的详情，返回了6种房型，从标准双床到行政套房，每种都带：房型名称、面积、床型、早餐类型、价格（CNY）、是否可免费取消、最后退改时间。
这些信息量和你在OTA上看到的详情页基本一致，但格式是结构化JSON，Agent可以直接理解和对比。
场景3：价格对比
拿同一家酒店的同一天入住价格，和其他平台做了对比。结果：道旅的价格是¥1,053，其他平台是¥1,264。差了约20%。这个价差的原因后面才想明白：它给的是供应链直供底价，道旅本来就是给OTA供货的供应商，现在通过MCP直接把底价开放给了Agent开发者——等于跳过了中间的零售加价环节。
交易闭环：从搜索到下单
搜索和查价只是前半段。真正让我觉得"这事成了"的，是交易闭环。
道旅的MCP提供了完整的交易链路：
Step 1：搜索酒店 → 拿到hotelId
Step 2：查房型报价 → 拿到ratePlanId
Step 3：锁价确认 → 调用price-confirm，拿到referenceNo
这一步很关键。锁价意味着系统在一段时间内为你保留这个价格，即使后续酒店涨价，你按锁定价下单。referenceNo是交易凭证，后续下单要用。
Step 4：提交预订 → 调用book，传入入住人信息（姓名、邮箱），返回一个支付链接
Step 5：查询订单 → 调用orders，查看订单状态。
对话里走一遍完整流程：
用户：帮我订这家酒店，7月15日入住，7月17日退房，2人入住
Agent：好的，我先为您确认价格。
Agent：（调用price-confirm）价格已锁定：¥1,053/晚，2晚合计¥2,106。免费取消截止时间：7月13日18:00前。是否确认预订？
用户：确认
Agent：（调用book）预订已提交！支付链接已生成，请点击完成支付：
整个流程在对话里完成，没有跳转到任何外部平台。用户只需要在最后一步点击支付链接完成付款。
一个意外发现：盯价功能
测试过程中，MCP还提供了一个盯价能力——设置一个目标酒店和价格阈值，当价格低于阈值时主动推送提醒。
这个功能对C端用户来说很实用：订了酒店担心买贵？设一个盯价，如果降价了自动提醒你取消重订。还没订酒店但想等低价？设一个监控，降价了第一时间通知你。
用户：帮我盯一下这家酒店，如果7月15日入住的价格降到900以下就提醒我
Agent：（配置监控规则）已为您设置价格监控。当前价格¥1,053，目标价格¥900。当价格触发阈值时，我会第一时间通知您。
总结
从14:30开始调研，到17:00跑通完整的搜索→查价→锁价→预订→盯价流程，实际花了约2.5小时。其中：调研和选型：30分钟，申请Key+配置：5分钟，功能测试：1小时，交易闭环验证：30分钟，盯价功能探索：15分钟，如果是纯接入（不深入测试），从申请Key到第一次成功调用，确实5-10分钟就够了。
几个实际感受：
第一，MCP协议的价值被低估了。如果没有MCP，我需要读API文档、写HTTP请求、处理认证、解析返回格式、适配数据结构——这套流程下来至少半天。MCP把这一切标准化了，Agent自动发现工具、自动构造参数、自动解析返回。开发者只需要配一个URL和一个Key。
第二，供应链直连和OTA API是两个物种。OTA API给你的是"零售端数据"——价格已经被加过、库存可能被过滤。供应链直连给你的是"源头数据"——直签酒店的实时PMS同步，价格是直供底价。对于Agent来说，后者明显更适合。
第三，交易闭环是分水岭。能搜索的API很多，能搜索+能下单的极少。RollingGo的锁价→预订→支付链路是完整的，这让Agent从"能聊天"变成了"能办事"。
第四，定价权是个隐藏的价值点。通过Partner Center可以自主配置加价比例，这意味着接入方不只是"调用API的技术角色"，而是"拥有商业自主权的分销节点"。对于想做商业化变现的开发者来说，这个权限比免费调用更有价值。
