企业官网建设流程全解析

技术团队在选择RollingGo MCP 接入方案时，需要根据业务阶段（MVP 验证 vs. 生产级应用）和用户体验要求（跳转支付 vs. Agent 内闭环）来做出判断。本文从功能、技术实现、适用场景等维度对两种方案进行对比，帮助团队快速定位最适合自己的接入方式。

概述：两种接入模式的核心差异
RollingGo MCP 提供两种集成方案，以满足不同业务阶段和开发需求。

快速接入模式（3 Tool）采用 API Key 认证，提供酒店搜索、详情查看和标签获取 3 个核心工具。开发团队参考文档即可在 5 分钟内完成接入，用户需跳转至 H5 网站完成支付。

深度集成模式（7 Tool）采用 OAuth 2.0 授权码模式，提供从搜索到订单管理的 7 个工具链，支持用户在 Agent 内完成支付闭环，实现全链路交易。需联系官方获取接入指南。

总体对比：6 个维度的快速决策参考
认证方式：快速接入模式采用 API Key 认证（Authorization: Bearer <YOUR_API_KEY>）；深度集成模式采用 OAuth 2.0 授权码模式。
工具数量：快速接入模式提供 3 个工具（searchHotels、getHotelDetail、getHotelSearchTags）；深度集成模式提供 7 个工具（含 hotelPriceConfirm、createHotelBooking 等）。
预订流程：快速接入模式下用户需跳转 H5 网站完成支付；深度集成模式支持在Agent 内闭环完成支付和下单。
支付方式：快速接入模式为 H5 网站支付；深度集成模式支持 Agent 内支付（无需跳转）。
接入时长：快速接入模式可在 5 分钟内快速接入；深度集成模式需联系获取接入指南。
适合人群：快速接入模式适合快速验证 / MVP 场景团队；深度集成模式适合生产级应用 / 追求极致体验团队。
功能差异详解：从搜索到支付的全链路对比
快速接入模式功能范围

• 基础信息查询
  • searchHotels：酒店搜索
  • getHotelDetail：酒店详情查看
  • getHotelSearchTags：搜索标签获取
• 支付流程：用户选择酒店后，跳转至RollingGo H5 网站完成支付。
• 功能定位：实现"搜索→详情→跳转"的信息流转路径，适合作为流量引导或信息展示工具。
  深度集成模式功能范围
• 基础信息查询：与快速接入模式相同（searchHotels、getHotelDetail、getHotelSearchTags）。
• 交易核心功能
  • hotelPriceConfirm：实时价格确认与锁定
  • createHotelBooking WithPaymentURL：创建订单并生成支付链接
• 支付与订单管理
  • 通过 PaymentURL 在 Agent 内直接完成支付
  • searchHotelOrders：订单列表查询
  • getHotelOrderDetail：订单详情查看
• 功能定位：实现"搜索→确认→下单→支付→管理"全链路闭环，提供完整的交易与售后服务能力。
  两种模式在支付流程上的差异最为显著。快速接入模式在用户确认预订意向时中断体验，引导至外部 H5 页面；而深度集成模式通过 createHotelBooking WithPaymentURL 工具生成的支付链接，可无缝嵌入 Agent 界面，保持用户操作环境的连续性与一致性。
  接入方式对比：技术实现与前置准备
  快速接入模式（3 Tool）
  接入步骤

1. 申请 API Key：从RollingGo开发者平台获取 Bearer Token 格式的 API Key。
2. 集成工具：在 Agent 中调用 searchHotels、getHotelDetail、getHotelSearchTags 三个工具。
3. 配置跳转：在酒店详情页配置跳转至RollingGo H5 支付页面的链接。
4. 测试验证：进行搜索、详情查看及跳转链路测试。
   技术门槛与准备

• 技术门槛：较低，前端开发人员即可独立完成。
• 前置准备：有效的 API Key、基础开发环境。
• 开发周期：1-2 天可完成集成与测试。
  深度集成模式（7 Tool）
  接入步骤

1. 配置 OAuth 2.0：按照指南注册 OAuth 应用，配置授权回调地址。
2. 集成工具链：依次集成 7 个工具，重点实现 hotelPriceConfirm 的价格确认逻辑与 createHotelBooking 的订单创建及支付链接处理。
3. 实现支付回调：部署服务端接口，处理支付成功或失败的回调通知，更新订单状态。
4. 完整测试：进行端到端的全链路测试，包括支付流程和订单查询。
   技术门槛与准备

