# M002 Order Task Workflow 订单任务主流程 V1

> 文档状态：历史参考。当前 M002 后续开发基线已由
> `M002-order-task-workflow-v3.md` 承接；V2 保留为当前阶段实现记录。
> 本文只用于理解早期流程讨论和边界来源。

## 文档信息

| 项目 | 内容 |
| --- | --- |
| 文档版本 | 0.1 |
| 日期 | 2026-07-06 |
| 状态 | 第一版流程草稿 |
| 适用范围 | SourceMessage 之后的 SuperAgent 抽取、订单挂靠、任务处理、OPERA/OHIP 模拟操作主流程 |
| 主要读者 | 产品、后端、前端、测试、后续协作 agent |

## 1. 文档定位

本文记录 TH Hotel 当前确认的订单任务主流程第一版理解，用于承接已经完成的
`SourceMessage Inbox` 能力，并为后续 PRD、接口契约、数据模型和实现 checkpoint 提供
统一业务语义。

本文只沉淀流程和边界，不代表已经开始实现代码。后续进入开发前，仍需要补充具体任务字段、
SuperAgent 创建任务接口契约、前端页面范围、数据库模型和验收标准。

## 2. 已确认结论

- AgentBus 是当前原始消息起点，后续也可能增加其他入口。
- AgentBus 只负责原始来源事实进入本系统，当前已经通过 `SourceMessage Inbox` 保存。
- SuperAgent 是黑盒抽取能力，本系统不关心它内部如何抽取。
- SuperAgent 不直连本系统数据库，只能通过本系统后端接口查询已有订单和任务上下文。
- SuperAgent 抽取成功后，通过调用本系统后端接口创建一个或多个任务。
- SuperAgent 告知的任务类型是本系统创建任务的依据，本系统暂时不做业务合法性判断。
- 本系统只做接口鉴权、基础 JSON 可解析性、幂等键、必要技术字段等技术校验。
- 任务必须挂靠到订单下，异常任务也需要先创建临时订单作为处理容器。
- 同一次 SuperAgent 调用如果返回多个任务，必须按返回 JSON 列表顺序确定任务执行顺序。
- 同一个订单下，前一个任务未完成时，后续任务只能查看，不能编辑、确认或执行模拟操作。
- 用户在任务详情页可以查看、修改字段内容，并确认订单归属。
- 用户确认字段和订单关系后，才能执行 OPERA/OHIP 模拟操作。
- 当前 OHIP/OPERA 不接真实接口，只做模拟操作。
- 所有任务类型转换、订单切换、临时订单逻辑删除都必须记录审计和原因。

## 3. 总体流程

```text
AgentBus / 未来其他入口
→ SourceMessage Inbox 记录原始来源事实
→ SuperAgent 读取或处理原始来源数据
→ SuperAgent 抽取结构化 JSON
→ SuperAgent 通过本系统后端接口查询已有订单和任务上下文
→ SuperAgent 调用本系统接口创建一个或多个任务
→ 本系统按任务类型和返回顺序创建任务并挂靠订单
→ 用户在任务详情页查看、修改字段、确认订单归属
→ 用户确认后执行 OPERA/OHIP 模拟操作
→ 任务完成后，同订单下后续任务解锁处理
```

中文说明：

- `SourceMessage Inbox` 是来源事实层，不表达订单、任务或业务结论。
- SuperAgent 负责抽取并告知任务类型，但不直接改变本系统最终业务状态。
- Order / Task 是本系统后续业务核心，本系统必须掌握任务顺序、可处理状态、审计和模拟操作结果。

## 4. 与 M001 SourceMessage 的关系

已完成的 M001 只覆盖以下能力：

```text
AgentBus 原始消息
→ SourceMessage Inbox 落库
→ 查询安全摘要
→ 受控读取原文
→ 记录原文读取审计
```

M001 不做以下事情：

