知识中心：从资料到 AI 成员的完整闭环
知识中心是平台统一的知识生产、治理与发布入口。它面向销售、客服和系统帮助等业务场景：业务同学按自己的业务逻辑维护内容，平台再把已审核的知识投影给 V2 Agent 使用。
它不是另一个独立的 FAQ 库或 RAG 配置页。FAQ、RAG、MCP 服务（实时查询）都是知识发布后的消费去向；知识的主维护位置始终是知识空间。
一、先理解三个层次
资料来源
→ 知识空间：整理、审核、补齐业务知识
→ 发布版本：冻结本次可用内容
→ 投影与绑定：精准问答 / RAG / 导航与实时查询 / V2 Agent
| 层次 | 解决的问题 | 主要使用者 |
|---|---|---|
| 资料来源 | 内容从哪里来、发生了什么变化 | 文档维护人、系统管理员 |
| 知识空间 | 应该准备哪些知识、谁审核、哪些内容缺失 | 业务负责人、客服负责人 |
| 发布与消费 | 哪个版本被哪个 AI 成员使用 | 知识负责人、AI 成员管理员 |
一条资料可以来自网页、文件、Markdown、团队素材、现有问答库、外部 API 或系统菜单。资料进入空间后会成为有类型、可审核、可追踪来源的知识条目；只有通过审核并进入发布版本的内容，才可以进入线上 Agent 的知识资源。
二、知识中心的一级菜单
知识中心按工作顺序分为三组：
| 菜单组 | 页面 | 用途 |
|---|---|---|
| 一、采集来源 | 文档加工 | 上传文件、抓取网页、录入 Markdown 或导入对话记录，先生成待审核知识。 |
| 团队素材 | 管理图片、视频、文件等可复用素材；需要时关联到知识条目或对话交付物。 | |
| 二、加工与发布 | 知识空间 | 选择业务类型、维护知识、审核、补别名、管理来源、发布版本和 Agent 消费绑定。 |
| 三、投影去向 | 精准问答库 | 查看已发布的标准问答投影；旧库可保留查看，但不应成为新的主维护入口。 |
| RAG 连接 | 配置组织的 RAG 连接与数据集，查看发布版本的 RAG 投影。 | |
| MCP 服务（在「AI 团队」菜单下） | 配置 MCP 服务及其工具，供知识声明的实时查询能力调用。 |
日常操作应从“资料来源”或“知识空间”开始，而不是直接修改精准问答库或 RAG 数据集。
三、先选业务类型，再按业务分类准备知识
知识中心内部使用通用知识类型保证发布与运行一致；页面对业务同学展示的是业务分类和模板。创建空间时应选择最接近业务的类型，例如：
- 软件系统客服：介绍系统功能、给出页面入口、指导操作、解释权限与排查问题；
- 电商客服：商品、库存、物流、售后、优惠、服务规则；
- 知识付费或课程客服：课程介绍、学习路径、权益、内容访问、退款与服务边界；
- 销售知识空间：产品方案、客户案例、报价政策、异议处理、线索推进资料。
业务类型决定首页应检查哪些类别，而不改变 V2 Agent 的运行边界。这样业务人员不必先理解“问答型、文档型、数据型”，仍能知道该准备什么；运行时再按知识条目的结构决定是否适合精准问答、RAG、导航或实时查询。
软件系统客服：系统介绍应放什么
“系统介绍”不是功能清单，也不是技术架构文档。它是一份给客户或一线客服使用的统一产品说明，用来稳定回答“这是什么系统、适合谁、能解决什么问题”。建议以一份产品 / 服务介绍作为主文档，至少写清：
- 系统定位与目标用户；
- 客户能获得的核心价值；
- 主要能力与典型使用场景；
- 适用范围与暂不支持的边界。
可以再附用户帮助总览、产品截图、演示视频或预约演示链接。价格、权限、套餐、配额和会变化的承诺，要单独放到“规则与边界”；某项功能具体怎么操作，要放到“操作指南”；内部数据库、部署、密钥和研发设计不应导入系统介绍。
在“系统介绍”页签点击从文档补充，可上传 PDF、PPT、Word、Markdown 等资料或抓取公开产品页。文档解析后选择目标空间和“系统介绍 / 参考资料”，同步为待审核知识；审核通过、进入 Release 并完成 RAG 投影后，才会被绑定的 Agent 使用。
同一种运行类型可以归入不同业务分类。例如电商的“售后规则”和“优惠活动规则”都可能是规则型知识。新建或编辑时请选择“业务分类”；它只影响维护、覆盖度和待办，不改变 Agent 的 FAQ/RAG/MCP 使用方式。没有明确分类的存量知识仅在类型唯一归属时自动分类；存在歧义时会显示为“待分类”，由业务负责人确认。
软件系统客服应准备的知识
| 分类 | 回答什么 | 推荐内容 |
|---|---|---|
| 系统/产品介绍 | 系统是什么、适合谁 | 产品定位、目标用户、核心能力、边界。 |
| 功能与入口 | 这个功能在哪、能做什么 | 功能名称、功能 ID、菜单路径、页面链接、权限前提、链接卡。 |
| 操作指南 | 具体怎么做 | 前置条件、分步操作、截图或视频、完成标准、常见卡点。 |
| 标准问答 | 明确规则是什么 | 标准问题、唯一口径、相似问法、关联功能。 |
| 故障排查 | 为什么不能用、怎么恢复 | 现象、原因、检查步骤、解决方案、何时转人工。 |
| 规则与边界 | 谁能用、是否收费、有什么限制 | 权限、套餐、限额、兼容性、不能承诺的事项。 |
| 实时数据与字典 | 当前值或可查询事实是什么 | 错误码、状态码、产品/订单等数据集定义，以及对应 MCP 查询说明。 |
建议以功能 ID作为贯穿主键：一个功能关联其介绍、入口链接、操作步骤、FAQ、权限规则和排错信息。这样 AI 在解释功能后，能自然继续给出“去哪里操作”和“下一步怎么做”。
做门店招聘（服务员、后厨等到店面试岗位）的，可以直接参考门店招聘知识模版，里面有九类知识的写法，模版还自带可以直接导入的基础内容。
做售后答疑（客户买了之后问怎么用、怎么退、坏了怎么办）的，参考通用客服（售后）知识模版，七类知识和转专员的写法都在里面。
做售前接待（客户来咨询、要资料、约演示）的，参考通用售前客服知识模版，里面写了什么时候留资、什么时候预约、什么不算同意。
给自己的应用系统（Web 后台、小程序、App）配客服的，参考应用系统客服知识模版，功能入口怎么按端写、哪些内容可以从系统直接导出都在里面。
四、知识空间里的日常工作
1. 建立空间并选择业务类型
一个知识空间是资料隔离、审核与发布的边界。为一个系统客服、一个电商店铺、一个课程产品或一个销售团队建立独立空间；不要把彼此无关的业务资料混放。
「知识空间」菜单打开的是空间列表：每行显示业务类型、知识条数、待审条数、绑定的 AI 成员和是否已生效，可以搜索和翻页；新建空间也在这一层。点进某个空间才是它的工作台，录入、审核、发布都在里面完成，地址形如 /knowledge-center/spaces/24，可以直接收藏或分享给同事。
2. 接入或新建来源
- 系统菜单/功能清单：适合自动生成“功能与入口”知识，来源系统更新后可再次同步并查看差异。
- 帮助文档、网页、文件、Markdown：适合生成操作指南、产品介绍和长文依据；导入后先检查解析结果。
- 团队素材：适合保存需要在回答中交付的截图、视频、附件或案例资料。
- 外部 API / 系统数据：适合同步稳定资料；实时变化的数据不应复制为静态答案，应声明为实时查询。
- 空间内维护：适合补充一条标准问答、规则、故障排查或临时说明。
来源只负责提供内容和变更。来源导入不会直接改变 Agent，必须在空间内完成审核和发布。
3. 审核、补别名和关联
审核时重点检查：
- 内容是否正确、是否适用于当前业务空间；
- 标准问答是否只有一个明确答案，避免把长篇操作手册写进短答；
- 是否补齐用户常用说法、别名和关联主题；
- 是否有正确的功能入口、附件或链接卡；
- 是否标注权限、渠道、适用人群与转人工边界。
来源自动同步的内容在本地编辑后会标记为“本地接管”。此后来源同步不会覆盖它；需要继续让来源自动更新时，应在来源侧修正后重新导入，而不是长期混用两种维护方式。
4. 发布给 AI 成员
发布是不可变的版本动作，建议按以下顺序进行：
- 确认需要上线的条目已审核；
- 确认岗位策略满足发布条件；
- 创建 Release，查看冻结的条目与策略版本；
- 按需要投影到精准问答、RAG、导航目录和实时查询说明；
- 运行投影完整性验证；
- 在“Agent 消费绑定”确认目标 V2 Agent，并激活该 Release；
- 用“试问”和真实渠道对话验证答案、链接和卡片展示。
发布后仍要在投影页检查实际消费状态。知识中心是事实源；精准问答库、RAG 连接和 MCP 服务是该事实源的受控投影或运行连接。
五、FAQ、RAG 和 MCP 分别怎么用
| 能力 | 最适合的内容 | AI 的使用方式 |
|---|---|---|
| 精准问答 | 权限、价格、支持范围、固定规则等必须统一口径的问题 | 高置信命中后直接使用标准答案。 |
| RAG | 操作手册、产品介绍、长文说明、政策细节 | 召回内容片段作为回答依据，适合解释和分步指导。 |
| 导航与链接卡 | 页面入口、菜单路径、附件、截图、视频 | 在 Web/App/渠道中以可点击链接卡或兼容形式交付。 |
| MCP 实时查询 | 错误码、库存、订单状态等会变化或结构化的数据 | 在已声明、已绑定并通过授权的前提下查询；不能把实时事实硬写成静态知识。 |
同一个事实应有一个主维护位置：固定短答优先放标准问答；长步骤放操作指南/RAG；持续变化的数据放实时查询。这样更新时不会出现改了一处、另一处仍是旧内容的问题。
六、客服知识的质量闭环
知识中心首页会把需要处理的事情转成待办：
- 未答上的问题：从真实用户原话补写知识，必要时转为标准问答、操作指南或故障排查；
- 待审核草稿：审核前不会进入发布版本；
- 待复核或未排复核期：为规则、政策和易变化内容安排负责人及复核日期；
- 从未被用到：优先检查别名、用户问法、投影、Agent 绑定和统计周期，不要直接删除内容；
- 类别偏薄或缺必备：按业务类型补齐缺少的知识类别，而不是只增加零散 FAQ。
客服与销售的检索策略不同：客服强调权威、可解释和边界清晰；销售可更多使用方案、案例和推荐内容。它们可复用同一知识中心，但应由不同岗位策略、阈值、推荐问题和 Agent 绑定来消费。
七、软件系统客服的最小可上线清单
上线一个软件系统客服前，至少准备：
- 已同步且可访问的功能/页面入口；
- 覆盖高频问题的标准问答及相似问法；
- 核心功能的操作指南和链接卡；
- 权限、套餐、限制和转人工边界；
- 常见报错与错误码的排查路径；
- 已验证的 FAQ、RAG 与 MCP 投影；
- 已绑定的 V2 Agent 和至少一条渠道测试记录。
如果用户问“某功能在哪里”，系统应给出页面链接卡；问“怎么操作”，应给出步骤和必要的素材；问“为什么用不了”，应先解释权限或排查路径；遇到实时数据问题，才调用受控的 MCP 查询。
八、推荐维护节奏
| 节奏 | 要做的事 |
|---|---|
| 每次系统发布 | 同步菜单、接口或文档来源，查看差异，补齐受影响的知识，审核后发布新 Release。 |
| 每周 | 处理未答问题、检查低命中或从未使用内容，补充别名与推荐问题。 |
| 每月或按内容时效 | 复核政策、权限、价格、错误码与外部数据说明。 |
| 每次 Agent 调整 | 核对 Agent 消费绑定、FAQ/RAG/MCP 实际资源，并重新跑关键场景验证。 |
知识中心的目标不是堆积文档，而是让每一条业务知识都有清晰来源、负责人、审核状态、发布版本和实际消费去向。