实现 M002 V3 入站解析与路由基线

This commit is contained in:
andy
2026-07-11 14:11:18 +08:00
parent c5e72078e5
commit 3589bd99c7
22 changed files with 2306 additions and 72 deletions

View File

@@ -4,15 +4,17 @@
| 项目 | 内容 |
| --- | --- |
| 文档版本 | 0.2 |
| 日期 | 2026-07-08 |
| 状态 | 后端 checkpoint 计划与阶段实现记录 |
| 文档版本 | 0.3 |
| 日期 | 2026-07-11 |
| 状态 | V2 后端 checkpoint 阶段记录V3 新开发和当前实现状态以 `M002-order-task-workflow-v3.md` 为准 |
| 适用范围 | M002 后端实现拆分、交付物和验收标准 |
| 主要读者 | 后端、测试、产品、后续协作 agent |
## 1. 文档定位
本文把 `M002-order-task-workflow-v2.md``M002-superagent-task-result-api-contract.md``M002-backend-data-model-design.md` 拆成可执行后端 checkpoint。
本文把 `M002-order-task-workflow-v2.md``M002-superagent-task-result-api-contract.md``M002-backend-data-model-design.md` 拆成可执行后端 checkpoint,用于理解当前已阶段实现的 M002 V2 能力
2026-07-11 后M002 后续新开发必须先读 `M002-order-task-workflow-v3.md`。V3 已确认采用 0711 P0 冻结基线,新增结构化 `S10/S99`、42 路由、方案 C、type-known manual review 同卡解阻、复核场景订单归属确认和 P1/P2 fail-closed 边界。本文下方 V2 checkpoint 不再覆盖这些新需求。
每个 checkpoint 都应先读项目规范,再按本项目包结构和注释要求实现。不要一次性把完整后端做完,也不要在不确定字段或目录归属时先写再重构。
@@ -27,8 +29,12 @@
- `docs/import/reusable/backend-base-structure-pagination-guidelines.md`
- `docs/import/reusable/alibaba-java-coding-guidelines-summary.md`
- `docs/project/requirements/M002-order-task-workflow-v2.md`
- `docs/project/requirements/M002-order-task-workflow-v3.md`
- `docs/project/requirements/M002-superagent-task-result-api-contract.md`
- `docs/project/requirements/M002-backend-data-model-design.md`
- `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/README_交付说明.md`
- `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md`
- `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更说明_3.0_to_当前版_2026-07-10.xlsx`
- `docs/import/20260706/开发AI先读_工作顺序.md`
- `docs/import/20260706/AI输出参数并集字典.xlsx`
- `docs/import/20260706/任务卡展示编辑矩阵.xlsx`

View File

