1.業務背景

在得物客服機器人自研早期，傳統一問一答式的FAQ解決方案粒度較粗，在實際的業務場景中，越來越難以滿足用戶的咨詢需求，也沒有差異化的流程解決方案精準的引導用戶解決問題，大量用戶的咨詢依然依賴人工客服解決問題。早期的多輪SOP引擎主要依賴于三方平臺，三方響應速度比較慢，提供的服務可定制化的能力不足，在流程配置上，效率也比較低。隨著業務的快速發展，提高機器人在復雜場景下的解決能力，降低人工客服的成本，提供靈活的可視化多輪SOP流程配置后臺，是非常有必要的，至此開啟了自研多輪SOP流程引擎的里程。

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流程引擎從立項到發布，整個周期差不多一個月左右的時間，從無到有的過程，是各投入方一起努力的結果。目前多輪流程引擎除了服務于上述兩個場景之外，也在工單業務、質檢業務探索使用場景，同時也在持續豐富坐席輔助場景，為一線客服提供標準化的服務流程，提升一線客服的解決率。在功能上，我們也會持續完善流程引擎的能力，支持更多業務場景的使用，將流程引擎的能力不斷完善，打造成為業界的標桿。