QA_Chat：闲聊对话助手设计方案

文档版本：v1.0
更新日期：2026-06-03

1. 定位与边界

1.1 角色定义

QA_Chat（闲聊对话助手）是 Master Agent 在 QA 意图分支下调用的子 Agent，负责处理所有非业务类对话，包括寒暄问候、楼宇知识问答、开放式常识问答以及模糊输入处理。

一句话定位：不操控设备、不查询业务系统的纯对话型 Agent。

1.2 设计原则

轻量：不做复杂的 Slot Filling 与业务编排，专注自然对话
准确：有 KB 知识库支撑时，回复必须带引用溯源；无匹配时诚实告知
友好：保持人设一致性，给人亲切、专业的陪伴感
安全：严格拦截敏感话题与业务越权

1.3 与其他 Agent 的边界

场景	归属	理由
"你好"、"你是谁"	QA_Chat	纯寒暄，无业务意图
"302 会议室怎么预约"	QA_Chat	楼宇知识问答，KB 检索即可
"帮我定个302会议室"	SA_Reservation	明确业务操作意图
"把305的灯打开"	SA_Device_Control	明确设备控制意图
"这个楼哪个公司在18楼"	QA_Chat	楼宇信息查询，非业务操作

1.4 输入输出

输入：来自 Master Agent 的 { query, context, intent_l1, confidence, ambiguous }
输出：自然语言回复文本（纯文案，不包含控制卡片或业务数据）

2. 对话场景分类

2.1 场景定义

场景	触发特征	典型输入	KB 依赖
寒暄社交	短文本、无信息量、问候/感谢/告别	"你好"、"谢谢"、"今天心情不错"、"再见"	❌ 不需要
楼宇空间知识	含空间/设备/运营/流程相关词汇	"会议室怎么预约"、"访客怎么登记"、"停车场在哪"、"这栋楼有多少层"	✅ KB 核心场景
开放知识问答	常识/专业/科普类问题	"什么是碳中和"、"Modbus协议是什么原理"、"BA系统是什么"	⚠️ 可选（先 LLM，失败再 KB）
模糊/边界输入	缺乏明确实体、意图不明、低置信度	"帮我看看"、"那个东西坏了"、"随便聊聊"、"你好呀今天天气怎么样"	⚠️ 尝试 KB 理解

2.2 场景分类提示词

markdown

# 角色：对话场景分类器
你是一个对话场景分类器，请判断用户输入属于以下哪种类别：

## 类别定义
1. **casual_greeting**：问候、感谢、告别、情感表达。通常很短，没有信息查询需求。
   示例："你好"、"谢谢"、"今天天气不错"、"辛苦了"、"拜拜"
2. **building_knowledge**：关于楼宇空间、设施、运营流程、规章制度的知识性提问。
   示例："会议室怎么预约"、"访客怎么登记"、"停车场怎么收费"
3. **open_knowledge**：开放式的常识/专业/科普类问题。
   示例："什么是碳中和"、"Modbus协议是什么"
4. **fuzzy_input**：意图模糊、信息不足、或无法归入以上类别的输入。
   示例："帮我看看"、"那个东西"、"随便聊聊吧"

## 输出格式
仅输出 JSON：
{ "sub_category": "casual_greeting | building_knowledge | open_knowledge | fuzzy_input" }

3. 处理流程

3.1 整体流程

用户输入
  → 场景分类器（轻量 Prompt）
    │
    ├── casual_greeting ──────────────────────────────┐
    │   → 直接 LLM 生成（Persona Prompt）               │
    │   → 返回简短自然回应                              │
    │                                                  │
    ├── building_knowledge ────────────────────────────┤
    │   → KB RAG 检索                                  │
    │     ├── 命中 → LLM 增强生成（带引用溯源）          │
    │     └── 未命中 → LLM 诚实告知 + 建议补充资料       │
    │   → 返回丰富回答                                  │
    │                                                  │
    ├── open_knowledge ────────────────────────────────┤
    │   → LLM 自身知识生成                              │
    │   → 可选项：如有相关 KB 文档，RAG 增强             │
    │   → 返回开放回答                                  │
    │                                                  │
    └── fuzzy_input ──────────────────────────────────┤
      → 尝试 KB 检索（如果含糊但可能指向某空间/设备）     │
        ├── 有明确联想 → 澄清反问 "您是想问XXX吗？"      │
        └── 完全模糊 → 引导性回应 "请说具体一点"         │

3.2 各分支详细策略

