用途
Booking 技能是面向用户直接预订请求的入口，覆盖航班、酒店、餐厅和活动门票（体育、演唱会、剧院等）四类交易。它负责将“帮我订明天两人的晚餐”“订下周二从 SFO 到 JFK 的航班”这类请求转化为经过验证的预订或购买，并尽可能减少用户操作。此外，它还可处理由旅行规划（Travel Planning）委托的、有边界的实时可用性或价格检查，但不承担行程规划职责。
主要能力
- 支持四类预订：航班、酒店、餐厅、活动门票。
- 主动收集上下文：在提问前，会检查持久偏好、已连接邮箱中的确认/收据/会员信息、已登录的提供商账户、日历冲突、钱包或卡档案、实时库存与提供商条款。
- 按最佳路径搜索：优先使用已连接的原生提供商或认证的第一方账户，其次连接预订平台比较，再使用提供商官网的认证浏览器、信誉良好的市场或聚合器，最后在工具可用时使用电话。
- 呈现少量真实可订选项（通常三到五个），包含区分性细节与含税费总价，并说明首选项胜出原因。
- 在提交前提供紧凑的最终审核，涵盖项目、价格、费用、取消/退款/变更/缺席条款及支付来源的安全标签。
- 执行后验证：只有提供商返回确认页面、参考号、票证或明确已预订状态后才报告预订成功；若提交结果模糊，会检查账户并搜索确认邮件，避免重复预订。
- 返回简洁回执，包含人类可读的预订详情、确认/参考号、已支付或承诺总额及最重要的截止日期。
使用方式
技能通过自然语言请求触发。用户直接表达预订意图即可，无需填写问卷。技能会先解析相对日期为确切本地日期，识别预订类型和最少交易字段，并利用已授权来源填充信息。仅在缺失事实会导致搜索差异大、预订错误或无法安全获取且交易必需时提问，且保持最多一个未回答问题。搜索时按类别参考的路由进行，例如航班需先阅读 references/flights.md 和 presentation.md，酒店、餐厅、门票各有对应参考文件。浏览器结账前需阅读 browser-booking.md。呈现选项时，航班比较优先使用原生结构化航班列表（若客户端支持），其他预订类型使用纯 Markdown。
适用场景
- 用户有明确预订意图的直接请求，例如“订明天两人的晚餐”“找周五 SoHo 的酒店”“买 Patriots 下一场比赛的票”。
- 旅行规划委托的有限实时可用性或价格检查。
- 需要利用已保存偏好、忠诚度、积分或信用额度的预订。
限制
- 不用于规划旅行、构建多部分行程或填充用户未要求的相邻需求（如交通、托儿、活动、餐食）。
- 不用于无预订意图的“去哪里”探索。
- 不用于事实性问题（如营业时间、评论、航班状态）。
- 不用于更改或取消现有预订，除非请求明确要求且相关提供商工具支持。
- 若直接请求包含多个预订，会逐一处理但不扩展为更广泛的旅行或场合计划。
- 不编造合法姓名、年龄、身份证号、无障碍需求、饮食限制或支付详情。
- 不要求用户将敏感值粘贴到聊天中，除非当前提供商技能明确允许该字段用于结账；支付卡数据和账户凭证从不允许。
- 不暴露内部提供商名称、命令、标识符、报价 ID 或工具选择。
- 不静默替换不同日期、机场、酒店、餐厅、活动、座位等级、票价等级或实质性不同价格。
- 不将完整支付、护照、旅行者安全或忠诚度号码包含在回执中。
- 若持久记忆不可用，偏好资料仅限当前会话，不会暗示其会保留。
暂未提供
该技能的收费、价格、平台兼容性、具体效果指标等未在资料中说明。