【开发者来信栏目导语】 本栏目为旅行Agent开发者生态共建专栏定期收录一线酒旅开发者、渠道运维、Agent搭建者的落地开发日志、对接复盘、功能适配笔记。内容仅做技术交流、行业开源参考所有组件能力、接口能力仅为开发者对接使用。我做 Travel Agent 旅行AI方向有两年了从最早的「接 OpenAI API 写一坨 if-else」到后来上 LangChain / Dify / Coze / Claude Tool Use最近一年又集中对接了一轮 MCP 协议。这次想聊的不是「怎么接」而是「为什么必须接」。准确地说是想回答一个被身边同行反复问起的问题「我自己的大模型 我自己的爬虫 我自己的数据库照样能跑通一个『能查酒店』的 Agent为什么还要单独接一个 Hotel MCP」这个问题在 2024 年问可能还有争议。但在 2026 年 LLM 越来越卷、Agent 越来越像样、酒旅场景越来越「真刀真枪」的环境下答案是非常明确的。这封信就按「先问为什么 → 协议是什么 → 酒店场景为什么特殊 → Hotel MCP 怎么做」的顺序拆开讲。所有接口字段、配置参数、踩坑点全部基于我对酒店 MCP 的一次完整适配过程实测。2. 通用大模型的「能聊」困局2.1 LLM 训练数据的天然缺陷Travel Agent 看起来是个对话问题实际上是个实时数据 复杂规则问题。而通用大模型本身有几个绕不开的硬性短板短板具体表现对 Travel Agent 的影响训练数据有截止日期模型权重里只冻结了某个时间点之前的世界2026 年的新酒店、2025 年新开的度假村模型一无所知没有实时库存模型不知道「现在这间房有没有房」同一房型不同时间的可订状态模型只能瞎猜没有真实价格模型只能复述历史报价或编一个「看起来合理」的数价格一旦变化Agent 给出的是过期信息甚至幻觉没有履约能力模型不会真的「下单」「锁房」「退订」哪怕对话吹得再像也只是「能聊」这 4 条单拎一条都还好组合在一起就是致命的Travel Agent 是个「骗不了人」的场景。用户搜杭州西湖酒店搜出来 5 家结果全是没有房的价格或者全是有房的过期价 —— 一次两次还行第三次用户就再也不用了。2.2 「幻觉」在酒旅场景的代价做 ToC 的同行应该都有体会旅行是一个高客单价 强情绪 易投诉的场景。用户订到一家不存在的酒店 → 投诉 退款 客诉工单用户订到的价格比实际高 → 「你骗我」三连用户订到的房型跟描述不符 → 现场拉扯 差评LLM 的「幻觉」在写作、问答、闲聊场景里是「偶尔的小错误」在酒旅场景是直接经济损失 品牌伤害。我自己的结论是Travel Agent 必须建立在「真实可执行」的数据层之上模型只是对话壳。这是「为什么必须接外部 API」的第一层原因。3. Agent 为什么需要真实世界 API3.1 数据、时效、确定性三个绕不开的硬性条件要把一个 LLM 变成一个「能办事」的 Agent模型本身缺三样东西┌────────────────────────────────────────────────────────────┐ │ Agent 三层依赖 │ │ │ │ ① 数据层 ──→ 真实库存、真实价格、真实房型、真实退改政策 │ │ ② 时效层 ──→ 秒级 / 分钟级同步不能拿月度爬虫当实时 │ │ ③ 确定性层 ──→ 接口返回值必须可重放、可对账、可追溯 │ │ │ │ 三者缺一Agent 只能「表演」不能「履约」 │ └────────────────────────────────────────────────────────────┘第一层数据层。LLM 没法自己「看到」实时酒店库存必须有渠道把数据喂给 Agent。第二层时效层。酒旅库存和价格都是「分钟级变动」—— 早上 8 点和晚上 8 点的同一房型价差 30% 是常态。爬虫做月度全量可以做小时级变动根本扛不住。第三层确定性层。同一个 query调两次必须返回一致的结果除非库存真的变了。这要求数据源本身是「协议级接口」不是「抓页面解析 DOM」。3.2 自己爬 vs 调 API成本结构的本质差异很多同行第一反应是「我自己爬不就行了」。我早期也是这么干的结果三年下来发现自建爬虫有三个绕不开的坎维度自建爬虫协议级 API维护成本反爬升级一次重写一次数据源维护在接口侧调用方零感知法律风险反爬协议、ToS 灰色地带走授权商务对接合规可商用稳定性页面改版 → 抓取脚本挂 → 数据全断接口字段稳定破坏性变更提前公告数据质量页面价格是「展示价」实际下单价另算接口价格即履约价零价差这还没算上「多国家、多币种、多语言、海外酒店房型翻译」这些扩展项。所以结论是Agent 要变成「能办事」必须接协议级 API不是爬虫。但「接哪个 API」是个新问题 —— 这就引出了 MCP 协议。4. MCP 协议是什么4.1 一句话定义MCPModel Context Protocol是 Anthropic 在 2024 年底提出、2025 年逐步成为行业事实标准的模型 ↔ 工具通信协议。它解决的核心问题是让任意 LLM 都能用统一规范调用任意工具不再为每个工具写一套适配代码。打个比方没有 MCP 之前每个 LLMClaude / GPT / Gemini / Kimi调每个工具高德地图 / 美团 / 飞书日历 / 酒店 API都要写一套「胶水代码」有 MCP 之后工具侧按 MCP 规范暴露接口LLM 侧按 MCP 规范消费接口N × M 的适配问题变成 N M4.2 MCP 与 Function Call 的区别很多同行会把 MCP 跟 Function Call 混为一谈其实差很多维度Function CallMCP提出方OpenAI 2023Anthropic 2024协议性质厂商私有规范开放协议跨厂商可用工具位置调用方进程内in-process远程服务out-of-process上下文传递一次性 prompt 注入持久化 context会话级复用性换个 LLM 要重写同一份 MCP 服务Claude / Cursor / Cline 都能直接接Function Call 是「LLM 调用一个函数」MCP 是「LLM 接入一整套工具生态」。4.3 MCP 协议的三层价值站在 Travel Agent 开发者的角度MCP 协议带来了三层价值价值 1跨客户端复用写一份 MCP 服务Claude Desktop / Cursor / Cline / Cherry Studio / 国产 Agent 平台都能直接接。不用每接一个客户端重写一遍 SDK。价值 2上下文持久化Function Call 是「一问一答」传完参数就完事。MCP 是「会话级」工具可以持续观察 LLM 上下文、保留调用状态、记录历史。价值 3生态可组合MCP 是个开放协议第三方工具作者可以发布自己的 MCP 服务。今天我接的是酒店 MCP明天我加个机票 MCP、签证 MCP、租车 MCP对 Agent 来说都是「同一个调用模式」。┌──────────────────────────────────────────────────────────────┐ │ Travel Agent · MCP 协议层价值流 │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 酒店 MCP │ │ 机票 MCP │ │ 签证 MCP │ │ 租车 MCP │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ └──────────────┴──── MCP 协议层 ──────────────┘ │ │ │ │ │ ┌───────────────┼───────────────┐ │ │ ▼ ▼ ▼ │ │ Claude Cursor Cline │ │ │ │ 1 份 MCP 服务 3 套客户端直接消费 │ └──────────────────────────────────────────────────────────────┘这是「为什么要走 MCP 而不是直接调 API」的第二层原因。5. 为什么酒店场景特殊5.1 酒店库存的四大特征聊完「为什么需要 API」「为什么走 MCP」再问一层为什么酒旅场景里酒店比机票 / 火车票 / 租车都难做核心是酒店库存有四个「反直觉」特征特征具体含义对 Agent 设计的挑战强时效同一房型每小时都可能调价临近入住可能翻倍任何缓存超过 1 小时都不可靠强库存一间房就一间订完真没了不能用「概率」描述可订性必须精确到 0/1多渠道分价直售价、分销价、协议价、会员价差异显著Agent 选哪套价决定用户最终付多少多退改规则免费取消、限时取消、不可取消、阶梯收费并存Agent 必须按用户偏好做精准筛选这四个特征组合在一起酒店搜索 / 比价 / 锁房三个动作都需要接口级实时能力没有任何一个可以靠模型幻觉兜底。5.2 「看似简单的查询」背后的复杂度举个最常见的例子「帮我找下周五杭州西湖周边 3 公里内、带泳池、四星、含早的酒店预算 600 以内要能免费取消。」用户一句话Agent 背后要做的事意图解析把「杭州西湖周边 3 公里」转成lat30.246, lng120.137, radius3000标签匹配把「带泳池、含早」转成 hotel-tags 字典里的SWIMMING_POOL/BREAKFAST_INCLUDED星级筛选把「四星」转成star-ratings min4, max4价格筛选price_min0, price_max600退改筛选遍历每家酒店的 cancellation_policy标记free_cancellationtrue距离计算用经纬度算每家酒店到西湖的实际距离库存校验每家酒店查search-hotelshotel-detail双重确认价格排序按final_price升序这 8 步里有 6 步依赖真实数据源2 步依赖业务规则。LLM 能干的是「1 意图解析」「2 标签匹配」「5 退改筛选」「8 排序逻辑」,干不了的是「3 真实库存」「4 真实价格」「6 实时距离」「7 真实可订状态」。5.3 酒店 vs 机票库存模型差异很多 Travel Agent 同行上来先做机票因为机票库存看起来「简单」维度机票酒店库存模型座位O/D 维度房型 × 物理酒店 × 日期价格更新频率分钟级分钟级 凌晨批量调价渠道差异官网 / OTA / GDS 价差较小直签 / 分销 / 协议价差 10-30%退改复杂度起飞前 4/24/72 小时阶梯入住前 24/48 小时、旺季提前 7 天阶梯锁房 / 锁座航司极少提供锁座渠道级锁房 15-120 分钟是标配这是我坚定选择先做酒店 MCP、暂缓机票 MCP 落地的核心原因 ——酒店场景的复杂度更能验证 Agent 的真实履约能力。6. Hotel MCP 接口能力深度拆解项目仓库GitHub | https://github.com/DIDA-AI/Dida-hotel-MCP-CN效果示例图 1Travel Agent 真实对话流Hotel MCP 已接入┌──────────────────────────────────────────────────────────────────┐ │ Travel Agent · 对话窗口 │ ├──────────────────────────────────────────────────────────────────┤ │ 用户 │ │ 帮我找下周五杭州西湖周边 3 公里内、带泳池、四星、含早的酒店 │ │ 预算 600 以内要能免费取消。 │ │ │ │ Agent │ │ 已通过 hotel-mcp 拉取到 4 家匹配酒店按「价格 / 距离 / 评分」 │ │ 排序如下 │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ #1 西湖温德姆至尊豪廷大酒店 4★ ¥588 1.2km 可取消 │ │ │ │ #2 杭州西溪喜来登 4★ ¥612 2.7km 可取消 │ │ │ │ #3 杭州黄龙饭店 4★ ¥565 1.8km 限时 8 折 │ │ │ │ #4 西湖凯悦 4★ ¥695 0.4km 不可取消 │ │ │ └──────────────────────────────────────────────────────────┘ │ │ 已为「#1 西湖温德姆」启动 30 分钟临时锁房是否确认下单 │ └──────────────────────────────────────────────────────────────────┘6.1 整体接口设计实测下来RollingGo 酒店 MCP 的接口设计是「4 个核心 2 个增强」结构接口作用调用频次search-hotels区域酒店检索返回列表高频每次查询都调hotel-detail单家酒店详情房型、价格、库存、退改高频列表中前 N 家再深查hotel-tags标签字典查询泳池 / 含早 / 停车 等启动期 1 次后续缓存lock-room临时锁房15-120 分钟中频下单前调hotel-price-monitor价格变动监控回调式低频持续后台任务search-by-location经纬度 半径范围搜索中频按 LBS 检索6.2search-hotels核心参数表这是调用频次最高的接口参数设计直接决定 Agent 能不能精准筛出用户想要的酒店参数类型必填用途--citystring是城市中文名或英文名--check-in-datedate是入住日期YYYY-MM-DD--check-out-datedate是离店日期--star-ratingsint range否min,max格式--price-rangeint range否min,max格式--tagsstring list否来自hotel-tags的标准标签--radiusint否配合--lat/--lng使用--sort-byenum否PRICE/STAR/DISTANCE--pageint否分页游标--page-sizeint否单页条数建议 ≤ 206.3hotel-detail返回字段表进入详情后Agent 需要的关键字段字段含义Agent 用法room_types[].room_id房型唯一 ID锁房时使用room_types[].name房型名称展示给用户room_types[].final_price含税最终价排序 / 比价room_types[].breakfast是否含早筛选条件room_types[].cancellation.free_until免费取消截止时间退改判断room_types[].inventory_remaining剩余可订房量库存校验room_types[].flash_sale是否限时优惠突出展示hotel.policies.checkin_from入住最早时间行程规划hotel.policies.checkout_until离店最晚时间行程规划6.4 锁房接口的工程化意义lock-room是 Hotel MCP 区别于「普通酒店搜索 API」的关键增强# 锁房调用示例Python SDKfromrollinggo_mcpimportHotelMCP clientHotelMCP(api_keymcp_xxx)# 1. 先 search 拿到候选candidatesclient.search_hotels(city杭州,check_in_date2026-07-10,check_out_date2026-07-12,star_ratings(4,4),price_range(400,700),tags[SWIMMING_POOL,BREAKFAST_INCLUDED],sort_byPRICE,page_size10)# 2. 取 top 3 深查top3[c.hotel_idforcincandidates[:3]]details[client.hotel_detail(hid,check_in_date,check_out_date)forhidintop3]# 3. 选最便宜的免费取消房型启动锁房targetmin(details,keylambdad:d.cheapest_free_cancellation_room().final_price)lockclient.lock_room(hotel_idtarget.hotel_id,room_idtarget.cheapest_free_cancellation_room().room_id,hold_minutes30,# 锁 30 分钟idempotency_keyfagent-{uuid4()}# 幂等键防重复)# 4. 把锁房 token 给到用户下单页return{lock_token:lock.token,expires_at:lock.expires_at}锁房的核心价值是「把『查询』和『下单』之间的 5-30 分钟用户决策时间变成可被 Agent 独占的预留库存。没有锁房Agent 给用户的报价可能 30 秒后就失效有了锁房用户决策期内价格 库存都被锁死Agent 才真正做到了「能办事」。6.5 价格回调 vs 轮询Hotel MCP 的回调式盯价很多 Agent 同行做酒店监控第一反应是「写个 Cron 每 5 分钟查一次」。Hotel MCP 提供的是「回调式盯价」—— Agent 设定一个监控规则目标酒店 期望价格MCP 在价格跌破阈值时主动回调告知 Agent不用 Agent 自己轮询。┌─────────────────────────────────────────────────────────────┐ │ 价格监控对比 │ │ │ │ ❌ 轮询式自建方案 │ │ Agent ──→ 每 5 分钟调一次 search-hotels │ │ │ ↓ │ │ │ 100 家酒店 × 1 天 28800 次调用 │ │ │ ↓ │ │ └──────→ 90% 调用都「无变化」 浪费 │ │ │ │ ✅ 回调式Hotel MCP │ │ Agent ──→ 注册监控规则hotel_id target_price │ │ │ ↓ │ │ └──────→ 价格变化时 MCP 主动回调HTTP POST │ │ ↓ │ │ 仅在「真降价」时推送0 浪费 │ └─────────────────────────────────────────────────────────────┘回调式对 Agent 来说是质变调用量从「日均万级」降到「日均百级」Agent 可以「订阅」多家酒店用户一提问就拿到最新底价完全省掉自己维护 Cron / 定时任务 / 消息队列的工作量6.6 配置示例把 Hotel MCP 接到 Codex// ~/.codex/mcp_config.json{mcpServers:{hotel-mcp:{type:streamable-http,url:https://mcp.rollinggo.cn/mcp,headers:{Authorization:Bearer mcp_xxxxxxxxxxxxxxxx}}}}# 启动 Codex 后调用示例importsubprocess# Codex 自动加载 MCP 工具Agent 可直接调 hotel-mcp.search-hotels# 测试连通性resultsubprocess.run([codex,exec,--mcp-tool,hotel-mcp.list_available_tools],capture_outputTrue,textTrue)print(result.stdout)# 列出 search-hotels / hotel-detail / lock-room 等写在最后LLM 解决了「能聊」MCP 解决了「能调用协议」Hotel MCP 解决了「能在酒旅场景履约」。三层缺一不可。Travel Agent 的护城河不在「用哪个 LLM」而在「能不能给用户提供真实可下单的酒店 机票 全链路服务」。本篇为社群开发者实操手记仅供生态内技术对接参考。如需申请 RollingGo 开发者权限、MCP 接口文档、Skill 模板可走官方生态共建通道申领。如果你也对旅行 AI 感兴趣欢迎在评论区聊聊你最想用 AI Agent 解决什么旅行场景的问题本文收录于 RollingGo 酒旅开发者社群 | 执笔生态共建开发者