• 技术门槛：较高，需要前后端协同开发，涉及支付安全、状态同步与回调处理。
• 前置准备：OAuth 应用配置、支付回调公网地址、订单数据库设计、合规审核材料。
• 开发周期：通常需要 1-2 周或更长，取决于业务复杂度。
  适合人群与场景：明确各自的最佳应用
  快速接入模式适用对象
  适合团队
• 处于创业早期，希望快速验证酒店搜索功能与用户需求的团队。
• 开发内部工具（如员工差旅助手）的团队，对用户体验要求相对宽松。
• 开发周期被严格限制（例如要求一周内上线），资源紧张的项目组。
  典型场景
• MVP 产品验证：在产品概念验证阶段，快速集成酒店搜索能力，收集用户行为数据。
• 流量引导平台：内容社区或比价平台，将有意向的用户引导至RollingGo官网完成交易，赚取引流佣金。
• 轻量级内部系统：公司内部的行政或差旅报销系统，仅需查询和跳转功能。
  深度集成模式适用对象
  适合团队
• 拥有成熟产品，追求极致无缝用户体验的旅行类 App 或电商平台。
• 业务模式依赖在自有平台内完成交易闭环，以提升用户留存与转化率。
• 需要为用户提供订单跟踪、售后支持等完整服务链条的平台。
  典型场景
• 在线旅游代理（OTA）平台：需要在自有 App 内完成从搜索到支付的全流程，并管理用户订单。
• 企业差旅管理系统（TMC）：与企业内部报销、审批流程深度集成，要求统一的订单管理与数据对接。
• 超级 App 或聚合平台：将酒店预订作为一项内置服务，要求体验与其他服务保持一致，避免跳出。
  核心决策因素可归纳为四点：业务所处阶段（探索验证期还是成熟运营期）、对用户体验一致性的要求、可投入的开发资源与时间，以及对订单管理能力的需求。
  决策建议：如何根据需求选择接入方式
  选择接入方式是一个基于多重约束的决策过程，建议按以下逻辑进行判断：
  决策逻辑链

1. 评估业务阶段：产品是否已跨越 MVP 验证期，进入稳定增长或成熟运营阶段？
2. 明确体验要求：用户支付流程的跳出，是否会对产品核心指标（如转化率、留存率）造成不可接受的折损？
3. 盘点开发资源：是否有足够的后端开发资源与时间（至少 1-2 周）来处理 OAuth 集成、支付回调等复杂逻辑？
4. 确认管理需求：业务是否需要后续的订单查询、状态跟踪或用户售后服务功能？
   选择快速接入模式（3 Tool）的明确信号：项目处于 MVP 验证阶段，可以接受用户跳转支付以缩短上线时间，开发周期紧张（少于 1 周），暂时不需要订单管理功能。
   选择深度集成模式（7 Tool）的明确信号：产品已进入成熟期，要求 Agent 内闭环体验以保障用户体验与转化率，拥有充足的开发资源（2 周以上），需要完整的订单管理和售后支持体系。
   对于部分团队，可以考虑混合演进策略：初期采用快速接入模式验证市场需求与技术可行性；待用户量增长、模式跑通后，再规划迁移至深度集成模式，以实现体验升级与功能深化。
   联系与资源：获取进一步支持

• 快速接入文档：快速接入模式（3 Tool）的完整 API 文档、SDK 及示例代码可在RollingGo官方开发者门户直接获取，无需额外联系。
• 技术支持：集成过程中遇到的技术问题，可通过官方文档中的支持渠道或发送邮件至 contact@rollinggo.ai 进行咨询。
• 版本更新：建议订阅RollingGo官方技术博客或更新日志，及时了解 API 变更、新功能发布及最佳实践。
  对于追求快速验证的团队，3 Tool 模式让你在一个下午就能完成集成，把宝贵的开发时间留给核心业务逻辑；对于追求极致体验的团队，7 Tool 模式提供从搜索到订单管理的全链路闭环，让用户在你的 Agent 内完成每一次完美预订。
  无论选择哪种模式，RollingGo MCP（rollinggo.store）的目标始终一致——让酒店预订能力像水电一样即插即用，成为 AI 应用的标配功能。
• 海量库存：覆盖全球 200+ 国家/地区，100 万+ 酒店资源，高星酒店与特色民宿一网打尽。
• 价格优势：直连酒店集团与批发商，确保协议价与实时房态，佣金政策透明友好。
• 技术友好：完善的 MCP 协议支持，清晰的 API 文档，专业技术团队全程陪跑。
• 合规可靠：持牌经营，资金安全，订单履约率行业领先，个人开发者和企业都能申请。
  AI 时代的酒店预订，不该是复杂的集成难题。RollingGo MCP 已经铺好了路，剩下的，就是让你的用户享受丝滑的预订体验。