# 智能客服产品方案
让客服回答有依据，让知识更新有流程，让复杂问题有可追踪的处理过程。
企业通常不缺文档，而是缺少一条从「谁维护、何时生效」到「回答引用了哪一版」的可信链路。G2rain 以知识库为事实来源，结合对话入口、Agent 执行与平台权限，为产品咨询、客户支持和内部服务台提供可逐步落地的智能客服方案。
体验知识对话 (opens new window) · 查看平台演示 (opens new window) · 联系维护者
本页既介绍当前已发布的知识服务能力，也说明 Agent 协作的方案边界。演示页面和各仓库的发布状态不能替代目标环境中的跨服务联调与业务验收。
# 适合哪些服务场景
| 场景 | 常见问题 | 方案中的处理方式 |
|---|---|---|
| 产品与政策咨询 | 功能怎么用？当前版本的规则是什么？ | 从已发布的产品手册、政策文件与 FAQ 检索证据，回答时呈现来源；更新须经过版本发布。 |
| 客户上手与使用支持 | 如何创建账号、开通功能、完成配置？ | 将操作指南和高频问答纳入知识库，按主题组织，持续根据提问补充内容。 |
| 内部服务台 | 员工在不同部门反复询问流程和规范。 | 按组织、岗位与业务权限管理知识和入口，避免把内部资料作为公开答案。 |
| 多步骤问题处理 | 单条知识不足以完成排查，需要查询系统状态或执行工具。 | 在已授权、已注册的工具范围内，由 Agent 组织步骤、返回进度并留下执行记录；具体业务工具需按场景接入。 |
它更适合有持续变化的知识、需要追溯答案依据、或需要区分组织和岗位访问范围的团队。若仅需一个固定 FAQ 页面，可以先从知识整理与问答试点开始，不必一次引入所有 Agent 模块。
# 从问题到结果：两条工作路径
# 路径一：基于已发布知识的问答
- 知识录入：运营人员录入文件或 FAQ，设置分类、标签和版本信息。
- 审核与处理：核对原始内容后，系统解析文档、切分文本、生成向量并建立索引。索引完成不等于对外生效。
- 人工发布：发布操作切换活动版本。MySQL 记录知识状态与活动版本，Milvus 保存可重建的检索投影；旧版本不应继续作为当前答案的依据。
- 检索取证：用户提问后，知识服务按组织与活动版本校验候选证据；没有合适证据时返回无证据结果，而不是强行编造答案。
- 回答与核对：知识服务可通过
/knowledge/retrieve提供证据，或通过/knowledge/answer基于证据与服务端模板生成受控回答。用户可查看引用来源，运营人员可回看问答效果。
这条路径的重点不是“上传即能答”，而是让内容负责人决定哪一版可以被回答使用。文档处理失败、未审核或尚未发布时，不应绕过流程进入生产检索。
# 路径二：Agent 辅助处理复杂问题
对于需要澄清问题、组合多个步骤或调用业务工具的请求，可以配置 Agent 与 Skill，由 Runtime 组织模型和工具调用，并向前端返回执行进度与结果。Model Nexus 管理模型接入，MCP Registry 管理工具注册；知识证据仍由知识服务通过业务接口提供，Agent 不应直接读取知识数据库、文件或向量索引。
例如用户问“为什么我的功能还不能使用”，Agent 可以先澄清账号与场景，再在授权范围内查询已发布操作说明；若还需读取实际开通状态，则须接入相应业务工具并验证调用者权限。查询真实账号状态、创建工单或转人工不是本方案默认已经接好的能力，需要按企业系统和服务流程实施。
# 运营人员与客服人员如何协作
| 角色 | 在方案中的工作 | 可核对的结果 |
|---|---|---|
| 知识运营人员 | 收集问题、维护文件与 FAQ、分类标注、提交审核和版本更新。 | 知识条目、处理状态、版本及发布记录。 |
| 内容审核人员 | 核对原始资料的正确性、适用范围和生效时点，决定是否发布。 | 被批准的活动版本；必要时回滚到可用版本。 |
| 客服或支持人员 | 使用问答入口查找依据，识别无证据或需要进一步处理的问题。 | 带来源的答复、未解决问题清单及可追查的会话。 |
| 平台管理员 | 配置组织、岗位、应用访问以及模型和工具接入。 | 可审查的权限边界与配置；执行记录辅助排障。 |
这套分工把“知识是否正确”与“模型能否说得流畅”分开。模型可以帮助组织语言与步骤，但内容生效由知识发布流程决定；工具调用也必须遵循用户和业务系统的授权。
# 产品能力如何组合
| 能力层 | 对应模块 | 在智能客服中的作用 |
|---|---|---|
| 知识运营与证据 | 知识库服务、知识运营端 | 管理文件与 FAQ、审核处理、版本发布与回滚、检索及受控回答。 |
| 对话与任务执行 | Agent Runtime | 编排 Agent 执行、模型和工具调用，记录任务状态，通过 SSE 返回进度与结果。 |
| 配置与观察 | Agent Studio、Agent App | 管理 Agent、Skill 等配置，提供会话和执行追踪入口。 |
| 模型与工具 | Model Nexus、MCP Registry | 统一模型访问，管理可发现和可调用的外部工具。 |
| 企业基础能力 | IAM、Basis 与 Gateway | 建立身份、组织与岗位权限；为接口访问和数据归属提供边界。 |
| 部署基础 | g2rain-deploy | 提供知识库和 Agent 业务片段，以及 Docling、Milvus 等依赖的容器编排。 |
其中，知识服务是知识状态和证据的所有者，Milvus 不是发布状态的权威来源。运行时的 Skill 或工具绑定也不能代替最终用户的授权校验。知识库能力和 Agent 平台能力分别介绍模块细节。
# 数据、安全与可靠性边界
- 组织隔离：检索不仅看向量相似度，还须按组织和当前活动版本复核。知识管理、原文下载和业务工具调用分别执行权限检查。
- 答案可追溯：优先回答有来源的内容；无证据、来源失效或服务异常应明确反馈，不应把模型猜测包装成企业事实。
- 版本可治理：草稿、处理完成和正式发布是不同状态。更新知识时关注旧版失效与回滚后的检索结果，而不只看页面显示的版本号。
- 工具最小授权：Agent 只调用经过注册并为场景开放的工具。涉及客户资料、订单和账号状态时，还需业务系统再次校验调用权限。
- 异常可定位：保留会话、任务进度与调用记录有助于查明失败环节，但生产环境仍应单独验证超时、重试和恢复策略。
# 从试点到上线的实施路径
- 确定一个服务范围：选定一类高频问题及负责人，明确哪些用户、组织和岗位可以提问或维护知识。
- 盘点可信资料：整理当前手册、FAQ、政策版本与失效资料，标出发布日期、适用对象和原文负责人。
- 建立发布流程：约定谁录入、谁审核、何时切换活动版本，以及错误发布后的回滚责任。
- 部署最小闭环：先打通知识服务、运营端、文档处理、向量检索和对话入口，再决定是否接入 Agent 模型与业务工具。部署项目文档提供部署入口。
- 用真实问题验收：拿业务人员提供的问题集测试正确答案、无答案、过期答案和跨组织访问。问题集通过后再扩大资料与用户范围。
- 持续运营：根据未命中问题和错误引用修订资料，重新审核发布；新增工具或自动化动作单独做权限与风险评估。
部署仓库已经提供知识库和 Agent 的容器片段，但它们是搭建与联调的基础，不等于企业业务系统、人工客服流程和生产运维已经全部接好。
# 建议的试点验收清单
| 验收主题 | 应实际验证的问题 |
|---|---|
| 知识命中 | 高频问题能否命中正确文件或 FAQ？引用的版本是否为当前活动版本？ |
| 无证据处理 | 不在资料范围的问题，是否明确表示缺少依据而非生成看似确定的结论？ |
| 发布与回滚 | 新版发布、旧版失效及回滚后，检索和回答是否同步变化？ |
| 权限隔离 | 不同组织、岗位的用户能否被阻止读取不属于自己的知识与原文？ |
| 执行稳定性 | 文档解析失败、模型或工具超时、检索不可用时，用户看到什么，运营人员如何定位？ |
| 人工处理衔接 | 需要人工服务时，谁接收、如何带上问题上下文、由哪个系统承接？此项需要按实际流程设计。 |
不建议只用“回答看起来不错”作为验收依据。应保留问题、预期依据、实际引用、失败原因和修订结果，形成可重复的回归测试集。
# 在线体验
| 演示入口 | 建议体验内容 |
|---|---|
| 知识对话演示 (opens new window) | 提问、追问，查看回答是否提供知识参考；再试一个资料范围外的问题。 |
| 平台主应用演示 (opens new window) | 浏览平台入口、知识运营页面及相关应用协作。 |
体验用户名 admin，密码 admin。演示环境用于了解交互方式，数据与可用性可能变化；产品界面展示中的知识版本和执行追踪截图是独立示例，不代表同一次完整端到端执行。
# 当前交付范围与下一步
知识库服务和知识运营端有 v1.0.0 发布说明，覆盖文件/FAQ、发布流程、证据检索与受控回答等项目能力。Agent 各模块、演示界面和容器编排提供了构建复杂客服流程的组成部分。跨服务的知识证据调用、授权传递、异常恢复、实际业务工具和人工接管，需要以目标环境的联调和验收为准；不将其表述为开箱即用的完整客服系统。
如果准备评估落地，可以带上现有知识资料、典型问题、组织权限要求与目标业务系统，通过联系方式沟通试点范围。也可以先查看项目进展与开源项目了解平台现状。
← 产品方案