th-hotel-simple/docs/project/requirements/booking-fixed-parameter-extraction-flow-business-confirmation-draft-v1.md

# Booking Agent 固定参数：邮件/附件提取与流转业务确认稿 v1

| 项目 | 内容 |
| --- | --- |
| 文档状态 | **DRAFT / P17 已确认；其余项目待业务逐项确认** |
| 核对日期 | 2026-08-13 |
| 核对对象 | QBD、普通 LianTai 当前入站邮件及当前 `.xlsx` 附件 |
| 核心问题 | Booking Agent 用来判断业务的固定参数，从哪里取、怎样处理、怎样绑定、最终收到什么 |
| 不在本稿范围 | 页面、权限、Layer 6/7、V4 任务卡、PMS/Opera、上线切换 |
| 当前发布状态 | 规则与离线合同已存在；真实 Booking Agent Profile/Provider/运行仍为 `HOLD` |

## 0. 先看结论

本稿只核对下面这条链，不再展开整个项目架构：

```text
当前邮件发件人
→ 选择 QBD 或 LianTai 固定模板
→ 从当前 Excel 的指定业务行提取 10 类固定来源参数
→ 从当前 subject/body 和备注材料补充中立事实、目标关联和服务事项
→ 系统绑定到“目标 → 住宿段 → 房型项”，并完成 Room Type / Rate 套餐解析
→ Booking Agent 根据这些当前材料判断业务类型、目标拆分和候选参数
```

最重要的产品边界是：

1. **提取参数**和**Agent 判断结果**不是一回事。表格里的 `NEW BOOKING` 先形成“来源写了 New”的事实，最终是否形成 New 候选仍由 Booking Agent 判断。
2. 每个提取值都必须同时保留：**原文、规范值、属于哪一行/住宿段/房型、准确来源位置**。
3. 不允许靠行序、数组位置、相似 Tour Code 或历史订单猜归属。
4. 不同物理业务行永远不自动合并成一项候选；同一个 Tour Code 只允许在系统计算 Rate 套餐时共享订单级上下文。
5. Booking Agent 不打开 Excel；它收到的是已经提取、绑定和映射后的当前业务材料。
6. **FIT 与 GROUP 不使用两套提取规则。**QBD/LianTai 始终先提取同一组固定参数；全部参数提取、绑定完成后，Booking Agent 才根据有效房量判断 FIT/GROUP，不为 FIT 改读姓名或另一组字段。

## 1. 固定参数分成三类

### 1.1 从邮件/附件直接提取的 10 类参数

| 参数 | 业务含义 | 是否直接来源于邮件/附件 |
| --- | --- | --- |
| `GROUP_CODE` | Tour Code / 主团号 / 订单目标代码 | 是 |
| `SOURCE_ACTION_DATE` | 来源写出的动作指令日期 | 是 |
| `SOURCE_ACTION_KIND` | 来源写的是 New / Update / Cancel | 是 |
| `ARRIVAL_DATE` | 入住日期 | 是，允许按渠道日期规则补全年月 |
| `DEPARTURE_DATE` | 离店日期 | 是，允许按渠道日期规则补全年月 |
| `NIGHTS` | 晚数 | 否；由离店日减入住日计算 |
| `SOURCE_ROOM_NAME` | 邮件/表格中的完整来源房型 | 是 |
| `BREAKFAST_INCLUDED` | 来源房型是否带独立 `BF` 标记 | 否；从来源房型文字确定性判断 |
| `ROOM_QUANTITY` | 房间数量 | 是；未写时按固定模板默认 1 |
| `SOURCE_PRICE` | 来源房价数字 | 是；只接受紧贴房型的固定写法 |

### 1.2 系统在送入 Booking Agent 前补充的参数

| 参数包 | 来源与处理 | Booking Agent 怎么用 |
| --- | --- | --- |
| 渠道 Profile | 由发件人地址精确选择 `QBD` 或 `LIANTAI` | 知道应采用哪套已确认规则；不能从正文或文件名改判 |
| 目标/来源绑定 | 给每个值附上目标、物理来源单元、房型项和证据位置 | 知道“这个日期/房数/房价属于谁” |
| canonical Room Type | 用 `SOURCE_ROOM_NAME` 在目录中精确规范匹配 | 直接消费映射结果；Agent 不自行猜房型 |
| Rate 选项/套餐 | 系统按渠道、来源房型、来源价格、早餐条件预先计算 | Agent 根据自己判断出的 Booking Type 选择适用选项 |
| Rooming List typed resolution | 系统先判断当前附件是否为 Excel 名单并唯一绑定 Tour Code | Agent 不打开名单、不读取客人姓名，只消费判断结果 |
| 当前材料问题 | 缺值、冲突、无法绑定、目录无结果等 | 决定是局部 Risk，还是保留业务类型交员工补字段 |

