**摘要**：OpenAI 设计负责人说"聊天框不会是终极界面"，YC 总裁说把成功工作沉淀为 Markdown 技能文件能让流程可重复。这两句话放到客服场景里，指向同一件事：客服从问答框，走向有知识边界、有治理的工作流。本文依据福昕智能 AI 客服的技术设计文档，拆它的知识库隔离、Prompt 三层治理、四类意图编排，以及 Widget 前台入口与差评回流闭环。

---

## 一、聊天框不是终点

聊天框是入口，不是能力本身。把客服做成"一个框 + 一个模型"，会很快撞到边界：答非所问、口径漂移、个人数据乱用。要往前走，得给对话加上知识边界和治理。

### 从问答框到带治理的工作流

设计文档把客服定义为一套平台：多租户站点接入、可治理知识库、可控 Prompt、多模型路由、Data Hub 个人数据接入、Widget SDK、运营活动推荐、管理端闭环。聊天框只是入口那一截，后面是一整套治理在支撑。

### 知识库 + Prompt 就是客服场景的技能文件

YC 说的"把成功工作沉淀为 Markdown 技能文件"，在客服里对应的就是知识库 + Prompt 治理。知识库决定"客服知道什么"，Prompt 决定"客服怎么说话、守什么边界"。两者按站点沉淀、可版本、可审计，正好是把经验变成可复用资产的方式。

## 二、知识库按站点隔离的 RAG

知识库不是一股脑塞进一个向量库，而是按站点隔离。

### 分类方案与 Collection 命名

知识库分类采用"系统预置分类方案 + 租户默认 + 站点覆盖"。预置方案如 ecommerce_cs（商品、订单、售后、优惠、会员权益）、internal_policy（制度、流程、材料清单）。向量 collection 按站点生成，命名格式固定：

```text
{站点 collection 命名}
格式：  {siteId}__cs-{category}
示例：  site_zhixuan__cs-product
        site_zhixuan__cs-faq
        site_zhixuan__cs-marketing
```

隔离规则很硬：AI CS 主会话只读取当前站点的 collection；空 collection 不再 fallback 到全局 cs-product；AI Service 对 `ai-cs` caller 只允许读站点 collection 格式；`ai-cs-admin` 可管理站点知识库，但不能访问内部 NL2SQL schema；普通 `ai-assistant` 不能读 AI CS 站点 collection。

### 文档到向量的处理流程

知识从上传到可用，是一条异步链路，状态可观测：

```mermaid
flowchart LR
    A[管理员上传文档 / 新增 FAQ] --> B[Workbench 写 knowledge_docs 元数据]
    B --> C[POST /v1/knowledge/documents]
    C --> D[AI Service 创建异步任务]
    D --> E[文档解析 / 分块 / 清洗]
    E --> F[写入向量 collection]
    F --> G[状态 processing / done / failed]
```

Workbench 负责写元数据并触发任务，AI Service 做解析、分块、清洗并写入 Chroma，状态回传 processing / done / failed，管理端能看到向量化进度。

## 三、Prompt 三层治理

Prompt 不是写在代码里的一行 system prompt，而是三层治理。

### 系统预置 / 模板库 / 生效快照

| 层级          | 说明                                  | 是否直接线上生效 |
| ------------- | ------------------------------------- | ---------------- |
| 系统预置库    | 随代码交付的默认模板，管理端只读展示  | 无快照时作为兜底 |
| Prompt 模板库 | Workbench 管理，用于复用、审计、版本  | 不直接生效       |
| 生效快照      | 写入租户或站点的 promptTemplate* 字段 | 直接影响运行时   |

模板覆盖对话口径、人设、安全边界、业务规则。编排界面同时服务技术治理和产品运营：技术侧关注变量、准入和安全底座，产品侧关注场景、话术风格和站点覆盖。

### 主 RAG 模板的解析优先级

运行时拼主 RAG System Prompt，按固定优先级取快照，且主 RAG 模板必须保留 `{context}`，否则运行时不使用该模板：