@@ -4,9 +4,9 @@
| 项目 | 内容 |
| --- | --- |
| 文档版本 | 0.1 |
| 日期 | 2026-07-07 |
| 状态 | 后端数据模型与阶段实现记录 |
| 文档版本 | 0.2 |
| 日期 | 2026-07-11 |
| 状态 | V2 后端数据模型与阶段实现记录V3 新开发和当前实现状态以 `M002-order-task-workflow-v3.md` 为准 |
| 适用范围 | AI 过渡层、订单、任务、任务卡、审计和 OPERA 模拟结果 |
| 主要读者 | 后端、数据库、测试、后续协作 agent |
@@ -16,6 +16,8 @@
本文不是完整最终模型。当前后端已经按本模型落地第一阶段 Flyway migration、Entity、Mapper、Repository、Service 和测试;后续真实 OPERA、前端页面和 SuperAgent 查询上下文接口仍需继续补充。
2026-07-11 后M002 V3 已确认采用 0711 P0 冻结基线。后续数据模型扩展必须支持结构化 `S10/S99``message_events[]`、42 路由、方案 C 中的 AI 原始三元组 / 系统处理分类分离、type-known manual review 同卡解阻和 `adapter_contract_error`,不能只沿用本文的 `ai_task_results[]` 阶段模型。
## 2. 设计原则
- 保留 AI 原始 JSON不覆盖、不重写、不丢字段。
@@ -123,7 +125,7 @@
表名:`workflow_reservation_ai_transition`
一条 `ai_task_results[]` item 对应一行。
V2 一条 `ai_task_results[]` item 对应一行。M002 V3 后,`message_events[]``S10/S99` 入口通知、`unhandled_current_intents[]` 和 adapter 契约错误也统一以 transition 方式追溯保存。
| 字段 | 类型建议 | 中文说明 |
| --- | --- | --- |
@@ -136,8 +138,10 @@
| `execution_order` | `INT` | 映射到订单任务队列的初始顺序 |
| `catalog_code` | `VARCHAR(32)` | Skill 目录代码 |
| `skill_id` | `VARCHAR(128)` | Skill 标识 |
| `result_type` | `VARCHAR(32)` | AI 结果类型 |
| `result_type` | `VARCHAR(64)` | AI 结果类型,例如 `normal_task``manual_review``source_message_review_notification``adapter_contract_error` |
| `ai_task_type` | `VARCHAR(64)` | AI 原始任务类型 |
| `route_code` | `VARCHAR(64)` | M002 V3 派生路由码S10/S99 使用外部 route_code业务事件使用系统稳定路由码 |
| `system_process_category` | `VARCHAR(64)` | 系统处理分类:`BUSINESS_TASK``SOURCE_MESSAGE_NOTIFICATION``UNHANDLED_CURRENT_INTENT``ADAPTER_CONTRACT_ERROR` |
| `system_task_type` | `VARCHAR(64)` | 系统主任务类型 |
| `task_card_type` | `VARCHAR(64)` | 任务卡类型 |
| `task_subtype` | `VARCHAR(128)` | 业务动作 subtype |
@@ -157,6 +161,8 @@
| `informational_message_json` | `LONGTEXT` | 信息提醒 JSON |
| `attachments_json` | `LONGTEXT` | 附件 JSON |
| `context_used_json` | `LONGTEXT` | 上下文 JSON |
| `adapter_error_code` | `VARCHAR(128)` | Adapter 契约错误代码,仅在当前 event 不建业务任务时保存 |
| `adapter_error_message` | `VARCHAR(512)` | Adapter 契约错误说明,仅保存安全摘要 |
| `created_at` / `updated_at` | `DATETIME(6)` | 创建和更新时间 |
索引建议:
@@ -164,6 +170,8 @@
- 唯一索引:`hotel_id + item_idempotency_key`
- 普通索引:`hotel_id + source_message_id + source_event_index`
- 普通索引:`hotel_id + result_type + ai_task_type`
- 普通索引:`hotel_id + route_code`
- 普通索引:`hotel_id + system_process_category`
- 普通索引:`hotel_id + group_code`
- 普通索引:`hotel_id + confirmation_number`
@@ -394,7 +402,7 @@
- 任务阻塞状态:实时计算,不落 `BLOCKED`
- OPERA 真实接口字段映射:后续真实系统接入后在 adapter 层补充。
- 全量 Excel 字段路径:后端引用 `docs/import/20260706/任务卡展示编辑矩阵.xlsx` 作为完整规则来源,不手抄成数据库。
- 前端展示 / 编辑白名单:前端引用 `docs/import/20260708/任务卡前端展示字段表 3.0.xlsx`,该白名单不作为后端校验和 OPERA 映射的替代来源。
- 前端展示 / 编辑白名单:V2 阶段前端引用 `docs/import/20260708/任务卡前端展示字段表 3.0.xlsx`V3 起以 2026-07-11 P0 冻结基线中的前端 Excel 和路由说明为准。前端白名单不作为后端校验和 OPERA 映射的替代来源。
## 15. 待确认问题

View File

