5G消息来了，谈谈如何与小程序进行结合

本文首发至 FinClip 博客

短信这种功能手机时代的“王者”应用，在智能手机、社交软件通行天下的当下，简直是化石般的存在，对于移动互联网而言，它确实是一种“史前”技术。如果不是异地旅游的时候收到移动运营商的漫游提醒、用信用卡消费的时候收到交易金额提醒、以及不时被一些坚持不懈的垃圾信息骚扰，我们几乎已经忘记了短信功能在手机里的存在。对于消费者而言，短信服务的唯一最有用场景就是：收短信确认码。

“古代“短信还有一系列不合时宜的弊端，例如全文本的消息格式 - 在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 发挥引流、传播、辅助作用，让三者产生互补融合与协同的效果？