2105 lines
62 KiB
Markdown
2105 lines
62 KiB
Markdown
# 面向客服/售后/前台/智能座舱的高响应 Agent 技术方案
|
||
|
||
## 1. 文档目标
|
||
|
||
本文档用于设计一套可落地的 Agent 系统，满足以下核心诉求：
|
||
|
||
- 响应快：用户发起操作后，系统能够在极短时间内给出首响应或执行反馈。
|
||
- 执行准：对高频业务请求识别准确，对复杂请求可拆解、可校验、可执行。
|
||
- 可多轮：支持上下文记忆、槽位补全、断点续跑和任务恢复。
|
||
- 可扩展：适配客服、售后、前台接待、智能座舱等不同业务场景。
|
||
- 可运营：意图、槽位、规则、话术、插件均支持配置化管理。
|
||
|
||
本方案不是单纯的问答机器人，而是一个“可理解用户意图、可生成执行计划、可调用业务能力完成任务”的 Agent 平台。
|
||
|
||
## 2. 目标场景
|
||
|
||
### 2.1 客服场景
|
||
|
||
- 查询订单、物流、退款进度
|
||
- 识别催单、投诉、转人工、取消订单等诉求
|
||
- 多轮追问补全订单号、手机号、收货人等信息
|
||
|
||
### 2.2 售后场景
|
||
|
||
- 退货、换货、维修、预约上门
|
||
- 收集故障描述、图片、时间、地址等槽位
|
||
- 根据政策规则决定是否可直接处理、升级或转人工
|
||
|
||
### 2.3 前台场景
|
||
|
||
- 来访登记、会议室预约、路线引导、通知被访人
|
||
- 识别身份、预约信息、时间、地点等关键字段
|
||
- 支持多步骤任务执行和结果确认
|
||
|
||
### 2.4 智能座舱场景
|
||
|
||
- 导航、空调、车窗、音乐、电话、座椅等车控指令
|
||
- 识别复合指令，如“打开空调并导航去公司”
|
||
- 在驾驶场景下保证低延迟、强确定性和安全边界
|
||
|
||
## 3. 总体设计原则
|
||
|
||
### 3.1 快慢分层
|
||
|
||
高频、标准化、可确定执行的请求走“快路径”；复杂、低频、跨任务、带条件逻辑的请求走“慢路径”。
|
||
|
||
- 快路径：小模型分类 + 规则校验 + 直接执行
|
||
- 慢路径：RAG 召回 + LLM 精判 + 工作流生成 + 插件执行
|
||
|
||
这样可以同时满足“响应速度”和“复杂理解能力”。
|
||
|
||
### 3.2 LLM 不直接控制业务
|
||
|
||
LLM 只负责：
|
||
|
||
- 意图识别与精判
|
||
- 多意图拆分
|
||
- 槽位提取
|
||
- 执行计划生成
|
||
- 回复文案生成
|
||
|
||
真正的业务执行由规则引擎、状态管理器和插件执行器完成，避免 LLM 幻觉带来的误操作。
|
||
|
||
### 3.3 会话状态中心是核心
|
||
|
||
多轮对话不能依赖模型“记忆”，必须建设独立的 Session State。
|
||
|
||
状态中心负责：
|
||
|
||
- 保存当前会话上下文
|
||
- 保存已识别意图和已填充槽位
|
||
- 保存当前任务状态和执行进度
|
||
- 记录待补充信息和断点恢复位置
|
||
|
||
### 3.4 配置优先、插件扩展
|
||
|
||
以下能力尽量配置化，而不是写死在代码中：
|
||
|
||
- 意图定义
|
||
- 槽位定义
|
||
- 规则表达式
|
||
- 反问话术
|
||
- 权限与风控限制
|
||
- 插件路由关系
|
||
|
||
## 4. 建设目标
|
||
|
||
### 4.1 业务目标
|
||
|
||
- 支持不少于 100 个可配置意图
|
||
- 支持单意图、多意图、条件意图三类输入
|
||
- 支持跨轮补充槽位并继续执行
|
||
- 支持知识问答、事务办理、设备控制三类能力
|
||
|
||
### 4.2 体验目标
|
||
|
||
- 首字响应时间小于 800ms
|
||
- 高频标准请求平均响应时间 500ms 到 1500ms
|
||
- 复杂规划请求平均响应时间 1500ms 到 3500ms
|
||
- 多轮槽位补全过程中保持上下文一致
|
||
|
||
### 4.3 质量目标
|
||
|
||
- 高频意图识别准确率大于 95%
|
||
- 槽位抽取 F1 大于 90%
|
||
- 高风险动作误执行率接近 0
|
||
- 转人工触发符合业务策略并可追踪
|
||
|
||
## 5. 能力边界与功能点
|
||
|
||
### 5.1 核心能力
|
||
|
||
- 意图识别：识别用户到底要做什么
|
||
- 槽位提取：提取时间、地点、金额、对象、设备等参数
|
||
- 多意图拆分：识别一句话中多个任务
|
||
- 逻辑解析：识别顺序、条件、重试、并行关系
|
||
- 会话管理：跟踪当前任务、历史轮次和上下文变量
|
||
- 任务执行：调用业务接口、设备控制接口或人工服务接口
|
||
- 结果回复：结构化返回执行结果，必要时生成自然语言
|
||
|
||
### 5.2 平台能力
|
||
|
||
- 意图知识库管理
|
||
- 规则与话术配置平台
|
||
- 插件注册中心
|
||
- 会话状态存储
|
||
- 指标监控与日志追踪
|
||
- 安全审计与权限控制
|
||
|
||
### 5.3 场景化能力
|
||
|
||
- 客服：FAQ、工单、订单操作、转人工
|
||
- 售后：退换修、预约、故障诊断、流程推进
|
||
- 前台：访客接待、通知、预约、引导
|
||
- 智能座舱：设备控制、导航、多设备联动、安全确认
|
||
|
||
## 6. 系统总体架构
|
||
|
||
```text
|
||
用户输入
|
||
-> 接入层（Web/App/语音/车机）
|
||
-> 预处理层（ASR/文本归一化/敏感词/语言检测）
|
||
-> 路由层
|
||
-> 快路径：意图分类模型 + 规则匹配 + 插件执行
|
||
-> 慢路径：向量召回 + LLM 精判 + Workflow 生成
|
||
-> 状态中心（Session/Context/Slots/Current Step）
|
||
-> 执行引擎（规则引擎 + 插件调度 + 断点恢复）
|
||
-> 回复生成层（模板/LLM）
|
||
-> 用户
|
||
```
|
||
|
||
## 7. 核心处理链路
|
||
|
||
### 7.1 快路径
|
||
|
||
适用于客服、前台、座舱中的高频标准请求，例如：
|
||
|
||
- “查一下我的订单”
|
||
- “打开空调”
|
||
- “帮我通知张三来前台”
|
||
|
||
执行流程：
|
||
|
||
1. 对输入做标准化与轻量实体提取
|
||
2. 进入轻量意图分类模型
|
||
3. 命中高置信度意图后，进行槽位校验
|
||
4. 槽位齐全则直接调用插件执行
|
||
5. 槽位缺失则触发反问并记录状态
|
||
|
||
优势：
|
||
|
||
- 延迟低
|
||
- 成本低
|
||
- 可控性强
|
||
|
||
### 7.2 慢路径
|
||
|
||
适用于复杂请求，例如：
|
||
|
||
- “帮我查一下订单，如果还没发货就取消”
|
||
- “导航去公司，然后把空调调到 22 度，再给我播放轻音乐”
|
||
- “我要退货，若超过 7 天就帮我转人工”
|
||
|
||
执行流程：
|
||
|
||
1. 向量召回 Top-K 候选意图
|
||
2. LLM 对候选意图做精判
|
||
3. 对输入做多意图拆分
|
||
4. 生成结构化 Workflow JSON
|
||
5. 执行引擎按步骤调度插件
|
||
6. 缺槽位时暂停并反问
|
||
7. 用户补充后从断点恢复执行
|
||
|
||
## 8. 推荐的多层 Agent 架构
|
||
|
||
### 8.1 第 1 层：输入理解层
|
||
|
||
职责：
|
||
|
||
- 文本清洗
|
||
- 口语归一化
|
||
- 同义词映射
|
||
- 设备指令别名统一
|
||
- 敏感/危险指令预过滤
|
||
|
||
### 8.2 第 2 层：意图路由层
|
||
|
||
职责：
|
||
|
||
- 判断是否命中高频快路径
|
||
- 判断是否需要进入复杂规划链路
|
||
- 判断是问答类、事务类还是控制类任务
|
||
|
||
推荐策略：
|
||
|
||
- 高频意图使用专门分类器
|
||
- 低频和新增意图使用向量召回
|
||
- 复杂指令交给 LLM 做精判和拆解
|
||
|
||
### 8.3 第 3 层：会话状态层
|
||
|
||
核心数据：
|
||
|
||
- session_id
|
||
- user_id / device_id
|
||
- current_intent
|
||
- current_workflow
|
||
- completed_steps
|
||
- pending_slots
|
||
- business_context
|
||
- risk_level
|
||
|
||
### 8.4 第 4 层：执行编排层
|
||
|
||
职责：
|
||
|
||
- 执行工作流
|
||
- 管理步骤状态
|
||
- 根据规则判断分支
|
||
- 调用插件
|
||
- 处理重试、超时和回滚
|
||
|
||
### 8.5 第 5 层：能力插件层
|
||
|
||
插件示例：
|
||
|
||
- 查询订单插件
|
||
- 取消订单插件
|
||
- 创建售后工单插件
|
||
- 访客登记插件
|
||
- 通知员工插件
|
||
- 导航插件
|
||
- 空调控制插件
|
||
- 音乐控制插件
|
||
|
||
### 8.6 第 6 层：回复生成层
|
||
|
||
优先级建议：
|
||
|
||
- 优先模板化返回
|
||
- 复杂解释场景再用 LLM 生成自然语言
|
||
- 高风险动作必须做明确确认和结果回执
|
||
|
||
## 9. 意图、槽位、工作流设计
|
||
|
||
### 9.1 意图设计
|
||
|
||
建议每个意图至少包含：
|
||
|
||
- intent_id
|
||
- intent_name
|
||
- domain
|
||
- description
|
||
- examples
|
||
- boundary
|
||
- required_slots
|
||
- optional_slots
|
||
- execution_plugin
|
||
- risk_level
|
||
|
||
示例：
|
||
|
||
```json
|
||
{
|
||
"intent_id": "cabin_set_ac_temperature",
|
||
"intent_name": "设置空调温度",
|
||
"domain": "cabin_control",
|
||
"required_slots": ["temperature"],
|
||
"optional_slots": ["zone"],
|
||
"execution_plugin": "ac_control_plugin",
|
||
"risk_level": "low"
|
||
}
|
||
```
|
||
|
||
### 9.2 槽位设计
|
||
|
||
每个槽位建议配置：
|
||
|
||
- 名称
|
||
- 类型
|
||
- 是否必填
|
||
- 默认值
|
||
- 校验规则
|
||
- 提问模板
|
||
- 错误提示
|
||
- 来源优先级
|
||
|
||
### 9.3 Workflow 设计
|
||
|
||
复杂请求最终统一转成结构化执行计划。
|
||
|
||
示例：
|
||
|
||
```json
|
||
{
|
||
"workflow_id": "wf_1001",
|
||
"logic_type": "sequence",
|
||
"steps": [
|
||
{
|
||
"step": 1,
|
||
"intent": "query_order_status",
|
||
"slots": {
|
||
"order_id": "A123"
|
||
}
|
||
},
|
||
{
|
||
"step": 2,
|
||
"condition": "order_status == 'pending_shipment'",
|
||
"intent": "cancel_order"
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
## 10. 多轮对话设计
|
||
|
||
### 10.1 多轮的本质
|
||
|
||
多轮不是每一轮都重新做完整识别，而是：
|
||
|
||
- 首轮生成任务或命中任务
|
||
- 后续轮次只做补槽位、确认、修正、继续执行
|
||
|
||
### 10.2 状态机设计
|
||
|
||
建议会话状态包括：
|
||
|
||
- `idle`：空闲
|
||
- `understanding`：理解中
|
||
- `waiting_slot`：等待用户补充信息
|
||
- `ready_to_execute`：准备执行
|
||
- `executing`：执行中
|
||
- `paused`：中断等待
|
||
- `completed`：完成
|
||
- `fallback`：兜底或转人工
|
||
|
||
### 10.3 断点续跑
|
||
|
||
示例：
|
||
|
||
1. 用户说“我要退货”
|
||
2. 系统识别退货意图，但缺少订单号
|
||
3. 系统反问“请提供订单号”
|
||
4. 用户回复“A123”
|
||
5. 系统只做槽位提取，不重新做全量规划
|
||
6. 系统恢复原任务继续执行
|
||
|
||
### 10.4 多轮省略恢复与上下文改写
|
||
|
||
参考车机场景的公开方案，多轮对话不能只靠“读取上一轮状态”，还应增加“相邻轮改写”和“高频缓存命中”能力。
|
||
|
||
适用场景：
|
||
|
||
- “音量调大” -> “再大一点”
|
||
- “导航去公司” -> “不要高速”
|
||
- “查一下北京天气” -> “上海呢”
|
||
|
||
建议新增一层 `context rewrite engine`，位于 `Session State` 和 `Router` 之间：
|
||
|
||
1. 读取上一轮已确认的主任务、领域和关键槽位
|
||
2. 将“当前轮短句 + 上一轮已确认语义”送入高频缓存引擎查询
|
||
3. 若命中缓存模板，直接改写为完整指令
|
||
4. 若缓存未命中，再使用轻量改写模型生成补全后的标准句
|
||
5. 改写后再进入意图识别与槽位提取
|
||
|
||
示例：
|
||
|
||
- 上一轮：`空调调高`
|
||
- 当前轮：`再高一点`
|
||
- 改写后：`把空调温度再调高一点`
|
||
|
||
缓存建议：
|
||
|
||
- key：`previous_intent + current_utterance_pattern`
|
||
- value：`rewritten_text / target_intent / slot_delta`
|
||
- 数据来源：高频真实语料、线上点击日志、人工标注样本
|
||
|
||
收益：
|
||
|
||
- 显著提升省略表达、连续调节、改口表达的识别率
|
||
- 避免每一轮都走完整大模型规划
|
||
- 将多轮短句场景时延压缩到接近单轮快路径
|
||
|
||
## 11. 模型方案
|
||
|
||
### 11.1 选型原则
|
||
|
||
- 高频场景优先低延迟
|
||
- 复杂场景优先理解能力
|
||
- 高风险场景优先可控和可审计
|
||
- 模型职责必须拆开，不要一个模型包打天下
|
||
|
||
### 11.2 推荐模型组合
|
||
|
||
#### A. 轻量意图识别模型
|
||
|
||
用途：
|
||
|
||
- 高频标准请求分类
|
||
- 第一时间做快路径路由
|
||
|
||
推荐方向：
|
||
|
||
- BERT / RoBERTa 中文分类模型
|
||
- 小型指令模型蒸馏版
|
||
- ONNX / TensorRT 部署后的轻量分类模型
|
||
|
||
适合场景：
|
||
|
||
- 客服高频查询
|
||
- 前台固定流程
|
||
- 座舱高频控制
|
||
|
||
#### B. 向量召回模型
|
||
|
||
用途：
|
||
|
||
- 动态意图库检索
|
||
- 召回候选意图与候选技能
|
||
|
||
推荐方向：
|
||
|
||
- BGE-M3
|
||
- BCE Embedding
|
||
- text-embedding 系列中文向量模型
|
||
|
||
#### C. 主 LLM
|
||
|
||
用途：
|
||
|
||
- 候选意图精判
|
||
- 多意图拆分
|
||
- 槽位抽取
|
||
- Workflow 生成
|
||
- 自然语言回复
|
||
|
||
推荐方向：
|
||
|
||
- 通义千问系列
|
||
- DeepSeek 系列
|
||
- GLM 系列
|
||
- GPT 类模型
|
||
|
||
建议：
|
||
|
||
- 线上使用支持函数调用、结构化输出、低温度推理的模型
|
||
- 对复杂规划与多轮状态更新使用 JSON schema 约束输出
|
||
|
||
#### D. ASR / TTS 模型
|
||
|
||
用于前台语音交互和智能座舱：
|
||
|
||
- ASR：语音转文本
|
||
- TTS：语音播报反馈
|
||
- VAD：语音活动检测，提升交互流畅度
|
||
|
||
### 11.3 推荐模型职责拆分
|
||
|
||
- 小模型：意图分类、风险识别、简单槽位抽取
|
||
- 向量模型：候选意图召回
|
||
- 大模型：复杂理解、规划和自然语言生成
|
||
- 规则引擎：确定性判断与业务约束
|
||
|
||
这是兼顾速度、成本和准确性的最佳组合。
|
||
|
||
### 11.4 端云协同模型分工
|
||
|
||
要达到接近车机助手的体验，必须采用“本地优先、云端增强、结果融合”的模型架构，而不是所有请求都走一个远端大模型。
|
||
|
||
建议分工如下：
|
||
|
||
- 本地 ASR / 文本归一化：负责第一时间得到稳定文本或拼音特征
|
||
- 本地快分支 1：关键词/规则/Trie 高频模式匹配
|
||
- 本地快分支 2：轻量 BERT 意图分类模型
|
||
- 本地快分支 3：多轮缓存改写 + 连续调节识别
|
||
- 本地快分支 4：轻量检索或 FAQ 命中
|
||
- 云端慢分支：复杂语义理解、多意图拆分、条件规划、知识问答、RAG、API 预测
|
||
|
||
融合原则：
|
||
|
||
- 本地结果若达到最高置信等级，则直接触发首响应与本地执行
|
||
- 云端结果若在可接受时间窗口内返回，则可覆盖或补充本地结果
|
||
- 对高风险动作，云端只能提供建议，最终执行仍由规则与插件层裁决
|
||
|
||
### 11.5 声学语义大模型的落地方式
|
||
|
||
参考公开专利中的“声学编码 + 字符转写 + 检索增强 + 大模型”思路，后续如果要做语音版车机，不建议继续把 ASR、NLU、知识检索和 API 预测完全割裂成独立长链路。
|
||
|
||
推荐两阶段落地：
|
||
|
||
- 第一期：保留模块化工程架构，但缩短串行链路，做到 `ASR -> local router -> plugin/cloud planner`
|
||
- 第二期：引入端到端语音语义模型，使其直接输出：
|
||
- intent
|
||
- slots
|
||
- candidate_api
|
||
- reject / clarify / execute decision
|
||
|
||
这样可以同时保留工程可控性和后续车机语音体验的升级空间。
|
||
|
||
## 12. 技术栈建议
|
||
|
||
### 12.1 服务端
|
||
|
||
- Python：适合快速构建 AI 编排、模型接入、规则处理
|
||
- FastAPI：提供高性能 API 服务
|
||
- Celery / 队列系统：处理异步任务和外部接口调用
|
||
|
||
如果团队更偏 Java，也可使用：
|
||
|
||
- Java + Spring Boot
|
||
- LangChain4j 或自研 Agent 编排层
|
||
|
||
### 12.2 检索与存储
|
||
|
||
- Redis：会话状态、热点缓存、限流计数
|
||
- PostgreSQL：业务数据、配置中心、日志审计
|
||
- Elasticsearch：检索与日志分析
|
||
- Qdrant / Milvus：向量检索与意图知识库召回
|
||
|
||
### 12.3 Agent 编排与规则
|
||
|
||
- 自研 Workflow Engine 或基于状态机的编排引擎
|
||
- JSON Schema：约束结构化输出
|
||
- 规则引擎：表达式解析、条件判断、路由控制
|
||
|
||
### 12.4 前端与接入
|
||
|
||
- Web 前端 / App SDK
|
||
- 呼叫中心接入
|
||
- 企业 IM 接入
|
||
- 车机系统接入
|
||
- 语音网关接入
|
||
|
||
### 12.5 可观测与运维
|
||
|
||
- Prometheus + Grafana：监控
|
||
- OpenTelemetry：链路追踪
|
||
- Loki / ELK：日志采集与分析
|
||
|
||
## 13. 响应速度优化方案
|
||
|
||
这是本系统成败的关键。
|
||
|
||
### 13.1 低延迟设计
|
||
|
||
- 高频意图前置分类，不直接把所有请求都交给 LLM
|
||
- 热门意图和常用知识走缓存
|
||
- 首响应和最终响应分离，先反馈“正在处理”
|
||
- LLM 使用流式输出
|
||
- 复杂任务异步执行，前台先返回受理状态
|
||
|
||
### 13.2 结构化提速
|
||
|
||
- 只给 LLM 候选意图，不让模型自由发散
|
||
- 后续轮次只做槽位提取，不重复做全流程规划
|
||
- 采用模板化回复代替不必要的长文本生成
|
||
|
||
### 13.3 工程提速
|
||
|
||
- 模型服务常驻内存
|
||
- Embedding 批量化和缓存
|
||
- 插件接口超时控制与降级
|
||
- 预加载高频配置与词典
|
||
|
||
### 13.4 参考车机方案的极速响应架构
|
||
|
||
为了逼近“小鹏 P7 类”体验，建议在当前快慢路径基础上，升级为“本地多支路并发 + 结果分级融合 + 云端延迟覆盖”的架构。
|
||
|
||
```text
|
||
用户输入
|
||
-> 并发启动本地多支路
|
||
-> Branch A: keyword / rule / trie
|
||
-> Branch B: local bert classifier
|
||
-> Branch C: context rewrite + cache engine
|
||
-> Branch D: retrieval matcher
|
||
-> 结果分级器
|
||
-> high grade: 直接首响应 / 直接执行
|
||
-> medium grade: 等待 100~300ms 观察其他分支
|
||
-> low grade: 进入云端理解
|
||
-> 云端 planner / rag / llm
|
||
-> 融合器输出目标结果
|
||
```
|
||
|
||
分级融合建议使用以下特征：
|
||
|
||
- ASR 置信度 / 清晰度
|
||
- 本地意图分类置信度
|
||
- 领域置信度
|
||
- 槽位完备度
|
||
- 是否命中高频缓存
|
||
- 是否命中历史会话上下文
|
||
- 是否属于高风险动作
|
||
|
||
推荐时延预算：
|
||
|
||
- 0~150ms：文本标准化、关键词、Trie、缓存改写
|
||
- 150~350ms：本地 BERT / 本地检索 / 本地槽位提取
|
||
- 350~600ms：返回首响应或执行简单任务
|
||
- 600~1500ms：云端补充复杂理解或条件规划结果
|
||
|
||
首响应策略：
|
||
|
||
- 能本地直接执行的，优先回短反馈，如“好的，正在导航”
|
||
- 需要云端复杂规划的，先回受理反馈，如“收到，我先帮你确认一下”
|
||
- 云端超时不阻塞首响应，必要时走兜底或稍后补充结果
|
||
|
||
该策略是实现 `<1s` 体验的关键，不要求所有任务都在 1 秒内完成，但要求绝大多数任务在 1 秒内给出可感知反馈。
|
||
|
||
## 14. 准确率与执行可靠性设计
|
||
|
||
### 14.1 准确率保障
|
||
|
||
- 高频意图单独建模
|
||
- 意图边界描述清晰化
|
||
- 引入负样本和相似意图对比训练
|
||
- 使用 RAG 缩小候选范围后再让 LLM 精判
|
||
|
||
### 14.2 执行可靠性保障
|
||
|
||
- 高风险动作必须二次确认
|
||
- 插件执行前后都记录审计日志
|
||
- 核心步骤支持幂等、重试和回滚
|
||
- 输出必须是结构化结果，禁止自由文本直接驱动操作
|
||
|
||
### 14.3 风控策略
|
||
|
||
- 敏感词和危险动作拦截
|
||
- 用户身份和权限校验
|
||
- 场景安全等级区分
|
||
- 智能座舱中行车状态下限制高风险控制动作
|
||
|
||
### 14.4 多命令拆分与任务栈
|
||
|
||
为了支持“打开空调并导航去公司，再播放轻音乐”这一类车机复合指令，建议在路由层之后增加 `command splitter` 和 `task stack manager`。
|
||
|
||
输出结构建议：
|
||
|
||
```json
|
||
{
|
||
"task_id": "task_001",
|
||
"logic_type": "sequence",
|
||
"commands": [
|
||
{"intent": "cabin_set_ac", "slots": {"temperature": 22}},
|
||
{"intent": "cabin_nav_to", "slots": {"destination": "公司"}},
|
||
{"intent": "cabin_play_music", "slots": {"genre": "轻音乐"}}
|
||
]
|
||
}
|
||
```
|
||
|
||
执行要求：
|
||
|
||
- 简单并列命令支持顺序执行
|
||
- 需要条件判断的命令转为 workflow condition
|
||
- 允许用户在执行中打断、改口和取消后续任务
|
||
- 为每个任务保留任务栈、当前步骤和已完成步骤
|
||
|
||
打断策略：
|
||
|
||
- 新请求与当前任务冲突时，允许暂停旧任务并保存上下文
|
||
- 明确打断词出现时，清空当前任务栈或清理对应子任务上下文
|
||
- 对高风险动作，打断后不得默认自动恢复
|
||
|
||
### 14.5 拒答、澄清与简短反馈策略
|
||
|
||
要实现“反馈迅速而简短，不会的内容有合适拒绝话术”，不能只靠模型生成，应建设统一的 `response policy layer`。
|
||
|
||
回复规则：
|
||
|
||
- 简单执行成功：一句话短反馈，长度优先控制在 8~20 个字
|
||
- 缺槽位：只追问一个最关键槽位，不一次性问太多
|
||
- 不支持的请求：明确说明边界并给出可做事项
|
||
- 风险动作：先确认再执行
|
||
- 云端失败：给出降级反馈，不暴露内部错误
|
||
|
||
建议内置 5 类模板：
|
||
|
||
- `ack`：收到，马上处理
|
||
- `clarify`：信息不够，请补一个关键字段
|
||
- `confirm`：高风险动作确认
|
||
- `reject`：能力边界拒答
|
||
- `fallback`：系统忙或结果不稳定时的兜底
|
||
|
||
示例：
|
||
|
||
- `ack`：`好的，正在为你导航`
|
||
- `clarify`：`请告诉我订单号`
|
||
- `confirm`：`确认要取消这个订单吗`
|
||
- `reject`：`这个我暂时做不了，但我可以帮你导航、查订单或调空调`
|
||
- `fallback`：`我先记下你的需求，稍后再试一次`
|
||
|
||
核心原则：
|
||
|
||
- 首反馈短
|
||
- 首反馈稳
|
||
- 不会就明确拒答
|
||
- 不确定就先澄清
|
||
- 不让模型自由发挥高风险话术
|
||
|
||
## 15. 配置化设计
|
||
|
||
建议把以下内容全部放入配置中心：
|
||
|
||
- 意图定义
|
||
- 槽位定义
|
||
- 规则表达式
|
||
- 反问模板
|
||
- 插件映射
|
||
- 风险等级
|
||
- 转人工策略
|
||
- 场景开关
|
||
|
||
这样新增业务时，尽量做到“不改核心代码，只加配置和插件”。
|
||
|
||
## 16. 效果预期
|
||
|
||
### 16.1 对业务的价值
|
||
|
||
- 降低人工客服和前台重复劳动
|
||
- 提升售后处理自动化比例
|
||
- 提高智能座舱交互的自然度和完成率
|
||
- 缩短用户从提问到执行完成的路径
|
||
|
||
### 16.2 对用户的体验
|
||
|
||
- 回答更快
|
||
- 多轮更顺
|
||
- 执行更稳
|
||
- 出错可解释
|
||
- 失败可转人工
|
||
|
||
### 16.3 可量化指标
|
||
|
||
- 首响应耗时
|
||
- 请求完成率
|
||
- 单轮解决率
|
||
- 多轮补槽成功率
|
||
- 插件执行成功率
|
||
- 转人工率
|
||
- 用户满意度
|
||
|
||
## 17. 分阶段落地建议
|
||
|
||
### 17.1 第一阶段：POC
|
||
|
||
目标：
|
||
|
||
- 先验证快路径和多轮补槽是否可用
|
||
|
||
范围：
|
||
|
||
- 10 到 20 个高频意图
|
||
- 单领域试点，如客服或智能座舱
|
||
|
||
方案：
|
||
|
||
- 轻量分类模型 + Redis 状态中心 + 少量插件 + 模板回复
|
||
|
||
### 17.2 第二阶段：商用 MVP
|
||
|
||
目标：
|
||
|
||
- 覆盖主要业务链路，支持转人工和监控闭环
|
||
|
||
范围：
|
||
|
||
- 50 到 100 个意图
|
||
- 问答 + 事务 + 执行三类能力
|
||
|
||
方案：
|
||
|
||
- 分类模型 + 向量召回 + LLM 精判 + 执行引擎 + 配置中心
|
||
|
||
### 17.3 第三阶段：平台化
|
||
|
||
目标：
|
||
|
||
- 多场景复用，支持客服、售后、前台、座舱统一底座
|
||
|
||
范围：
|
||
|
||
- 多租户、多场景、多插件
|
||
|
||
方案：
|
||
|
||
- 插件平台、规则平台、意图库平台、评测平台、可观测平台全面建设
|
||
|
||
## 18. 最终建议
|
||
|
||
对于“回答迅速且执行准确”的 Agent，不建议直接用单一大模型硬做，而应采用以下混合架构：
|
||
|
||
- 高频请求：小模型分类直达执行
|
||
- 动态意图：向量召回缩小范围
|
||
- 复杂请求：LLM 做拆分、精判和工作流生成
|
||
- 多轮会话：状态中心负责记忆与恢复
|
||
- 最终执行：插件和规则引擎负责落地
|
||
|
||
一句话总结：
|
||
|
||
这是一个“快路径保证速度、慢路径保证理解、状态中心保证多轮、插件执行保证结果”的 Agent 架构。
|
||
|
||
如果后续继续推进，下一步建议补两份文档：
|
||
|
||
- 一份《系统架构图 + 时序图》
|
||
- 一份《意图表、槽位表、插件表、接口协议表》
|
||
|
||
## 19. 系统架构图
|
||
|
||
### 19.1 总体架构图
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[用户<br/>App / Web / 呼叫中心 / 车机] --> B[接入层<br/>API Gateway / WS / 语音网关]
|
||
B --> C[预处理层<br/>ASR / 文本归一化 / 安全过滤 / 语言识别]
|
||
C --> D[意图路由层]
|
||
|
||
D --> E[快路径<br/>轻量分类模型 + 规则匹配]
|
||
D --> F[慢路径<br/>向量召回 + LLM 精判 + Workflow 生成]
|
||
|
||
E --> G[槽位校验]
|
||
F --> H[复杂任务解析]
|
||
|
||
G --> I[状态中心<br/>Session / Slots / Context / Current Step]
|
||
H --> I
|
||
|
||
I --> J[执行引擎<br/>状态机 / 规则引擎 / 插件调度]
|
||
J --> K[插件层<br/>订单 / 售后 / 前台 / 座舱 / 转人工]
|
||
|
||
K --> L[业务系统<br/>CRM / ERP / 工单 / 地图 / IoT / 车控]
|
||
J --> M[回复生成层<br/>模板回复 / LLM 润色 / TTS]
|
||
M --> N[用户反馈]
|
||
|
||
I --> O[Redis]
|
||
J --> P[PostgreSQL]
|
||
F --> Q[向量库 Qdrant / Milvus]
|
||
J --> R[监控审计<br/>日志 / Trace / Metrics]
|
||
```
|
||
|
||
### 19.2 模块职责说明
|
||
|
||
- 接入层：统一承接文本、语音、车机和 IM 渠道请求。
|
||
- 预处理层：负责 ASR、文本标准化、敏感词过滤、别名归一。
|
||
- 意图路由层：判断进入快路径还是慢路径。
|
||
- 状态中心：保存会话、槽位、上下文和当前执行进度。
|
||
- 执行引擎：按规则与工作流调度插件，控制暂停、恢复、重试和回滚。
|
||
- 插件层：承接具体业务动作，保证执行可控和可审计。
|
||
|
||
## 20. 核心时序图
|
||
|
||
### 20.1 高频请求快路径时序图
|
||
|
||
适用场景：
|
||
|
||
- “打开空调”
|
||
- “查询订单”
|
||
- “通知张三到前台”
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant U as 用户
|
||
participant G as 接入层
|
||
participant R as 路由层
|
||
participant C as 轻量分类模型
|
||
participant S as 状态中心
|
||
participant E as 执行引擎
|
||
participant P as 业务插件
|
||
participant B as 业务系统
|
||
|
||
U->>G: 发起请求
|
||
G->>R: 预处理后的文本
|
||
R->>C: 意图分类
|
||
C-->>R: 高频意图 + 置信度
|
||
R->>S: 读取/更新会话状态
|
||
R->>E: 发起执行请求
|
||
E->>P: 调用目标插件
|
||
P->>B: 调用业务接口
|
||
B-->>P: 返回结果
|
||
P-->>E: 执行结果
|
||
E->>S: 更新步骤状态
|
||
E-->>G: 结构化结果
|
||
G-->>U: 返回执行结果
|
||
```
|
||
|
||
### 20.2 复杂请求慢路径时序图
|
||
|
||
适用场景：
|
||
|
||
- “查订单，如果没发货就取消”
|
||
- “导航去公司，再把空调调到 22 度”
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant U as 用户
|
||
participant G as 接入层
|
||
participant R as 路由层
|
||
participant V as 向量召回
|
||
participant L as LLM
|
||
participant S as 状态中心
|
||
participant E as 执行引擎
|
||
participant P as 插件层
|
||
|
||
U->>G: 发起复杂请求
|
||
G->>R: 预处理后的输入
|
||
R->>V: 召回候选意图 Top-K
|
||
V-->>R: 候选意图列表
|
||
R->>L: 候选意图 + 用户输入
|
||
L-->>R: 精判结果 + Workflow JSON
|
||
R->>S: 保存 workflow 和 slots
|
||
R->>E: 启动执行
|
||
E->>P: 按步骤调度插件
|
||
P-->>E: 每步执行结果
|
||
E->>S: 更新 current_step / context
|
||
E-->>G: 汇总结果
|
||
G-->>U: 返回执行反馈
|
||
```
|
||
|
||
### 20.3 多轮补槽与断点续跑时序图
|
||
|
||
适用场景：
|
||
|
||
- “我要退货”
|
||
- “帮我预约维修”
|
||
- “导航去机场，走高速”
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant U as 用户
|
||
participant G as 接入层
|
||
participant R as 路由层
|
||
participant L as LLM/抽取模型
|
||
participant S as 状态中心
|
||
participant E as 执行引擎
|
||
participant P as 插件层
|
||
|
||
U->>G: 我要退货
|
||
G->>R: 首轮请求
|
||
R->>L: 识别意图并抽取槽位
|
||
L-->>R: 退货意图，缺少 order_id
|
||
R->>S: 保存 pending_slots=order_id
|
||
R-->>G: 生成追问
|
||
G-->>U: 请提供订单号
|
||
|
||
U->>G: A123456
|
||
G->>S: 带 session_id 读取上下文
|
||
S-->>G: 返回待补槽位信息
|
||
G->>L: 仅做槽位提取
|
||
L-->>G: order_id=A123456
|
||
G->>S: 更新槽位并置为 ready_to_execute
|
||
G->>E: 从断点恢复执行
|
||
E->>P: 调用退货插件
|
||
P-->>E: 返回结果
|
||
E->>S: 更新为 completed
|
||
E-->>G: 执行成功
|
||
G-->>U: 已为你提交退货申请
|
||
```
|
||
|
||
## 21. 场景执行图
|
||
|
||
### 21.1 智能座舱复合指令执行图
|
||
|
||
示例指令：
|
||
|
||
- “打开空调到 22 度，导航去公司，再播放轻音乐”
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[用户输入复合指令] --> B[意图拆分]
|
||
B --> C1[设置空调]
|
||
B --> C2[导航到公司]
|
||
B --> C3[播放轻音乐]
|
||
|
||
C1 --> D[槽位校验 temperature=22]
|
||
C2 --> E[槽位校验 destination=公司]
|
||
C3 --> F[槽位校验 genre=轻音乐]
|
||
|
||
D --> G[空调插件]
|
||
E --> H[导航插件]
|
||
F --> I[音乐插件]
|
||
|
||
G --> J[更新座舱上下文]
|
||
H --> J
|
||
I --> J
|
||
J --> K[统一反馈执行结果]
|
||
```
|
||
|
||
### 21.2 客服售后条件流程图
|
||
|
||
示例指令：
|
||
|
||
- “帮我查订单，如果还没发货就取消”
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A[用户输入] --> B[识别查询订单 + 取消订单]
|
||
B --> C[生成条件工作流]
|
||
C --> D[执行查询订单插件]
|
||
D --> E{是否已发货}
|
||
E -- 否 --> F[执行取消订单插件]
|
||
E -- 是 --> G[返回不可取消说明]
|
||
F --> H[返回取消成功]
|
||
G --> I[结束]
|
||
H --> I
|
||
```
|
||
|
||
## 22. 时序图对应的工程说明
|
||
|
||
### 22.1 为什么要先路由再规划
|
||
|
||
- 不是所有请求都需要 LLM。
|
||
- 高频请求先经过快路径，能够显著降低响应延迟和调用成本。
|
||
- 复杂请求才进入召回与规划链路，保证资源集中用在真正困难的问题上。
|
||
|
||
### 22.2 为什么多轮只做补槽不重规划
|
||
|
||
- 这样可以减少模型重复推理，显著缩短第二轮及后续轮次响应时间。
|
||
- 可以避免上下文漂移，保证任务持续围绕原始目标推进。
|
||
- 更适合客服、售后、前台、座舱这类明确任务型交互。
|
||
|
||
### 22.3 为什么执行一定要经过状态中心
|
||
|
||
- 执行过程需要可追踪、可暂停、可恢复。
|
||
- 插件失败、超时、用户打断等情况都需要状态中心统一管理。
|
||
- 后续做审计、风控、会话分析时，也必须依赖完整状态记录。
|
||
|
||
## 23. 下一步详细设计建议
|
||
|
||
在当前架构图和时序图基础上，建议下一步输出以下内容：
|
||
|
||
1. 意图清单：按客服、售后、前台、座舱四大域拆分。
|
||
2. 槽位字典：定义每个意图所需字段、校验规则和追问模板。
|
||
3. 插件接口表：定义入参、出参、幂等键、超时与错误码。
|
||
4. MVP 范围：先选 10 到 20 个高频意图，构建第一版闭环。
|
||
|
||
## 24. 意图清单初稿
|
||
|
||
### 24.1 字段说明
|
||
|
||
建议每个意图至少包含以下字段：
|
||
|
||
- `intent_id`：意图唯一标识
|
||
- `intent_name`：意图名称
|
||
- `domain`：所属业务域
|
||
- `type`：问答 / 事务 / 控制
|
||
- `priority`：优先级
|
||
- `risk_level`：风险等级
|
||
- `entry_path`：快路径 / 慢路径
|
||
- `required_slots`：必填槽位
|
||
- `plugin_id`：执行插件标识
|
||
|
||
### 24.2 客服域意图表
|
||
|
||
| intent_id | intent_name | type | risk_level | entry_path | required_slots | plugin_id |
|
||
| --- | --- | --- | --- | --- | --- | --- |
|
||
| cs_query_order | 查询订单状态 | 事务 | low | 快路径 | order_id | plugin.order.query |
|
||
| cs_query_logistics | 查询物流 | 事务 | low | 快路径 | order_id | plugin.logistics.query |
|
||
| cs_cancel_order | 取消订单 | 事务 | medium | 快路径 | order_id | plugin.order.cancel |
|
||
| cs_refund_status | 查询退款进度 | 事务 | low | 快路径 | refund_id/order_id | plugin.refund.query |
|
||
| cs_transfer_human | 转人工 | 事务 | low | 快路径 | reason | plugin.service.transfer_human |
|
||
| cs_complaint_submit | 提交投诉 | 事务 | medium | 慢路径 | complaint_type, content | plugin.ticket.complaint |
|
||
|
||
### 24.3 售后域意图表
|
||
|
||
| intent_id | intent_name | type | risk_level | entry_path | required_slots | plugin_id |
|
||
| --- | --- | --- | --- | --- | --- | --- |
|
||
| af_apply_return | 申请退货 | 事务 | medium | 快路径 | order_id, reason | plugin.aftersale.return |
|
||
| af_apply_exchange | 申请换货 | 事务 | medium | 慢路径 | order_id, reason | plugin.aftersale.exchange |
|
||
| af_apply_repair | 申请维修 | 事务 | medium | 慢路径 | product_id, fault_desc | plugin.aftersale.repair |
|
||
| af_book_service | 预约上门服务 | 事务 | medium | 慢路径 | address, time_range, phone | plugin.aftersale.booking |
|
||
| af_query_ticket | 查询工单进度 | 事务 | low | 快路径 | ticket_id | plugin.ticket.query |
|
||
| af_upload_material | 补充售后材料 | 事务 | low | 快路径 | ticket_id, material_type | plugin.ticket.material |
|
||
|
||
### 24.4 前台域意图表
|
||
|
||
| intent_id | intent_name | type | risk_level | entry_path | required_slots | plugin_id |
|
||
| --- | --- | --- | --- | --- | --- | --- |
|
||
| front_visitor_register | 来访登记 | 事务 | medium | 慢路径 | visitor_name, phone, host_name | plugin.frontdesk.visitor_register |
|
||
| front_notify_host | 通知被访人 | 事务 | low | 快路径 | host_name | plugin.frontdesk.notify_host |
|
||
| front_book_meeting_room | 预约会议室 | 事务 | medium | 慢路径 | room_name, start_time, end_time | plugin.frontdesk.book_room |
|
||
| front_route_guide | 路线引导 | 问答 | low | 快路径 | destination | plugin.frontdesk.route_guide |
|
||
| front_check_appointment | 查询预约信息 | 事务 | low | 快路径 | phone/appointment_id | plugin.frontdesk.query_appointment |
|
||
| front_print_badge | 打印访客证 | 控制 | medium | 快路径 | visitor_name, company | plugin.frontdesk.print_badge |
|
||
|
||
### 24.5 智能座舱域意图表
|
||
|
||
| intent_id | intent_name | type | risk_level | entry_path | required_slots | plugin_id |
|
||
| --- | --- | --- | --- | --- | --- | --- |
|
||
| cabin_nav_to | 导航到目的地 | 控制 | medium | 快路径 | destination | plugin.cabin.navigation |
|
||
| cabin_set_ac | 设置空调 | 控制 | low | 快路径 | temperature | plugin.cabin.ac_control |
|
||
| cabin_window_control | 控制车窗 | 控制 | medium | 快路径 | position, action | plugin.cabin.window_control |
|
||
| cabin_play_music | 播放音乐 | 控制 | low | 快路径 | song/genre | plugin.cabin.music_play |
|
||
| cabin_call_contact | 拨打电话 | 控制 | high | 慢路径 | contact_name | plugin.cabin.call_contact |
|
||
| cabin_multi_command | 复合指令执行 | 控制 | medium | 慢路径 | workflow | plugin.cabin.workflow_executor |
|
||
|
||
### 24.6 通用兜底意图
|
||
|
||
| intent_id | intent_name | type | risk_level | entry_path | required_slots | plugin_id |
|
||
| --- | --- | --- | --- | --- | --- | --- |
|
||
| common_faq | 知识问答 | 问答 | low | 快路径 | 无 | plugin.knowledge.faq |
|
||
| common_clarify | 澄清意图 | 问答 | low | 慢路径 | 无 | plugin.dialog.clarify |
|
||
| common_reject | 拒绝执行 | 问答 | high | 快路径 | 无 | plugin.guard.reject |
|
||
| common_fallback | 兜底处理 | 问答 | low | 慢路径 | 无 | plugin.dialog.fallback |
|
||
|
||
## 25. 槽位字典初稿
|
||
|
||
### 25.1 通用槽位表
|
||
|
||
| slot_name | type | required | example | validate_rule | ask_template | used_by |
|
||
| --- | --- | --- | --- | --- | --- | --- |
|
||
| order_id | string | 是 | A123456 | 长度 6-32，字母数字 | 请提供订单号 | 客服、售后 |
|
||
| refund_id | string | 否 | R2025001 | 长度 6-32 | 请提供退款单号 | 客服 |
|
||
| ticket_id | string | 是 | T90001 | 长度 4-32 | 请提供工单号 | 售后 |
|
||
| appointment_id | string | 否 | AP2026001 | 长度 4-32 | 请提供预约编号 | 前台 |
|
||
| product_id | string | 是 | SKU12345 | 长度 4-64 | 请提供商品编号或设备编号 | 售后 |
|
||
| reason | string | 是 | 不想要了 | 长度 2-200 | 请说明原因 | 客服、售后 |
|
||
| fault_desc | string | 是 | 无法开机 | 长度 5-300 | 请描述故障现象 | 售后 |
|
||
| complaint_type | enum | 是 | 服务问题 | 枚举校验 | 请问是商品问题、物流问题还是服务问题 | 客服 |
|
||
| content | string | 是 | 客服态度差 | 长度 5-500 | 请描述具体情况 | 客服 |
|
||
| phone | string | 是 | 13800138000 | 手机号格式 | 请提供手机号 | 售后、前台 |
|
||
| time_range | string | 是 | 明天下午 2 点到 4 点 | 可解析时间范围 | 请提供预约时间 | 售后、前台 |
|
||
| address | string | 是 | 上海浦东新区 XX 路 | 长度 5-200 | 请提供服务地址 | 售后 |
|
||
| material_type | enum | 是 | 故障图片 | 枚举校验 | 请说明要补充的材料类型 | 售后 |
|
||
| visitor_name | string | 是 | 张三 | 长度 2-50 | 请提供来访人姓名 | 前台 |
|
||
| host_name | string | 是 | 李经理 | 长度 2-50 | 请问要拜访谁 | 前台 |
|
||
| company | string | 否 | 某某科技 | 长度 2-100 | 请提供访客单位名称 | 前台 |
|
||
| room_name | string | 是 | 3F-A01 | 会议室编码格式 | 请提供会议室名称或编号 | 前台 |
|
||
| start_time | datetime | 是 | 2026-05-10 14:00 | 标准时间格式 | 请提供开始时间 | 前台 |
|
||
| end_time | datetime | 是 | 2026-05-10 15:00 | 晚于开始时间 | 请提供结束时间 | 前台 |
|
||
| destination | string | 是 | 公司/虹桥机场 | POI 或地址可解析 | 请告诉我要去哪里 | 前台、座舱 |
|
||
| temperature | number | 是 | 22 | 16-30 | 请问要设置多少度 | 座舱 |
|
||
| position | enum | 是 | 主驾窗 | 枚举校验 | 请问要控制哪个车窗 | 座舱 |
|
||
| action | enum | 是 | 打开/关闭 | 枚举校验 | 请问要打开还是关闭 | 座舱 |
|
||
| song | string | 否 | 夜曲 | 长度 1-100 | 请问要播放哪首歌 | 座舱 |
|
||
| genre | string | 否 | 轻音乐 | 长度 1-50 | 请问要听什么类型的音乐 | 座舱 |
|
||
| contact_name | string | 是 | 王总 | 长度 2-50 | 请问要拨打给谁 | 座舱 |
|
||
| workflow | json | 是 | 复合动作 JSON | JSON Schema 校验 | 正在解析复合指令 | 座舱 |
|
||
|
||
### 25.2 槽位配置建议
|
||
|
||
每个槽位建议增加如下元数据：
|
||
|
||
- `normalize_fn`：归一化方法，例如金额、时间、地址标准化
|
||
- `source_priority`：优先从用户当前输入、历史会话还是业务上下文中取值
|
||
- `confirm_required`：是否需要用户确认
|
||
- `risk_binding`：是否与风险动作绑定
|
||
- `rewrite_prompt`：槽位识别失败时的重试提示
|
||
|
||
### 25.3 槽位提取策略
|
||
|
||
- 首轮请求：意图识别与槽位提取同时进行
|
||
- 补槽轮次：只提取 `pending_slots`
|
||
- 高风险槽位：提取后必须二次确认
|
||
- 可继承槽位：如 `phone`、`host_name`，可从历史会话或用户档案中补全
|
||
|
||
## 26. 插件接口规范初稿
|
||
|
||
### 26.1 插件统一接口
|
||
|
||
所有业务插件建议遵循统一接口，便于执行引擎调度：
|
||
|
||
```json
|
||
{
|
||
"plugin_id": "plugin.order.cancel",
|
||
"request_id": "req_001",
|
||
"session_id": "sess_001",
|
||
"user_id": "user_001",
|
||
"intent_id": "cs_cancel_order",
|
||
"slots": {
|
||
"order_id": "A123456",
|
||
"reason": "不想要了"
|
||
},
|
||
"context": {
|
||
"channel": "app",
|
||
"trace_id": "trace_001"
|
||
}
|
||
}
|
||
```
|
||
|
||
统一响应格式建议如下：
|
||
|
||
```json
|
||
{
|
||
"success": true,
|
||
"code": "OK",
|
||
"message": "订单取消成功",
|
||
"data": {
|
||
"order_id": "A123456",
|
||
"status": "cancelled"
|
||
},
|
||
"need_confirm": false,
|
||
"need_more_slots": [],
|
||
"retryable": false
|
||
}
|
||
```
|
||
|
||
### 26.2 插件表初稿
|
||
|
||
| plugin_id | plugin_name | domain | input_slots | output_fields | timeout_ms | retry_policy | idempotent_key |
|
||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||
| plugin.order.query | 查询订单 | 客服 | order_id | order_status, pay_status | 1500 | 失败重试 1 次 | session_id + order_id |
|
||
| plugin.logistics.query | 查询物流 | 客服 | order_id | logistics_status, trace_list | 1500 | 失败重试 1 次 | session_id + order_id |
|
||
| plugin.order.cancel | 取消订单 | 客服 | order_id, reason | cancel_status | 2000 | 不自动重试 | session_id + order_id |
|
||
| plugin.service.transfer_human | 转人工 | 客服 | reason | queue_no, wait_time | 1000 | 不自动重试 | session_id + reason |
|
||
| plugin.aftersale.return | 申请退货 | 售后 | order_id, reason | return_ticket_id | 2000 | 不自动重试 | session_id + order_id |
|
||
| plugin.aftersale.repair | 申请维修 | 售后 | product_id, fault_desc | repair_ticket_id | 2500 | 不自动重试 | session_id + product_id |
|
||
| plugin.aftersale.booking | 上门预约 | 售后 | address, time_range, phone | booking_id | 2500 | 失败重试 1 次 | session_id + phone + time_range |
|
||
| plugin.frontdesk.visitor_register | 来访登记 | 前台 | visitor_name, phone, host_name | visit_id, qr_code | 2000 | 不自动重试 | session_id + phone |
|
||
| plugin.frontdesk.notify_host | 通知被访人 | 前台 | host_name | notify_status | 1000 | 失败重试 1 次 | session_id + host_name |
|
||
| plugin.frontdesk.book_room | 预约会议室 | 前台 | room_name, start_time, end_time | booking_status, booking_id | 2000 | 不自动重试 | session_id + room_name + start_time |
|
||
| plugin.cabin.navigation | 导航 | 座舱 | destination | route_id, eta | 1200 | 失败重试 1 次 | session_id + destination |
|
||
| plugin.cabin.ac_control | 空调控制 | 座舱 | temperature | ac_status | 800 | 不自动重试 | session_id + temperature |
|
||
| plugin.cabin.window_control | 车窗控制 | 座舱 | position, action | window_status | 800 | 不自动重试 | session_id + position + action |
|
||
| plugin.cabin.music_play | 音乐播放 | 座舱 | song/genre | play_status, media_id | 1000 | 失败重试 1 次 | session_id + song + genre |
|
||
|
||
### 26.3 插件错误码建议
|
||
|
||
| code | meaning | action |
|
||
| --- | --- | --- |
|
||
| OK | 执行成功 | 正常返回 |
|
||
| MISSING_SLOT | 缺少必要槽位 | 转为追问流程 |
|
||
| INVALID_SLOT | 槽位不合法 | 触发重试提示 |
|
||
| NEED_CONFIRM | 需要用户确认 | 进入确认节点 |
|
||
| NO_PERMISSION | 权限不足 | 拒绝执行并解释原因 |
|
||
| RISK_BLOCKED | 风险拦截 | 终止执行并记录审计 |
|
||
| BIZ_TIMEOUT | 下游超时 | 可重试或降级 |
|
||
| BIZ_FAILED | 业务失败 | 给出失败原因 |
|
||
| SYSTEM_ERROR | 系统异常 | 兜底或转人工 |
|
||
|
||
### 26.4 插件开发约束
|
||
|
||
- 插件必须无状态，状态统一交给状态中心管理。
|
||
- 插件必须返回结构化结果，不能只返回自然语言。
|
||
- 高风险插件必须支持 `need_confirm` 控制。
|
||
- 写操作类插件必须支持幂等键。
|
||
- 插件必须记录 trace_id，支持全链路审计。
|
||
|
||
## 27. 接口协议建议
|
||
|
||
### 27.1 对话入口接口
|
||
|
||
`POST /api/v1/agent/chat`
|
||
|
||
请求示例：
|
||
|
||
```json
|
||
{
|
||
"session_id": "sess_001",
|
||
"user_id": "user_001",
|
||
"channel": "app",
|
||
"input_text": "帮我查一下订单，如果没发货就取消",
|
||
"input_type": "text",
|
||
"metadata": {
|
||
"device_id": "dev_001",
|
||
"tenant_id": "tenant_a"
|
||
}
|
||
}
|
||
```
|
||
|
||
响应示例：
|
||
|
||
```json
|
||
{
|
||
"session_id": "sess_001",
|
||
"reply_type": "workflow_result",
|
||
"reply_text": "已为你查询订单，当前未发货，正在为你取消。",
|
||
"intent": "cs_cancel_order",
|
||
"status": "executing",
|
||
"pending_slots": [],
|
||
"workflow_id": "wf_001",
|
||
"trace_id": "trace_001"
|
||
}
|
||
```
|
||
|
||
### 27.2 补槽接口
|
||
|
||
`POST /api/v1/agent/fill-slots`
|
||
|
||
请求示例：
|
||
|
||
```json
|
||
{
|
||
"session_id": "sess_001",
|
||
"user_id": "user_001",
|
||
"input_text": "订单号是 A123456"
|
||
}
|
||
```
|
||
|
||
响应示例：
|
||
|
||
```json
|
||
{
|
||
"session_id": "sess_001",
|
||
"status": "ready_to_execute",
|
||
"filled_slots": {
|
||
"order_id": "A123456"
|
||
},
|
||
"pending_slots": [],
|
||
"reply_text": "收到，正在继续为你处理。"
|
||
}
|
||
```
|
||
|
||
### 27.3 管理后台接口建议
|
||
|
||
- `GET /api/v1/intents`
|
||
- `POST /api/v1/intents`
|
||
- `GET /api/v1/slots`
|
||
- `POST /api/v1/plugins/register`
|
||
- `GET /api/v1/sessions/{session_id}`
|
||
- `GET /api/v1/traces/{trace_id}`
|
||
|
||
## 28. MVP 一期范围建议
|
||
|
||
### 28.1 一期目标
|
||
|
||
目标不是一开始覆盖所有场景，而是优先打通一条“能快速响应、能多轮补槽、能真正执行”的闭环。
|
||
|
||
### 28.2 推荐一期场景
|
||
|
||
建议先选两个最有代表性的场景：
|
||
|
||
- 客服：查询订单、查物流、取消订单、转人工
|
||
- 智能座舱：导航、空调控制、音乐播放、复合指令
|
||
|
||
这样可以同时覆盖：
|
||
|
||
- 标准事务型任务
|
||
- 高实时控制型任务
|
||
- 多轮补槽能力
|
||
- 复杂复合指令能力
|
||
|
||
### 28.3 一期推荐意图
|
||
|
||
建议第一期先落 12 个意图：
|
||
|
||
| domain | intent_id | intent_name | priority |
|
||
| --- | --- | --- | --- |
|
||
| 客服 | cs_query_order | 查询订单状态 | P0 |
|
||
| 客服 | cs_query_logistics | 查询物流 | P0 |
|
||
| 客服 | cs_cancel_order | 取消订单 | P0 |
|
||
| 客服 | cs_transfer_human | 转人工 | P0 |
|
||
| 售后 | af_apply_return | 申请退货 | P1 |
|
||
| 售后 | af_query_ticket | 查询工单进度 | P1 |
|
||
| 前台 | front_notify_host | 通知被访人 | P1 |
|
||
| 前台 | front_route_guide | 路线引导 | P1 |
|
||
| 座舱 | cabin_nav_to | 导航到目的地 | P0 |
|
||
| 座舱 | cabin_set_ac | 设置空调 | P0 |
|
||
| 座舱 | cabin_play_music | 播放音乐 | P0 |
|
||
| 座舱 | cabin_multi_command | 复合指令执行 | P0 |
|
||
|
||
### 28.4 一期必须具备的能力
|
||
|
||
- 会话状态中心
|
||
- 快路径意图分类
|
||
- 基础槽位提取
|
||
- 补槽追问与断点恢复
|
||
- 插件统一协议
|
||
- 至少 8 个可执行插件
|
||
- 基础监控和审计日志
|
||
|
||
### 28.5 一期不建议过早投入的能力
|
||
|
||
- 全量复杂规则平台
|
||
- 多租户运营后台
|
||
- 自动训练平台
|
||
- 端到端自主规划型 Agent
|
||
|
||
### 28.6 一期验收标准
|
||
|
||
| metric | target |
|
||
| --- | --- |
|
||
| 高频快路径平均响应时间 | <= 1.5s |
|
||
| 复杂慢路径平均响应时间 | <= 3.5s |
|
||
| 多轮补槽成功率 | >= 85% |
|
||
| 插件执行成功率 | >= 95% |
|
||
| 高频意图识别准确率 | >= 95% |
|
||
| 高风险误执行率 | 0 |
|
||
|
||
## 29. 开发拆分建议
|
||
|
||
### 29.1 服务拆分
|
||
|
||
- `gateway-service`：统一接入与鉴权
|
||
- `nlu-service`：分类、抽取、召回、精判
|
||
- `session-service`：会话状态管理
|
||
- `orchestrator-service`：工作流执行与插件调度
|
||
- `plugin-service`：业务插件实现
|
||
- `ops-console`：配置与观测后台
|
||
|
||
### 29.2 迭代顺序
|
||
|
||
1. 先做会话状态中心和统一协议。
|
||
2. 再做快路径分类与基础插件闭环。
|
||
3. 然后接入向量召回和 LLM 精判。
|
||
4. 最后补复合指令、多轮恢复、监控审计。
|
||
|
||
### 29.3 人员建议
|
||
|
||
- 后端工程师：2 人
|
||
- AI/NLP 工程师：1 到 2 人
|
||
- 前端或客户端工程师：1 人
|
||
- 测试工程师：1 人
|
||
- 产品经理：1 人
|
||
|
||
## 30. 下一步建议
|
||
|
||
基于当前文档，下一步最适合继续补的是：
|
||
|
||
1. 数据库表结构设计
|
||
2. Redis Session 结构设计
|
||
3. Workflow JSON Schema
|
||
4. 插件 SDK 规范
|
||
5. 评测集与测试用例设计
|
||
|
||
## 31. 数据库表结构设计
|
||
|
||
### 31.1 设计原则
|
||
|
||
- 业务配置与运行态数据分离。
|
||
- 高并发状态放 Redis，持久化和审计放 PostgreSQL。
|
||
- 配置表优先满足可运营、可灰度、可版本化。
|
||
- 运行表优先满足可追踪、可排障、可回放。
|
||
|
||
### 31.2 核心表清单
|
||
|
||
| table_name | purpose |
|
||
| --- | --- |
|
||
| intents | 意图定义表 |
|
||
| intent_examples | 意图示例语料表 |
|
||
| slots | 槽位定义表 |
|
||
| intent_slot_bindings | 意图和槽位绑定表 |
|
||
| plugins | 插件注册表 |
|
||
| plugin_routes | 意图到插件路由表 |
|
||
| workflow_templates | 工作流模板表 |
|
||
| sessions | 会话主表 |
|
||
| session_messages | 会话消息表 |
|
||
| task_executions | 任务执行表 |
|
||
| task_steps | 任务步骤表 |
|
||
| plugin_calls | 插件调用日志表 |
|
||
| audit_logs | 审计日志表 |
|
||
| evaluation_cases | 评测样本表 |
|
||
|
||
### 31.3 关键表字段示例
|
||
|
||
#### intents
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| intent_id | varchar(64) unique | 意图唯一标识 |
|
||
| intent_name | varchar(128) | 意图名称 |
|
||
| domain | varchar(64) | 业务域 |
|
||
| type | varchar(32) | 问答/事务/控制 |
|
||
| risk_level | varchar(16) | 风险等级 |
|
||
| entry_path | varchar(16) | 快路径/慢路径 |
|
||
| enabled | boolean | 是否启用 |
|
||
| version | int | 配置版本 |
|
||
| description | text | 说明 |
|
||
| created_at | timestamp | 创建时间 |
|
||
| updated_at | timestamp | 更新时间 |
|
||
|
||
#### slots
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| slot_name | varchar(64) unique | 槽位名称 |
|
||
| slot_type | varchar(32) | string/number/enum/json |
|
||
| required | boolean | 是否必填 |
|
||
| validate_rule | varchar(256) | 校验规则 |
|
||
| ask_template | varchar(256) | 追问模板 |
|
||
| normalize_fn | varchar(64) | 归一化方法 |
|
||
| confirm_required | boolean | 是否需要确认 |
|
||
| enabled | boolean | 是否启用 |
|
||
| created_at | timestamp | 创建时间 |
|
||
| updated_at | timestamp | 更新时间 |
|
||
|
||
#### intent_slot_bindings
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| intent_id | varchar(64) | 意图标识 |
|
||
| slot_name | varchar(64) | 槽位名称 |
|
||
| required | boolean | 对该意图是否必填 |
|
||
| priority | int | 提问优先级 |
|
||
| source_priority | varchar(128) | 来源优先级 |
|
||
| created_at | timestamp | 创建时间 |
|
||
|
||
#### plugins
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| plugin_id | varchar(128) unique | 插件标识 |
|
||
| plugin_name | varchar(128) | 插件名称 |
|
||
| domain | varchar(64) | 所属域 |
|
||
| endpoint | varchar(256) | 插件地址或服务名 |
|
||
| timeout_ms | int | 超时时间 |
|
||
| retry_policy | varchar(64) | 重试策略 |
|
||
| idempotent_rule | varchar(128) | 幂等规则 |
|
||
| enabled | boolean | 是否启用 |
|
||
| created_at | timestamp | 创建时间 |
|
||
| updated_at | timestamp | 更新时间 |
|
||
|
||
#### sessions
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| session_id | varchar(64) unique | 会话标识 |
|
||
| user_id | varchar(64) | 用户标识 |
|
||
| channel | varchar(32) | 渠道 |
|
||
| current_intent | varchar(64) | 当前意图 |
|
||
| current_status | varchar(32) | 当前状态 |
|
||
| current_workflow_id | varchar(64) | 当前工作流 |
|
||
| risk_level | varchar(16) | 当前风险等级 |
|
||
| last_message_at | timestamp | 最后活跃时间 |
|
||
| created_at | timestamp | 创建时间 |
|
||
| updated_at | timestamp | 更新时间 |
|
||
|
||
#### session_messages
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| session_id | varchar(64) | 会话标识 |
|
||
| role | varchar(16) | user/assistant/system |
|
||
| message_text | text | 文本内容 |
|
||
| structured_payload | jsonb | 结构化载荷 |
|
||
| trace_id | varchar(64) | 链路标识 |
|
||
| created_at | timestamp | 创建时间 |
|
||
|
||
#### task_executions
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| task_id | varchar(64) unique | 任务标识 |
|
||
| session_id | varchar(64) | 会话标识 |
|
||
| workflow_id | varchar(64) | 工作流标识 |
|
||
| status | varchar(32) | pending/running/paused/completed/failed |
|
||
| current_step | int | 当前步骤 |
|
||
| context_snapshot | jsonb | 上下文快照 |
|
||
| error_code | varchar(64) | 错误码 |
|
||
| error_message | varchar(256) | 错误信息 |
|
||
| created_at | timestamp | 创建时间 |
|
||
| updated_at | timestamp | 更新时间 |
|
||
|
||
#### task_steps
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| task_id | varchar(64) | 任务标识 |
|
||
| step_no | int | 步骤号 |
|
||
| intent_id | varchar(64) | 步骤意图 |
|
||
| plugin_id | varchar(128) | 插件标识 |
|
||
| status | varchar(32) | 步骤状态 |
|
||
| input_payload | jsonb | 入参 |
|
||
| output_payload | jsonb | 出参 |
|
||
| started_at | timestamp | 开始时间 |
|
||
| ended_at | timestamp | 结束时间 |
|
||
|
||
#### plugin_calls
|
||
|
||
| field | type | desc |
|
||
| --- | --- | --- |
|
||
| id | bigint pk | 主键 |
|
||
| trace_id | varchar(64) | 链路标识 |
|
||
| task_id | varchar(64) | 任务标识 |
|
||
| plugin_id | varchar(128) | 插件标识 |
|
||
| request_payload | jsonb | 请求内容 |
|
||
| response_payload | jsonb | 响应内容 |
|
||
| success | boolean | 是否成功 |
|
||
| latency_ms | int | 调用耗时 |
|
||
| created_at | timestamp | 创建时间 |
|
||
|
||
### 31.4 建表索引建议
|
||
|
||
- `intents(intent_id)` 唯一索引
|
||
- `slots(slot_name)` 唯一索引
|
||
- `plugins(plugin_id)` 唯一索引
|
||
- `sessions(session_id)` 唯一索引
|
||
- `sessions(user_id, updated_at)` 组合索引
|
||
- `session_messages(session_id, created_at)` 组合索引
|
||
- `task_executions(session_id, status)` 组合索引
|
||
- `plugin_calls(trace_id)` 普通索引
|
||
|
||
## 32. Redis Session 结构设计
|
||
|
||
### 32.1 设计目标
|
||
|
||
- 支持毫秒级读取会话状态
|
||
- 支持多轮补槽和断点恢复
|
||
- 支持任务并发控制和幂等去重
|
||
- 支持热点上下文缓存
|
||
|
||
### 32.2 Key 设计
|
||
|
||
| key_pattern | type | purpose | ttl |
|
||
| --- | --- | --- | --- |
|
||
| `agent:session:{session_id}` | Hash | 会话主状态 | 24h |
|
||
| `agent:slots:{session_id}` | Hash | 当前已填槽位 | 24h |
|
||
| `agent:pending:{session_id}` | List | 待补槽位队列 | 24h |
|
||
| `agent:workflow:{session_id}` | String | 当前 Workflow JSON | 24h |
|
||
| `agent:context:{session_id}` | String | 上下文快照 JSON | 24h |
|
||
| `agent:lock:{session_id}` | String | 会话执行锁 | 30s |
|
||
| `agent:idempotent:{key}` | String | 幂等去重键 | 10m |
|
||
| `agent:cache:intent:{text_hash}` | String | 高频意图缓存 | 30m |
|
||
|
||
### 32.3 Session Hash 示例
|
||
|
||
Key: `agent:session:sess_001`
|
||
|
||
```json
|
||
{
|
||
"session_id": "sess_001",
|
||
"user_id": "user_001",
|
||
"channel": "app",
|
||
"status": "waiting_slot",
|
||
"current_intent": "af_apply_return",
|
||
"workflow_id": "wf_001",
|
||
"current_step": "1",
|
||
"risk_level": "medium",
|
||
"last_active_at": "2026-05-09T10:00:00Z"
|
||
}
|
||
```
|
||
|
||
### 32.4 Slots Hash 示例
|
||
|
||
Key: `agent:slots:sess_001`
|
||
|
||
```json
|
||
{
|
||
"order_id": "A123456",
|
||
"reason": "不想要了"
|
||
}
|
||
```
|
||
|
||
### 32.5 Pending Slots List 示例
|
||
|
||
Key: `agent:pending:sess_001`
|
||
|
||
```json
|
||
[
|
||
"order_id",
|
||
"reason"
|
||
]
|
||
```
|
||
|
||
### 32.6 Context JSON 示例
|
||
|
||
Key: `agent:context:sess_001`
|
||
|
||
```json
|
||
{
|
||
"biz_context": {
|
||
"order_status": "pending_shipment"
|
||
},
|
||
"history_summary": "用户发起退货申请",
|
||
"plugin_results": {
|
||
"plugin.order.query": {
|
||
"success": true,
|
||
"status": "pending_shipment"
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
### 32.7 Redis 操作建议
|
||
|
||
- 进入执行前对 `agent:lock:{session_id}` 加分布式锁。
|
||
- 每次补槽后同时更新 `session`、`slots`、`pending`。
|
||
- 工作流执行完成后，可保留短时缓存用于追问和结果追溯。
|
||
- 长会话可异步落盘 PostgreSQL 后缩短 Redis TTL。
|
||
|
||
## 33. Workflow JSON Schema 设计
|
||
|
||
### 33.1 设计目标
|
||
|
||
- 让 LLM 输出严格受控
|
||
- 让执行引擎易于解析
|
||
- 支持单步、顺序、条件、并行和补槽暂停
|
||
|
||
### 33.2 Workflow 顶层结构
|
||
|
||
```json
|
||
{
|
||
"workflow_id": "wf_001",
|
||
"workflow_type": "sequence",
|
||
"domain": "customer_service",
|
||
"intent_id": "cs_cancel_order",
|
||
"status": "ready",
|
||
"risk_level": "medium",
|
||
"slots": {
|
||
"order_id": "A123456"
|
||
},
|
||
"missing_slots": [],
|
||
"steps": [],
|
||
"meta": {
|
||
"source": "llm_planner",
|
||
"version": "1.0"
|
||
}
|
||
}
|
||
```
|
||
|
||
### 33.3 Step 结构
|
||
|
||
```json
|
||
{
|
||
"step": 1,
|
||
"step_id": "step_001",
|
||
"intent_id": "cs_query_order",
|
||
"plugin_id": "plugin.order.query",
|
||
"action": "query_order",
|
||
"status": "pending",
|
||
"depends_on": [],
|
||
"slots": {
|
||
"order_id": "A123456"
|
||
},
|
||
"on_success": "next",
|
||
"on_failure": "fallback",
|
||
"timeout_ms": 1500
|
||
}
|
||
```
|
||
|
||
### 33.4 条件步骤结构
|
||
|
||
```json
|
||
{
|
||
"step": 2,
|
||
"step_id": "step_002",
|
||
"type": "condition",
|
||
"condition": {
|
||
"expr": "context.order_status == 'pending_shipment'"
|
||
},
|
||
"if_true": {
|
||
"intent_id": "cs_cancel_order",
|
||
"plugin_id": "plugin.order.cancel"
|
||
},
|
||
"if_false": {
|
||
"action": "reply",
|
||
"message": "订单已发货，暂时无法取消。"
|
||
}
|
||
}
|
||
```
|
||
|
||
### 33.5 补槽暂停结构
|
||
|
||
```json
|
||
{
|
||
"status": "waiting_slot",
|
||
"missing_slots": [
|
||
{
|
||
"slot_name": "order_id",
|
||
"ask_template": "请提供订单号",
|
||
"priority": 1
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
### 33.6 JSON Schema 示例
|
||
|
||
```json
|
||
{
|
||
"$schema": "https://json-schema.org/draft/2020-12/schema",
|
||
"title": "AgentWorkflow",
|
||
"type": "object",
|
||
"required": ["workflow_id", "workflow_type", "intent_id", "status", "steps"],
|
||
"properties": {
|
||
"workflow_id": {
|
||
"type": "string"
|
||
},
|
||
"workflow_type": {
|
||
"type": "string",
|
||
"enum": ["single", "sequence", "conditional", "parallel"]
|
||
},
|
||
"domain": {
|
||
"type": "string"
|
||
},
|
||
"intent_id": {
|
||
"type": "string"
|
||
},
|
||
"status": {
|
||
"type": "string",
|
||
"enum": ["ready", "waiting_slot", "running", "completed", "failed"]
|
||
},
|
||
"risk_level": {
|
||
"type": "string",
|
||
"enum": ["low", "medium", "high"]
|
||
},
|
||
"slots": {
|
||
"type": "object"
|
||
},
|
||
"missing_slots": {
|
||
"type": "array"
|
||
},
|
||
"steps": {
|
||
"type": "array",
|
||
"items": {
|
||
"type": "object",
|
||
"required": ["step", "step_id"],
|
||
"properties": {
|
||
"step": {
|
||
"type": "integer"
|
||
},
|
||
"step_id": {
|
||
"type": "string"
|
||
},
|
||
"intent_id": {
|
||
"type": "string"
|
||
},
|
||
"plugin_id": {
|
||
"type": "string"
|
||
},
|
||
"action": {
|
||
"type": "string"
|
||
},
|
||
"status": {
|
||
"type": "string"
|
||
},
|
||
"depends_on": {
|
||
"type": "array"
|
||
},
|
||
"slots": {
|
||
"type": "object"
|
||
}
|
||
}
|
||
}
|
||
},
|
||
"meta": {
|
||
"type": "object"
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
### 33.7 约束建议
|
||
|
||
- LLM 只能从候选意图和候选插件中选择，不能自由生成未知标识。
|
||
- 所有工作流必须通过 JSON Schema 校验后才能进入执行引擎。
|
||
- 高风险动作必须显式输出 `risk_level` 和 `need_confirm`。
|
||
- 补槽状态和执行状态必须严格区分，避免重复执行。
|
||
|
||
## 34. 开工建议
|
||
|
||
在完成以上设计后，建议按以下顺序正式开工：
|
||
|
||
1. 初始化后端项目骨架。
|
||
2. 实现配置模型、会话模型和 Workflow Schema。
|
||
3. 打通 `/chat` 和 `/fill-slots` 两个核心接口。
|
||
4. 先接入 mock 插件，完成完整闭环。
|
||
5. 再逐步接入真实业务系统和模型服务。
|
||
|
||
## 35. 多标签 Detector 过渡方案
|
||
|
||
### 35.1 背景
|
||
|
||
当前多意图链路已经具备以下结构：
|
||
|
||
- `clause split` 负责切分明显并列或条件语句
|
||
- `clause classifier` 负责对单个子句提供语义补偿
|
||
- `multi_intent_detector` 负责在整句粒度提供多标签先验
|
||
- `planner fusion` 负责合并 heuristic、classifier 和 detector 的信号
|
||
|
||
现阶段的问题不在 `planner` 主骨架，而在 detector 的训练方式。当前 detector 基于单标签分类头的 logits 做 sigmoid 解释，只能作为过渡信号，不能代表真正学到的“多标签共现关系”。
|
||
|
||
### 35.2 迁移目标
|
||
|
||
本阶段的目标不是重写规划器，而是把 detector 从“推理时解释型多标签”升级成“训练时显式监督的多标签模型”。
|
||
|
||
迁移后应满足：
|
||
|
||
- `planner` 继续消费 `detector_prior`，主骨架保持稳定
|
||
- detector 使用独立模型目录，不与单标签 classifier 共享分类头
|
||
- 训练样本显式表达一个句子对应多个 intent 的监督关系
|
||
- 评测指标从单一准确率升级为多标签指标
|
||
- 为下一阶段 `NER / token classification` 提供更稳定的候选意图集合
|
||
|
||
### 35.3 数据格式
|
||
|
||
保留现有单标签训练数据：
|
||
|
||
```json
|
||
{"text": "打开车窗", "intent_id": "cabin_window_open"}
|
||
```
|
||
|
||
新增多标签训练数据：
|
||
|
||
```json
|
||
{"text": "打开车窗并播放音乐", "intent_ids": ["cabin_window_open", "cabin_play_music"]}
|
||
```
|
||
|
||
约束建议：
|
||
|
||
- 单标签样本可以直接提升为 `intent_ids` 长度为 1 的多标签样本
|
||
- 多标签样本优先覆盖座舱高频并列控制场景
|
||
- `__social__` 与 `__out_of_scope__` 不作为多标签共现目标，避免污染业务动作组合学习
|
||
- 多标签语料要覆盖口语连接词、顺序词、弱连接和省略表达
|
||
|
||
### 35.4 模型与训练
|
||
|
||
建议为 detector 使用独立训练脚本和独立输出目录：
|
||
|
||
- 训练脚本：`scripts/train_local_bert_multi_intent.py`
|
||
- 评测脚本：`scripts/eval_local_bert_multi_intent.py`
|
||
- 模型目录：`models/local_bert_multi_intent/`
|
||
|
||
训练方式：
|
||
|
||
- 底座继续使用本地 MacBERT
|
||
- 任务类型设置为 `multi_label_classification`
|
||
- 标签为多热向量，损失函数为 `BCEWithLogitsLoss`
|
||
- 输出为每个意图的独立概率，不再依赖单标签 softmax 头的副产物
|
||
|
||
### 35.5 运行时接入
|
||
|
||
运行时只替换 detector 的模型来源和解释方式，不改 `planner` 主逻辑。
|
||
|
||
接入原则：
|
||
|
||
- `classifier` 继续服务单子句语义分类
|
||
- `multi_intent_detector` 独立加载多标签模型
|
||
- detector 输出仍然是 `candidates -> detector_prior`
|
||
- detector 默认屏蔽 `__social__` 和 `__out_of_scope__`
|
||
- 当 detector 不可用时，planner 仍可退化到 `clause split + clause classifier + heuristic`
|
||
|
||
### 35.6 与 NER 的衔接
|
||
|
||
在真正多标签 detector 稳定前，不建议直接推进 `NER / token classification` 作为主增量。
|
||
|
||
原因：
|
||
|
||
- NER 擅长抽取边界，不擅长先决定整句有几个意图
|
||
- 如果上游 detector 仍是假多标签，NER 很容易围绕错误意图做精细抽取
|
||
- 先把多标签 detector 训练扎实，可以让 NER 在“候选意图集合已收敛”的前提下工作
|
||
|
||
因此推荐顺序固定为：
|
||
|
||
1. 真正多标签 detector
|
||
2. detector 线上评测和阈值稳定
|
||
3. NER / token classification
|
||
|
||
### 35.7 本阶段验收标准
|
||
|
||
本阶段完成后至少应满足：
|
||
|
||
- detector 支持独立训练、独立加载、独立评测
|
||
- 对典型并列座舱指令，`recall@k` 和 `micro_f1` 明显优于现有 sigmoid 解释方案
|
||
- `planner` 主骨架无需改写，现有 fusion 逻辑保持兼容
|
||
- 后续引入 NER 时，只需增加边界抽取模块，不必再次调整 detector 接口
|
||
|
||
## 36. Joint NLU 升级方案
|
||
|
||
### 36.1 目标
|
||
|
||
本阶段不再继续扩旧的 heuristic 槽位提取逻辑，而是把本地 NLU 快链路升级成真正的 `Joint Intent + Slot` 联合识别。
|
||
|
||
升级目标：
|
||
|
||
- 用一个共享编码器同时完成意图识别和槽位抽取
|
||
- 替换当前 `HeuristicSlotExtractor` 的主路径职责
|
||
- 保留 `planner / workflow / session / response policy` 主骨架
|
||
- 多意图整句仍走 `clause split + multi-intent detector + planner`
|
||
- 单句或单 clause 的语义理解改为 `JointBERT`
|
||
|
||
### 36.2 为什么不直接推倒整条链
|
||
|
||
当前系统已经有稳定的上层编排能力：
|
||
|
||
- `fusion` 负责 `execute / clarify / reject / route_to_cloud`
|
||
- `planner` 负责 `sequence / conditional workflow`
|
||
- `workflow executor` 负责多步执行、条件判断、确认和补槽
|
||
|
||
这些能力并不是 `JointBERT` 能替代的。
|
||
|
||
因此本次升级只替换本地理解层，不重写上层编排层。
|
||
|
||
### 36.3 新架构边界
|
||
|
||
升级后的本地链路定义为：
|
||
|
||
```text
|
||
text
|
||
-> rewrite
|
||
-> Joint NLU
|
||
- intent head
|
||
- slot tagging head
|
||
-> fusion / planner
|
||
-> workflow executor
|
||
```
|
||
|
||
新的职责划分：
|
||
|
||
- `JointBERT`：单句或单 clause 的 intent + slot
|
||
- `multi-intent detector`：整句多标签先验
|
||
- `planner`：多意图、条件句、多步骤 workflow
|
||
- `workflow executor`：补槽、确认、执行、汇总
|
||
|
||
### 36.4 Joint NLU 数据格式
|
||
|
||
新增联合训练数据，采用 span 标注格式：
|
||
|
||
```json
|
||
{
|
||
"text": "把空调调到22度",
|
||
"intent_id": "cabin_set_ac",
|
||
"slots": [
|
||
{"slot_name": "temperature", "value": "22度", "start": 6, "end": 9}
|
||
]
|
||
}
|
||
```
|
||
|
||
说明：
|
||
|
||
- 单条样本只标注一个主意图
|
||
- 多意图句在训练阶段优先拆成 clause 级样本
|
||
- 无槽位意图的 `slots` 为空数组
|
||
- 运行时将 span 转换为 token-level BIO 标签
|
||
|
||
### 36.5 模型结构
|
||
|
||
采用共享编码器的双头结构：
|
||
|
||
- 编码器：`MacBERT`
|
||
- 意图头：句级单标签分类
|
||
- 槽位头：token classification，输出 BIO 标签
|
||
|
||
第一版先不引入复杂的 slot-gate，先保证：
|
||
|
||
- 共享编码器
|
||
- 联合训练
|
||
- 意图与槽位共享语义表征
|
||
|
||
在当前项目里，这已经比“句分类 + 规则抽槽”前进一步。
|
||
|
||
### 36.6 接入方式
|
||
|
||
运行时新增 `JointNLU` 服务，供两处复用：
|
||
|
||
1. `classifier backend = joint_bert`
|
||
- 用联合模型的 intent head 输出意图分数
|
||
2. `slot_extractor backend = joint_bert`
|
||
- 用联合模型的 slot head 输出槽位
|
||
|
||
要求：
|
||
|
||
- 两个 backend 共享同一个模型实例，避免重复冷启动
|
||
- 对同一文本允许做短时预测缓存，避免一次请求重复前向
|
||
- 若联合模型不可用，直接报错或显式 fallback，不继续隐式走旧 heuristic 逻辑
|
||
|
||
### 36.7 与多意图链路的关系
|
||
|
||
`JointBERT` 不直接负责整句多意图 workflow 规划。
|
||
|
||
多意图流程保持：
|
||
|
||
1. `multi-intent detector` 对整句给出多标签先验
|
||
2. `planner` 进行 clause split
|
||
3. 每个 clause 用 `Joint NLU` 做 intent + slot
|
||
4. `planner` 汇总 clause 结果为 workflow
|
||
|
||
这样做的原因：
|
||
|
||
- 经典 JointBERT 更适合单句单意图
|
||
- 当前系统已经有成熟的 clause-level planner 骨架
|
||
- 直接让一个单模型接管整句多步骤规划，风险更高
|
||
|
||
### 36.8 替换原则
|
||
|
||
本次升级的明确原则：
|
||
|
||
- 默认主链路不再依赖 `HeuristicSlotExtractor`
|
||
- planner 内部的 clause slots 也优先改为 `Joint NLU`
|
||
- 原 heuristic 抽槽只保留为测试对照或应急兜底，不再作为主路径
|
||
|
||
### 36.9 验收标准
|
||
|
||
升级完成后至少满足：
|
||
|
||
- 单步任务的槽位抽取来自 `Joint NLU`
|
||
- 缺槽位逻辑、确认逻辑、多步 workflow 逻辑保持兼容
|
||
- `router` 和 `planner` 都能读取联合模型输出
|
||
- 本地常见控制句的槽位抽取精度高于旧 heuristic
|
||
- 冷启动通过 warmup 控制，首轮推理不发生首次懒加载抖动
|