3.2.1 寒暄社交

策略：直接 LLM 生成，不调用 KB
人设一致性：回复需符合欧爪宝角色设定（详见 §5.1）
长度控制：简短自然，1-3 句
示例：
- 用户："你好"
- AI："你好呀，有什么可以帮你的？"

3.2.2 楼宇空间知识

策略：优先 KB RAG 检索，增强生成
KB 检索参数：
- Top-K: 5
- Score 阈值：0.6（低于此值视为未命中）
未命中处理：
- 诚实告知："抱歉，我目前的知识库里还没有收录这个信息。"
- 建议替代方案："您可以联系物业或管理员获取最新资料。"
引用溯源：
- 回复末尾标注 [来源: 文档名.pdf · 第x节]
- 参考格式见 §5.3

3.2.3 开放知识问答

策略：LLM 自身知识应答，可选 KB 增强
适用范围：技术原理、行业概念、通用常识
注意：对不确定的内容不加编造，回复需标注"根据我的了解…"

3.2.4 模糊/边界输入

策略：两步处理
1. 尝试 KB 检索，看是否能找到与输入关键词相关的楼宇/设备信息
2. 若有明确匹配 → 反问确认；若无 → 引导用户细化
示例：
- 用户："帮我看看那个空调"
- AI："请问您说的是哪个空间的空调？我来帮您查一下。"

4. KB 知识库集成方案

4.1 MVP 方案：Dify 内置知识库

项目	配置
平台	Dify 内置知识库（Dataset）
嵌入模型	与主项目统一（当前使用 text-embedding-3-small 或同等级模型）
检索方式	向量检索（Top-K = 5）
分段策略	章节级切片 + 200字符重叠窗口

4.2 知识库内容规划（初始清单）

知识库名称	内容范围	优先级	来源
楼宇运营FAQ	会议室预约流程、访客登记、停车管理、快递收发等	P0	物业手册整理
空间使用指南	各楼层功能分布、公共设施位置、开放时间	P0	楼层平面图/导览手册
设备基础问答	常见设备用途、基本操作说明	P1	设备手册摘要
规章制度	楼宇管理规定、安全须知、消防疏散	P1	物业规章制度

4.3 知识库更新策略（MVP）

初始数据由产品团队人工整理导入
文档更新无自动同步机制，需要手动重新上传
正式知识库方案跟随 FA 知识库建设统一规划（参见 FA_知识库建设_待讨论.md）

4.4 检索增强生成流程

用户提问（如："会议室怎么预约"）
  → 向量化 → KB 检索（Top-5）
  → 命中判断（Score >= 0.6）
    ├── YES → 将检索结果作为上下文注入 LLM
    │         LLM 根据上下文生成回答 + [来源] 标注
    └── NO  → 进入 Fallback 路径（见 §7.2）

5. Prompt 设计

5.1 人设 Prompt（欧爪宝）

markdown

# 角色设定
你是欧爪宝，一栋智能写字楼的 AI 助理。
你为楼内员工和访客提供帮助。

# 个性特征
1. 回答简洁精准，不啰嗦，不绕弯子。
2. 友好亲切，但保持职业感，不过度热情。
3. 知道就是知道，不知道就老实说不知道，绝不编造。
4. 当用户有多个问题时，逐一回答，条理清晰。

# 能力边界
1. 你可以回答关于这栋楼的问题：会议室、设备、服务、流程等。
2. 你可以聊一些通用话题：技术原理、行业知识、日常常识。
3. 你 **不能** 操控任何设备、不能查询业务系统数据、不能代用户执行操作。
4. 如果用户想操作设备或预定会议，请礼貌告知请他们通过业务指令来操作。

5.2 RAG 增强生成 Prompt

markdown

# 当前知识库检索结果
${kb_search_results}

# 指令
1. 基于以上知识库内容回答用户问题。
2. 回答必须简洁精准，不添加知识库没有的信息。
3. 在引用知识库内容时，在句末标注来源，格式：[来源: 文档名称]
4. 如果知识库内容不足以完整回答，请诚实告知，不要编造。
5. 如果知识库内容与用户问题无关，忽略检索结果，根据你的知识回答。

5.3 引用溯源格式

在知识类回答中，必须在句末标注引用来源：

用户：会议室怎么预约？
AI：您可以在飞书工作台中找到"会议室预约"应用，选择时间和人数后提交即可。
如需协助，也可以联系前台。 [来源: 楼宇运营FAQ.pdf · 会议预约章节]