### 1.3 由 Booking Agent 判断、不能伪装成“提取值”的内容

| Agent 判断项 | 判断规则摘要 |
| --- | --- |
| 最终业务类型 | New、Update、Cancel、Trace、Rooming List，以及 Allotment 派生动作 |
| Booking Type | 完成统一提取后，按同一 Tour Code 的全部有效 `ROOM_QUANTITY` 合计：1–4 为 FIT，5 及以上为 GROUP；姓名、人数、渠道名称和邮件中的 FIT/GRP 字样均不参与改判 |
| 候选拆分 | 不同物理来源行分别形成候选；同一来源单元多个房型可在同一候选内 |
| Trace 与部门 | 根据当前具体服务事项决定是否形成 Trace，并提出 `FO` 或 `FO+HSK` |
| Risk | 业务类型或必要目标不能安全判断时形成局部 Risk |
| 未归类原文 | 当前材料中未被任何支持业务承接的原文；Payment 目前也只放这里 |

## 2. 所有参数共同遵守的处理规则

### 2.1 每个值必须带两套表达

以 QBD C 列 `  QBD-2608-001  ` 为例：

```text
原文 source_value               = "  QBD-2608-001  "
规范值 normalized_source_value  = "QBD-2608-001"
参数角色 fact_role              = GROUP_CODE
目标 target_ref                 = 本物理业务行对应的目标
来源 source_unit_ref            = 具体住宿段；订单级参数可不落到住宿段
房型 room_item_ref              = 具体房型项；非房型参数为空
证据 evidence_refs              = 附件、Sheet、行号、单元格/文字区段
```

Booking Agent 应同时看得到原文和规范值；规范化不能删除 BF、Q10、床型、景观、FAM/PAX 等业务区分信息。

### 2.2 唯一值、缺失、多值和冲突

| 来源情况 | 处理规则 |
| --- | --- |
| 同一参数槽只有一个唯一解释 | 形成固定事实，送入下游 |
| 同一参数槽多处来源给出相同规范值 | 合成一个事实，保留全部证据位置 |
| 有原文，但不能得到唯一解释 | 不猜值；原文作为待判断材料并标记复核 |
| 来源完全没有该内容 | 不制造事实，也不制造假原文；后续按该业务类型的必填规则处理 |
| Parser 与正文补充得到不同值 | 附件 Parser 事实不被覆盖，保留冲突并复核 |
| Parser 技术失败 | 不发布任何部分事实；整份附件进入受控复核/兜底 |

### 2.3 三层归属关系

```text
目标 target_ref
└── 物理来源单元 source_unit_ref（业务行中的一个住宿段）
    └── 房型项 room_item_ref（一个【...】房型块）
```

- `GROUP_CODE` 属于目标。
- 入住、离店属于具体住宿段。
- 来源房型、早餐、数量、价格必须属于具体房型项。
- 缺少明确归属时形成阻断问题，不能按“第一个日期配第一个房型”处理。

## 3. QBD：从表格具体位置到 Booking Agent

### 3.1 先确认是不是可提取的 QBD 表

| 确认项 | 当前规则 |
| --- | --- |
| 发件人 | 规范化后必须精确等于 `op.qbdtravel@gmail.com` |
| 附件 | 当前邮件中可安全读取的 `.xlsx` |
| Sheet | 唯一业务 Sheet，标题/Sheet 名的酒店、年月和 QBD 模板要一致 |
| 表头 | 前 10 行内必须唯一识别四个核心表头；标准模板对应 C/E/H/J |
| 业务行 | C、E、H、J 均非空，且四格都是同一受认可的 QBD 橙色 |
| 多文件/多 Sheet/重复表头 | 不挑第一个，整份走复核 |

因此业务描述应写成：**“当前标准模板是 C/E/H/J，但程序先认唯一表头，再认列位，不是脱离表头永远盲取固定字母。”**

### 3.2 QBD 逐参数确认表

