簡訊這種功能手機時代的“王者”應用，在智慧手機、社交軟體通行天下的當下，簡直是化石般的存在，對於移動網際網路而言，它確實是一種“史前”技術。如果不是異地旅遊的時候收到移動運營商的漫遊提醒、用信用卡消費的時候收到交易金額提醒、以及不時被一些堅持不懈的垃圾資訊騷擾，我們幾乎已經忘記了簡訊功能在手機裡的存在。對於消費者而言，簡訊服務的唯一最有用場景就是：收簡訊確認碼。

“古代“簡訊還有一系列不合時宜的弊端，例如全文字的訊息格式 - 在meme和表情包充斥聊天工具、5 分鐘以上的影片都嫌長的時代，誰有耐心看一串沉悶的文字？又例如垃圾資訊充斥 - 消費者早就習慣了自行訂閱或者退訂公眾號以及退群、拉黑，對垃圾資訊無法控制就索性直接不開啟簡訊工具（誓要消除一切訊息提醒紅點的強迫症患者除外）。垃圾簡訊中嵌入的網頁連結，把消費者帶到了釣魚網站或者造成手機中毒銀行賬戶被盜，也讓簡訊服務蒙受了不安全的壞名聲。

智慧手機上的社交通訊軟體，在即時通訊的基礎上發展出各種應用功能，迅速在移動運營商的基礎設施上提供了另一層價值，“越過運營商” - 被稱為 OTT（Over the Top）類應用，加速讓簡訊服務消亡。一句話總結：傳統簡訊機制，對智慧手機的“智慧”運用為零，自從第一臺iPhone釋出以來，就沒有進化過。

5G 訊息（Rich Communication Service - RCS 國際標準的中國版），嘗試改變上述的狀況，在 5G 網路來臨之際，以富媒體的通訊服務替換傳統簡訊服務，試圖給 5G 網路帶來第一個“殺手級”應用。

和 OTT Apps 相比：“了無新意” vs “大不同”

5G 訊息支援更加豐富多元的媒介內容：文字、語音、影片、地理位置定位、支付、卡片應用等等。這些對於現有 OTT 類 App 的使用者而言，可以說是“了無新意” - 有什麼是一個社交 App 搞不定的？而且，5G 訊息工具的使用者體驗，也很難超越當前無處不在的主流社交軟體。

但另一方面，對於消費者和商家而言，通訊工具的基礎技術設施發生巨大變化，底層邏輯也截然不同。OTT 軟體是由私有平臺提供，雖然其普及度往往造成其成為一個“既成事實”的公共基礎設施表象，本質上它的存在邏輯，是讓你免費使用從而獲得你的使用行為直接或間接帶來的資料，再利用這些資料生產出某些最終還是你買單的服務或產品。當然，這過程中世界各國也相應的建立資料安全、隱私保護的相關法律，對消費者、商家的資料進行保護，對網際網路平臺進行法律約束，例如歐盟出臺 GDPR（General Data Protection Regulation），我國在去年 11 月正式推出迄今在全球最為嚴格的《個人資訊保護法》（簡稱“《個保法》”），但這不改變 OTT 軟體及其運營者的性質。

5G 訊息，是由電信運營商提供的公共基礎技術設施。電信運營商在過去以來，受其所在行業定位、商業模式以及相關法律的影響或規範，在全球範圍也沒有“運用消費者資料生產收費服務與產品“並取得商業成功的先例。

用資料產生價值，再引導使用者為資料買單已經成為行業慣例

5G 訊息也不是由單一網際網路巨頭或者電信業巨頭控制的平臺，包括重新啟用並積極推動 RCS 標準的 Google，都需要與電信運營商、手機廠商以及其他一系列機構組織共同協作，構建由使用者、運營商、企業客戶、MaaP 平臺廠商、AI/NLP 提供商、HUB 集中輸出系統廠商、SDK 廠商、終端廠商八方分工合作的行業生態。

但問題也來了，”八方支援“是兩刃劍，一方面是打破壟斷、讓更多方共同參與，另一方面也可能是低效。環節過多，整合體驗不佳，這八方中最重要的一方：消費者使用者，可能就不玩了。

輕應用：決定商業生態的價值