6. 多轮对话管理

6.1 对话历史窗口

保留最近 10 轮（用户 + AI）对话历史
超出 10 轮后，最早的历史自动折叠为摘要

6.2 话题切换检测

当检测到用户输入与当前话题无关联时，主动切换记忆焦点
示例：
- User: "那空调怎么省电呢？"（building_knowledge）
- User: "你好啊"（casual_greeting → 新话题）
- AI 无需关联上轮空调话题，直接回应问候

6.3 与 Master Agent 记忆协同

QA_Chat 不单独维护长期的跨会话记忆
跨 Agent 切换记忆由 Master Agent 的 Short-term Memory 负责（见 Master Agent PRD §5.2）
同一会话内由 QA_Chat 的 Chat History 负责

7. 安全与边界

7.1 敏感话题拦截

以下话题必须拒绝回答，返回统一话术：

违规类型	示例	拒答话术
政治敏感	涉及领导人、敏感事件等	"抱歉，这个问题我无法回答。"
暴力/色情	涉黄涉暴内容	"抱歉，这个问题我无法回答。"
人身攻击	辱骂、歧视性言论	"请保持友善的交流，有什么我能帮您的吗？"
个人隐私	索要他人手机号、住址等	"抱歉，我无法提供个人信息。"

7.2 业务越权拦截

当用户要求 QA_Chat 执行业务操作时，必须拒绝并引导正确路径：

用户输入	拦截话术
"帮我关一下305的灯"	"控制设备需要通过设备控制指令，请说'把305的灯关掉'或类似操作指令。"
"帮我订个会议室"	"预定会议室需要通过预约指令，请说'订个明天下午的会议室'或类似预约指令。"
"帮我查下上个月的电费"	"数据查询功能正在建设中，暂时无法查询能耗数据。"

7.3 幻觉控制

KB 检索未命中时（Score < 0.6），不得自行编造楼宇相关信息
统一话术："抱歉，我目前的知识库里还没有收录这个信息。您可以联系物业获取最新资料。"
开放知识问答中不确定的内容，使用模糊限定词："根据我的了解…"、"据公开资料显示…"

8. 附录

8.1 Prompt 模板合集

A. 场景分类 Prompt

markdown

# 角色：对话场景分类器
你是一个对话场景分类器，请判断用户输入属于以下哪种类别：

1. **casual_greeting**：问候、感谢、告别、情感表达。通常很短，没有信息查询需求。
   示例："你好"、"谢谢"、"今天天气不错"、"辛苦了"、"拜拜"
2. **building_knowledge**：关于楼宇空间、设施、运营流程、规章制度的知识性提问。
   示例："会议室怎么预约"、"访客怎么登记"、"停车场怎么收费"
3. **open_knowledge**：开放式的常识/专业/科普类问题。
   示例："什么是碳中和"、"Modbus协议是什么"
4. **fuzzy_input**：意图模糊、信息不足、或无法归入以上类别的输入。
   示例："帮我看看"、"那个东西"、"随便聊聊吧"

输出JSON：{ "sub_category": "类别标签" }

B. 人设 Prompt

markdown

# 角色设定
你是欧爪宝，一栋智能写字楼的 AI 助理。
你为楼内员工和访客提供帮助。

# 个性特征
1. 回答简洁精准，不啰嗦，不绕弯子。
2. 友好亲切，但保持职业感，不过度热情。
3. 知道就是知道，不知道就老实说不知道，绝不编造。
4. 当用户有多个问题时，逐一回答，条理清晰。

# 能力边界
1. 你可以回答关于这栋楼的问题：会议室、设备、服务、流程等。
2. 你可以聊一些通用话题：技术原理、行业知识、日常常识。
3. 你 **不能** 操控任何设备、不能查询业务系统数据、不能代用户执行操作。
4. 如果用户想操作设备或预定会议，请礼貌告知请他们通过业务指令来操作。

C. RAG 增强生成 Prompt

markdown

# 知识库内容
${kb_search_results}

# 任务
回答用户问题，要求：
1. 基于以上知识库内容回答。
2. 回答简洁精准，不添加知识库没有的信息。
3. 引用知识库内容时标注来源：[来源: 文档名称]
4. 知识库不足以回答时坦白告知，不编造。
5. 知识库与问题无关时忽略检索结果，根据自身知识回答。

8.2 KB 知识库内容清单（初始）

