th-hotel-simple/docs/project/requirements/M002-order-task-workflow-v1.md

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. 总体流程

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

中文说明：

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

4. 与 M001 SourceMessage 的关系

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

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. 任务顺序与可处理状态

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

排序规则第一版：

orderId + orderSequence

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

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

后续任务的可处理规则：

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

任务切换订单后：

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

10. Task Detail 行为

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

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

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

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

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

11. 异常任务处理流程

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

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 中具体叫什么。
• 任务状态机需要哪些稳定状态。
• 模拟操作的完成条件和失败后是否允许跳过。
• 任务完成是否允许人工强制完成，若允许需要什么权限和审计。
• 第五种任务类型是否存在，若存在具体业务含义是什么。