- 不创建订单。
- 不创建任务。
- 不调用 SuperAgent。
- 不判断任务类型。
- 不执行 OPERA/OHIP 模拟操作。
- 不自动 ACK、回复客户或写业务结果。

因此，本文流程和当前 SourceMessage 代码没有冲突。SourceMessage 是后续订单任务流程的上游来源事实。

## 5. 核心角色与职责边界

| 模块或外部系统 | 职责 | 不负责 |
| --- | --- | --- |
| AgentBus | 接收邮件等外部渠道消息，并把原始 payload 推送给本系统 | 不做 AI 抽取，不创建任务，不调用业务写接口 |
| SourceMessage Inbox | 保存原始来源事实、幂等、查询安全摘要、受控读取原文 | 不表达订单归属，不表达任务类型，不表达业务合法性 |
| SuperAgent | 抽取结构化 JSON，判断任务类型，调用本系统后端接口创建任务 | 不直连数据库，不绕过本系统权限和审计，不直接执行 OPERA/OHIP |
| Order | 承载任务队列、订单号、临时订单状态和业务订单关系 | 不保存 SuperAgent 外部协议细节 |
| Task | 承载任务类型、抽取字段、用户确认字段、处理状态和执行顺序 | 不直接替代订单，不直接保存原始邮件全文 |
| Operation Simulation | 记录用户确认后的 OPERA/OHIP 模拟操作、结果和重试 | 当前不调用真实 OHIP/OPERA 接口 |

## 6. SuperAgent 任务创建边界

SuperAgent 创建任务时，本系统只做技术接收校验，不做业务合法性判断。

技术校验包括：

- 接口鉴权和调用方身份校验。
- 请求 JSON 可解析。
- 幂等键或批次标识存在。
- 任务列表结构可识别。
- 任务类型是本系统已经约定的稳定代码。
- 任务列表顺序可保留。

暂时不做的业务判断包括：

- 不判断任务是否应该是 `NEW_BOOKING`。
- 不判断任务是否应该是 `UPDATE_BOOKING`。
- 不判断任务是否应该是 `CANCEL_BOOKING`。
- 不根据字段缺失自动改成异常任务。
- 不判断 `CANCEL_BOOKING` 前是否真的存在已完成的 `NEW_BOOKING`。
- 不判断房型、日期、金额、订单号等字段是否业务合理。

如果 SuperAgent 告知是异常任务，本系统就按异常任务创建。如果 SuperAgent 告知是其他已知任务类型，本系统就按该类型创建。

## 7. 订单模型第一版理解

订单应至少区分内部身份、临时展示编号和真实业务订单号。

| 概念 | 中文说明 |
| --- | --- |
| `orderId` | 本系统内部订单 ID，永远存在，用于任务挂靠和内部引用 |
| `temporaryOrderCode` | 临时订单编号或前端展示编号，用于还没有明确真实订单号的场景 |
| `businessOrderNo` | 真实业务订单号，可能来自 SuperAgent 抽取结果、用户确认字段或后续模拟操作回填 |
| `orderStatus` | 订单状态，例如临时、有效、逻辑删除等 |
| `deletedReason` | 逻辑删除原因，主要用于异常任务转移后删除原临时订单 |

`NEW_BOOKING` 任务不一定都需要等待 OPERA 模拟创建后才获得真实订单号。系统应优先查看用户确认后的字段中是否已有订单号：

- 如果确认字段中已有订单号，则优先使用该订单号作为 `businessOrderNo`。
- 如果确认字段中没有订单号，则先使用内部订单 ID 或临时编号追踪，后续如果模拟操作返回真实订单号再回填。

## 8. 任务模型第一版理解

任务至少需要保存 SuperAgent 原始抽取内容和用户确认后的内容。

