# 技术方案 - REQ-AI-001 复杂场景与统一路由

> **版本**: v1.1
> **日期**: 2026-07-27
> **REQ编号**: REQ-AI-001
> **关联PRD**: `PRD-REQ-AI-001-复杂场景与统一路由-v1.1.md`
> **状态**: 架构设计
> **架构师**: 高见远（Bob）

---

## 目录

- [一、设计理念](#一设计理念)
- [二、统一路由层](#二统一路由层)
- [三、复杂场景重构第一阶段](#三复杂场景重构第一阶段)
- [四、复杂场景重构第二阶段](#四复杂场景重构第二阶段)
- [五、技术架构总结](#五技术架构总结)
- [六、验收标准](#六验收标准)

---

## 一、设计理念

### 1.1 TeliChat 三重约束机制

借鉴 TeliChat 白盒架构，确保复杂对话场景的可靠性：

| 约束 | 作用 | 实现方式 |
|------|------|---------|
| **拓扑结构限制** | 限制对话可以走到哪里 | `ScenarioConfig.actions` 有序列表 + Python 代码路由 |
| **信息状态约束** | 决定当前已经知道什么 | `auto_information_items` PostgreSQL 表 |
| **Python 代码约束** | 负责真正的业务判断 | FastAPI 业务逻辑 |

### 1.2 信息项修饰机制

| 修饰 | 含义 | 在复杂场景中的应用 |
|------|------|------------------|
| `固定` | 用户回答后不再重复询问 | 已通过系统获取的信息（操作系统、用户名） |
| `增量` | 允许用户补充新信息 | 故障描述、错误信息 — **非线性跳转核心** |
| `明确` | 必须明确回答 | 紧急程度确认 — **信息更正核心** |
| `隐含` | 可以从上下文推断 | AI 推断的问题类型 |
| `复述` | 要求用户确认信息正确性 | 重要操作确认 — **信息更正核心** |
| `必需` | 必须填写才能进入下一节点 | 必填字段 — **任务中断恢复核心** |

### 1.3 全局意图类型

| 意图 | 用户表达示例 | 处理策略 | 对应场景 |
|------|-------------|---------|---------|
| `SKIP` | "这个问题先不管了" | 跳过当前节点，记录未完成 | 非线性跳转 |
| `INSERT` | "对了，我的打印机也有问题" | 插入新任务到队列 | 多意图并行 |
| `RESUME` | "还是说回刚才那个网络问题" | 恢复之前话题 | 任务中断恢复 |
| `SWITCH` | "先帮我看看VPN吧" | 切换到指定话题 | 非线性跳转 |
| `CORRECT` | "刚才说错了，是win10" | 更新信息项值 | 信息更正 |
| `SUPPLEMENT` | "再补充一下，是财务部的电脑" | 增量补充信息 | 信息更正 |
| `PAUSE` | "我先去开会，等会继续" | 保存状态，等待恢复 | 任务中断恢复 |
| `RESUME_TASK` | "好了，继续吧" | 恢复中断的任务 | 任务中断恢复 |
| `ESCALATE` | "叫个人工来" | 转接坐席 | 所有场景 |

---

## 二、统一路由层

### 2.1 业务路由推荐

当员工提问涉及非IT问题（如行政、HR、财务等）时，自动推荐对应部门的联系人。<br>**注**：打印机、复印机、扫描仪属于IT服务范畴，不在此列。

#### 2.1.1 核心技术挑战与对策

| 挑战 | 对策 |
|------|------|
| **向后兼容**：扩展 Dify Prompt 后不能破坏现有审批识别 | 原审批判断规则原文保留不动，仅新增非IT判断段落；原3字段语义和取值不变，新增3字段 |
| **路由检测时机**：在消息处理流程中何时调用 Dify | 在 `process_h5_ai_reply` 后台任务中新增路由检测步骤，位于 BYOD 检测之后，打招呼/呼叫人工检测之前 |
| **误路由防护**：IT问题被误识别为非IT | `routing_confidence < 0.7` 不触发名片推荐，走正常 AI 回复流程 |

#### 2.1.2 多层级路由模型

```
部门(department) → 业务(business) → 应用(application) → 角色(role) → 职责(responsibility)
                                                                              ↓
                                                                        联系方式(contact_point)
```

联系方式可配置在任意层级，匹配时采用「就近原则」：
- 优先查找职责级别
- 其次角色级别
- 再次应用级别
- 以此类推

#### 2.1.3 Dify 统一意图识别

扩展 Dify Prompt 输出格式：

```json
{
  "is_approval_request": true/false,
  "confidence": 0.0-1.0,
  "approval_type": "设备申请",
  "intent_type": "approval" / "it_consult" / "non_it_routing" / "chitchat",
  "business_category": "行政" / "人力资源" / "财务" / null,
  "routing_confidence": 0.0-1.0
}
```

**判断优先级链**：
1. IT审批意图 → intent_type: "approval"
2. IT范围内咨询/报修 → intent_type: "it_consult"
3. 非IT业务路由 → intent_type: "non_it_routing"
4. 闲聊/无关 → intent_type: "chitchat"

---

## 三、复杂场景重构第一阶段

### 3.1 核心技术挑战

| 挑战 | 说明 | 对策 |
|------|------|------|
| **不引入 Neo4j 实现 TeliChat 三重约束** | 本阶段约束不引入 Neo4j | 三重约束映射：拓扑 → `ScenarioConfig.actions` 有序列表 + Python 代码路由；信息状态 → `auto_information_items` PostgreSQL 表 |
| **全局意图识别与现有场景识别的兼容** | 新增 PAUSE/RESUME_TASK/CORRECT/SUPPLEMENT 4 种全局意图 | 在 IntentRouter.detect() 前置一层全局意图检测，命中全局意图时跳过场景识别 |
| **暂停状态持久化与恢复点一致性** | 暂停时需保存完整上下文 | PostgreSQL 持久化会话状态 + Redis 存储恢复点快照（含 TTL 25h 自动过期） |
| **信息项版本管理与更正锁定** | 更正需保留变更历史 | `auto_information_items` 表记录 `version` + `update_history`，`is_locked` 字段控制更正锁定 |
| **24 小时超时自动关闭** | 暂停超过 24 小时需自动关闭会话 | 后台定时任务扫描 `paused` 状态会话，超时则标记 `closed` |

### 3.2 总体架构

```
员工 H5 / 坐席工作台
         │ HTTP / WebSocket
         ▼
FastAPI 路由层 (api/automation.py)
    新增: /pause /resume /correct /supplement /info-items /paused
         │
         ▼
自动化服务层 (services/automation/)
  ├── IntentRouter (+全局意图检测)
  ├── SessionManager (+pause/resume/correct/supplement)
  ├── InformationItemService (新增)
  ├── TimeoutCleaner (新增, 24h扫描)
  └── ProgressPublisher (+5种新WS事件)
         │
    ┌────┴────┐
    ▼         ▼         ▼
PostgreSQL  Redis    Dify
+新表       +恢复点    AI
```

### 3.3 数据模型

#### 3.3.1 `auto_information_items` 表

```sql
CREATE TABLE auto_information_items (
    id              VARCHAR(36) PRIMARY KEY,
    session_id      VARCHAR(36) NOT NULL,
    name            VARCHAR(128) NOT NULL,
    value           TEXT NOT NULL DEFAULT '',
    modifiers       JSON NOT NULL DEFAULT '[]',
    is_filled       BOOLEAN NOT NULL DEFAULT FALSE,
    is_locked       BOOLEAN NOT NULL DEFAULT FALSE,
    version         INTEGER NOT NULL DEFAULT 1,
    update_history  JSON NOT NULL DEFAULT '[]',
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    updated_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
```

#### 3.3.2 `auto_sessions` 表新增字段

```sql
ALTER TABLE auto_sessions ADD COLUMN paused_at TIMESTAMPTZ;
```

### 3.4 核心功能

| 功能 | 说明 |
|------|------|
| **暂停/恢复** | 员工可暂停会话并指定时间恢复，坐席可代恢复/关闭 |
| **信息更正** | 支持 CORRECT 意图更新信息项值，保留版本历史 |
| **信息补充** | 支持 SUPPLEMENT 意图增量补充信息 |
| **超时关闭** | 暂停超过24小时自动关闭会话 |
| **坐席感知** | 坐席工作台实时看到暂停/恢复/更正事件 |

---

## 四、复杂场景重构第二阶段

### 4.1 上下文压缩

#### 4.1.1 Tokenizer 选择

| 方案 | 说明 | 优先级 |
|------|------|--------|
| `tiktoken`（cl100k_base） | OpenAI 官方编码器，与 Dify/GPT 系列模型一致 | 首选 |
| 字符估算兜底 | 1 token ≈ 1.5 个中文字符估算 | 兜底 |

#### 4.1.2 压缩引擎设计

```python
class ContextCompressor:
    def count_tokens(messages: list) -> int
    def should_compress(session_id) -> bool
    def compress(session_id, messages, info_items, actions, task_node) -> CompressedContext
    def _extract_key_info(info_items, actions, task_node) -> str
    def _summarize_history(messages_to_compress) -> str
    def _progressive_compress(context, level=1) -> str
```

#### 4.1.3 渐进式压缩策略

| 级别 | 策略 | 压缩效果 |
|------|------|---------|
| Level 1 | LLM 摘要 + 保留最近4轮对话 | token 降低约 60% |
| Level 2 | LLM 摘要 + 保留最近2轮对话 | token 降低约 80% |
| Level 3 | 纯关键信息 + 保留最近1轮对话 | token 降低约 90% |
| 超出 | 截断最旧消息 | 降级保护 |

### 4.2 多轮纠错

#### 4.2.1 快照机制

每次更正前创建快照，支持撤销最近5次更正：

```python
class SnapshotService:
    def create_snapshot(session_id, trigger_item_key, correction_ids) -> InformationSnapshot
    def undo_correction(session_id) -> dict  # 限制最近5次
    def get_snapshot_history(session_id) -> list
    def get_version_diff(session_id, v1, v2) -> dict
```

#### 4.2.2 批量更正

```python
class CorrectionService:
    def batch_correct(session_id, corrections: list) -> BatchCorrectResult  # 原子性事务
    def check_dependencies(session_id, item_key) -> list  # 依赖联动警告
```

### 4.3 数据模型

```sql
-- 上下文压缩记录表
CREATE TABLE auto_context_compressions (
    id              SERIAL PRIMARY KEY,
    session_id      VARCHAR(36) NOT NULL,
    tokens_before   INTEGER NOT NULL,
    tokens_after    INTEGER NOT NULL,
    compression_ratio NUMERIC(5,2) NOT NULL,
    compression_level SMALLINT NOT NULL DEFAULT 1,
    summary         TEXT,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- 信息项快照表
CREATE TABLE auto_information_snapshots (
    id              SERIAL PRIMARY KEY,
    session_id      VARCHAR(36) NOT NULL,
    trigger_item_key VARCHAR(64) NOT NULL,
    snapshot_data   JSON NOT NULL,
    correction_ids JSON NOT NULL DEFAULT '[]',
    is_undone      BOOLEAN NOT NULL DEFAULT FALSE,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
```

---

## 五、技术架构总结

### 5.1 核心技术栈

| 层 | 技术栈 |
|---|--------|
| 后端 | FastAPI + SQLAlchemy + PostgreSQL + Redis |
| H5前端 | Vue3 + Vant4 + TypeScript |
| 坐席前端 | Vue3 + Element Plus |
| AI意图识别 | Dify 原生 API（扩展现有 Prompt） |

### 5.2 技术债务规避

| 项 | 规避方案 |
|----|----------|
| LLM 幻觉 | 代码约束 + 拓扑限制（TeliChat 核心解决） |
| 图谱复杂度 | 设计跳转权限控制 |
| 状态一致性 | 使用事务保证 |
| 性能 | 添加缓存层 |

---

## 六、验收标准

### 6.1 统一路由层

| 场景 | 验收条件 |
|------|----------|
| 非IT路由触发 | 员工发送"名片印刷找谁" → Dify识别为 non_it_routing → 发送名片卡片 |
| 路由置信度阈值 | routing_confidence < 0.7 → 不触发名片推荐，走正常AI流程 |
| 审批识别兼容性 | 审批问题仍正常识别，不受路由Prompt影响 |

### 6.2 复杂场景第一阶段

| 场景 | 验收条件 |
|------|----------|
| 暂停功能 | 员工输入"先去开会" → 会话暂停 → 恢复点保存到Redis |
| 恢复功能 | 员工输入"继续" → 恢复暂停会话 → 从断点继续执行 |
| 信息更正 | 员工说"刚才说错了，是win10" → 信息项更新 → 版本历史记录 |
| 超时关闭 | 暂停超过24小时 → 会话自动标记closed → 员工收到通知 |

### 6.3 复杂场景第二阶段

| 场景 | 验收条件 |
|------|----------|
| 上下文压缩 | 消息token超过6000 → 自动压缩 → token降低60%以上 |
| 批量更正 | 一次提交多个更正 → 原子性事务 → 全部成功或全部回滚 |
| 更正撤销 | 可撤销最近5次更正 → 信息项回滚到历史版本 |

---

## 变更记录

| 变更日期 | 变更内容 | 变更类型 | 关联PRD |
|----------|---------|---------|---------|
| 2026-07-27 | 新增智能打招呼检测：解决"您好+具体问题"被误判为纯打招呼的问题，新增 `_SUBSTANTIVE_KEYWORDS` 实质问题关键词列表 | 缺陷修复 | PRD-REQ-AI-001-v1.2 |

---

## 附录：源文档归档记录

本技术方案合并自以下文档：

| 源文档 | 合并章节 |
|--------|----------|
| 复杂场景技术方案-v1.1.md | 一、设计理念 |
| 复杂场景重构第一阶段-v1.0.md | 三、复杂场景重构第一阶段 |
| 复杂场景重构第二阶段-v1.0.md | 四、复杂场景重构第二阶段 |
| 业务路由推荐-v2.1.1.md | 二、统一路由层 |

---

*本文档为 REQ-AI-001 复杂场景与统一路由的完整技术方案*