OTT 類應用的成功關鍵，離不開其聰明的結合輕應用技術，支援無比豐富的生活場景、商業場景、社會活動場景，從電商到健康檢疫，無處不在，讓使用者無法離開。5G 訊息顯然也重點考慮了類似的機制。

什麼是輕應用？

區別於手機上的原生 App，首先是對於消費者使用者而言“輕” - 免下載安裝、無需感知軟體升級、隨需隨用、上下文無縫切換。其次是對於開發者而言“輕” - 採用解析類程式語言（例如標籤類語言、指令碼類語言）以及相對易學的開發框架，較低門檻的快速實現各種應用場景並簡易釋出。只有使用體驗好成本低、開發門檻低成本低，才能形成豐富的內容、海量的使用者與開發者生態。

各種平臺上的聊天機器人扮演者售前諮詢，售後客服，智慧助手的角色

在 OTT 應用上，我們最熟悉的輕應用技術是小程式（有些網際網路平臺稱之為小應用），在 RCS 上，輕應用的標準技術形態是 chatbot（聊天機器人）。

聊天機器人無疑是一種輕應用，它是由開發者以某種規範、標準、框架開發而成的應用，它的前端互動介面除了透過自然語言應答之外，也可以是由即時通訊客戶端解析渲染而成的一些互動控制元件（例如選單、按鈕），使用者確實也無需使用通訊工具以外的任何特殊軟體，更無安裝或升級之虞。

對於 5G 訊息而言，這兩種輕應用技術有什麼差異？小程式能否與 5G 訊息結合？

聊天機器人和小程式的“對比”

其實各有應用場景和適用空間。但同為輕應用類技術，不妨類比一下。

聊天機器人並非新生事物，它同樣在 OTT 類應用中大行其道，但到目前為止，這類技術在國內市場的存在感不強，大部分使用者可能主要透過一些電商平臺的機器人客服體驗過它的存在。聊天機器人在 Slack、Telegram 等國外的即時通訊與協同類軟體中較為常用。作為 5G 訊息內建的標準應用形態，也許不久後聊天機器人會更廣泛的為國內消費者所熟悉。

小程式，卻是國內網際網路技術創新的產物和亮點。這種輕應用形態是國內社交軟體、超級 App 的標配。其如此之成功，乃至在 W3C 下成立的新的技術標準工作組（主要成員是國內的科技公司），試圖形成標準“走向世界”，2021 年似乎在標準制定上取得了一些里程碑的進展。小程式的成功，也許一定程度上“壓制”了聊天機器人這種輕應用形態在社交軟體上的採用。

W3C出具的關於小程式的介紹性技術報告

聊天機器人，既然是透過“聊天”與使用者發生互動，這種輕應用形態顯然必須依託於通訊技術。但它體現一種所謂的 A2P（Application to Person）使用特點，強調企業透過機器人向客戶提供服務，不見得是最適合社交傳播的技術形態。有趣的是，小程式雖然誕生於社交平臺，特別適合於使用者之間（Person to Person）的社交傳播，卻並不依賴於通訊技術作為技術載體。小程式可以完美執行在沒有即時通訊能力的 App 中，在使用者間分享傳播；而聊天機器人必須執行在有即時通訊能力的環境中，卻並不適合於使用者間分享傳播。

聊天機器人透過移動運營商的RCS通道提供聊天式的“請求-應答”，小程式作為 Web 應用的一種特殊形態透過網際網路以 HTTP 協議的方式讓使用者與雲端實現“請求-應答”。前者的人機互動方式是，使用者透過自然語言或者透過會話中對機器人傳送過來的一些選單、按鈕的選擇，發起請求。後者的人機互動方式是，使用者操作介面的連結、表單發起請求。

聊天機器人可能有一定“智慧”，也可能沒有 – 例如結合了自然語言理解（NLU）能力的聊天機器人可以理解使用者透過即時通訊發過來的一些詞彙、句子並準確翻譯成結構化的查詢（query）再觸發後臺的應用服務，但這不是聊天機器人必備的。小程式的“智慧”，應該主要體現在其“千人千面”、自動針對當前使用者的個性化服務能力上，和所謂人工智慧，不見得有必然聯絡。

以下是兩種輕應用形態的一些對比

	RCS ChatBots	小程式