| 概念 | 中文说明 |
| --- | --- |
| `taskId` | 本系统内部任务 ID |
| `orderId` | 当前挂靠订单 ID |
| `taskType` | 任务类型，由 SuperAgent 或后续人工转换确定 |
| `taskStatus` | 任务状态，用于控制是否可编辑、可确认、可执行 |
| `batchId` | SuperAgent 创建任务批次 ID 或调用 ID |
| `batchItemIndex` | 同一次 SuperAgent 返回列表中的顺序，从 0 或 1 开始需后续统一 |
| `orderSequence` | 订单下的任务执行顺序 |
| `extractedJson` | SuperAgent 原始抽取 JSON，不应被用户编辑覆盖 |
| `confirmedJson` | 用户修改并确认后的 JSON，用于后续模拟操作 |
| `sourceMessageId` | 关联 SourceMessage ID，便于追溯原始邮件或来源消息 |

任务类型当前确认：

- `NEW_BOOKING`：新建订单任务。
- `UPDATE_BOOKING`：更新订单任务。后续可按字段组在前端展示不同卡片。
- `CANCEL_BOOKING`：取消订单任务。
- `EXCEPTION`：异常任务，表示 SuperAgent 无法判断属于前三类。

关于“任务大致 5 种”的表述，当前只确认以上 4 类。后续新增类型以具体任务分类和字段定义为准。

## 9. 任务顺序与可处理状态

订单下的任务必须按顺序处理。

排序规则第一版：

```text
orderId + orderSequence
```

同一次 SuperAgent 调用创建多个任务时：

- 必须保留 SuperAgent 返回 JSON 列表中的任务顺序。
- 同一个批次里，列表前面的任务优先执行。
- 不能只依赖创建时间排序，因为同批次任务时间可能完全一样。

后续任务的可处理规则：

- 当前面存在未完成任务时，后续任务只能查看。
- 后续任务不能编辑字段。
- 后续任务不能确认订单关系。
- 后续任务不能执行 OPERA/OHIP 模拟操作。
- 后续任务不能重试模拟操作。

任务切换订单后：

- 必须记录操作人、原订单、新订单、原因和时间。
- 任务进入目标订单队列后，需要按目标订单任务队列规则重新判断是否可处理。
- 如果目标订单前面已有未完成任务，该任务切过去后也只能查看。

## 10. Task Detail 行为

任务详情页不是只读确认页，而是用户处理任务的主要工作台。

任务可处理时，用户可以：

- 查看 SuperAgent 原始抽取结果。
- 查看关联 SourceMessage 的安全摘要或受控原文入口。
- 修改字段内容。
- 确认订单归属。
- 对异常任务选择转换目标类型。
- 输入转换、切换或删除原因。
- 确认后触发 OPERA/OHIP 模拟操作。
- 查看每条模拟操作结果。
- 对失败或允许重试的模拟操作发起重试。

任务不可处理时，用户只能查看：

- 任务基础信息。
- 当前挂靠订单。
- 抽取字段和已确认字段。
- 阻塞原因，例如“同订单下前置任务未完成”。
- 前置任务信息或跳转入口。

## 11. 异常任务处理流程

异常任务也必须挂靠订单。创建异常任务时，系统创建一个新的临时订单，并将异常任务挂靠到该临时订单。

```text
SuperAgent 创建 EXCEPTION 任务
→ 系统创建临时订单
→ 异常任务挂靠临时订单
→ 用户在任务详情页处理异常任务
→ 用户选择转为 NEW_BOOKING / UPDATE_BOOKING / CANCEL_BOOKING
→ 用户填写原因并确认
→ 系统写审计
```

### 11.1 转为 NEW_BOOKING

- 临时订单继续保留。
- 任务类型从 `EXCEPTION` 改为 `NEW_BOOKING`。
- 用户可以修改并确认字段。
- 系统优先查看确认字段中的订单号是否有值。
- 如果订单号有值，则将该值作为真实业务订单号。
- 如果订单号无值，则继续使用临时编号追踪，后续模拟操作如返回真实订单号再回填。
- 必须记录任务类型变更审计和原因。

### 11.2 转为 UPDATE_BOOKING

