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