| ID | 原始位置 | 输出参数 | 提取与规范规则 | 绑定及流转 | 缺失/异常 |
| --- | --- | --- | --- | --- | --- |
| Q01 | C 列 `Tour Code 主团号` | `GROUP_CODE` | 保留整格原文；规范值只去首尾空白，不拆词、不改号 | 作为本物理业务行的目标；同行所有住宿段和房型继承该目标；送入 Booking Agent 作为 GROUP 必要身份 | C 为空时该行不入选；多个来源别名值不一致时不合并 |
| Q02 | H 列 `หมายเหุต / 备注` 行首完整日期 | `SOURCE_ACTION_DATE` | 接受受控的日/月/年写法；两位年份按 20xx；统一为 `YYYY-MM-DD` | 与本行目标绑定，只表示来源指令日期；不是收件时间、入住日或取消生效日 | 年份缺失或日期非法时不猜；当前主 V2 桥接仍有丢失风险，见第 8 节 |
| Q03 | H 列动作文字；J 为 `CXL/CXL:` 时强制取消 | `SOURCE_ACTION_KIND` | `NEW BOOKING`→New；`AMD/AMEND BOOKING`、`AMD/AMEND ALLOTMENT`、`AMD/AMEND GROUP CODE`→Update；`CANCEL/CANCEL BOOKING/CXL`→Cancel | 作为“本行来源动作”送给 Booking Agent；Agent 再判断最终业务类型 | 未识别动作进入材料/复核；正文不能覆盖同行已有动作 |
| Q04 | 正常行：J 列 `GROUP IN 入住日期`；CXL 行：E 日期段＋H 动作日期 | `ARRIVAL_DATE` | 正常行以 J 为年月日锚点，并与 E 的起始日交叉核对；CXL 用 H 年月和 E 起始日补全 | 绑定到 E 中对应住宿段 `source_unit_ref` | 不能唯一补全、J/E 冲突或非法日期时不猜 |
| Q05 | E 列日期段＋J/H 年月锚点 | `DEPARTURE_DATE` | E 中 `start-end` 的 end 为离店日；end 小于 start 时按受控跨月规则落到下一月 | 与对应入住日绑定到同一住宿段 | 必须晚于入住日；不成立时复核 |
| Q06 | 入住日、离店日 | `NIGHTS` | `离店日期 - 入住日期`，不读取 F 列，不跨住宿段累计 | 与同一住宿段一起送入下游 | 任一日期不确定就不生成晚数 |
| Q07 | E 列每个 `【...】` 房型块 | `SOURCE_ROOM_NAME` | 一个括号块形成一个房型项；只移除已确认的尾部价格 token；保留 BF、Q10、U、床型、套房、景观、FAM/PAX 等；统一大小写/空白/无业务含义的横线差异 | 绑定到本住宿段下的 `room_item_ref`；先用于 Room Type/Rate 映射，再随映射结果一起给 Agent | 房型结构不能唯一解释时，原块转材料，不猜 canonical Room Type |
| Q08 | E 列房型块中的早餐条件 | `BREAKFAST_INCLUDED` | 独立 BF=`true`；明确 RO/不含早=`false`；均未出现时不生成；Q10 不参与早餐判断 | 绑定同一房型项，并参与 Rate 套餐筛选 | 来源早餐与目录套餐冲突时 Rate 不锁定，交复核 |
| Q09 | `【...】` 右侧紧邻整数 | `ROOM_QUANTITY` | 明写整数按原文；未写时按 QBD 固定规则默认 1，并记录“默认 1”的规则证据 | 绑定同一房型项；供 Booking Type 房量合计、候选房数和 Allotment 判断 | 不能把房型内价格或别处人数当房量；非法值不猜 |
| Q10 | `【...】` 内房型文字末尾紧贴的价格 token | `SOURCE_PRICE` | `8.5`→`850`；其他合法正数×1000；必须紧贴房型末尾；原 token 同时保留 | 绑定同一房型项；供系统 Rate 解析；在候选中只作来源价格展示 | 完全没写价格时不造事实/材料；`1.2/1.3`、空格分离等不唯一写法只把价格原文交复核 |
| Q11 | 可选 `WAITING 等待确认 / อักษรดำ` 表头列，列位可变 | 当前备注材料 | 只读取已经入选的业务行；非空整格原样保留，不拆数字、不解析价格 | 先由 Parsing Agent 分流为服务事项、展示信息或复核材料，再给 Booking Agent | 不参与选行；空值不输出；多个 WAITING 表头候选时不猜 |

### 3.3 QBD 明确忽略的列/内容

| 位置 | 规则 |
| --- | --- |
| F 列 Nights Override | 无论表头和值是什么都完全忽略；不提取、不告警、不覆盖晚数 |
| 文件名 | 只用于显示和审计，不能替代发件人/Profile/模板判断 |
| 其他颜色行 | 不是“只要有颜色就取”；非认可橙色不形成 QBD 当前业务行 |

### 3.4 QBD 修改前/修改后

