UCP住宿预订草案公开：Google AI模式订酒店要换成开放标准，接入不影响排名

摘要：通用商务协议UCP在9月25日发布了住宿预订能力的第一版草案，代号dev.ucp.lodging.booking，可以走REST或MCP，覆盖查房价房态、填入住人、分期付款和取消政策。Google的开发者问答写明，未来几个月AI模式里的酒店预订会改用这套开放标准；接入与否不影响酒店和房价在列表里的排名，接入的报价会多一个直接预订按钮；酒店或预订平台仍是交易的商户，客户数据归自己。草案目前只支持一间房，数据模型可能有破坏性改动，Google那边还只有候补名单。

在Google搜索框里说一句“下个月去东京住三晚，要能免费取消的”，然后直接在对话里把房订了，不跳转酒店官网。8月底，美国的英文用户已经能这样订酒店。现在的问题是，这背后的接口用什么标准。

Search Engine Journal的Matt Southern在9月28日的报道里给了答案：通用商务协议（UCP）发布了住宿预订草案，Google说接下来几个月会把AI模式的酒店预订换到这套标准上。这篇以那篇报道为主体，对照UCP草案原文和Google的开发者文档，把规范里写了什么、Google承诺了什么、酒店和做旅游SEO的人该关心什么讲清楚。

站内写过UCP在电商上的来龙去脉，比如UCP让电商SEO转向AI选品，也写过小商家接ACP还是UCP。这次是它第一次正式走出零售，进入住宿行业。

酒店预订是怎么一步步接到UCP上的？

把几个时间点串起来看，节奏很清楚。

8月27日那次上线，按SEJ当时的报道，用户描述行程和偏好，AI模式给出带评论和细节的酒店列表，已集成的合作方会多一个在Google上继续的选项，用户选房型、看取消政策、用Google Pay付款，酒店或预订平台是交易商户并负责客服。首批预订平台是Booking.com、Expedia、Hotels.com、Priceline和Trip.com，酒店集团是精选国际、希尔顿、洲际、万豪和温德姆。

当时Google把这些公司叫作已集成的合作方，没说它们是不是都用了UCP。现在的说法是：未来几个月，AI模式的酒店预订会采用这套开放标准。哪些现有合作方会迁移、什么时候切换，Google的问答和住宿页都没写。

UCP住宿预订草案到底规定了什么？

按UCP在GitHub上的草案发布公告，这项能力的代号是dev.ucp.lodging.booking，由住宿技术委员会起草，现在开放公众反馈。公告列出的重点是四块：实时查价查房、入住人信息登记、复杂的付款安排、和UCP已有的身份关联与支付处理组件打通。

规范正文页面顶部挂着醒目的提示：这是草案，数据模型、协议绑定和操作流程都在快速迭代，可能出现破坏性改动。下面讲的内容，都要带着这句话读。

五个操作和六种状态

规范定义了五个逻辑操作：创建预订会话、查询会话、更新会话（整体替换）、完成预订、取消会话。平台可以通过REST接口调用，也可以通过MCP调用。

一次预订会话会在六种状态之间流转，状态由商家设置，平台根据返回的消息决定下一步做什么。

需要转交用户的情况又细分两种：一种是商家需要的信息接口收集不了，会话还不完整；另一种是会话已经完整，但政策、法规或权益规则要求用户本人确认。两种都通过continue_url交给用户在商家那边处理。

出错了怎么处理

每条错误消息都带一个严重程度，告诉平台该怎么办。

草案列了四个标准错误码：房间或临时锁定的库存已经没了（inventory_exhausted），分配的入住人数超过房间容量（occupancy_exceeded_capacity），付款失败（payment_failed），以及完成时资格声明核验不通过（eligibility_invalid）。做过酒店直连的人看到这几条应该很眼熟，都是线上订房最常见的翻车点。

遇到需要加强验证的情况，比如欧洲支付规定里的强客户认证、3D Secure、生物识别或身份核验，商家会在响应里列出待办动作。动作没完成，商家就不能让会话进入可完成状态，要退回未完成或转交用户，并给出一条可恢复的错误消息，指向那个具体动作。

会话会过期，锁房有两种做法