技術型別	一種輕應用，免安裝免升級，隨需隨用	一種輕應用，免安裝自動升級，本地啟動執行，隨需隨用
執行方式	由即時通訊工具、簡訊工具解析呈現	由執行時（Runtime）解析、渲染、執行，執行時可能是一種獨立的引擎以可嵌入式元件形態存在（例如凡泰極客 FinClip），也可能融合於某種軟體應用中（主要是 OTT 類軟體例如微信）
MVC剖析	Model：業務資料與後臺服務 View：文字資訊、富媒體的卡片呈現，有相對固定的一些類別與形態 Controller：使用者透過 ChatBots 應用所特有的底部/懸浮選單進行互動，訊息工具本身也是一種“freeform”（自由形態）傳送自然語言給機器人的互動機制。本質上是透過 RCS 通道傳送訊息給伺服器。但自然語言輸入需要 NLU/NLP 技術處理才能轉化為確定的、結構化的輸入訊號	Model：業務資料與後臺服務 View：本質上是基於各種 UI 元件組裝的 Web 應用，具體效果視設計而定，靈活多變 Controller：使用者透過 UI 介面進行互動，本質上是產生基於 HTTP 的事件，提交至伺服器。輸入訊號是確定無誤的、結構化的。
資料交換	依託、利用運營商的 RCS/5G 訊息通道，使用者與 ChatBots 之間的通訊是 RCS 訊息	基於網際網路，透過 HTTP 進行
UX/人機互動	採用 Conversational UI（會話型互動），使用者在和機器人“交談”過程中獲得“請求-應答”方式的服務	一個“具體而微”的全功能互動軟體，有一般使用者習以為常的軟體操作介面。透過 HTTP 進行“請求-應答”
資料安全與隱私保護	由一個產業鏈的多方去共同履行。但其中運營商是最關鍵環節。運營商處於受監管的電信行業，且受其根本商業模式、商業基因的影響，以及所在地法律法規的約束，主要透過提供公共基礎電信服務設施收取相關服務費用，並不以對使用者資料進行收集分析加工再生產以某些形態商業化為目的	（1）對消費者免費的 OTT 應用，並非真正的公共技術基建設施。使用者（包括消費者以及商業組織）的資料成為該企業的私有數字資產，雖然當前歐盟、北美、我國均陸續出臺相關的資料保護法律法規進行規範。（2）企業應用作為宿主和執行平臺，透過內嵌 FinClip 小程式執行沙箱等私有化技術自行掌握小程式執行與生態運營能力，則自行對自己的使用者資料安全與隱私保護負責，遵循國家對一般 App 資訊保安的規定即可
人工智慧結合	能與自然語言處理（NLP）、影像識別等人工智慧領域的技術結合，在會話中理解使用者訴求，把使用者發出的非結構化內容（包括但不限於文字、圖片、音影片）進行精準理解從而轉化成結構化的 query。AI/NLP 技術提供商是 5G 訊息生態的一部分	不直接涉及，取決於具體的應用自行實現
主動觸達使用者	在雙向的 RCS 簡訊通道上，天然具備主動推送、觸達使用者的能力	本身不具備觸達使用者的能力，視乎所在的 OTT 應用或者宿主應用有無主動觸達使用者的能力

開發成本與“智障”風險

聊天機器人與小程式，都有與使用者進行人機互動的前端，前者的互動介面，主要由 RCS 通訊工具（通常內建於 5G 手機中）本身的訊息輸入框、文字訊息的“氣泡”、以及一些由機器人傳送回來的供使用者選擇的“卡片”、選單、按鈕等圖形控制元件組成，看上去比較簡單。

後者的互動介面就是“具體而微”的 Web 應用，由豐富完整的各種 UI 元件構建而成。兩者的前端，其實都是遵循 Model-View-Controller（MVC）這種前端軟體的典型設計模式的 – 聊天機器人這種應用，即便是主要透過會話的方式進行互動，它依然是有非常清晰的後端資料模型、領域模型、封裝服務，它也有一定的介面，使用者透過通訊工具聊天框發出的會話“指令”，所產生的事件與使用者在一般 App 的 UI 模式下觸控螢幕控制元件所產生的服務請求，對於雲端的服務而言，並無二致。

但是，對於企業而言，開發一個聊天機器人和開發一個小程式，成本是一樣的嗎？答案恐怕是否定的。