| Excel 富文本状态 | 业务解释 | 流转规则 |
| --- | --- | --- |
| 整个房型＋数量块都划线 | `BEFORE` 修改前值 | 只作变更证据，不当作当前目标值 |
| 同行已有 BEFORE，另一个完整块未划线 | `AFTER` 修改后值 | 作为本次 Update 的当前目标值 |
| 没有 BEFORE，完整块未划线 | `CURRENT` 当前值 | 作为本次来源当前值 |
| 同一块内部或同一物理行状态混合 | `MIXED` | 不强行配对/拆分，保留材料并复核 |

日期、晚数、房型、数量、价格必须一起跟随该住宿段/房型块的状态，不能只把划线房型当旧值，却把同段日期当新值。

同一物理来源单元有两组及以上当前住离周期时：

- 不自动拆成多张 New/Update；
- 不按顺序把房型分给某个日期；
- 整个受影响来源单元交 Booking Agent 形成局部 Risk。

### 3.5 QBD 端到端示例

原表一行业务材料：

```text
C = "  QBD-2608-001  "
E = "8-10 Wyndham Jomtien Pattaya (【U-TWN8.5】2)"
H = "06/08/2026 AMD BOOKING"
J = 08-Aug-2026
```

固定提取结果：

```text
GROUP_CODE             = QBD-2608-001
SOURCE_ACTION_DATE     = 2026-08-06
SOURCE_ACTION_KIND     = UPDATE_BOOKING
ARRIVAL_DATE           = 2026-08-08
DEPARTURE_DATE         = 2026-08-10
NIGHTS                 = 2
SOURCE_ROOM_NAME       = U-TWN
BREAKFAST_INCLUDED     = （不生成；来源未声明 BF/RO）
ROOM_QUANTITY          = 2
SOURCE_PRICE           = 850
```

后续流转：

```text
C列团号
→ 绑定这一物理业务行
→ E列住宿段和房型继承同一目标
→ 系统用 U-TWN 做精确 Room Type 映射
→ 系统用 QBD + U-TWN + 850 + 不含早计算 Rate 选项
→ Booking Agent 看到来源动作、日期、房型/房量和 Layer 4 解析结果
→ Agent 判断该行是否形成 UPDATE_BOOKING 候选，并按同团号全部有效房量判断 FIT/GROUP
```

## 4. LianTai：从表格具体位置到 Booking Agent

### 4.1 先确认是不是可提取的 LianTai 表

| 确认项 | 当前规则 |
| --- | --- |
| 发件人 | 规范化后必须精确等于 `op.liantaitravel@gmail.com` |
| 模板 | 当前只支持 August 9 列模板；July 7 列模板不猜列位，走复核 |
| Sheet | 标题、Sheet 和年月必须唯一一致；`AUTO_CALC`、`DASHBOARD` 等辅助页忽略 |
| 业务行 | A、D、G 均非空、均为 solid 非白底色，且三格底色签名相同 |
| 同团号多行 | 每条物理行独立，不跨行合成一项业务候选 |

### 4.2 LianTai 九列处理总表

| 列 | 原始业务含义 | 处理规则 |
| --- | --- | --- |
| A | `Tour Code / 主团号` | 提取为 `GROUP_CODE` |
| B | Tour Days / 行程天数 | 完全忽略 |
| C | 人数 | 完全忽略；不能决定 FIT/GROUP |
| D | 酒店明细 | 提取住宿日期、来源房型、数量、价格；模板外残余原文保留 |
| E | Nights Override | 完全忽略；晚数只按离店减入住 |
| F | 导游 | 完全忽略 |
| G | 动作＋备注 | 提取最新有效动作日期/类型；完整原文和非动作残余同时保留 |
| H | 酒店回执 | 完全忽略，不保存、不展示 |
| I | REMARK | 非空整格原文交 Parsing Agent/员工，不直接生成业务类型 |

### 4.3 LianTai 逐参数确认表