预订会话是确认前的临时资源。商家可以给一个过期时间，说明会话状态、报价和临时锁定的库存能保留多久。锁房有两种做法：在过期前临时锁定库存；或者不锁，每次更新时实时核对房态，到完成预订那一刻再真正分配。用户中途放弃，平台可以调用取消操作主动释放库存，否则到了过期时间自动释放。商家也不能在价格改了之后不先把新总价返回给平台就直接完成预订。

一次住宿由什么组成

规范把一次预订分成一个或多个住宿单元，每个单元绑定五样东西：房型、价格方案、入住和离店日期、入住人数、入住人分配。草案的数据模型允许一单包含多个住宿单元，但Google问答里说的第一个里程碑只支持一间房，多间房可能作为以后的扩展。

几个设计细节对隐私和客服都有影响。

• 付款人和入住人分开：付款人是签合同、付钱、负责联系的一方，入住人是实际住进去的人，付款人可以同时也是入住人。这样公司订房、帮别人订房都好处理。
• 入住人的编号由平台生成，只在这一次会话里有效，不能用跨商家的长期追踪标识，也不能放个人身份信息；商家也不能靠这个编号把不同会话里的人关联起来。
• 预订进入可以完成状态之前，平台不应该发送编号以外的入住人身份字段，而且只发商家通过消息明确要的那些。护照号、国籍、出生日期这类额外信息，要由商家逐项通过消息协商。
• 必须有一个明确的主联系人：付款人或被标成主要入住人的客人，要有法定全名和联系方式，否则商家不能把会话推进到可以完成的状态。
• 商家要按房型容量核对入住人数，儿童按入住当天的周岁年龄归入年龄段；预订完成后，只要拿得到邮箱，商家必须发确认邮件。

请求里还可以带出行目的，常见值是商务和休闲，平台可以发别的值，商家不认识的就当没指定。另有两类信号：一类是买家所在地区、语言这类参考信息，用来做相关性和本地化，商家可以在有更可靠信息时忽略；另一类是平台为授权和防欺诈提供的环境数据，规范要求必须来自平台直接观察或可独立验证的第三方证明，不能是买家自己声称的。

规范还区分了两个阶段：搜索和报价阶段给的价格、房型、政策摘要都是临时的；一旦创建预订会话，商家就要查实时库存（或按自己的政策临时锁房）、确定价格规则、核对房间容量、算出有约束力的总价并附上取消条款。真正的订单要到完成预订那一步才生成。

价格、税费和取消政策怎么写进协议？

这一部分最能看出酒店业和零售的不同，也是做旅游站的人最该细看的。

全包价：总价只能有一个

规范要求住宿预订遵守全包价规则，并点名了美国联邦贸易委员会和欧盟的价格透明规定。具体做法是：价格明细里每个会话必须有且只有一条总价，其余各项都是加数，小计、服务费、税费、折扣加起来必须正好等于总价；入住前要让客人看到这次住宿的全部费用，隐藏收费或没披露的到店费用都算违规。

规范给了一个东京三晚的例子，金额单位是日元。

64,000加6,400加6,000加1,200，正好77,600。到店才收的那两笔，照样要算进总价、摆在客人眼前。很多酒店在比价网站上只报房费，到前台再收一笔设施费，按这套规范是行不通的。

价格明细和付款时间分开管

价格明细回答的是一共多少钱，付款安排回答的是什么时候付。规范把付款安排分为一个或多个分期，每期有三种类型：完成预订时立即付、未来某个日期或事件时付（比如入住时付尾款）、在酒店现场付（比如当地旅游税、强制设施费）。所有分期加起来必须等于总价。

第二个例子是三晚、每晚400美元的定金加尾款方案，金额按美分记：房费120,000、服务费3,000、州住宿税12,000，总价135,000。定金是第一晚40,000加服务费3,000加首期税费4,000，共47,000，预订时付；剩下的88,000延后支付。两笔加起来正好135,000。

如果有到店才能收的强制税费，商家应该在消息里给出披露类警告，指向对应的那一期付款，写明税率、减免条件和支付方式。会话进行中房价或税费变了，商家要返回重新算好的总价，并用totals_changed警告标出来；金额变化需要客人明显注意的，平台必须展示，不能自动关掉或藏起来。