- 用户选择一个已有订单。
- 任务类型从 `EXCEPTION` 改为 `UPDATE_BOOKING`。
- 任务从临时订单切换到目标订单。
- 原临时订单逻辑删除。
- 必须记录任务类型变更、订单关系变更、临时订单逻辑删除审计和原因。
- 切换后必须受目标订单任务队列顺序约束。

### 11.3 转为 CANCEL_BOOKING

- 用户选择一个已有订单。
- 任务类型从 `EXCEPTION` 改为 `CANCEL_BOOKING`。
- 任务从临时订单切换到目标订单。
- 原临时订单逻辑删除。
- 必须记录任务类型变更、订单关系变更、临时订单逻辑删除审计和原因。
- 切换后必须受目标订单任务队列顺序约束。

## 12. OPERA/OHIP 模拟操作

当前阶段没有真实 OHIP/OPERA 接口，只做模拟操作。

模拟操作第一版规则：

- 只有当前订单下可处理的任务才能执行模拟操作。
- 执行前必须完成字段修改和订单关系确认。
- 一个任务可能生成多条模拟操作。
- 任务详情页需要展示每条模拟操作的结果。
- 每条模拟操作应有独立状态、失败原因、重试次数和最近执行时间。
- 重试必须可追溯，不能覆盖历史执行结果。
- 任务是否完成，需要根据该任务要求的模拟操作是否全部达到完成条件判断。

模拟操作的具体类型、字段、完成条件和重试限制后续另行定义。

## 13. 审计要求

以下行为必须有审计：

- SuperAgent 创建任务批次。
- 同批次内每个任务的创建顺序。
- 用户修改任务字段。
- 用户确认订单关系。
- 任务类型转换。
- 任务切换订单。
- 临时订单逻辑删除。
- OPERA/OHIP 模拟操作执行。
- 模拟操作重试。

审计至少应包含：

| 字段 | 中文说明 |
| --- | --- |
| `actor` | 操作人或系统调用方 |
| `action` | 操作类型 |
| `reason` | 用户填写或系统记录的原因 |
| `beforeSnapshot` | 变更前摘要 |
| `afterSnapshot` | 变更后摘要 |
| `occurredAt` | 发生时间 |

审计中不得记录 Secret、Token、完整邮件正文、附件 URL 或不必要的个人敏感信息。

## 14. 暂不包含范围

第一版流程文档暂不定义：

- 具体 SuperAgent 创建任务接口 JSON Schema。
- 具体订单表、任务表、操作表结构。
- 具体前端页面布局。
- 具体任务字段和卡片展示规则。
- 真实 OHIP/OPERA 接口调用。
- SuperAgent 内部 prompt、skill 或抽取实现。
- 业务字段合法性判断规则。
- 任务类型之外的自动分类逻辑。

## 15. 后续建议 checkpoint

建议后续按以下顺序拆分，不一次性做完：

1. 定义 SuperAgent 调本系统创建任务接口契约。
2. 定义 Order / Task / Task Audit / Operation Simulation 的最小数据模型。
3. 实现任务入站创建、幂等、批次顺序和订单挂靠。
4. 实现任务详情读取、字段编辑和订单关系确认。
5. 实现异常任务转换、订单切换和临时订单逻辑删除。
6. 实现 OPERA/OHIP 模拟操作结果和重试机制。
7. 再根据前端页面范围实现列表、详情和队列状态展示。

## 16. 待确认问题

- SuperAgent 创建任务接口的正式 JSON 格式是什么。
- SuperAgent 任务批次 ID 和每个任务 item 的幂等键由谁生成。
- `batchItemIndex` 从 0 开始还是从 1 开始。
- 订单号字段在不同任务类型的 `confirmedJson` 中具体叫什么。
- 任务状态机需要哪些稳定状态。
- 模拟操作的完成条件和失败后是否允许跳过。
- 任务完成是否允许人工强制完成，若允许需要什么权限和审计。
- 第五种任务类型是否存在，若存在具体业务含义是什么。