遵循一套不同的設計“哲學”

雖然你可能可以重用、共用同一套伺服器端邏輯，可是對於開發聊天機器人，你的 IT 員工需要學習掌握一套新的方法，例如你的 UX 設計師需要設計的不再是圖形介面體驗而是基於人類會話交談應答相應的“會話流”（Conversation Flow），你的產品經理需要給機器人設計一個“人設”（虛擬人格）以及相應的會話風格並像編劇一樣設計出會話場景的“劇本”，你的開發人員則需要掌握一些新技術 – 最起碼能駕馭一個簡單的規則引擎去解決與使用者會話過程中複雜繁多的條件判斷分支、構建決策樹，或者甚至需要去學習一些新的技能例如 AIML（Artificial Intelligence Markup Language，一種人工智慧標識語言）等等。

投資一些新工具

最起碼你的 IT 需要採購一套 MaaP 平臺軟體或者租用一個雲版的服務，此外你可能需要一些新的設計工具（例如上述“會話流”的設計工具）以及開發工具（例如一些所謂的“ChatBots Builder”）。

如果你希望機器人能理解客戶的會話從而作出智慧回應，顯然你需要購買 NLP/NLU 相關的技術或服務去對人類語言進行分析、理解、處理。例如 NLU 技術幫助機器人把自然語言解構成 Intent（意圖）、Entity（概念實體）、Context（語境、上下文），NLP 技術則負責做語義分析、情感分析、實體識別（例如識別出客戶的句子中提到的是一個產品的名字還是一個地址）、甚至客戶輸入的錯別字自動識別更正，等等。

前端越簡單，後端事越大

聊天機器人的前端顯得比較簡單，這意味著開發工程師可以做少一點事情嗎？恰恰相反，供使用者互動的點少了，你的伺服器端必須變得更加智慧。雖然你的聊天機器人給客戶推送了各種會話型 UI 供其選擇，但別忘了使用者在任何時候都可以透過 RCS 通訊工具的聊天框輸入任何內容，你的機器人如果應對失據，則很可能鬧笑話、顯得弱智。這可以算是一個非常影響使用者體驗、使用者信任度的風險。所以，你很可能還需要為你的機器人的訓練成本買單。

聊天機器人可以分成兩類：Rule-based（基於規則）與AI-based（基於人工智慧）。後者在大多數情況下不為一般企業所掌握，只能透過購買一定的技術與服務去實現。前者基於相對簡單的演算法，可能是在 5G 訊息發展早期大部分所謂聊天機器人的主要實現機制。

AI-powered awkward first date

聊天機器人不是 5G 訊息的特產，此前已經存在多年，但特別“著名”而成功的機器人，無論是機器人客服還是機器人投資顧問，似乎並未出現。正如去年一篇行業文章所觀察，可用的聊天機器人數量，“令人尷尬的少”。

網上曾有關於 5G 訊息的文章稱，5G 訊息有“去 App 化、去小程式化”的潛力。但在原生 App 世界裡有許許多多超級 App，在聊天機器人世界裡相應的“著名機器人”卻還未出現。倒是小程式這種形態的輕應用，無論是個數還是增速，都已經遠超原生 App。

什麼樣的輕應用能促進 5G 訊息普及

5G 訊息，在 5G 的旗幟下透過 RCS 標準和智慧手機的結合，構建由電信運營商、MaaP平臺廠商、終端廠商、企業、消費者等八方共建的商業生態，致力於“把蛋糕做大”。RCS 具備了當前主流 OTT 應用的大部分能力 - 多媒體內容、群聊、音影片通訊、chatbot 形態的輕應用、企業應用號/服務號等等，加上 5G 作為國家科技戰略重點的加持，運營商的積極推動，以及眾多借此機會涉足 5G 概念的廠商的踴躍參與，“把蛋糕做大”有天時地利人和。但能做多大，最終取決於消費者使用者的使用意願，從而決定企業的大量採用併為其買單的意願。相當於局布好了，最重要的那倆是否積極進入的問題。

輕應用是解決問題的關鍵

對於消費者普羅大眾而言，體驗是否順暢，夠輕夠便利，對於企業而言，開發成本是否低、能否最大程度重用主流技術框架、技術工具、人員資源、開發技能。

