# IT智能服务台 - 复杂场景重构与统一路由 PRD(合并版) **版本**:v1.2 **日期**:2026-07-27 **状态**:已评审 **作者**:许清楚 **子系统**:03-AI服务 **模块**:意图路由 --- ## 一、文档变更记录 | 版本 | 日期 | 变更说明 | |------|------|----------| | v1.2 | 2026-07-27 | 新增4.1.1 打招呼检测规则:解决"您好+具体问题"被误判为纯打招呼的问题 | | v1.1 | 2026-07-19 | 完成7个待确认问题的决策:
- 暂停超时阈值:可配置,默认8小时
- 可更正字段:按类型区分
- 压缩阈值:可配置,默认6000 tokens
- 撤销次数:默认3次
- 依赖关系:仅记录来源
- 业务类别:预设+管理员添加
- 路由置信度:可配置,默认0.7 | | v1.0 | 2026-07-19 | 初始合并版本,整合以下文档:
- 复杂场景重构第一阶段
- 复杂场景重构第二阶段
- 业务路由推荐
- 统一意图路由层 | --- ## 二、产品目标 | # | 目标 | 衡量指标 | |---|------|----------| | G1 | **任务可中断、可恢复** — 员工因临时事务离开时,自动化处置流程不丢失,回来后一句话即可继续 | 暂停会话恢复成功率 ≥ 95%;恢复后无需重新输入已提供信息 | | G2 | **信息可更正、可补充** — 员工说错或想补充信息时,系统能正确理解并更新,不重复询问已修正的信息 | 更正意图识别准确率 ≥ 90%;更正后信息项值正确更新率 ≥ 95% | | G3 | **坐席可感知** — 坐席工作台能实时看到会话的暂停/恢复/更正事件,掌握员工处置进度 | 坐席端可查看暂停会话列表及恢复点信息;更正事件在会话时间线可见 | | G4 | **长对话不中断** — 长对话场景下 AI 不因 token 超限而中断或丢失关键信息 | 超长会话(>6000 tokens)AI 正常响应率 ≥ 99%;关键信息项零丢失 | | G5 | **多轮纠错** — 员工可在同一会话中多次更正/补充信息,系统自动维护版本与依赖 | 单 session 支持无限次更正;依赖联动提示准确率 ≥ 95% | | G6 | **透明体验** — 压缩与多轮纠错对员工透明,不增加操作负担 | 员工无额外操作步骤;压缩过程用户无感知 | --- ## 三、用户故事 ### 3.1 任务中断恢复 | # | 角色 | 用户故事 | |---|------|----------| | US-1 | 员工 | **As a** 员工, **I want** 在自动化处置过程中说"我先去开会"就能暂停任务, **so that** 我不用急急忙忙处理完,也不用担心中途离开导致流程丢失 | | US-2 | 员工 | **As a** 员工, **I want** 回来后说"继续刚才的"就能从断点恢复, **so that** 我不需要重新描述问题、重新提供已填的信息 | | US-3 | 员工 | **As a** 员工, **I want** 暂停后如果有多个未完成的任务,系统能提示我选择恢复哪个, **so that** 我不会搞混多个处置流程 | | US-4 | 坐席 | **As a** 坐席, **I want** 在工作台看到员工会话的暂停/恢复状态和更正记录, **so that** 我能了解处置进度的完整上下文,在需要介入时不会信息缺失 | | US-5 | 坐席 | **As a** 坐席, **I want** 能手动恢复或终止员工暂停过久的会话, **so that** 避免暂停任务长期堆积占用资源 | ### 3.2 信息更正与补充 | # | 角色 | 用户故事 | |---|------|----------| | US-6 | 员工 | **As a** 员工, **I want** 当我说错信息后(如用户名说成 zhangsan 实际是 lisi),系统自动更正, **so that** 不会因为口误导致处置结果错误 | | US-7 | 员工 | **As a** 员工, **I want** 能随时补充额外信息(如"顺便说一下,是财务部的电脑"), **so that** 系统掌握更完整的信息来精准处置 | | US-8 | 员工 | **As a** 员工, **I want** 在对话过程中可以多次更正不同信息项(先更正工号,再更正设备型号),每次更正都被完整记录 | | US-9 | 员工 | **As a** 员工, **I want** 更正某个信息项后,系统能提示我哪些关联信息需要一并更新,避免信息不一致 | | US-10 | 员工 | **As a** 员工, **I want** 如果我更正错了,我可以撤销最近一次更正,恢复到更正前的状态 | | US-11 | 坐席 | **As a** 坐席, **I want** 能在坐席端查看完整的信息项版本链,并对比任意两个版本的差异,以便快速理清员工多次更正的脉络 | ### 3.3 上下文压缩 | # | 角色 | 用户故事 | |---|------|----------| | US-12 | 员工 | **As a** 员工, **I want** 在超长对话中 AI 依然记得我之前提交的关键信息(如工号、申请事由),这样我不必反复重复 | | US-13 | 员工 | **As a** 员工, **I want** 长对话被"智能记忆"后仍能继续正常审批与执行流程,不会因为对话太长而收到错误或中断 | | US-14 | 运维 | **As a** 运维人员, **I want** 能够查看每次上下文压缩的日志记录,这样在 AI 行为异常时可以定位是否与压缩有关 | ### 3.4 业务路由 | # | 角色 | 用户故事 | |---|------|----------| | US-15 | 员工 | **As a** 员工, **I want** 当我咨询非IT业务时,系统能帮我转接到对应业务负责人, **so that** 我能得到正确的帮助 | | US-16 | 坐席 | **As a** 坐席, **I want** 能看到业务路由的日志记录, **so that** 在需要时能追溯路由决策 | --- ## 四、架构总览 ### 2.1 整体架构 ``` 用户消息到达 │ ├──→ 并行执行: │ ├── 控制意图识别(第0层) │ │ └── PAUSE/RESUME/CORRECT/SUPPLEMENT │ │ │ │ │ └── 命中 → 优先处理控制逻辑 │ │ │ └── 业务意图识别(第1层) │ └── approval/it_consult/non_it_routing/chitchat │ │ │ └── 正常业务路由 │ ▼ 消息合并器(单队列输出) │ ▼ 响应用户 ``` ### 2.2 分层说明 | 层级 | 名称 | 职责 | 响应目标 | |------|------|------|----------| | 第0层 | 控制意图层 | 识别PAUSE/RESUME/CORRECT/SUPPLEMENT | 优先级最高,秒级响应 | | 第1层 | 业务意图层 | 识别approval/it_consult/non_it_routing/chitchat | 毫秒级响应 | | 第2层 | 动态信息与诊断链 | 信息更正/版本链/排查步骤联动 | 版本变化触发重算 | --- ## 三、第0层:控制意图层 ### 3.1 意图类型 | 意图 | 说明 | 响应目标 | |------|------|----------| | PAUSE | 用户主动暂停会话 | 立即响应,保存上下文 | | RESUME_TASK | 用户恢复暂停的会话 | 立即响应,恢复进度 | | CORRECT | 用户更正之前的信息 | 记录变更,触发版本链,联动排查步骤 | | SUPPLEMENT | 用户补充缺失的信息 | 记录补充,触发版本链,联动排查步骤 | ### 3.2 设计原则 1. **并行识别**:控制意图识别与业务意图识别并行执行,互不阻塞 2. **优先级规则**:控制意图 > 业务意图 3. **消息合并**:同一轮对话只产出一条最终响应,避免多队列问题 ### 3.3 场景示例 ``` 场景1:用户暂停 用户:先去开会,稍后继续 系统:好的,您先忙~需要继续时跟我说一声「继续」就好。当前进度:{步骤描述} 场景2:用户恢复 用户:继续 系统:欢迎回来!您之前在处理「{会话标题}」,当前进度:{步骤描述},我们继续吧~ 场景3:用户更正 用户:抱歉,部门写错了,我是财务部的 系统:[记录更正] + [更新版本链] + [重新计算排查步骤] 「好的,已更新为财务部。根据您的情况,建议重新排查以下步骤:...」 场景4:用户补充 用户:对了,电脑是台式机 系统:[记录补充] + [更新版本链] + [重新计算排查步骤] 「好的,已记录。根据新信息,更新排查步骤如下:...」 ``` --- ## 四、第1层:业务意图层 ### 4.1 意图类型 | 意图 | 说明 | 后续流程 | |------|------|----------| | approval | 审批需求 | 推送审批卡片 | | it_consult | IT咨询 | 进入排查流程 | | non_it_routing | 非IT业务 | 路由到业务联系人 | | chitchat | 闲聊/打招呼 | 友好回复,不调用AI推理 | #### 4.1.1 打招呼检测规则 为避免无意义的AI调用,系统在进入意图识别前会先进行打招呼检测: - **纯打招呼**(如"你好"、"您好"、"hi")→ 返回欢迎语,**不调用AI** - **打招呼+实质问题**(如"您好,我电脑开不了机")→ 跳过打招呼检测,继续意图识别 **技术实现**:`ai_handler.py` 的 `is_greeting()` 方法 ```python # 伪代码示意 def is_greeting(content): # 如果消息包含实质性问题关键词,不视为打招呼 substantive_keywords = ["绑定", "连不上", "报错", "无法", "打印机", ...] if any(kw in content for kw in substantive_keywords): return False # 纯打招呼关键词检测 greeting_keywords = ["你好", "您好", "hi", "hello", ...] is_greet = any(kw in content for kw in greeting_keywords) # 纯打招呼且消息足够短才触发 return is_greet and len(content) <= 15 ``` ### 4.2 路由分层决策 | 层级 | 方法 | 适用场景 | |------|------|----------| | 第1层 | 本地规则 | 关键词匹配、常用语 | | 第2层 | 知识图谱 | 实体识别、业务关联 | | 第3层 | Dify | 复杂意图、多轮对话 | ### 4.3 业务路由联动 当用户更正信息(如部门)时,联动更新业务路由配置: | 信息项 | 联动字段 | 说明 | |--------|----------|------| | 部门 | service_area | 业务路由的服务范围 | | 姓名 | contact_name | 业务联系人姓名 | **联动规则**: 1. 用户更正 → 信息项更新 → 触发业务路由同步 2. 优先级:人工配置 > 自动更正 3. 记录audit log,便于追溯 --- ## 五、动态信息与诊断链(核心模块) ### 5.1 模块定位 本模块整合三个强耦合的功能: 1. **信息更正/补充** - 记录用户更正和补充的信息 2. **版本链** - 维护信息项的版本历史 3. **排查步骤** - 根据当前版本信息动态生成排查流程 ### 5.2 核心设计原则 **版本变化触发排查步骤重新计算**: ``` 用户更正/补充信息 │ ▼ 版本链记录变更(新增版本快照) │ ▼ 触发排查步骤重新计算 │ │ │ ├── 重置diagnosis_stage到initial │ │ │ └── 根据新版本信息重新生成排查流程 │ ▼ 展示更新后的排查步骤 ``` ### 5.3 数据模型 #### InformationItem(信息项表) | 字段 | 类型 | 说明 | |------|------|------| | session_id | UUID | 会话ID | | name | String | 信息项名称 | | value | String | 信息项值 | | modifiers | Array | 修饰词 | | is_filled | Boolean | 是否已填写 | | version | Integer | 版本号 | | derived_from | String | 推导来源 | | correction_reason | String | 更正备注 | | update_history | JSON | 更新历史 | | updated_at | Timestamp | 更新时间 | #### 版本快照 每次信息变更时,生成版本快照: - 快照内容:当前所有信息项的值 - 快照关联:当前diagnosis_stage状态 ### 5.4 排查步骤联动 | 触发条件 | 排查步骤行为 | |---------|-------------| | 用户更正信息 | 自动重新触发排查步骤 | | 坐席切换版本 | 自动重新触发排查步骤 | | 坐席撤销更正 | 回滚到上一版本 + 重新触发排查步骤 | **diagnosis_stage重置规则**: - 当版本切换时,diagnosis_stage重置为`initial` - 重新进入gathering_info阶段收集信息 ### 5.5 版本链可视化 | 功能 | 说明 | |------|------| | 时间线展示 | 按时间顺序展示信息项变更记录 | | diff对比 | 版本间差异对比 | | 撤销恢复 | 坐席可回滚到历史版本 | --- ## 六、上下文压缩 ### 6.1 触发条件 当对话token超过8000阈值时,触发上下文压缩。 ### 6.2 压缩策略 | 策略 | 说明 | |------|------| | Token阈值检测 | 监控对话总token数 | | 压缩摘要 | 将早期消息压缩为摘要 | | 快照保存 | 保留完整版本快照 | ### 6.3 推送策略 **不进行实时WebSocket推送**。 原因: 1. 压缩对用户无感知,界面无变化 2. 减少消息干扰 3. 可通过AI回复自然提及 **替代方案**: - AI在回复中可自然提及:"由于对话较长,我简化了早期上下文,如有需要请提醒我补充" --- ## 七、WS事件定义 ### 7.1 控制意图事件 | 事件名 | 说明 | 载荷 | |--------|------|------| | automation.paused | 会话已暂停 | session_id, resume_point, step_description | | automation.resumed | 会话已恢复 | session_id, resume_point, step_description | | automation.timeout_closed | 暂停超时关闭 | session_id, timeout_duration | | automation.info_corrected | 信息已更正 | session_id, item_name, old_value, new_value, new_version | | automation.info_supplemented | 信息已补充 | session_id, item_name, new_value, new_version | ### 7.2 事件推送规则 - 所有事件通过WebSocket推送 - 消息合并器确保单队列输出 - 同一轮对话只推送一条消息 --- ## 八、非目标(Non-Goals) 本PRD**不包含**以下内容: 1. ~~控制意图的WebSocket实时推送~~(由AI回复承载) 2. ~~上下文压缩的实时推送~~(对用户透明) 3. ~~时间线与版本链的分离设计~~(已整合为动态信息与诊断链) 4. ~~信息更正与业务路由的解耦~~(需要联动) --- ## 九、已确认配置参数 | 问题 | 结论 | 说明 | |------|------|------| | Q1: 暂停超时阈值 | **可配置,默认8小时** | 支持管理员调整,建议超时前15分钟提醒 | | Q2: 可更正/不可更正字段 | **按字段类型区分** | 可编辑:用户相关字段(部门、工号等);只读:会话元数据、AI生成字段 | | Q3: 上下文压缩阈值 | **可配置,默认6000 tokens** | 支持管理员调整 | | Q4: 更正撤销次数限制 | **默认3次** | 防止滥用,控制版本链复杂度 | | Q5: 信息项依赖关系 | **仅记录来源** | 使用derived_from字段记录推导来源,不自动推导 | | Q6: 业务类别清单 | **预设+管理员添加** | 预设常见类别,支持管理员动态添加 | | Q7: routing_confidence阈值 | **可配置,全局默认0.7** | 支持不同业务类别不同阈值 | --- ## 十、附录 ### 10.1 文档来源 - 复杂场景重构第一阶段-增量PRD.md(已整合) - 复杂场景重构第二阶段-增量PRD.md(已整合) - ht-zx-ly-业务路由推荐-PRD-V2.1.1.md(已整合) - 统一意图路由层PRD.md(已整合) ### 10.3 关联技术文档 | 文件 | 说明 | |------|------| | `02-技术文档/实现配置/dify_main_chat_prompt_v1.3_D1合并.md` | Dify主对话Prompt配置 | | `02-技术文档/实现配置/dify_main_chat_prompt_v1.md` | Dify主对话Prompt v1 | | `02-技术文档/实现配置/dify_unified_intent_prompt_v3.md` | 统一意图Prompt | | `02-技术文档/实现配置/dify_approval_system_prompt_v2.md` | 审批系统Prompt | | `02-技术文档/实现配置/dify_byod_intent_prompt.md` | BYOD意图Prompt | | `02-技术文档/实现配置/AI对话链路全栈改造实施计划-v1.0.md` | 实施计划 | | `02-技术文档/实现配置/Dify_App改造与AI供给链路修复方案-v1.0.md` | 修复方案 | | `02-技术文档/实现配置/approval_templates.json` | 审批模板配置 | ### 10.4 原型设计 | 文件 | 说明 | |------|------| | `04-原型设计/01-员工端-暂停恢复.html` | 员工端暂停/恢复交互(已参考prototypes-原型图设计风格) | | `04-原型设计/02-坐席端-版本链.html` | 坐席端版本链可视化与Diff对比 | | `04-原型设计/03-坐席端-业务路由.html` | 坐席端业务路由分发(待参考现有原型) | | `04-原型设计/04-坐席端-排查步骤联动.html` | 坐席端排查步骤与版本联动(待参考现有原型) | ### 10.4 关键决策记录 | 决策项 | 结论 | 日期 | |--------|------|------| | 全局意图定位 | 第0层(最高优先级),并行识别 | 2026-07-19 | | 信息更正与业务路由联动 | 需要联动 | 2026-07-19 | | 上下文压缩推送 | 不需要实时推送 | 2026-07-19 | | 时间线/版本链/排查步骤 | 合并为"动态信息与诊断链"模块 | 2026-07-19 | | 暂停超时阈值 | 可配置,默认8小时 | 2026-07-19 | | 可更正字段区分 | 按字段类型区分 | 2026-07-19 | | 上下文压缩阈值 | 可配置,默认6000 tokens | 2026-07-19 | | 更正撤销次数限制 | 默认3次 | 2026-07-19 | | 信息项依赖关系 | 仅记录来源 | 2026-07-19 | | 业务类别清单 | 预设+管理员添加 | 2026-07-19 | | routing_confidence阈值 | 可配置,默认0.7 | 2026-07-19 | --- ## 十一、验收标准 ### 11.1 任务中断恢复 | ID | 验收标准 | |----|----------| | AC-US-1 | 员工说"先去开会"等关键词时,系统暂停会话并返回确认消息 | | AC-US-2 | 暂停后员工说"继续",系统恢复会话并展示之前进度 | | AC-US-3 | 多个暂停会话时,系统展示选择列表供员工选择恢复哪一个 | | AC-US-4 | 坐席端可查看所有暂停会话列表及恢复点信息 | | AC-US-5 | 暂停超过8小时未恢复,系统自动关闭并通知员工 | ### 11.2 信息更正与补充 | ID | 验收标准 | |----|----------| | AC-US-6 | 员工更正信息时,系统正确识别CORRECT意图并更新信息项 | | AC-US-7 | 员工补充信息时,系统正确识别SUPPLEMENT意图并新增信息项 | | AC-US-8 | 更正/补充后,系统自动触发排查步骤重新计算 | | AC-US-9 | 坐席端可查看信息项的版本时间线 | | AC-US-10 | 坐席端可对比任意两个版本的差异(diff) | | AC-US-11 | 员工可撤销最近一次更正(限制3次) | | AC-US-12 | 撤销后,系统回滚到上一版本并重新计算排查步骤 | ### 11.3 上下文压缩 | ID | 验收标准 | |----|----------| | AC-US-13 | 当token超过6000阈值时,系统自动触发压缩 | | AC-US-14 | 压缩后AI仍能正确回答"我之前填的工号是多少"等回溯问题 | | AC-US-15 | 压缩过程对用户透明,无额外操作步骤 | | AC-US-16 | 运维可查看压缩日志(保留90天) | ### 11.4 业务路由 | ID | 验收标准 | |----|----------| | AC-US-17 | 员工咨询非IT业务时,系统识别为non_it_routing意图 | | AC-US-18 | 系统根据业务类别路由到对应联系人 | | AC-US-19 | routing_confidence低于0.7时,不自动路由 | --- *文档结束*