核心用法
Brek AI Partner Core Chat 是一个面向酒店搜索与预订场景的第三方 AI 助手集成技能。开发者通过该技能将 Brek 的智能对话能力嵌入自有产品，实现酒店查询、比价、预订及支付的全流程自动化。
执行流程：
1. 会话创建：每个终端用户需独立创建会话（POST /sessions），使用稳定的 actorId 标识用户身份
2. 事件驱动交互：后续所有对话通过 POST /events 发送至同一会话
3. 状态同步：按需调用 GET /sessions/{sessionId} 获取最新对话状态
关键安全机制：
- 幂等性控制：所有写操作（预订、支付确认、取消等）必须携带确定性生成的
idempotencyKey，格式为<partnerId>:<sessionId>:<kind>:<clientActionId>，防止重复扣款或重复预订 - 熔断机制：遭遇连续 5xx 或超时故障时自动开启断路器，避免级联故障
- 速率限制：严格遵循 429 响应的
retry-after头，实施指数退避重试
支付安全：
- 严禁在聊天中请求、传输或存储原始卡号、CVV、完整 PAN
- 仅接受支付服务商托管字段返回的 tokenized
paymentMethodId - 所有支付确认动作（
action_confirm_payment_card）前必须获得用户明确授权
显著优点
- 企业级合规设计：内置 PCI DSS 相关的支付数据隔离，将敏感信息处理完全外抛至 Brek 安全门户
- 防滥用架构：本地预算限制、调用频次计数器、多层级熔断机制，有效保护上下游系统
- 幂等性原生支持：关键交易操作强制幂等键，天然防止网络重试导致的重复业务动作
- 多租户友好：
partnerId+workspaceId双维度隔离，支持 SaaS 化部署模式
潜在缺点与局限性
- 基础设施依赖重：要求外部持久化存储（幂等去重存储、预算计数存储、用量计量日志），自建成本不低
- 非自主调用：
autonomous_invocation: false意味着无法作为后台定时任务触发，必须绑定用户显式交互 - 错误处理复杂：409 会话冲突、404 租户错误等状态需要客户端实现会话重建逻辑，增加集成复杂度
- 密钥管理严格：API key 缺失时必须通过"内部负责人或已审批支持渠道"获取，流程阻塞感强
适合人群
- OTA 平台开发者：需在自有 App/网站内嵌入酒店 AI 助手，又不想自建 NLP 与供应链对接
- 企业差旅管理 SaaS：为多企业客户（workspace）提供标准化酒店预订能力，同时满足各企业合规要求
- 支付合规敏感型团队：缺乏 PCI DSS 认证资质，希望将支付敏感域完全外包给 Brek
常规风险
| 风险类别 | 说明 | 缓解措施 |
|---------|------|---------|
| 密钥泄露 | `BREK_PARTNER_API_KEY` 若硬编码或日志泄露，可导致恶意调用 | 使用密钥管理服务，禁止日志打印完整 key |
| 幂等键碰撞 | `clientActionId` 生成策略不当导致重复键，引发 409 或静默跳过 | 采用 UUIDv7 或雪花算法，确保全局单调递增 |
| 会话状态漂移 | 网络分区后本地状态与 Brek 服务端不一致 | 定期 `GET /sessions/{sessionId}` 同步状态 || 预算超支 | 本地预算计数器与 Brek 侧计费不同步 | 双写校验，设置硬顶熔断阈值 |
| 支付合规 | 开发者误将原始卡号传入自定义字段 | 代码审查 + 自动化敏感数据扫描 |
总结建议
Brek AI Partner Core Chat 是一个设计严谨的企业级酒店 AI 集成方案，尤其适合合规要求高、多租户架构的在线旅游场景。集成方需重点投入在幂等键生成策略、持久化存储选型及密钥生命周期管理上，以发挥其安全架构的最大价值。