Servify DocsServify Docs
首页
产品
架构
部署
  • 安全基线
  • 配置作用域
  • Token 生命周期
  • 开放接口安全清单
  • 实施计划
  • WeKnora 集成
  • CI / Runner
  • 版本发布
  • 测试金字塔
  • Mermaid 兼容性
GitHub
首页
产品
架构
部署
  • 安全基线
  • 配置作用域
  • Token 生命周期
  • 开放接口安全清单
  • 实施计划
  • WeKnora 集成
  • CI / Runner
  • 版本发布
  • 测试金字塔
  • Mermaid 兼容性
GitHub

Servify

面向企业独立部署的智能客服系统

了解产品能力查看部署文档

Web 接入

以网站客服入口为起点,把访客接待、实时会话和后续处理串成统一链路。

AI 协同接待

通过知识库和模型能力完成首答、澄清和建议,让 AI 成为客服流程里的协作角色。

远程协助

针对需要演示、引导和排查的问题,支持远程协助场景,不只停留在文字问答。

人工接管与转接

坐席可以随时接管 AI 会话,并继续转接、协作和推进复杂问题。

工单闭环

无法即时解决的问题进入工单继续跟进,让服务从聊天延伸到持续处理。

后台运营

在统一后台管理坐席、知识库、权限、安全策略和产品运行配置。

产品概览

Servify 不是先做平台再兼容客服,而是先把客服主链路做完整:

Web 接入 -> AI 首答 -> 远程协助 -> 人工接管 -> 转接协作 -> 工单闭环

当前文档站的重点,也应该围绕这条链路来理解产品,而不是先从 implementation backlog 开始读。

这里的远程协助,不是把“WebRTC 可用”单独当成功能名词,而是把实时指导、联合排查、人工接管和后续工单处理放进同一条服务链路里。

为什么是 Servify

独立部署优先

Servify 适合需要独立部署、可控接入和持续演化的企业客服场景。它默认服务的是单个企业团队,而不是把多租户平台化能力放在产品正中央。

远程协助是差异点

很多客服系统只做到聊天和工单,但真实服务过程里,经常需要“看着客户做、带着客户做、一起排查问题”。Servify 把远程协助视为产品能力,而不是隐藏在底层实时通信里的附属特性。

当前仓库已经具备这类能力的实时基础,包括 Web 会话、消息、WebSocket / WebRTC 相关链路、人工接管和后续工单闭环;但文档表达会刻意避免把它夸大成“已完整交付某种重型远控产品”。

AI 和人工不是割裂关系

AI 负责首答、澄清、知识召回和建议,人工可以随时接管、继续处理和协作,让整个客服体验保持连续。

推荐阅读

  1. 总体架构设计
  2. 部署指南
  3. 本地开发
  4. 实施计划索引

你可以从这里继续

快速了解产品

  • 总体架构设计
  • 远程协助
  • 部署指南
  • 本地开发

深入运行与安全

  • 运行安全基线
  • 配置作用域规则
  • Token 生命周期与密钥轮换
  • 开放接口安全清单

继续看研发与实施细节

  • 实施 Backlog 索引
  • 外部知识库集成指南:Dify 优先,WeKnora 兼容
  • 版本发布策略
  • 测试金字塔
  • CI / GitHub Hosted Runner
  • Mermaid 兼容性

常用入口

  • 本地自检:make local-check
  • 安全检查:make security-check CONFIG=./config.yml
  • 可观测性检查:make observability-check CONFIG=./config.yml
  • 发布检查:make release-check CONFIG=./config.yml
Servify documentation site