```text
主 RAG Prompt 解析优先级：
1. 站点开启 Prompt 覆盖且模板含 {context} ？ -> 用站点 promptTemplate 快照
2. 否则租户默认模板含 {context} ？          -> 用租户 promptTemplate 快照
3. 否则按 promptScene 用系统内置模板
（平台安全规则由运行时拼接，站点/租户模板不能删除平台安全基座）
```

可用变量包括 `{context}`、`{aiPersonaName}`、`{serviceScope}`、`{aiPersonaIntro}`、`{aiDialogStyle}`、`{siteName}`；personal_query 另有专属模板字段 `personalQueryPromptTemplate*`，必须含 `{personal_context}`。

## 四、四类意图走到不同编排

同样的聊天框，背后是四类意图在分流。

### knowledge / personal_query / complain / chat

scrm-ai-cs 通过 AI Service 判断意图，四类各走各的编排：knowledge 走 RAG 与常规模型，personal_query 走本地模型与 Data Hub 个人数据，complain 走敏感模型与脱敏，chat 走常规模型。路由编排把"意图 → 模型档位 + Prompt"固定下来，而不是每次临时拼。

### personal_query 的专属 Prompt 与数据链路

personal_query 回答"我的订单、会员、积分、退款"，需要真实结构化数据，不靠知识库。它用独立模板字段，必须包含 `{personal_context}`：

```text
personal_query Prompt 可用变量：
  {personal_context}   结构化个人数据上下文（来自 Data Hub 标准 CustomerSummary）
  {query}              用户原始问题
  {aiPersonaName} {serviceScope} {aiPersonaIntro} {aiDialogStyle} {siteName}
```

数据链路是：Widget 带 accessToken 建会话 → scrm-ai-cs 调 Data Hub `identity/resolve` 解析 userId → 调 `customer/summary` 取标准客户摘要 → 连同 `{personal_context}` 交给 AI Service 的 personal_query，由本地模型生成回答。Widget 只透传 accessToken，不直接连业务系统；AI CS 也不直连租户业务库，统一走 Data Hub。

## 五、Widget 前台入口与知识闭环

治理最终要在前台被用户摸到，也要能从反馈里回流。

### 会话恢复 / 身份透传 / 主动触达

scrm-ai-cs-widget 是前台入口，能力不止收发消息：会话 ID 存在 localStorage（key 为 `scrm_sid_{siteId}`）实现会话恢复；默认读 cookie `accessToken`，也支持 `data-identity-type="localStorage"` 从 localStorage 取；SSE 支持 `delta` / `done` / `error` / `sources` / `recommend`。它还暴露全局 API 支撑主动触达与浏览打点：

```javascript
window.ScrmWidget.open('我想了解会员权益');   // 主动打开客服窗口并带入问题
window.ScrmWidget.close();
window.ScrmWidget.isOpen();
window.ScrmWidget.trackPageView({           // 补充页面浏览上下文，用于主动触达与推荐
  page: '/product/123',
  title: '年度会员',
  category: 'membership'
});
```

浏览上下文、活动关键词和营销知识库共同决定主动触达与 recommend 事件的质量。

### 差评沉淀 FAQ 的闭环

闭环的最后一环在管理端：差评审核页汇总 bad 反馈或低分内容，审核通过后能把差评问题一键创建为 FAQ，进入知识库治理闭环。一次答错不被丢掉，而是变成下次的已知答案。配合运营活动页面，营销素材进 `cs-marketing` collection，既支撑对话内推荐，也支撑 Widget 主动触达。

## 六、配置与排查

知识库和 Prompt 配置是可观测、可回退的，出问题有迹可循。

### 知识 / Prompt 配置排查表

| 现象                    | 先查这里                                                                                       |
| ----------------------- | ---------------------------------------------------------------------------------------------- |
| 搜不到刚上传的文档      | 向量化状态是否 done；collection 是否当前站点 `{siteId}__cs-*`                                |
| 回答脱离站点知识        | AI CS 主会话是否只读当前站点 collection；空 collection 是否误 fallback                         |
| Prompt 改动不生效       | 是否写入生效快照 promptTemplate*；主 RAG 模板是否保留 `{context}`                            |
| personal_query 答非所问 | Data Hub `identity/resolve` / `customer/summary` 是否通；模板是否含 `{personal_context}` |
| 差评没进知识库          | 差评审核页是否审核并一键创建 FAQ；collection 是否重新向量化                                    |

