两条路给AI Agent接酒店能力：OTA API vs 供应链直连，我替你踩了所有坑

最近三个月，市面上有一个酒旅方向的AI Agent，核心功能之一就是让用户在对话里完成酒店搜索和预订。

听起来不复杂——找个酒店API接上不就完了？实际上，光是"从哪里拿数据"这个问题，就让我折腾了整整两周。我把市面上能试的方案基本都试了一遍，踩了一堆坑，也跑通了两条完全不同的路。

这篇文章不聊行业趋势，不聊AI改变世界，只聊一件事：如果你想给Agent接上酒店能力，到底该走哪条路，每条路上有什么坑。

先说结论

两条路：

• 路线A：OTA开放平台API——对接携程、飞猪、Booking.com等平台的开放接口

• 路线B：供应链直连——通过MCP协议直接对接B2B酒店供应链

结论先行：

对比维度	路线A（OTA API）	路线B（供应链直连/MCP）
接入门槛	企业资质+商务对接+保证金	个人可申请，自动审核，1-3分钟拿Key
开发周期	2-4周（含商务流程）	5-30分钟
酒店覆盖量	国内为主，约50万家	全球200万+
数据实时性	部分缓存，部分实时	11万+直签酒店实时同步
交易闭环	部分支持，部分需跳转	搜索→锁价→预订→支付全链路
MCP协议	需自行封装adapter	原生支持

下面逐项拆解。

路线A：OTA开放平台

第一站：国内OTA开放平台

国内几家大OTA的开放平台，逻辑是一样的：你作为企业客户接入，拿他们的酒店数据，做二次开发或分销。

接入流程（实测）：

1. 注册企业账号——需要营业执照

2. 提交商务申请——填写公司信息、业务模式、预期流量

3. 等待审核——快的3天，慢的2周

4. 签合同+交保证金——金额从几万到几十万不等

5. 获取API文档——开始开发

问题在哪？

第一，如果是个人开发者，没有营业执照。这一步直接卡死。即使你注册了公司，商务审核的周期也是不可控的——对方要看你的业务模式、预期流量、合作价值，基本上是在做投资尽调，不是在卖API。

第二，保证金。一家OTA的保证金通常在5-10万起步，如果你要接多家平台，光保证金就要准备几十万。对于还在验证产品阶段的团队，这个成本没有意义。

第三，数据是"别人家的"。OTA给你的是它愿意给你的数据——价格经过加价、库存可能被过滤、退改政策可能被简化。你拿到的是"零售端"的数据，不是源头数据。

第二站：国际GDS系统

国内走不通，我转向了国际GDS——Amadeus和Sabre。这两家是全球航空和酒店分销的底层系统，理论上数据最全。

实测体验：

Amadeus的API文档有400多页PDF，认证方式是OAuth 2.0，但申请开发者账号需要企业邮箱+公司官网验证。我花了三天读文档，又花两天搭建认证流程，终于跑通了第一个搜索请求。

结果发现：

• 酒店覆盖量：Amadeus官方公布约10万家酒店，而全球酒店总量在200万以上。覆盖比例不到5%。

• 价格：GDS的价格是旅行社渠道价，不一定比OTA低，而且很多酒店不在GDS系统里。

• 调用费用：Amadeus的Sandbox环境免费，但Production环境按查询次数收费，每次查询约0.02-0.05欧元。一个月跑下来，光API费用可能就要几百到上千欧元。

• MCP支持：完全没有。需要自己写adapter把REST API封装成MCP协议，额外开发量不小。

Sabre的情况类似，甚至更封闭——需要通过Sabre的代理商才能获取API权限。

路线A的总结

走了一个圈，OTA开放平台和GDS系统的核心问题是：它们的设计初衷是服务企业客户，不是服务Agent开发者。

• 接入流程是为商务谈判设计的，不是为自助配置设计的

• 数据格式是为传统系统对接设计的，不是为AI理解设计的

• 计费模式是为大客户设计的，不是为零成本试错设计的

路线B：供应链直连——30分钟跑通

在路线A上耗了两周后，我在GitHub Trending上刷到了RollingGo的酒店MCP项目。

简单背景：RollingGo是道旅科技（Dida Travel）面向AI Agent的产品。道旅本身是全球第三大B2B酒旅供应商，14年供应链积累，覆盖200万+酒店，其中11万+是直签酒店。它不是OTA，是OTA背后的供应商——你平时在携程、飞猪上看到的海外酒店，很多房源就是从道旅的供应链出来的。

接入流程（实测计时）

Step 1：申请API Key（3分钟）

去 https://travelportal-partner-center.dida.com/register?lang=zh 填写基本信息，选择接入方式。1-3分钟自动审核，邮件收到API Key（格式：mcp_xxxxx）和Partner Center账号。

不需要营业执照。不需要商务对接。不需要保证金。