| ID | 原始位置 | 输出参数/材料 | 提取与规范规则 | 绑定及流转 | 缺失/异常 |
| --- | --- | --- | --- | --- | --- |
| L01 | A 列 `Tour Code / 主团号` | `GROUP_CODE` | 原文保留，规范值只 trim；同时承担 LianTai 的 group name/code 语义，但不生成第二个目标字段 | 作为本物理业务行目标，同行 D/G/I 材料绑定此目标 | A 为空或 A/D/G 选行条件不成立时不形成确定性业务行 |
| L02 | G 列每条“动作＋完整日期” | `SOURCE_ACTION_DATE` | 识别所有受控动作时间点，选日期最新的一条；同日选文本位置靠后的动作；统一为 `YYYY-MM-DD` | 与本物理行目标绑定 | 缺完整日期的动作不参加最新动作选择；不从收件时间补 |
| L03 | G 列最新有效动作 | `SOURCE_ACTION_KIND` | `NEW BOOKING`→New；`CANCEL BOOKING`→Cancel；`AMEND TO`→Update；`FINAL/LINE 已发送`不是动作 | 作为本行来源动作送给 Booking Agent；完整 G 原文仍作为材料 | 多条动作不累加；只保留最新有效动作作为固定事实 |
| L04 | D 列每个 `dd-dd` 明细段＋Sheet/标题年月 | `ARRIVAL_DATE` | 前一个数为入住日；用业务 Sheet 年月和相邻段顺序确定跨月 | 绑定本行的具体住宿段 | 不用 Tour Days、历史月表或系统当前日期补齐 |
| L05 | D 列日期段＋Sheet/标题年月 | `DEPARTURE_DATE` | 后一个数为离店日；小于入住日时按受控跨月逻辑解释 | 与入住日绑定同一住宿段 | 年月、连续性、日期合法性不能唯一确定时复核 |
| L06 | 入住日、离店日 | `NIGHTS` | `离店日期 - 入住日期` | 绑定同一住宿段 | E 列永远不能覆盖 |
| L07 | D 列每个 `【...】` 房型块 | `SOURCE_ROOM_NAME` | 与 QBD 共用来源房型规则；保留业务区分项，只移除唯一确定的尾部价格 token | 绑定具体房型项；先做 Room Type/Rate 解析，再给 Agent | 混合写法不能唯一解释时保留原文复核 |
| L08 | D 列房型块中的早餐条件 | `BREAKFAST_INCLUDED` | 独立 BF=true；明确 RO/不含早=false；均未出现时不生成；Q10 与早餐无关 | 绑定具体房型项，参与 Rate 套餐筛选 | 与目录套餐冲突时 Rate 不锁定 |
| L09 | `【...】` 后紧邻整数 | `ROOM_QUANTITY` | 明写整数；缺失默认 1 | 绑定具体房型项；供 Booking Type 和候选房数 | C 列人数不能补房量 |
| L10 | `【...】` 内房型末尾紧贴价格 | `SOURCE_PRICE` | `8.5`→850；其他合法正数×1000；括号外房量不能当价格 | 绑定具体房型项，供两个 LianTai Rate 选项计算 | G/I 中写到的钱只保留原文，不绑定房型、不生成来源价格 |
| L11 | D 列模板清理后的残余原文 | 当前材料 | 只删除已冻结的酒店名/路线/固定提醒模板；模板外内容全部保留 | 分流为服务 mention、员工展示或复核，再给 Booking Agent | `办公室付款/已确认`只展示，不生成 Payment |
| L12 | G 列完整原文 | 当前材料 | 即使已提取最新动作，整格仍原样保留 | 供 Agent/员工理解过程说明；不能产生第二套动作事实 | FINAL/LINE 等不得改写固定动作 |
| L13 | I 列 REMARK | 当前材料 | 非空整格原文保留 | 分流为服务 mention、展示或复核 | 不从备注中的数字自动借给房价/房量 |

### 4.4 LianTai 端到端示例

```text
A = "LT-2608-001"
D = "07-08 Jomtien Wyndham Pattaya (【U-TWN8.5】 2)"
G = "NEW BOOKING 01/07/2026\nAMEND TO 05/08/2026"
I = "Please prepare honeymoon setup"
```

固定提取/材料结果：

```text
GROUP_CODE             = LT-2608-001
SOURCE_ACTION_DATE     = 2026-08-05
SOURCE_ACTION_KIND     = UPDATE_BOOKING
ARRIVAL_DATE           = 2026-08-07
DEPARTURE_DATE         = 2026-08-08
NIGHTS                 = 1
SOURCE_ROOM_NAME       = U-TWN
BREAKFAST_INCLUDED     = （不生成；来源未声明 BF/RO）
ROOM_QUANTITY          = 2
SOURCE_PRICE           = 850
CURRENT MATERIAL       = 完整 G 原文 + I 列蜜月布置原文
```

后续流转：

```text
A列团号绑定这一物理行
→ D列生成一个住宿段和一个房型项
→ G列只把 2026-08-05 的 AMEND TO 作为最新来源动作
→ I列蜜月布置先形成中立服务事项，不直接叫 Trace
→ 系统分别计算 LianTai FIT 和 GROUP 的 Rate 选项
→ Booking Agent 按全部有效房量 2 判断 Booking Type=FIT
→ Agent 读取 FIT 对应 Rate 选项，并判断 Update 候选及是否同时产生 Trace
```

## 5. 当前邮件 subject/body 怎么提取和补充

### 5.1 Booking Agent 能看到什么

- 当前邮件 subject 原文及证据；
- 当前邮件 body 的当前业务原文及证据；
- 当前附件安全描述：附件 ID、文件名、媒体类型、大小、内容 hash、解析后的材料引用；
- 不发送附件二进制、Base64、下载 URL 或 Secret。

