2.多轮简介
在了解业务背景之后，可能很多人对客服场景中的多轮不太了解，这里结合实际的人机对话来介绍下机器人是如何基于多轮解决用户问题的。
从上面可以看出，用户咨询的过程按照问答的流程一步一步走完，期间并没有人工客服的介入，在多轮的会话中，客服机器人解决了用户的问题。那这里可能会有个疑问，机器人是怎么知道该问什么该答什么的？语义识别or算法识别，其实都不是，在配置后台有对应的可视化搭建页面来配置多轮的流程。
3.前期调研
在明确需求之后，通过什么样的技术能力搭建机器人多轮SOP流程，是从0到1去实现还是基于开源的框架去实现是当时面临的主要的选择问题。从0到1去实现当然是最好的，也是很多技术同学挑战自我的机会，不过当时面临的主要问题是流程的搭建涉及Canvas画布以及图形编辑，这块如果没有专业知识的背景，难度相对会比较大，再加上当时业务的快速发展，亟需自研的多轮产品来做定制化的能力，所以当时选择了基于开源的框架去实现。在对开源框架的调研上，也参考了比较多流程配置的实现，具体如下：
- X-Flowchart-Vue：一个基于vue的流程图编辑框架，能实现流程图的搭建，但是没法满足业务场景中的自定义节点样式；
- vue-flowchart-editor：一个基于vue的流程图编辑框架，提供了几种节点样式和简单的数据配置能力，对于自定义节点需要基于源码二次开发；
- Activity：一个比较完整的工作流程解决方案，是集成了前端、后端以及数据模型的一整套的流程引擎，如果使用的话，不仅前端这边要做二次开发，后端那边也得部署对应的服务或者对其二次设计和开发，成本比较高，并且Activity使用的前端技术栈比较老旧，在我们现有的系统里面比较难以集成，所以在当前的业务场景下并不合适；
- Flowable：一个业务流程引擎，开发语言主是Java，如果用的话，后端需要部署一整套流程引擎服务，前端这边主要配合修改，成本也比较大，在当前的业务场景下并不合适；
- X6：是 AntV 旗下的图编辑引擎，提供了一系列开箱即用的交互组件和简单易用的节点定制能力，方便快速搭建流程图等图应用。
每个框架都有自己的优缺点，最后选择了基于antv-x6图编辑引擎做二次开发，其主要原因如下：
- 蚂蚁的开源数据产品，社区比较活跃；
- 跟技术栈无关，可扩展性很好；
- 支持自定义节点，可定制化能力很高；
- 工具组件比较完备，能够开箱即用
4.技术架构
明确了技术选型之后，接下来就是具体的技术实现了。多轮SOP流程引擎不仅需要前端这块的设计实现，也离不开后端的设计实现，整体的架构设计如下图所示：
4.1 前端配置层
前端配置层主要包括多轮SOP可视化流程搭建、上下线管理、版本管理和接口管理四个功能模块。
- 多轮SOP可视化搭建：包含各业务节点的拖拽操作和数据配置，通过不同业务节点的关联关系生成完整的流程配置；
- 上下线管理：对于搭建好的多轮SOP流程需要做上线和下线的操作，当线上多轮流程出现问题的时候，需要及时下线；
- 版本管理：配置完的多轮SOP流程刚发布的时候，流程节点的回复话术或者功能都比较基础，需要通过线上用户的流程数据不断的完善流程能力，每次的变更都需要升级版本，确保线上稳定版本的同时，能对多轮SOP流程不断的进行调优；
- 接口管理：流程里面涉及的各业务节点依赖不同业务域的服务，比如订单需要依赖交易接口、物流需要依赖供应链接口等，在业务流程配置里面涉及到这类功能，就需要通过接口配置的方式去实现。
4.2 后端服务层
后端服务层核心部分是在流程执行引擎模块，在实际应用场景中，会根据用户输入的问题来匹配最合适的流程以解决用户的问题。在执行匹配到的流程的过程中，执行引擎会先创建流程的上下文，这里会从redis缓存里面加载上下文信息，根据上下文中记录的流程执行状态，确定从哪个节点开始执行，执行完以后进行上下文信息的更新。当流程执行结束的时候，再做上下文的销毁操作。
4.3 应用层
应用层主要是多轮SOP流程具体的使用场景，目前主要包括得物客服机器人和坐席辅助SOP两个使用场景。
5.技术挑战
5.1 数据建模
通过数据建模解决节点与节点之间关联关系的问题。
在多轮SOP流程可视化搭建过程中，画布节点的创建和连接是最复杂的，有些多轮场景的节点超过100个，节点之间的关系在画布上的体现就非常重要。目前业务自定义的节点有4类，如下：
每个节点都有自己的业务属性，这里主要通过数据建模的思想把每个节点的业务属性以及关联关系属性做了抽象，其思路如下：
X6提供的原始数据类型相对比较简单，只有id、html、data、shape等这些基本属性字段，在实际的业务场景中需要基于原始的属性字段去做扩展，X6提供的data属性就能很好的满足自定义业务数据的需求。分析四类业务节点之后，每个业务节点可以抽象通用的数据模型，其主要字段的含义如下：
- nodeName：节点的名称
- nodeType：节点的类型，这里有四种节点类型：填槽节点、跳转节点、回复节点和判断节点
- fromNodeId：来源节点的ID
- nextNodeId：指向节点的ID
- fromEdgeIdList：来源边ID的列表
- nextEdgeIdList：指向边ID的列表
- bizData：不同业务节点的业务属性信息
这里bizData作为业务节点的通用数据模型，用于存放不同业务节点属性数据，比如填槽节点有slot和abnorma等业务属性，回复节点有contentSort和content等业务属性。通过对业务节点的数据模型抽象，就可以表示不同节点之间的关联关系，如下图所示：
- 判断节点可以通过nextEdgeIdList属性关联填槽节点和跳转节点；
- 判断节点可以通过fromNodeId属性关联转人工回复节点；
- 转人工回复节点可以通过nextNodeId关联兜底回复节点；
- 兜底回复节点可以通过fromEdgeIdList关联转人工回复节点。
不同的节点关联关系通过语义化属性表示之后，再基于X6提供的addNode/addEdge方法实现节点和边的连接，这样无论画布中有多少个节点，节点之间的关联关系都非常的清晰。
5.2 RXJS
通过RXJS事件订阅和单向数据流解决不同功能模块数据流向的问题
在多轮SOP可视化搭建后台，有三个不同的功能区：工具栏、画布区和数据配置区，每个区域的操作都会涉及到节点数据的变更，如果没有清晰的数据流，将会导致数据变更混乱，保存的时候潜在数据错乱的风险。这里我们采用了RXJS事件订阅以及单向数据流的设计模式，具体实现如下图所示：
- 操作栏的节点操作会触发事件，比如删除节点操作；
- 在画布区选中需要删除的节点，触发节点数据删除事件；
- 数据表单配置区接收节点数据删除事件的数据，删除对应的节点数据并同步到数据内存缓存；
- 最后提交流程的时候，将内存中的数据传给服务端数据库。
整个过程，从节点数据流向表单数据再流向缓存数据，整个流向是单向的，不管在哪个模块触发最终的流向都是数据内存缓存。
对于数据流，目前有很多开源的框架可以使用，比如redux、vuex、dva等等，这里为什么采用RXJS？主要是因为RXJS比较轻量，同时跟技术栈无关，后续可扩展性更好。
5.3 流程编排
通过流程编排技术解决复杂多轮流程搭建的问题
截止到上半年，线上的多轮已经将近200个，有些复杂的流程包含100多个节点，对于100多个节点的复杂流程如果是一个节点一个节点去配置的话，那配置效率是极其低下的，那我们是怎么实现复杂流程快速搭建的呢？这里用到了流程编排技术。
流程编排是指通过拖拽可视化业务组件来编排业务流程，然后由流程引擎来执行这个流程。其标准化的协议是BPMN协议，BPMN协议包含了流程编排里面的各种图标、元件的含义和使用规范。在实际的应用场景中，我们并没有完全使用BPMN协议，而是遵循了BPMN协议，做了自定义的元件组件。对于复杂的流程，我们通过不同的子流程进行编排，其思路如下：
这里通过取消订单多轮流程举例，其流程拆分如下：
从上图可以清楚的看到，取消订单多轮流程包含了判断用户身份子流程、判断用户诉求子流程、取消订单子流程这三个子流程，其中每个子流程又是一个独立完整的流程。这样通过三个子流程的编排，就可以搭建取消订单复杂的多轮流程。
以上三点是在自研过程中遇到的主要的技术挑战，其实在做的过程中，还有很多的难点，比如上百个节点如何做到渲染秒开、复杂的逻辑（复制、剪切）如何编排、复杂的判断节点如何做到一键展开和折叠等等，这里就不一一阐述了。
6.业务成效
客服多轮SOP流程引擎的自研，完全取代了三方服务，不仅节省了每年至少几十万的外采服务成本，并且在业务上取得了不错的成效，做到了灵活定制，快速支撑业务的发展。自上线之后，主要覆盖得物客服机器人和坐席辅助机器人两个业务场景，其中得物机器人多轮SOP流程有上百个，坐席辅助机器人多轮SOP流程有几十个，在很大程度上提升了客服的解决率，减少了转人工成本。上线之后，以今年其中一个月份的数据为例，客服机器人的解决率有比较明显的提升，其中SOP的解决率相对于FAQ的解决率提升了15%多，SOP接待数是FAQ接待数的2倍多，在很大程度上节省了转人工成本。
7.总结
客服机器人多轮SOP流程引擎从立项到发布，整个周期差不多一个月左右的时间，从无到有的过程，是各投入方一起努力的结果。目前多轮流程引擎除了服务于上述两个场景之外，也在工单业务、质检业务探索使用场景，同时也在持续丰富坐席辅助场景，为一线客服提供标准化的服务流程，提升一线客服的解决率。在功能上，我们也会持续完善流程引擎的能力，支持更多业务场景的使用，将流程引擎的能力不断完善，打造成为业界的标杆。