还有一个行业习惯被写进了规范：提前付款享受的优惠，通常做成单独的价格方案，比如不可退款的提前预付价和可灵活取消的最优价，很少做成同一价格方案下的几种付款选项。同一个价格方案如果提供定金加尾款这类灵活付款，商家再在付款安排里给出分期明细。

取消政策变成机器可读

取消政策扩展给每条取消条款加了一个三选一的标记：现在可以免费取消、可以取消但有罚金（或已进入罚金期）、不可退款。另有一段给人看的说明，写清截止时间、时区和罚金规则，还可以附上完整条款的链接。

扩展文档说得很直白，这样平台不用离开去解析外部政策页面，就能回答这单能不能取消、免费还是要罚钱、是不是完全不退。对AI助手来说，这正是用户最常问的问题之一。

付款：酒店不用自己过PCI认证

规范写明，商家仍是交易的商户，通过这项能力接受刷卡付款不需要自己通过PCI DSS支付卡安全认证。支付处理方式从商家公开的UCP档案里发现，档案放在网站的/.well-known/ucp路径下。完成预订时必须带付款信息；不需要刷卡担保的到店付或延后付预订，传一个空的付款对象即可。

还有一条底线：除非支持AP2的代理支付授权扩展，预订必须由用户本人在可信的界面上手动确认。说白了，眼下AI可以帮你查、帮你填，最后那一下得你自己点。

Google承诺了什么，又有哪些没说？

Google这边的说法集中在UCP住宿版开发者问答里，最后更新于9月24日。几条对酒店和旅游平台最关键的话：

• 排名不受影响：选择接入预订集成，不影响Google怎么给你的酒店和房价在列表里排序，列表的体验保持一致；接入UCP的报价会多一个直接预订选项。
• 商户身份不变：你是交易商户，客户关系、预订数据和入住后的服务都归你，预订适用你自己的条款，Google会展示给客人，客人必须在流程里接受。
• 能分清流量来源：双方按规范交换预订、订单和交易的生命周期事件，你能区分哪些流量和付款来自Google的AI界面，哪些来自自己的网站和App。
• 实时核价：在显示最终预订按钮之前，Google会通过你的接口实时核对价格和房态。
• 支付：网站不需要支持Google Pay接口，但你的支付服务商要能处理Google的支付令牌，Google说多数大型支付服务商都支持；已有的Google Pay配置（比如限制某些卡种）不会沿用，要为UCP渠道单独配置。
• 营销：因为你是商户，你拿到的客人信息和直订一样，适用常规隐私法规和同意规则；Google计划以后在预订流程里加一个让用户主动同意接收营销信息的选项。

问答还提到UCP是模块化的，商家可以自己选要支持哪些能力，用接口、MCP或A2A接都行；协议和AP2、A2A、MCP这些已有标准兼容，并且是和旅游酒店业的头部公司共同设计、开源发布的。

Google也说，AP2可以作为UCP里的支付层，用于以后AI代理自主完成交易的场景，但没说必须用。

没说的部分同样重要。AI模式切换到UCP的具体日期没写，现有合作方谁会迁移没写；Google的住宿页面只有一个候补名单入口，详细的接入说明和规范写着即将推出。想接的酒店，现阶段能做的就是排队。

还有一个容易被误读的点。排名不受影响，说的是接不接入预订集成本身不改变排序。可接入的报价多一个直接预订按钮，用户在同样的位置上看到的东西不一样了，点击和转化会不会因此倾斜，Google没有给数据，也很难事先知道。

酒店和做旅游SEO的人现在该做什么？

这套标准离普通单体酒店还有一段距离，候补名单、草案状态、首批合作方都是大集团和大平台。不过方向已经很清楚，有几件事现在做不吃亏。

先把价格透明做到位

全包价、到店费用提前披露、价格明细加总等于总价，这几条既是UCP的要求，也是各国消费者保护规定的方向。官网和各分销渠道上的报价，最好现在就按这个标准整理：房费、服务费、到店收的设施费和当地税，每一笔写清楚、能加总。将来无论接UCP还是别的代理协议，数据都是现成的。

