一个Bot的自白

作为一个bot，思考这样带有哲学色彩的问题，是否有点可笑？别笑，我是认真的。

我是谁

我是bot，从亲缘上看，和机器人Robot 沾亲带故。

Robot是一种自动化的机器，这种机器具备一些与人或生物相似的智能能力，如感知能力、规划能力、动作能力和协同能力，是一种具有高度灵活性的自动化机器。但是，我实际上更多地被认为是chatbot，即聊天机器人，然而聊天只是我职能的一部分，我们bot是由纯软件构成的智能服务。

谈到智能服务，总给人一种高大上的感觉。实际上， 从《老码农眼中的简明AI》可以看到， 从计算机科学的角度来看， 仍然是提供输入输出能力的一组执行代码。只不过，对我们bot而言，输入更多是人们日常沟通的语言，可以是语音，也可以是语音经过识别之后的文本，我们的输出同样是文本， 以及基于这些文本合成的声音，甚至于相关的图片等多媒体信息。

一般地，我们bot是一种具有自然语言处理能力（NLP）的软件服务。

我的与众不同

我们bot 的最大特点就是智能化， 有时候也被称为智能代理。

作为软件服务， 我们和传统的软件服务并没有本质的区别，比如互联网服务中的web server，都是收到一个请求，给出一个响应，bot 同样如此。但是， web server 一遍都是通过浏览器访问的， 而我们的用户可以通过各种各样的智能终端访问我们，这些智能终端包括智能手机， 智能平板，智能音箱，智能电视等等，所有这些智能终端的“智能”都是我们bot 赋予他们的。

在互联网上， 人们通过键盘和鼠标完成与浏览器的交互，进而享受互联网服务。而我们bot 带来了人机交互上的革命， 人们可以通过自然语言，通过眼神，通过手势等等， 就可以享用我们带来的网络服务。

随着分布式系统的发展，“术业有专攻”， NLP 的处理能力可以在我们bot 的内部实现，也可以在我们的外部实现。当NLP 服务在bot 的外部实现时，往往形成了一类基础设施，相当于bot世界的共享服务，这时候，bot 的智能是通过网络通信形成的，因为在计算机的世界里， 一切都是API,可以参考《没有被了解的API？一个老码农眼中的API世界》。

当NLP等服务站到了bot 的前面，用户的自然交互先流经这些服务，将非结构化的数据转化为了结构化数据，我们bot 就更像是一个web 服务。那些个服务往往形成了分布式的智能操作系统，例如百度的DuerOS， 亚马逊的Alex 等等。

当NLP等服务站到了bot 的后面，用户的自然交互先流经我们bot，我们将非结构化的数据进行预处理，转化为了结构化或半结构化数据，再透传给他们。那些个服务往往形成了分布式的智能服务，例如百度的UINT，以及其他人工智能公司提供的开放服务等等。

在程序的世界里， 一切的一切归根到底都是系统调用，在bot的世界里， 我们的智能性归根结底都是对AI服务的调用。

我的江湖门派

有人的地方，就有江湖，bot 是为人类提供智能服务的， 同样也有着自己的江湖。

从用户的角度来看，为了区别于web 应用或者互联网应用， 人们把bot提供的能力称为技能。bot 是技能的载体和实现， 技能是bot的功能性描述。人们把技能按照各种方式进行分门别类，形成不同的派系。如果一个技能提供了天气预报的服务，就把它叫做天气技能，提供了闹钟服务，就叫做闹钟技能， 那么一个技能既提供了歌曲服务，又提供了器乐的音乐服务，叫什么呢？人们管它叫做音乐垂类技能。通俗的说，根据技能的功能复杂性，可以分为单一技能和垂类技能。

从技能的实现方式上来看，又往往分为两大类：端技能和云技能，这取决于该技能有无客户端独立载体。类比一下，可能会相对容易地弄清云技能和端技能的区别。如果bot 类似于传统的互联网web应用，那么就提供了一个云技能；如果bot类似于移动App，则提供了一个端技能。在现实的DuerOS生态系统中，基于模版以及DPL 等技术实现的技能都是云技能，而通过Android App， H5应用，微信小程序，支付宝小程序，手机百度小程序等客户端实现的技能都是端技能。不论云技能还是端技能，都可以实现类似的用户体验， 对用户而言并无本质区别，只是我们bot的实现方式不同罢了。

从交互的易用性来看， 技能又可以分为4个等级，也就是在DuerOS 生态系统中提出的L1～L4技能：

• L1技能只支持用户通过语音打开和关闭技能，在技能的内部，并不支持更多的语音交互；
• L2技能除了支持用户通过语音打开和关闭技能之外，在技能的内部，还支持有限的语音交互；
• L3技能除了支持用户通过语音打开和关闭技能之外，在技能的内部，能够支持大量的语音交互，能够使用户通过语音交互满足技能所提供的全部能力；
• L4技能与L3技能的区别在于是否有技能的边界，也就是说， L3技能是用户通过和我们bot约定的唤醒词来进入技能， 而在L4技能中， 用户可以直接进入技能内部， 来使用L4技能所提供的能力。

站在不同的视角， 人们还可以把技能进行各种其他的分类， 进而形成了一个个bot 的门类。

我平凡而又不平凡的一生

作为由代码组成的软件， 我们bot的生命周期同样避免不了软件工程的宿命：创建，运营，迭代和消亡。

根据bot 所提供能力的复杂程度， 代码实现的复杂程度会有较大的不同，但是创建bot的流程大同小异。以DuerOS生态系统为例，一个bot从创建到上线运行的流程如下：

创建bot，首先要提供关于bot 的元数据，包括：

1. bot 自身的描述性数据，例如，技能的名称，id，图标，说明图例，是否付费等等
2. bot 所支持技能交互的描述性数据，例如，与交互模型相关的意图，槽位，词典等，自定义的点击事件，手势等其他交互对应的数据等；
3. bot 在运行时所需的配置数据，例如，支持运行的终端/终端组类型，服务部署的URL，平台的回调地址， 账户关联的授权地址等等。

所有这些元数据的描述， 如果对原来的web service 有所了解的话， 会发现他们与WSDL 有着类似的味道，区别主要是技能交互的描述性数据， 这也是我们bot 自然语言处理能力的重要输入之一。

技能中具体能力的代码实现，与程序员写其他程序没什么两样，无非是判断，循环，计算和字符串处理，可以用任意的编程语言实现。技能的调试稍显复杂，尤其是端技能的调试步骤会更多一些，因为分布式系统的调试本就不那么简单。在DuerOS系统中， 关于技能调试可以参考《调试DuerOS的智能语音技能》和《Android App 技能在DuerOS的调试方法》。

在调试和部署完成后， 就可以上线提供服务了，如果使用了类似DuerOS 这样的操作系统，和需要通过官方的审核才能上线， 当然， 没有使用类似的系统， 完全是自主实现的bot，也需要在QA的测试和审核通过之后，才能实施上线。

技能上线了，意味我们bot 开始正式提供服务了，面向用户的运营， 面向具体服务的能够增减，Bot 随时都会进入持续迭代的演进流程。由于用户持续使用我们的能力， 迭代演进的周期可能会很长，即使不再迭代，Bot 仍可能运行相当长的时间。但是， 如果出现了服务不可用，或者技能根本没有用户使用， Bot 就是面临下线，往往意味着技能生命周期的终止。

时间是短暂的， bot 的一生也是如此， 我们存在的意义就是是否给人们带来了少许的便利，是否给人们带了些许的欢乐，是否给人们留下了一点儿美好的回忆。