### 5.2 邮件正文的处理规则

| ID | 正文内容 | 处理规则 | 与附件参数的关系 |
| --- | --- | --- | --- |
| M01 | 明确 Tour Code / Group Code | 可形成 `GROUP_CODE` 候选或目标绑定 | 只有附件中存在唯一同号业务目标时才自动绑定；否则保持消息级/复核 |
| M02 | 明确 New/Update/Cancel 指令 | 可形成 `SOURCE_ACTION_KIND` 候选 | 某行已有附件动作时，正文不能覆盖；冲突则该行复核 |
| M03 | 通用标题，如 `Update Booking` | 只表示整封邮件主题 | 不能把所有有色行统一改成 Update |
| M04 | 加床、蜜月布置、房间布置、举牌、会议室、其他具体服务 | 先形成中立服务事项，可带已知数量、来源房型和目标 | Booking Agent 再决定是否形成 Trace 及部门 |
| M05 | Allotment source→actual、旧团号→新团号 | 形成中立关系 | 关系本身不等于 Allotment 任务；必须有当前正文明确操作语义 |
| M06 | 员工只需知道的说明 | 原文进入展示信息 | 不伪装成动作、房价、付款任务 |
| M07 | 有执行可能但含义/目标/参数不清 | 形成复核材料 | 不猜目标或数值 |
| M08 | LianTai 固定问候、固定标题、固定提醒、联系人和页脚 | 提取阶段忽略其业务含义 | 不能产生目标、动作、姓名或服务事项 |

### 5.3 正文和附件谁优先

1. 具体物理业务行自己的动作优先。
2. 正文只有在该行没有动作、且正文明确点名该行或 Tour Code 时，才可补足动作。
3. 正文与目标行冲突时，不选“看起来更合理”的一个；保留附件事实并进入复核。
4. 正文没有 Tour Code 且同封存在多个目标时，备注默认保持消息级，不能按行序分配。

## 6. 从固定参数到 Booking Agent 的最后一段流转

### 6.1 系统先做明确绑定

| 参数 | 必须绑定到 | 不允许的做法 |
| --- | --- | --- |
| `GROUP_CODE` | 目标 `target_ref` | 复制到真实客人姓名 |
| `ARRIVAL_DATE/DEPARTURE_DATE/NIGHTS` | 住宿段 `source_unit_ref` | 按数组位置和房型拼接 |
| `SOURCE_ROOM_NAME/BREAKFAST/QUANTITY/PRICE` | 房型项 `room_item_ref` | 跨房型借数量、价格或早餐 |
| 服务事项 | 消息或唯一目标；有房型时再绑定来源房型 | 多目标时默认分给第一个 Tour Code |

### 6.2 系统做 Room Type 解析

```text
SOURCE_ROOM_NAME
→ 只统一大小写、空白和横线格式
→ 在已确认目录中做 exact-normalized 匹配
→ 唯一候选：输出 canonical Room Type
→ 0个或多个候选：Room Type 留空并复核，不选第一个
```

Company、价格和房量不能用于“帮忙猜”Room Type。

### 6.3 系统做 Rate 选项解析

Rate 与 Room Type 是两套独立映射。Rate 使用：

```text
渠道对应目录公司 + Rate 规则集 + SOURCE_ROOM_NAME + SOURCE_PRICE + 早餐条件
```

不用 canonical Room Type 反推 Rate。

| 渠道 | 送给 Booking Agent 的 Rate 选项 |
| --- | --- |
| QBD | 一套 `Q.B.D / GROUP_AND_FIT` 选项，FIT/GROUP 都适用 |
| LianTai | 两套选项：FIT=`LIANTAI ONLINE/DY`；GROUP=`LIAN TAI` |

每个有效 Rate 结果是一个不能拆开的套餐：

```text
Rate Code + 是否含早餐 + 早餐餐厅（LEELA / BUALUANG / 空）
```

其他固定处理：

- 缺价格时，QBD按公司默认`GRPA1`，LianTai按公司默认`GRP1`；适用于所有房型，包括独立套房。
- 若来源明确早餐条件与默认套餐冲突则不能套用，保持未解析交人工。
- 来源未写早餐餐厅、候选存在餐厅分叉时，按已配置默认 `BUALUANG`。
- 套房只有在同 Tour Code 有唯一主房 Rate 时才允许继承；只有套房或主房 Rate 不唯一时不猜。
- 同 Tour Code 全部来源房型必须收敛到同一个套餐；有一项未解析或套餐冲突，订单级 Rate 就保持未解析。

### 6.4 Booking Agent 实际应收到的最小包