@@ -0,0 +1,364 @@
# M002 Order Task Workflow 订单任务主流程 V3
## 文档信息
| 项目 | 内容 |
| --- | --- |
| 文档版本 | 0.1 |
| 日期 | 2026-07-11 |
| 状态 | 0711 P0 基线确认版;后端已完成 M002 V3 CP1-CP2 入站解析与路由基线 |
| 适用范围 | SourceMessage 之后的 SuperAgent 输出适配、任务路由、只读通知卡、人工复核同卡解阻、前后端协作边界 |
| 主要读者 | 产品、后端、前端、测试、SuperAgent 对接方、后续协作 agent |
## 1. 文档定位
本文是 `M002-order-task-workflow-v2.md` 的第三版修正。V2 记录了当前后端阶段实现:`ai_task_results[]``S000/S999` 文本结果、订单任务基础流转、任务草稿确认、OPERA 模拟骨架、SuperAgent 查询上下文接口和前端 P0 查询接口。
V3 记录 2026-07-11 导入的 SuperAgent P0 冻结基线,以及本项目已经确认的产品决策。后续 M002 新开发应优先按本文执行;当前代码中已经存在的 V2 行为,需要按 checkpoint 逐步兼容迁移,不能在未实现前对外宣称已经完成。
本文不替代 `docs/project/integrations/superagent-api-contract.md` 的线上联调接口说明。若要给 SuperAgent 联调方使用,必须在对应接口实现完成后同步更新该对外契约。
## 2. 权威输入资料
V3 以以下资料和决策为输入:
| 资料 | 用途 |
| --- | --- |
| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/README_交付说明.md` | 0711 P0 交付边界、可先实现范围、P1/P2 暂缓范围 |
| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更与路由说明_3.0_to_current.md` | Adapter / Frontend 的 42 路由、人工复核、Parent split、fail-closed 规则 |
| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/01_Adapter_Frontend/任务卡前端字段变更说明_3.0_to_当前版_2026-07-10.xlsx` | P0 字段、三元组路由、旧枚举迁移、非法组合和验收用例 |
| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/02_AI_Runtime/main_agent_prompt.md` | 当前 Main Agent 运行提示词 |
| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/02_AI_Runtime/booking-desk-event.skill` | 当前 Skill 包 |
| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/02_AI_Runtime/核心契约_展开阅读/*.md` | 输出契约、事件路由、内容完整性、Main 到 Skill 输入、人工复核规则 |
| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/03_P0_Acceptance/` | P0 fixtures 和轻量 validator |
| `docs/import/20260711/开发交付_P0冻结基线_2026-07-11/04_Known_Issues_非契约/` | P1/P2 未闭合范围,只用于识别暂缓和 fail-closed不作为生产规则源 |
本项目确认的产品决策:
- M002 V3 正式采用 0711 P0 基线。
- 旧数据 `S000/S999` 继续在任务列表可见;新数据迁移为 `S10/S99`
- `S10/S99` 继续复用隐藏技术订单 + 任务列表只读卡,不进入订单列表和订单执行队列。
- 缺少 `source_message.source_message_id` 时,目标契约采用 `HTTP 400 + infrastructure_input_error + retryable=true` 的技术错误响应;当前 CP1-CP2 后端暂返回标准错误包装typed 响应仍在后续 checkpoint。
- 内部任务模型采用“方案 C”完整保存 AI 三元组,系统处理分类和前端展示分类单独维护。
- type-known manual review 使用同一张业务卡复核解阻,不生成第二张 normal task。
- 第一版保存全部 42 条路由 / 枚举,先支持保存和列表展示。
- P1/P2 未闭合范围命中时 fail closed不由本系统发明字段或业务规则。
- 普通任务切换订单继续后置P0 仅支持“复核场景下确认订单归属”。
## 3. 相对 V2 的核心变化
| 主题 | V2 | V3 |
| --- | --- | --- |
| SuperAgent 业务输出 | 顶层 `source_message_id + ai_task_results[]` | 顶层 `source_message + message_events[] + case_candidates[] + extraction_warnings[] + unhandled_current_intents[]` |
| 信息类 / 入口问题 | `text/plain``S000,source_message_id` / `S999,source_message_id` | 结构化 JSON`S10` / `S99``result_type=source_message_review_notification` |
| 任务路由 | 以 `result_type + task_type + task_subtype` 粗映射系统主任务 | 按每个 `message_events[i]` 派生 42 条 P0 三元组 |
| 人工复核 | Fallback / manual_review 可转换为业务任务 | type-known review 保留原业务卡;只有类型或 subtype 未知才走 Fallback |
| 复核解阻 | 偏“转换”思路 | 同卡 `review_status + review_resolution.field_overrides[]` 解阻 |
| Message Notification | 历史信息提醒任务 | 新入口统一使用 `S10/S99` 只读源邮件通知卡;历史数据兼容展示 |
| P1/P2 未闭合 | 部分规则可能由系统先做 | 明确 fail closed / adapter_contract_error不猜测 |
## 4. SourceMessage Identity 和入口错误
### 4.1 SourceMessage ID 口径
`source_message.source_message_id` 是 SuperAgent 从上游输入原样带回的外部来源消息 ID对应 AgentBus 邮件 payload 中的 `source.external_message_id`。它不是本系统内部 `platform_source_message_inbox.id`
后端处理时按以下路径反查:
```text
系统酒店 + source_provider + source_channel + source_message.source_message_id
→ platform_source_message_inbox.external_message_id
→ platform_source_message_inbox.id
→ workflow / task / transition 表内部 source_message_id 外键
```
V3 第一版继续使用单酒店阶段的系统默认酒店;后续多酒店或权限收口时再扩展显式酒店上下文。
### 4.2 缺少 source_message_id
Gateway 必须在读取正文、附件、OCR、历史、系统上下文或调用 Skill 前校验 `source_message.source_message_id`
为空时,目标契约响应:
```json
{
"result_type": "infrastructure_input_error",
"error_code": "missing_source_message_id",
"retryable": true,
"missing_fields": [
"source_message.source_message_id"
]
}
```
当前 CP1-CP2 实现说明:后端已识别缺失并返回 `HTTP 400`,但响应体仍使用系统标准错误包装,尚未切换为上方 typed `infrastructure_input_error` 结构。
处理要求:
- HTTP 状态码第一版使用 `400`
- 不创建 SourceMessage、AI transition、订单、任务、通知卡或审计业务记录。
- 不把该错误当成 `S10/S99`、Fallback 或人工复核。
- 调用方可修正输入后重试。
## 5. SuperAgent 输出分流
V3 接收端按根结构分流:
```text
1. infrastructure_input_error
→ 返回技术错误,不建卡。
2. source_message_review_notification + route_code=S10/S99
→ 创建只读源邮件通知卡,任务列表可见,订单列表不可见。
3. 业务根 source_message + message_events[]
→ 按每个 message_events[i] 派生业务任务或复核任务。
4. unhandled_current_intents[]
→ 仅保存和展示为源邮件详情 / 任务详情中的未覆盖业务意图块,不自动创建业务任务卡。
```
`candidate_events[]` 是 Main 到 Skill 的内部输入,不属于最终入站结果。本系统不得把它当成最终任务卡或持久化业务事实。
## 6. S10 / S99 处理规则
### 6.1 新入口结果
`S10``S99` 均为结构化入口通知结果:
| route_code | result_type | 固定含义 | manual_review |
| --- | --- | --- | --- |
| `S10` | `source_message_review_notification` | 输入可理解,但没有匹配当前支持的 active 业务事件 | `null` |
| `S99` | `source_message_review_notification` | 输入不足,无法形成业务素材包或判断支持范围 | 完整 `main_agent_entry_review` |
两者都要求用户查看源邮件并自行决定是否回复或处理,不代表系统可以自动忽略邮件。
### 6.2 系统落地
新数据 `S10/S99` 的系统处理规则:
- 按外部 `source_message.source_message_id` 反查 SourceMessage Inbox。
- 创建隐藏技术订单,仅用于满足任务外键或列表聚合需要。
- 创建只读源邮件通知卡,任务列表可见。
- 订单列表不可见;订单详情不能作为普通订单页打开。
- 不参与订单任务执行队列,`queue_participation=false`
- 不阻塞任何订单任务,也不被任何订单任务阻塞。
- 不允许保存草稿、最终确认、复核转换、普通切换订单、执行 OPERA、重试 OPERA。
- 任务详情展示来源邮件、邮件会话、附件、SuperAgent 原始返回、`route_code` 和入口说明。
### 6.3 旧 S000 / S999 兼容
旧数据 `S000/S999` 已经在系统中以只读特殊任务展示。V3 不删除旧数据,也不要求历史回写。
兼容规则:
-`S000` 在前端和查询层按 `S10` 语义展示。
-`S999` 在前端和查询层按 `S99` 语义展示。
- 如果旧任务已经是 `SOURCE_MESSAGE_ONLY` 或等价只读类型,继续在任务列表可见。
- 新入站不再优先使用 `S000/S999` 文本格式;实现迁移前,对外契约应清楚标记当前代码支持范围。
## 7. Adapter 路由模型
### 7.1 42 条 P0 路由
V3 第一版必须保存并支持以下路由类别:
- 19 个业务 subtype每个 subtype 都有 normal 和 type-known manual review 两条路由,共 38 条。
- `S10``S99` 两条源邮件通知路由。
- 类型或 subtype 未知的 Fallback 路由:`manual_review + Fallback + business_event_review`
- `unhandled_current_intent + Unhandled Current Intent + requires_business_approval_or_unsupported_task_card` 展示路由。
第一版后端要求:
- 42 条路由全部进入枚举或稳定配置,不能只硬编码已实现的少数几条。
- 每条入站 event 都按自己的 `message_events[i]` 独立派生,不能在邮件根只生成一个任务。
- 同一封邮件多个任务按 SuperAgent 返回数组顺序和事件顺序生成执行顺序。
- `Note``Allotment Maintenance``update_allotment_control_block` 仅历史兼容,不允许新数据生成。
### 7.2 方案 CAI 三元组和系统处理分类分离
V3 内部模型采用方案 C避免把 SuperAgent 的任务三元组直接等同于本系统执行分类。
建议保存三层信息:
| 层级 | 字段示例 | 中文说明 |
| --- | --- | --- |
| AI 原始路由 | `ai_result_type``ai_task_type``ai_task_subtype``route_code` | 完整保存 SuperAgent 输出,不因系统处理而丢失 |
| 系统处理分类 | `system_process_category``system_task_type``queue_participation``readonly` | 决定是否进入订单队列、是否可编辑、是否可确认、是否可执行 |
| 前端展示分类 | `card_display_type``card_title_code``route_display_code` | 决定任务列表和详情如何展示 |
这样可以同时支持:
- `S10/S99` 有 AI 三元组,但不是业务执行任务。
- `unhandled_current_intent` 可展示,但不自动建业务任务卡。
- 新增业务卡可以先保存和列表展示,后续再逐步接校验和 OPERA adapter。
- type-known manual review 保留原业务 subtype不被强行改成 Fallback。
## 8. 业务任务和订单挂靠
### 8.1 业务任务
`normal_task` 业务事件可以按既有订单/任务模型生成业务任务;用户确认前不得执行 OPERA。
第一版应至少保留以下业务标识:
- `source_event_index`
- `array_index`
- `event_type`
- `ai_result_type`
- `ai_task_type`
- `ai_task_subtype`
- `route_code`
- `case_keys`
- `manual_review`
- `ai_payload_json`
- `review_status`
- `review_resolution`
### 8.2 订单归属
订单归属第一版规则:
- `New Booking` 无可靠业务号时创建临时订单。
-`group_code``confirmation_number` 等可定位字段时,优先挂靠或创建相应订单。
- 同一个 `hotel_id + GROUP_CODE` 只能有一个 `ACTIVE` 订单。
- 同一个 `hotel_id + CONFIRMATION_NUMBER` 只能有一个 `ACTIVE` 订单。
- `S10/S99` 使用隐藏技术订单,不进入订单列表。
P0 新增明确:复核场景下需要支持用户确认订单归属。它不是普通任务切换订单:
| 能力 | V3 范围 |
| --- | --- |
| 复核过程中确认 / 选择订单归属 | P0 需要支持 |
| type-known manual review 解决字段同时确认订单归属 | P0 需要支持 |
| Fallback 被用户判定为 New / Update / Cancel 并确定订单归属 | P0 需要支持 |
| 已创建普通任务任意切换到其他订单 | 继续后置,不在 P0 |
## 9. Type-known manual review 同卡解阻
### 9.1 路由原则
只要 SuperAgent 已能确定业务 `event_type` 和 subtype就必须保留原业务类型和 subtype。字段、目标对象、房型、Rate Code、证据或上下文不安全时使用同一业务卡的 manual-review mode。
只有业务类型或 subtype 本身无法确定时,才使用:
```text
manual_review + Fallback + business_event_review
```
### 9.2 状态模型
Agent payload 不可变。本系统在同一张卡上维护复核状态:
```json
{
"review_status": "pending",
"review_resolution": null
}
```
用户解决后:
```json
{
"review_status": "resolved",
"review_resolution": {
"field_overrides": [
{
"field_pointer": "/extracted_fields/room_items/0/pms_room_type_code",
"value": "SU1"
}
],
"resolved_by": "<user_id>",
"resolved_at": "2026-07-11T00:00:00Z"
}
}
```
要求:
- 不改写 `ai_payload_json`
- 不创建第二张 linked normal task。
- `missing_fields[]` 必须是 RFC 6901 JSON Pointer。
- Pointer 必须能映射到该业务卡已知可编辑字段,否则为 `adapter_contract_error`
- 订单归属确认可作为复核解阻的一部分保存,但不得打开普通任务随意切换订单能力。
- 全部缺失字段、订单归属、目录值和依赖校验通过后,才进入 Preflight / READY。
## 10. P1/P2 未闭合范围处理
0711 导入包已经明确 P1/P2 未闭合。后端、前端、Adapter 都不得自行发明规则。
命中以下情况时,第一版应 fail closed
- 42 路由与 runtime 输出不一致或无法唯一匹配。
- `manual_review` 九字段不完整。
- `missing_fields[]` 不是 RFC 6901 pointer或无法映射到可编辑字段。
- Parent split 关系字段不完整或无法一一对应。
- `Note``Allotment Maintenance``update_allotment_control_block` 新数据出现。
- Fix Charge、Preflight/lock、Fallback 非字段解阻、Voucher 文件对象缺失、Manual RateCode 边界等 P1/P2 未闭合场景。
处理建议:
- 单个 event 契约错误时,该 event 0 卡并记录 `adapter_contract_error`
- 同一邮件的 sibling events 继续独立处理。
- 契约错误不是人工复核,不能用 Fallback 吞掉。
- 前端应展示“契约问题 / 暂不支持”的稳定 code不把它当成可编辑业务卡。
## 11. 前端影响
前端需要按 V3 调整以下行为:
- 任务列表支持展示旧 `S000/S999` 和新 `S10/S99`,但新文案以 `S10/S99` 为主。
- `S10/S99` 只读卡只出现在任务列表和任务详情,不出现在订单列表。
- 任务列表不应仅按旧 `SOURCE_MESSAGE_ONLY` 判断;应兼容后端后续返回的 `route_code=S10/S99``result_type=source_message_review_notification`
- type-known manual review 不再统一展示成 Fallback应展示原业务卡名称和 subtype并显示复核状态。
- 复核解阻页需要能提交 `field_overrides[]`,并在复核场景下确认订单归属。
- `unhandled_current_intents[]` 只作为展示块,不提供执行按钮。
- P1/P2 fail-closed 返回时,前端展示稳定错误和源邮件入口,不让用户误以为可以确认执行。
## 12. 后端实施 checkpoint 建议
V3 建议拆成以下 checkpoint避免一次性重构过大
| Checkpoint | 目标 | 说明 |
| --- | --- | --- |
| M002-V3-CP1 | 文档和枚举基线 | 已完成:建立 42 路由枚举 / 稳定配置,作为入站路由唯一代码源 |
| M002-V3-CP2 | 入站解析兼容 | 已完成:正式回调支持结构化 S10/S99 和 V3 业务根,保留旧 S000/S999 兼容 |
| M002-V3-CP3 | 路由持久化 | 部分完成:已保存 AI 原始三元组、route_code、system_process_category、unhandled_current_intents 和 adapter_contract_errormessage_events / unhandled_current_intents 的前端完整展示仍后置 |
| M002-V3-CP4 | 列表 / 详情展示 | 任务列表和详情支持 S10/S99、42 路由只读展示、type-known review 展示 |
| M002-V3-CP5 | 同卡复核解阻 | 支持 review_status、field_overrides、复核场景订单归属确认和 READY 流转 |
| M002-V3-CP6 | P0 fixtures 回归 | 引入 0711 P0 fixtures / validator 作为后端适配测试参考,补充项目级测试 |
## 13. 明确不做
V3 P0 不做以下事项:
- 不做真实 OPERA / OHIP 写入。
- 不做普通任务任意切换订单。
- 不由前端直接调用 SuperAgent、AgentBus、OPERA、OHIP 或数据库。
- 不把 `candidate_events[]` 当成最终任务。
- 不自动根据 `unhandled_current_intents[]` 创建业务任务卡。
- 不用 P1/P2 Known Issues 自行发明字段或 schema。
- 不移除历史 `S000/S999` 数据展示。
## 14. 当前代码现状提醒
截至 M002 V3 CP1-CP2 落地后,当前后端已经实现:
- `S000/S999` 文本结果兼容处理。
- 结构化 `S10/S99` 入站处理,复用 `SOURCE_MESSAGE_ONLY` 只读特殊任务。
- 42 条 P0 路由枚举 / 稳定配置。
- V3 业务根 `source_message + message_events[]` 基础解析;能派生到稳定路由的 event 创建业务任务,无法派生的 event、显式 `contract_errors`、根 `missing_fields`、不完整 `manual_review` 和不完整 parent split 候选只落 `adapter_contract_error` transition。
- `unhandled_current_intents[]` 只落 `UNHANDLED_CURRENT_INTENT` transition不创建订单和任务也不伪装成 adapter 契约错误。
- AI transition 最小保存 `route_code``system_process_category``adapter_error_code``adapter_error_message`
- 订单 / 任务列表、任务详情、草稿保存、最终确认、OPERA 模拟骨架和审计列表。
- SuperAgent 查询上下文接口 1、2以及邮件会话相关查询。
仍需后续 checkpoint 实现:
- type-known review 同卡解阻、`review_status``review_resolution.field_overrides[]`
- 复核场景订单归属确认。
- `manual_review.missing_fields[]` 到任务卡可编辑字段白名单的完整映射校验。
- `source_message.source_message_id` 缺失时按 V3 typed `infrastructure_input_error` 结构响应。
- 任务列表 / 详情完整透出 V3 `route_code`、入口通知结构、unhandled intent 展示块和 adapter contract error 展示。
- 真实 OPERA / OHIP、普通任务任意切换订单、P0 fixtures / validator 全量回归。

View File

@@ -8,18 +8,20 @@
| 项目 | 内容 |
| --- | --- |
| 文档版本 | 0.3 |
| 日期 | 2026-07-10 |
| 状态 | 后端接口契约草稿 |
| 文档版本 | 0.5 |
| 日期 | 2026-07-11 |
| 状态 | V2 兼容 + M002 V3 CP1-CP2 入站解析基线;完整 V3 展示和同卡复核仍看 `M002-order-task-workflow-v3.md` 后续 checkpoint |
| 适用范围 | SuperAgent / Main Agent 调用本系统提交 AI 任务结果 |
| 主要读者 | 后端、SuperAgent 对接方、测试、后续协作 agent |
## 1. 文档定位
本文定义 SuperAgent / Main Agent 向本系统提交 `ai_task_results[]` 结构化结果,以及提交 S000/S999 特殊入口结果的后端接口契约。
本文定义 SuperAgent / Main Agent 向本系统提交 V3 `source_message + message_events[]` 业务根、结构化 S10/S99 入口通知、V2 `ai_task_results[]` 兼容结果,以及 S000/S999 特殊入口结果的后端接口契约。
本文承接 `M002-order-task-workflow-v2.md`,只定义本系统入站接口、鉴权、幂等、请求响应和技术校验边界,不定义 SuperAgent 内部 prompt、Skill 实现、OPERA 真实接口或前端展示细节。
2026-07-11 后M002 后续开发基线已迁移到 `M002-order-task-workflow-v3.md`。当前后端已完成 CP1-CP2结构化 `S10/S99` 入站、V3 业务根基础解析、42 路由枚举 / 稳定配置、`UNHANDLED_CURRENT_INTENT` 和 route 相关字段最小落库。旧 `S000/S999``ai_task_results[]` 仍作为兼容路径保留。对外联调以 `docs/project/integrations/superagent-api-contract.md` 为准。完整 type-known manual review 解阻、`missing_fields[]` 到任务卡字段白名单映射和 typed `infrastructure_input_error` 响应仍在后续 checkpoint。
## 2. 接口概览
| 项目 | 内容 |
@@ -29,7 +31,7 @@
| Content-Type | `application/json``text/plain` |
| 响应格式 | `application/json` |
| 一次请求范围 | 只能包含一个 `source_message_id` |
| 业务动作 | 接收 AI 结果或入口结果、写入 AI 过渡层生成订单 / 任务 / 任务卡 |
| 业务动作 | 接收 AI 结果或入口结果、写入 AI 过渡层,按可支持路由生成订单 / 任务 / 任务卡 |
| 鉴权方式 | HMAC-SHA256 签名 |
中文说明:
@@ -37,8 +39,8 @@
- 该接口是服务到服务的入站接口,不给前端直接调用。
- SuperAgent 不直连数据库,只能通过本接口提交任务结果或入口处理结果。
- 本接口只做技术校验和系统接收,不替代用户确认和 OPERA 模拟操作。
- `application/json` 用于 `normal_task` / `manual_review` 结构化任务。
- `text/plain` 用于 `S000,source_message_id` / `S999,source_message_id` 特殊入口结果。
- `application/json` 用于 V3 结构化 `S10/S99`、V3 业务根或 V2 `normal_task` / `manual_review` 兼容结构化任务。
- `text/plain` 用于 `S000,source_message_id` / `S999,source_message_id` 特殊入口结果兼容
### 2.1 SourceMessage ID 口径
@@ -175,7 +177,7 @@ JSON 请求体沿用 AI 导入文档定义的聚合结构。
| `ai_task_results[]` | 是 | AI 拆分出的任务结果列表,必须保留数组顺序 |
| `extraction_warnings[]` | 否 | 抽取警告;不直接等同于业务任务 |
第一版要求 `ai_task_results[]` 至少包含一条记录。没有业务动作的纯信息类邮件不要提交空数组,也不要新生成 `informational_message`应改`S000,source_message_id` 文本结果。
V2 第一版要求 `ai_task_results[]` 至少包含一条记录。没有业务动作的纯信息类邮件不要提交空数组,也不要新生成 `informational_message`新数据优先使用 V3 结构化 `S10/S99`,旧联调或兼容场景仍可使`S000,source_message_id` 文本结果。
### 4.3 `ai_task_results[]` 字段
@@ -184,7 +186,7 @@ JSON 请求体沿用 AI 导入文档定义的聚合结构。
| `source_event_index` | 是 | AI current 事件序号,建议从 1 开始 |
| `catalog_code` | 是 | Skill 目录代码,例如 S01、S02 |
| `skill_id` | 是 | Skill 标识 |
| `result_type` | 是 | 新入口只接受 `normal_task``manual_review``informational_message` 仅历史兼容 |
| `result_type` | 是 | V2 当前代码契约只接受 `normal_task``manual_review``informational_message` 仅历史兼容 |
| `task_type` | 是 | AI 原始任务类型 |
| `task_subtype` | 否 | 业务动作 subtype有则用于任务卡路由 |
| `current_or_history` | 否 | 当前或历史标识 |