### 一张对照表：知识库与 Prompt 的治理关系

| 维度     | 知识库                                 | Prompt                           |
| -------- | -------------------------------------- | -------------------------------- |
| 解决什么 | 客服知道什么（RAG 检索）               | 客服怎么说话、守什么边界         |
| 隔离单位 | `{siteId}__cs-{category}` collection | 租户 / 站点 promptTemplate* 快照 |
| 管理方式 | Workbench 上传、向量化、上下线         | 系统预置 + 模板库 + 生效快照     |
| 闭环入口 | 文档/FAQ → 向量 → 检索               | 差评一键沉淀 FAQ 回流            |

---

## FAQ

**聊天框不是终点，那终点是什么？**
终点是一套带知识边界和治理的工作流：知识库决定知道什么，Prompt 决定怎么说话守边界，意图路由决定走哪条编排，差评再回流成知识。

**知识库为什么按站点隔离而不共用？**
共用会让 A 站点的知识跑到 B 站点回答里。按 `{siteId}__cs-{category}` collection 隔离，AI CS 主会话只读当前站点，空 collection 也不 fallback 全局。

**Prompt 三层治理哪层真正生效？**
生效快照——写入租户或站点的 promptTemplate* 字段那层。系统预置库只在无快照时兜底，模板库只用于复用和审计，不直接生效。

**personal_query 和普通问答有什么区别？**
它回答"我的订单/会员/积分"，靠 Data Hub 取真实结构化数据，用必须含 `{personal_context}` 的专属模板，走本地模型，不依赖知识库。

**Widget 除了聊天还能做什么？**
会话恢复、登录态 token 透传、SSE 展示、留言评价、主动触达和浏览打点；`window.ScrmWidget` 还能主动打开窗口、trackPageView 补上下文。

**差评怎么变成知识？**
差评审核页汇总低分内容，审核通过后可一键创建为 FAQ，进入知识库并重新向量化，形成"答错→沉淀→下次答对"的闭环。

**主 RAG 模板为什么必须保留 {context}？**
`{context}` 是 RAG 检索结果占位符。模板不含它，运行时会判定该模板不可用，转而去取租户或系统兜底模板。

---

## 结语

聊天框是客服的起点，不是它的全部。把知识库隔离、Prompt 治理、意图编排和差评回流串起来，客服才从"一个会聊天的框"变成"一套可治理、可复用、能自我修正的工作流"。要评估自家的客服怎么走知识闭环，可联系福昕技术对接人按站点梳理知识分类、Prompt 快照与差评回流方案。

---

**标签**：AI 客服知识库、Prompt 治理、RAG、意图编排、知识闭环、Widget SDK、福昕智能 AI 客服

摘要：OpenAI 设计负责人说"聊天框不会是终极界面"，YC 总裁说把成功工作沉淀为 Markdown 技能文件能让流程可重复。这两句话放到客服场景里，指向同一件事：客服从问答框，走向有知识边界、有治理的工作流。本文依据福昕智能 AI 客服的技术设计文档，拆它的知识库隔离、Prompt 三层治理、四类意图编排，以及 Widget 前台入口与差评回流闭环。

聊天框不是终点：AI 客服的知识闭环怎么走？

客服从问答框，走向有知识边界、有治理的工作流。本文依据福昕智能 AI 客服的技术设计文档，拆它的知识库隔离、Prompt 三层治理、四类意图编排，以及 Widget 前台入口与差评回流闭环。

人工智能

架构设计

运维

福昕智能AI客服系统通过知识库按站点隔离、Prompt三层治理、四类意图编排及差评回流闭环，将客服从单一聊天框升级为可治理的工作流。支持多租户接入、个人数据安全调用及Widget主动触达，确保回答精准、流程可审计，并持续沉淀知识资产。

结构化数据

代码解释

路由

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

聊天框不是终点：AI 客服的知识闭环怎么走？-腾讯云开发者社区-腾讯云

聊天框不是终点：AI 客服的知识闭环怎么走？

聊天框不是终点：AI 客服的知识闭环怎么走？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