Chatbot 有它的適用場景和特點強項，作為 RCS 標準的一部分，隨著人工智慧技術的成熟，一定會獲得應用和普及。但是，如上文所述，它對企業有額外的投入成本，它頂著機器人的“光環”，主打基於人類語言的聊天式人機互動，就需要滿足消費者對“智慧”的更高期望，不夠智慧，效果可能適得其反，影響消費者對該企業服務的信任，這對企業而言有早期嘗試新技術的風險。

Chatbot 的開發框架、工具這幾年是在陸續的出現中，但無論如何，工具處於早期開發愛好者嚐鮮者的試驗階段，相信一段時間內嘗試開發 5G 訊息應用的人只能“徒手”寫程式碼了。而開發框架對於習慣於 MVC 模式的廣大前端開發者有適應過程，例如對於開發小程式而言 View 和 Controller 都在前端，其使用者透過 Controller 產生的輸入“訊號”是明確無誤的，但對於開發 ChatBots 而言，Controller 還包含、依賴於伺服器端的規則引擎和自然語言理解（NLU）技術 – 客戶聊天內容需要經過一層人工智慧技術才能轉換成規範化、結構化的請求，為後臺業務邏輯所理解而提供回應。會話型人機互動增加了 Controller 生成訊號的不確定性，對人工智慧技術有較高要求，對企業有額外的挑戰。

另一方面，5G 訊息具備 OTT 應用的很多能力，和小程式這種輕應用形態同樣可以結合的很好。其結合的優越性在於，讓 5G 訊息迅速獲得豐富的小程式內容、重用在我國已經非常成熟的海量開發者資源，消費者也已經形成了使用小程式的習慣沒有重新適應的問題。

小程式的支援能促進 5G 訊息的推廣普及，對於已經對小程式開發運營做出IT投入的企業，沒有顯著增加的成本。當前市場上已經出現一些企業用的、相容主流小程式技術的輕應用方案，如凡泰極客的 FinClip 小程式執行沙箱，是一種元件化外掛化的嵌入式技術，和 MaaP 平臺廠商、RCS SDK 提供商方案結合，即可讓企業開發者完全重用小程式開發技能、開發工具、開發框架，開發或遷移出自己的“5G 訊息小程式”。

小程式、聊天機器人與App是零和遊戲嗎

5G 訊息帶來新的商業生態，但佔據手機市場半邊天的蘋果，也早就有了自己的Apple Business Chat，對 RCS 標準的支援並不積極。此外 OTT 平臺如 Whatsapp 也有 Whatsapp Business 之類的解決方案，國內大型網際網路社交平臺則早已形成強大的商業應用生態。大家都在角逐同一批需要觸達消費者、營銷消費者、服務消費者的企業群體。

與此同時，根據工信部監測我國市場的資料，App 的個數確實是在下降之中。另一方面，小程式的數量和 DAU 則處於顯著增長狀態。有點此消彼長的意思。對於一些企業來說，放棄 App，以小程式融入網際網路數字世界是最佳選擇。對於另一些行業例如金融業的機構而言， App 依然是合規可控的唯一選擇，其他輕應用形態主要作為輔助工具。但有一點可以確定的，就是輕應用在市場的佔比會越來越“重”，透過 5G 訊息、智慧手機巨頭、網際網路大平臺進入到消費者的裝置端，佔據他們的螢幕時間。

對於大部分企業的 IT 而言，已經處於同時維護小程式（“輕”應用）、App（“重”應用）的狀態，如果 RCS ChatBots 被證明有助於在 5G 世界觸達客戶、推廣業務，應該願意增加預算去支援這種新的輕應用形態。

而企業需要考慮以下問題

能否充分利用此前的技術積累與投資？
如何建立一套技術架構以支援 App、小程式、機器人等多種前端互動的“入口”？
怎樣定義一套“設計語言”（Design Language）讓使用者在 App、小程式、機器人上均獲得強烈一致的品牌效果、視角風格和互動體驗？
如何讓小程式、機器人無論在移動運營商的 5G 訊息公共設施上還是在網際網路公司的私有 OTT 平臺上都給自家的 App 發揮引流、傳播、輔助作用，讓三者產生互補融合與協同的效果？

FInClip開放平臺：淺談輕應用的發展