企业官网建设流程全解析

我花了一个下午，给AI助手接上了全球200万家酒店

下午两点半，我坐在工位上，对着Cursor发呆。

事情是这样的：我在做一个出行规划类的AI Agent，功能已经搭得差不多了——能理解用户意图、能规划行程、能推荐景点。但有一个致命的短板：它不会订酒店。

不是"订不好"，是"完全不会"。你问它"杭州西湖附近有什么五星酒店"，它会给你写一篇小作文，告诉你"杭州酒店选择丰富，建议考虑西湖周边区域"——废话，我知道选择丰富，我要的是具体哪家、多少钱、能不能订。

问题的根源很简单：大模型的训练数据里没有实时酒店库存。它知道"杭州大概有什么酒店"，但不知道"这家酒店今天还有没有房、多少钱"。

要让Agent真正能订酒店，需要接一个真实的酒店数据源。今天下午，我把这件事搞定了。从零到跑通第一个真实订单，总共花了不到三个小时。下面是完整的实操记录。

如果你也在做类似的事

如果你也在搭Agent，或者想让你的AI助手具备酒店预订能力，我的建议是：

1. 先明确你的场景——是给个人用户用，还是给企业差旅用，还是做行程规划工具？场景不同，对数据源的要求不同

2. 优先选MCP原生支持的方案——省掉大量adapter开发工作

3. 测试交易闭环——不要只测搜索，一定要走一遍下单流程，确认数据真实性

4. 关注定价权——如果你想做商业化，这个权限比API费用更重要

接入申请地址：

RollingGo 接口申请

个人开发者和企业都可以申请，3天内首调解锁长期额度。一个Key同时覆盖酒店和机票MCP，不需要分开申请。

14:30 — 调研：为什么这事这么难

在动手之前，我先花半小时理清了一个问题：为什么之前一直没搞定？

答案很简单：传统的酒店API不是给个人开发者用的。

国内几家大OTA的开放平台，接入门槛是企业资质+商务对接+保证金。我查了一下流程：注册企业账号 → 提交商务申请 → 等审核 → 签合同 → 交保证金 → 拿API文档 → 开始开发。快的话两三周，慢的话一两个月。而且保证金从几万到几十万不等。

国际GDS系统（Amadeus、Sabre）更不现实，文档几百页，按查询次数收费，还不一定覆盖得到国内酒店。

我在GitHub上搜了一圈"hotel MCP"，出来十几个项目，点进去一看——大部分是Demo，返回的是假数据，价格是编的，不能下单。能用的极少。

直到我翻到道旅科技的项目，star数不算特别高，但README里的几个数字让我停下来了：

• 200万+全球酒店

• 11万+直签酒店（实时库存，非缓存）

• 500+全球供应商

• 支持MCP协议

最后一条是关键。MCP（Model Context Protocol）是2024年底Anthropic提出的开放协议，现在已经是AI Agent连接外部工具的事实标准。如果这个项目原生支持MCP，意味着我不需要写任何adapter代码，直接配置就能用。

决定试试。

15:00 — 申请Key：3分钟拿到

申请入口在rollinggo.store/apply，填了一个表单：姓名、邮箱、使用场景描述。提交之后，大概2分钟左右，邮件就到了。

邮件里包含两个东西：

5. API Key：格式是mcp_开头的一串字符

6. Partner Center账号：用来管理加价比例、查看订单和收益

整个过程不需要营业执照，不需要商务对接，不需要保证金。自动审核，即时下发。

这里有一个细节值得注意：邮件里说，3天内完成首次工具调用，就能解锁永久调用额度。也就是说，如果你申请了Key但一直不用，额度可能会回收。这个设计挺合理的——优先服务真正有需求的开发者。

15:10 — 配置Cursor：2分钟搞定

我日常用Cursor做开发，它原生支持MCP协议。配置方式很简单，在项目的.cursor/mcp.json里加一段：

{ "mcpServers": { "RollingGo-Hotel": { "url": "https://mcp.rollinggo.cn/mcp", "type": "http", "headers": { "Authorization": "Bearer mcp_your_key_here" } } } }

把mcp_your_key_here换成邮件里收到的实际Key。保存，重启Cursor。

如果你用的是Claude Desktop，配置文件在~/.claude/claude_desktop_config.json，格式一样。Codex、Windsurf、Cherry Studio等平台也类似，官方文档有每个平台的具体步骤。

配置完之后，我在Cursor的对话窗口里试了一句：

帮我搜一下杭州西湖附近后天入住的五星酒店

Cursor思考了两秒，自动调用了searchHotels工具。返回了5家酒店，每家都带名称、星级、最低价、到西湖的距离、设施标签。

第一个真实的酒店数据，跑通了。

15:30 — 深入测试：搜索能力到底怎么样

基础跑通之后，我开始测一些更复杂的场景。

场景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：价格对比

我拿同一家酒店的同一天入住价格，和携程做了对比。

结果：RollingGo的价格是¥1,053，携程是¥1,264。差了约20%。

这个价差的原因后面才想明白：它给的是供应链直供底价，携程给的是零售价。零售价里包含了平台佣金（通常15%-25%）。道旅本来就是给OTA供货的供应商，现在通过MCP直接把底价开放给了Agent开发者——等于跳过了中间的零售加价环节。

16:15 — 交易闭环：从搜索到下单

搜索和查价只是前半段。真正让我觉得"这事成了"的，是交易闭环。

RollingGo的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）预订已提交！支付链接已生成，请点击完成支付：[链接]

整个流程在对话里完成，没有跳转到任何外部平台。用户只需要在最后一步点击支付链接完成付款。

16:45 — 一个意外发现：盯价功能

测试过程中，我注意到MCP还提供了一个盯价能力——设置一个目标酒店和价格阈值，当价格低于阈值时主动推送提醒。

这个功能对C端用户来说很实用：订了酒店担心买贵？设一个盯价，如果降价了自动提醒你取消重订。还没订酒店但想等低价？设一个监控，降价了第一时间通知你。

我在Agent里试了一下：

用户：帮我盯一下这家酒店，如果7月15日入住的价格降到900以下就提醒我

Agent：（配置监控规则）已为您设置价格监控。当前价格¥1,053，目标价格¥900。当价格触发阈值时，我会第一时间通知您。

虽然这次测试没有等到实际降价，但功能逻辑是通的。

17:00 — 总结：一个下午的收获

从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的技术角色"，而是"拥有商业自主权的分销节点"。对于想做商业化变现的开发者来说，这个权限比免费调用更有价值。

以上就是一个下午的实操记录。没有高深的架构讨论，就是一个开发者把一件事从头到尾跑通的过程。如果你在接入过程中遇到问题，可以在GitHub仓库提Issue，或者到官方开发者群里交流。

写完这篇的时候看了一眼时间，比我预计的快了不少。看来选对工具，确实是最高效的开发。