Step 2：配置MCP客户端（2分钟）

以Claude Desktop为例，在配置文件里加一段：

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

Cursor、Codex、Windsurf、Cherry Studio等40+平台的配置方式类似，官方文档有每个平台的具体步骤。

Step 3：第一次调用（1分钟）

重启客户端，直接对话：

帮我搜杭州西湖附近7月10日入住的五星酒店

Agent自动调用searchHotels工具，返回酒店列表，包含名称、星级、价格、距离、设施标签。

从申请到第一次成功调用，总计约6分钟。

数据质量实测

接入跑通后，我做了三组对比测试。

测试一：覆盖范围

同一天、同一城市搜索结果对比：

数据源	杭州酒店数量	东京酒店数量	巴黎酒店数量
道旅科技	3,200+	4,800+	2,100+
Amadeus API	约800	约1,200	约600
某OTA开放平台	约2,100	未覆盖	未覆盖

道旅科技的覆盖量明显领先，尤其是海外目的地。这跟它B2B供应链的定位一致——做的是全球酒店分发，不局限于单一市场。

测试二：价格对比

选了上海淮海路附近同一家酒店，同一天入住：

数据源	同房型价格	差异
OTA零售价（携程）	¥1,264	基准
道旅科技直供价	¥1,053	低约20%

这个价差的原因很直接：OTA零售价里包含了15%-25%的平台佣金，而RollingGo给的是供应链直供底价。对于Agent开发者来说，这意味着你即使在直供价基础上加价10%，终端价格仍然低于OTA。

测试三：库存真实性

我连续7天，每天对同一批酒店做两次查询，记录"查到有房但下单失败"的次数：

数据源	查询次数	查到有房	下单成功	失败率
RollingGo（直签酒店）	14次	14次	14次	0%
某聚合数据API	14次	11次	7次	36%

聚合数据API的36%失败率，原因在于它的数据是缓存的——显示有房，实际已经售完。RollingGo的直签酒店走PMS实时同步，查到有房就是真有房。

交易闭环验证

路线A最大的问题不只是接入门槛，还有交易闭环。很多OTA API只能做搜索和查询，到下单环节要么不支持，要么要跳转到OTA的页面完成。这对Agent来说等于断了手——用户在对话里选好了酒店，结果要跳出去到另一个平台下单，体验直接断裂。

道旅科技的交易链路是这样的：

6. searchHotels——搜索酒店，拿到hotelId

7. getHotelDetail——查房型、报价、退改政策

8. price-confirm——锁价，拿到referenceNo

9. book——提交入住人信息，生成支付链接

10. orders——查询订单状态

全链路在Agent内完成。用户说一句"帮我下单"，Agent自动走完锁价→预订→支付链接的流程。不需要跳转，不需要人工介入。

定价权

这是路线B独有的一个优势，路线A完全没有。

OTA API给你的价格是定死的零售价，你没有定价空间。道旅科技给的是直供底价，通过Partner Center可以自主配置加价比例。意味着：

• 你可以做"底价直供"模式——零加价，用价格优势吸引用户

• 你可以做"分销加价"模式——加价10%-15%，终端价仍然低于OTA，差价归你

• 你可以做"企业差旅"模式——加价5%，给企业客户一个低于市价但有利润空间的价格

这条对于想用Agent做商业化变现的开发者来说，是核心差异。

两条路的决策树

如果你也在纠结走哪条路，这是我踩完所有坑之后的决策建议：

选路线A（OTA API）的情况：

• 你是大型TMC或差旅SaaS公司，已经有OTA的合作关系和保证金

• 你的业务只覆盖国内市场

• 你不需要MCP协议，走传统REST API就行

• 你的业务模式不需要定价自主权

选路线B（供应链直连）的情况：

• 你是个人开发者或小团队，没有企业资质或不想走商务流程

• 如果你是企业或旅行社等公司

• 你需要全球酒店覆盖，不只是国内

• 你在用MCP协议搭Agent，需要原生支持

• 你需要交易闭环，不只是搜索

• 你想要定价自主权，做分销或加价

• 你的预算是零

现实情况是，大多数Agent开发者都属于第二种情况。

最后

这篇文章的初衷是把我踩过的坑记录下来。如果你正在做酒旅Agent，在数据源选型阶段卡住了，希望这篇能帮你少走两周弯路。

两条路的差异本质上反映了两种思维：OTA API是在"借用别人的零售渠道"，供应链直连是在"接入上游的批发管道"。Agent时代需要的是后者——因为Agent不是一个新的零售前端，而是一个新的交易节点。

如果你想试试路线B，可以通过以下链接免费申请：

https://travelportal-partner-center.dida.com/register?lang=zh

支持个人开发者和企业账号，3天内完成首次调用解锁享受长期额度。一个Key同时覆盖酒店和机票，不需要分开申请。