| 包内内容 | 是否允许 |
| --- | --- |
| 当前 subject/body | 是 |
| 当前附件安全引用 | 是 |
| 10 类固定来源参数及原文/规范值 | 是 |
| 目标、住宿段、房型项绑定 | 是 |
| BEFORE/AFTER、服务事项、关系、展示/复核材料 | 是 |
| canonical Room Type、Rate 选项/套餐、Rooming List 解析 | 是 |
| 当前数据库订单、历史任务、生命周期结论 | 否 |
| 完整 History 正文和历史附件 | 否 |
| 附件二进制、URL、Secret、数据库/PMS 凭据 | 否 |

这里的“订单上下文”只表示**本封当前邮件的 Tour Code、住宿段、房型和 Rate 计算包**，不是把数据库里的当前订单交给 Agent。

## 7. Booking Agent 收到后如何使用这些参数

| 第一步 | Agent 判断 | 固定参数怎样支持 |
| --- | --- | --- |
| 识别是什么业务 | New / Update / Cancel / Trace / Rooming List / Allotment | 来源动作、当前正文、before→after、服务事项、关系 |
| 确认必要目标 | QBD/LianTai 固定渠道统一按附件提取的 Tour Code 建立目标；不因最后判为 FIT 而改走姓名提取 | `GROUP_CODE`、`target_ref`；真实姓名如从其他独立来源获得可保留，但不是固定渠道提取或判型条件 |
| 拆分候选 | 每个物理来源行独立；同一来源单元一个住离周期 | `target_ref/source_unit_ref/room_item_ref` |
| 计算 Booking Type | 先完成同一套参数提取，再按同 Tour Code 全部有效房量判断：1–4 FIT、5+ GROUP | 只读取有效 `ROOM_QUANTITY`；不读取姓名、人数列、渠道或 FIT/GRP 文本；无法得到有效房量时不猜 |
| 填 New/Update | 目标、来源单元、Booking Type、住离日期、来源房型、canonical Room Type、房量、Rate/早餐，价格可选展示 | Layer 3 固定参数＋Layer 4 结果 |
| 填 Cancel | 只要求目标身份 | 来源日期/房型可留作证据，但不进入 Cancel payload |
| 填 Trace | 具体服务事项、目标、部门及已知参数 | structured mentions＋Room Type |
| 处理缺字段 | 类型已明确时保留该类型，缺失字段为空交员工补 | 不把普通字段缺失改成 General/Risk |
| 处理未知类型/目标 | 形成局部 Risk | 不影响同封其他清楚的候选 |

## 8. 截至本次核对发现的实际接线断点

以下不是新的业务规则，而是“规则已经这样写，但当前工作区还没有完整传通”的事项。它们不应由产品人员在字段表里默许掉。

| 断点 ID | 当前现状 | 业务影响 | 建议收口 |
| --- | --- | --- | --- |
| G01 | 公共 Parser/Parsing Agent 的最终合并结果仍进入旧 Context；新 V2 主编排使用的是兼容投影 | Parsing Agent 补出的正文事实、绑定、关系和材料不一定完整进入 Booking Agent | 把唯一最新 Layer 3 结果直接接入同一 Layer 4/Agent 输入 |
| G02 | `SOURCE_ACTION_DATE` 在公共 Parser 已提取，在兼容层只保存为旧 hint；新 V2 输入工厂没有继续投影 | Booking Agent 当前可能看不到来源动作日期 | 在 `Layer3ResultV2.source_facts[]` 中正式保留该参数及绑定/证据 |
| G03 | QBD `BEFORE` 值在兼容层转为旧 hint，新 V2 输入工厂没有正式承接 | Update 的修改前→修改后证据可能丢失，Agent 只能看到当前值 | 给 V2 明确的 BEFORE 表达，不靠不透明旧 hint |
| G04 | 权威 schema/ADR 禁止 History 进入 Booking Agent；当前 Java wire DTO/projector 仍保留并传 `email_history`，同时测试/JSON schema又按禁止 History 验收 | 同一版本对 Agent 是否能看邮件 History 有两套答案 | 以 ADR-012 为准，物理删除 Agent wire 的 History 字段与投影 |
| G05 | **已关闭（2026-08-13）**：当前附件文件名型识别、Layer3中立材料和Layer4 typed resolution已接线 | 安全检查成功可提供唯一当前附件/Tour Code resolution；技术失败仍显式UNRESOLVED | 继续以`M012-layer3-current-rooming-list-filename-material-change-request-v1.md`及其evidence为回归门禁；Layer5仍独占业务判断 |

因此本稿可以用于确认**参数规则**，但不能被解读为“这些参数已经在生产端到端全部传通”。