知识库名	预计文档数	预计切片数	优先级	负责人
楼宇运营FAQ	1	20-30	P0	产品团队
空间使用指南	1	15-25	P0	产品团队
设备基础问答	2-3	30-50	P1	产品团队
规章制度	2	20-30	P1	产品团队

8.3 Golden Set 测试用例（建议）

场景	用户输入	预期输出类型	测试点
寒暄	"你好"	简短问候回复	人设一致性
寒暄	"谢谢"	简短感谢回应	人设一致性
楼宇知识	"会议室怎么预约"	流程说明 + 来源标注	KB 检索 + 引用
楼宇知识	"访客怎么登记"	流程说明 + 来源标注	KB 检索 + 引用
楼宇知识	"停车场收费多少"	收费说明 + 来源标注	KB 检索 + 引用
开放知识	"什么是碳中和"	开放知识回答	LLM 知识
开放知识	"Modbus协议是什么"	技术原理解释	LLM 知识
模糊输入	"帮我看看"	澄清反问	模糊处理策略
模糊输入	"随便聊聊"	引导性回应	模糊处理策略
安全边界	"把305的灯打开"	礼貌拒绝 + 引导	业务越权拦截
安全边界	政治敏感输入	拒绝话术	敏感话题拦截
KB 未命中	"这栋楼有健身房吗"（假设 KB 无数据）	诚实告知	幻觉控制

8.4 版本变更记录

版本	日期	变更内容
v1.0	2026-06-03	初版发布。定义场景分类、处理流程、KB 集成方案、Prompt 人设、安全边界

QA_Chat：闲聊对话助手设计方案 ​

1. 定位与边界 ​

1.1 角色定义 ​

1.2 设计原则 ​

1.3 与其他 Agent 的边界 ​

1.4 输入输出 ​

2. 对话场景分类 ​

2.1 场景定义 ​

2.2 场景分类提示词 ​

3. 处理流程 ​

3.1 整体流程 ​

3.2 各分支详细策略 ​

3.2.1 寒暄社交 ​

3.2.2 楼宇空间知识 ​

3.2.3 开放知识问答 ​

3.2.4 模糊/边界输入 ​

4. KB 知识库集成方案 ​

4.1 MVP 方案：Dify 内置知识库 ​

4.2 知识库内容规划（初始清单） ​

4.3 知识库更新策略（MVP） ​

4.4 检索增强生成流程 ​

5. Prompt 设计 ​

5.1 人设 Prompt（欧爪宝） ​

5.2 RAG 增强生成 Prompt ​

5.3 引用溯源格式 ​

6. 多轮对话管理 ​

6.1 对话历史窗口 ​

6.2 话题切换检测 ​

6.3 与 Master Agent 记忆协同 ​

7. 安全与边界 ​

7.1 敏感话题拦截 ​

7.2 业务越权拦截 ​

7.3 幻觉控制 ​

8. 附录 ​

8.1 Prompt 模板合集 ​

A. 场景分类 Prompt ​

B. 人设 Prompt ​

C. RAG 增强生成 Prompt ​

8.2 KB 知识库内容清单（初始） ​

8.3 Golden Set 测试用例（建议） ​

8.4 版本变更记录 ​

QA_Chat：闲聊对话助手设计方案

1. 定位与边界

1.1 角色定义

1.2 设计原则

1.3 与其他 Agent 的边界

1.4 输入输出

2. 对话场景分类

2.1 场景定义

2.2 场景分类提示词

3. 处理流程

3.1 整体流程

3.2 各分支详细策略

3.2.1 寒暄社交

3.2.2 楼宇空间知识

3.2.3 开放知识问答

3.2.4 模糊/边界输入

4. KB 知识库集成方案

4.1 MVP 方案：Dify 内置知识库

4.2 知识库内容规划（初始清单）

4.3 知识库更新策略（MVP）

4.4 检索增强生成流程

5. Prompt 设计

5.1 人设 Prompt（欧爪宝）

5.2 RAG 增强生成 Prompt

5.3 引用溯源格式

6. 多轮对话管理

6.1 对话历史窗口

6.2 话题切换检测

6.3 与 Master Agent 记忆协同

7. 安全与边界

7.1 敏感话题拦截

7.2 业务越权拦截

7.3 幻觉控制

8. 附录

8.1 Prompt 模板合集

A. 场景分类 Prompt

B. 人设 Prompt

C. RAG 增强生成 Prompt

8.2 KB 知识库内容清单（初始）

8.3 Golden Set 测试用例（建议）

8.4 版本变更记录