核心用法
本技能通过 StayingAPI 提供两大核心能力：实时价格查询与跨 OTA 比价。用户可通过 /v1/price 获取单个 Google Hotels 房源在指定日期的真实报价，或使用 /v1/price-compare 在单次调用中获取该房源在多个平台（如 Booking.com、Airbnb、Vrbo）的报价，并自动计算最低价（min）与中位数价（median）。
使用时需提供 STAYINGAPI_KEY 环境变量，支持 stay_test_ 前缀的免费沙盒密钥用于零成本测试。核心参数包括平台类型（platform）、房源 ID（listingId 或 URL）、入住/退房日期、成人及儿童人数。对于需爬取数据的异步请求，系统返回 202 状态码与轮询地址，用户需按 Retry-After 指引轮询直至任务完成。
显著优点
1. 真实价格保障：Live 密钥调用返回的价格均为实时抓取，非缓存或模拟数据，且承诺绝不会返回错误房源的价格。
2. 统一 Schema 设计：Google Hotels、Airbnb、Booking.com、Vrbo 四大平台数据格式一致，大幅降低多平台接入成本。
3. 智能比价计算：/v1/price-compare 自动聚合多平台报价并输出 min/median，无需用户自行计算。
4. 零成本测试：沙盒密钥完全免费，且失败、空结果、被拦截的请求均不计费，降低试错成本。
5. MCP 支持：兼容 Model Context Protocol，可通过 OAuth 2.1 + PKCE 安全接入，无需将密钥硬编码至 Agent。
潜在缺点与局限性
1. 覆盖不均衡：并非所有房源都能返回多平台比价结果，部分房源仅返回单一聚合最低价，需读取 offers.length 判断是否为真实跨平台对比。
2. Google 平台功能缺口：Google Hotels 暂无房源详情（listing）与评论（reviews）端点，需借助其他平台 ID 获取完整信息。
3. 异步调用复杂度：实时爬取场景需处理 202 轮询逻辑，增加了调用方的实现复杂度与等待时间。
4. ID 来源限制：Vrbo 房源若从非 /v1/search 渠道获取 ID，可能导致解析失败（all_actors_failed）。
5. 外部依赖风险：完全依赖 StayingAPI 服务可用性与 Google Hotels 数据开放策略，若上游接口变更或限流，功能将直接受影响。
适合的目标群体
- 差旅规划用户：需快速确认特定酒店在不同平台的价格差异，锁定最优预订渠道。
- 比价类 Agent 开发者：构建旅行助手、智能行程规划工具，需标准化多平台酒店数据接口。
- 运营监控场景：需追踪特定房源价格波动的民宿运营者或酒店收益管理人员。
- 预算敏感型消费者：在预订前希望确认"是否还有更低价"的决策辅助需求。
使用风险
- 服务可用性：依赖
api.stayingapi.com网络可达性，国内用户可能存在访问延迟或不稳定风险。 - API 限流：轮询频率过高将触发 429 限流（120 次/分钟），需合理设计退避策略。
- 密钥管理：虽支持 MCP 安全接入，但若采用环境变量方式，需确保
STAYINGAPI_KEY不被泄露至日志或版本控制。 - 数据时效性：异步任务完成时间取决于上游网站响应，极端情况下可能出现较长时间的等待或超时。
- 供应商中立性：StayingAPI 为独立第三方服务，与 Google Hotels 无官方合作关系，品牌归属与长期服务稳定性需自行评估。