## 9. 请按 ID 确认

P17 已按本次业务确认收口。其余项目可以直接回复“其余全部同意”，或者逐项写修改内容。

| 确认 ID | 请确认的业务口径 | 你的结论 |
| --- | --- | --- |
| P01 | QBD 标准列位为 C/E/H/J，但必须先按唯一表头识别；不能脱离模板盲取字母列 | 同意 / 修改： |
| P02 | QBD 只有 C/E/H/J 同一认可橙色且均非空的物理行才提取 | 同意 / 修改： |
| P03 | QBD C 列只形成 `GROUP_CODE`，trim 后绑定本行；永不复制成真实客人姓名 | 同意 / 修改： |
| P04 | QBD H 形成来源动作日期/类型；J 为 CXL 时强制 Cancel；正文不能覆盖已有行内动作 | 同意 / 修改： |
| P05 | QBD 正常日期按 J＋E，CXL 日期按 H＋E；晚数永远为离店减入住，F 完全忽略 | 同意 / 修改： |
| P06 | 每个 `【...】` 是一个房型项；房量取括号后整数，没写默认 1 | 同意 / 修改： |
| P07 | 来源房型保留 BF/Q10/床型/景观/FAM/PAX；BF 单独决定早餐，Q10 与早餐无关 | 同意 / 修改： |
| P08 | 价格必须紧贴房型末尾；8.5→850，其他合法数×1000；缺价格不猜，歧义价格交复核 | 同意 / 修改： |
| P09 | QBD WAITING 整格只作当前备注材料，不拆数字、不形成价格；列位按表头动态识别 | 同意 / 修改： |
| P10 | QBD 划线=BEFORE，未划线同组=AFTER；日期/房型/数量必须同步跟随状态 | 同意 / 修改： |
| P11 | LianTai 只支持当前 9 列模板；业务行严格取 A/D/G 同色非白且非空 | 同意 / 修改： |
| P12 | LianTai B/C/E/F/H 忽略，其中 C 人数不能决定 FIT/GROUP，H 永不保存/展示 | 同意 / 修改： |
| P13 | LianTai G 只取最新带完整日期的 New/Cancel/Amend；同日取文本后出现者，完整 G 仍保留 | 同意 / 修改： |
| P14 | LianTai D 提取日期/房型/房量/价格，D残余＋G完整原文＋I完整原文进入材料分流 | 同意 / 修改： |
| P15 | 附件行内动作优先；正文只可补没有动作且明确点名行/Tour Code的内容；冲突不覆盖 | 同意 / 修改： |
| P16 | 不同物理来源行永不合并候选；同 Tour Code 只共享订单级 Rate 计算上下文 | 同意 / 修改： |
| P17 | QBD/LianTai 不设 FIT 单独提取：始终按同一套固定参数和 Tour Code 绑定规则提取；完成后只按有效房量判型，1–4 为 FIT、5 及以上为 GROUP，姓名/人数/渠道/文字标签均不参与 | **已确认：统一提取、房量判型** |
| P18 | Room Type 只按来源房型精确规范匹配；0个/多个候选都不猜 | 同意 / 修改： |
| P19 | QBD给一套FIT/GROUP通用Rate选项；LianTai给FIT/GROUP两套选项，由Agent按房量结果选择 | 同意 / 修改： |
| P20 | Booking Agent 只看当前业务材料和已整理结果，不看完整History、数据库订单/任务/生命周期 | 同意 / 修改： |
| P21 | 同一物理来源单元出现两组以上当前住离周期时，New/Update整项转局部Risk，不自动拆分 | 同意 / 修改： |

## 10. 权威依据与使用说明

本稿是把现有技术契约翻译成业务确认语言，依据包括：

- `M012-qbd-liantai-parser-output-contract-v1.md`：冻结的 10 类来源参数与 fact/material 规则；
- `M012-qbd-deterministic-parser-change-request-v1.md`：QBD 表头、橙色行、日期、房型和富文本规则；
- `M012-liantai-shared-parser-parsing-agent-change-request-v1.md`：LianTai 九列、底色、日期、动作和备注规则；
- `M012-fixed-channel-parsing-agent-v1-contract.md`：当前正文、目标绑定、服务事项、展示与复核；
- `booking-email-contracts-v2.md`、`booking-business-agent-rules-v1.md`、ADR-012：Booking Agent 最小输入和业务判断边界。

在用户确认本稿前：

- 本稿不覆盖上述已接受规则；
- 文中发现的 G01–G05 只记录接线差异，不授权修改代码或启用运行；
- 用户确认后的改动应先更新权威契约/ADR，再实施，避免只改 Prompt 或只改某一层 DTO。