把取消政策写成结构化的

可免费取消、有罚金、不可退，这三档以后会直接被AI读取。官网上的取消政策别只是一段长长的法律文字，截止时间、时区、罚金比例要能被单独提取。这对搜索里的富结果和AI回答的准确性都有好处。

在数据里给AI渠道留位置

Google承诺用生命周期事件区分AI界面带来的预订。现在就在分析工具和订单系统里预留渠道字段，等接入时能直接单独统计出这部分订单和收入，不用事后返工。

这件事比看上去重要。商户身份留在酒店手里，意味着订单进的是你自己的系统，可如果渠道字段没留，这些订单在报表里就会混进直订，你会误以为官网转化变好了，而真正的来源是Google的AI界面。等哪天这个渠道的规则变了，你连受影响的盘子有多大都说不清。

内容和曝光仍然靠老功夫

AI模式先要把你的酒店列出来，用户才会看到预订按钮。列表靠的是酒店信息、评论、价格数据和网页内容这些老基础。旅游网站目的地页同质化、季节波动大的问题，站内在旅游类网站SEO里讲过。AI模式对点击的影响，可以参考AI模式随机实验：在实验里，强制用AI模式让外部点击率明显下降，对靠官网直订的酒店，这是需要认真对待的信号。

国内团队怎么看

技术委员会里有Trip.com，规范的东京示例用的也是亚洲常见的到店税费场景。做出境游、做海外酒店分销的国内团队，可以直接读GitHub上的草案并提反馈，这是少有的在标准定型前参与的机会。对接海外OTA的中小酒店，短期内大概率通过平台间接接入，留意合作平台的通知就行。

常见问题解答

UCP住宿预订草案是什么时候发布的？

UCP项目在9月25日宣布，住宿预订能力的第一版草案已合并进协议的GitHub仓库，开放公众反馈。

Google的AI模式已经在用UCP订酒店了吗？

Google的问答说未来几个月会采用这套标准。8月27日上线的AI模式酒店预订用的是已集成合作方，Google没说它们是否都用UCP。

接入UCP会提高酒店在AI模式里的排名吗？

Google的问答写明不会，接入预订集成不影响酒店和房价的排序，只是接入的报价会多一个直接预订选项。

通过AI模式订房，客人数据归谁？

归酒店或预订平台。它们是交易商户，保留客户关系、预订数据和入住后的服务，预订适用它们自己的条款。

酒店要支持Google Pay吗？

网站不需要支持Google Pay接口，但支付服务商要能处理Google的支付令牌，卡种限制等设置要为UCP渠道单独配置。

酒店需要通过PCI DSS认证吗？

按草案，商家通过这项能力接受刷卡付款，不需要自己通过PCI DSS认证。

AI能自动帮用户下单吗？

目前不能。除非支持AP2代理支付授权扩展，预订必须由用户本人在可信界面上手动确认。

草案支持一次订多间房吗？

数据模型允许一单包含多个住宿单元，但Google说第一个里程碑只覆盖一间房，多间房可能作为以后的扩展。

到店才收的税费要怎么处理？

必须算进总价，并在付款安排里标成到店支付，商家还应给出披露类提示，写明税率、减免和支付方式。

取消政策在协议里怎么表示？

取消政策扩展用三档标记：可免费取消、可取消但有罚金、不可退款，另附截止时间、罚金说明和完整条款链接。

UCP住宿草案是谁制定的？

由UCP的住宿技术委员会起草，成员包括Amadeus、Booking.com、Expedia、Google、希尔顿、万豪和Trip.com，也有开源社区的贡献者参与。

预订会话会过期吗？

会。商家可以给出过期时间，报价和临时锁定的库存只在这段时间内有效；用户中途放弃时，平台可以主动取消释放库存，否则到期自动释放。

订房过程中房价变了怎么办？

商家要返回重新计算的总价，并用价格变动警告标出来；需要客人明显注意的，平台必须展示，不能自动关闭或隐藏。

单体酒店现在怎么接入？

Google的UCP住宿页目前只有候补名单，详细接入说明还没发布。单体酒店短期内更可能通过已合作的预订平台间接接入。

权威参考资料