案例2-企业智能工单助手逻辑梳理

 

 

三条核心业务链

  1. 创建工单

说明：

- 这一条链路里，真正被持久化的是两类数据：

  - `conversation_states`：保存当前会话状态，方便多轮补问。

  - `tickets`：保存真正创建出的工单。

- 如果字段不全，流程不会写入 `tickets`，只会把缺失字段和提问文案写回 `conversation_states`。

2. 知识问答

说明：

- 这里不会写 `tickets` 表。

- 主要输出是：

  - `answer`

  - `retrieved_knowledge`

3. 查询工单状态

说明：

- 当前查询逻辑优先从本轮 `user_input` 里正则提取 `TK-YYYYMMDD-XXX`。

- 如果本轮没提到工单号，会回退读取当前状态中的 `ticket_result.ticket_id`。

数据如何流转：

 

整个项目的核心其实不是单个函数，而是 `AssistantState`。

`AssistantState` 目前承载这些关键字段：

- `user_input`：当前轮用户输入

- `intent`：意图分类结果

- `answer`：返回给页面展示的主文本

- `retrieved_knowledge`：知识库命中结果

- `ticket_fields`：已提取出的工单字段

- `missing_fields`：还缺哪些字段

- `clarification_question`：补问文案

- `ticket_result`：建单或查单结果

- `query_target`：查单目标

- `next_step`：流程下一步控制位

可以把它理解成：前端发来一句话，后端不断往 `state` 里补字段，最后再从 `state` 里挑出前端需要显示的部分返回

 

实际代码函数调用顺序：

### 从页面到后端

1. `home_page`

2. `build_page_html`

3. 浏览器执行 `sendMessage`

4. `fetch("/api/chat")`

5. `chat`

6. `ConversationStateRepository.load`

7. `run_ticket_creation_flow`

8. `ConversationStateRepository.save`

9. 返回 `ChatResponse`

10. 前端 `buildAssistantCard`

创建工单：

1. `chat`

2. `run_ticket_creation_flow`

3. `merge_user_input_into_state`

4. `classify_intent`

5. `extract_ticket_fields`

6. `clarify_missing_fields` 或 `create_ticket_node`

7. `TicketService.create_ticket`

8. `TicketRepository.save`

 

 查询工单时

1. `chat`

2. `run_ticket_creation_flow`

3. `classify_intent`

4. `query_ticket_status_node`

5. `resolve_query_target`

6. `TicketService.get_ticket`

7. `TicketRepository.get`

知识问答时

1. `chat`

2. `run_ticket_creation_flow`

3. `classify_intent`

4. `search_from_md`

5. `KnowledgeService.search`