所谓聊天机器人，指的是可以透过文字或语音通讯软体介面，与使用者进行互动对答的自动化程式。不论是经营品牌的企业、中小企业、独立开发者、创业者等，皆希望尝试搭上聊天机器人浪潮推展自家应用或服务。以全台实价登录网站为例，即是在Facebook Messenger、LINE中建立聊天机器人服务，只要使用者对其客服帐号询问地段、房间数等关键字，或是传送目前所在地的位置，可立即回覆该区域附近的成交行情，随手取得所需的资讯。

　　汇聚人潮的通讯软体 掀起聊天机器人热潮

　　其实就聊天机器人的概念而言，Chatbot.tw台湾聊天机器人开发社群发起人Clement Tang认为，就如同早期微软在Office软体中所设计的回纹针小帮手，若遇到操作问题可透过关键字、问题描述来询问，取得原本可能需翻阅操作手册才能找到的解答。近两年之所以受到各行业关注，甚至实作应用，Clement Tang观察，首先是大数据加上人工智慧、机器学习技术，让聊天机器人的「大脑」较以往更显聪明；其次是自然语言处理（NLP）能力，随着语言学与资讯技术的快速进步，自然语言处理与认知发展也跟着进化，可精准解析出语意中的Intent（意图）与Entity（实体），建立模拟人类的对谈模式。最重要的关键则是现代人沟通模式已高度仰赖通讯软体，在台湾相当受欢迎的Facebook Messenger、WeChat、LINE、Telegram等，纷纷投入支援聊天机器人，推动应用发展快速成长。

　　▲运用微软Bot Framework快速打造聊天机器人，只要透过Bot Connector介接各式通讯软体即可，毋须逐一建立。图为微软MVP董是明在T客邦创客Night讲座分享之投影片。

　　也因此开始有人探讨聊天机器人或许可取代App，论点包含：聊天机器人服务感觉更自然顺畅；单一介面，不需再学习即可上手；有学习演进能力，后端采用认知系统，可不断地扩充资料并训练，使聊天机器人更聪明；更重要的是，不需庞大建置费用，即可部署运行。

　　尽管这些论点不无道理，Clement Tang仍强调，如同几年前行动化应用推动网页应用系统App化的浪潮，实际上，并非不再需要架设网站，而是各有不同应用场景。意思是，手机平台较适合互动模式，若单纯执行工作，仍旧需要桌机、平板、笔电，操作浏览器介面较为方便。如今聊天机器人兴起后引发的对谈式商务，着眼点在于新增可接触人群／客层的通道。因此Clement Tang认为接下来应该观察的方式，在于可能因此产生新的入口网，「Kik Messenger创办人曾经提到，通讯软体会成为新的浏览器、聊天机器人会成为新的网站，后端皆为接取云端服务整合运行，这将是新的网际网路时代开端。」

　　整个聊天机器人生态圈，包含前端通讯软体、Bot Builder、人工智慧与机器学习、自然语言处理（NLP）、语音辨识等领域，同时，不同技术的开发平台供应商，皆有提供开发所需的框架（Framework）与工具，例如IBM Watson、微软Cognitive Service等。

　　以IBM Watson为例，在BlueMix云端平台上的WatsonAPI，只要新帐号注册过后，可享有一个月免费试用。网站上有说明文件、SDK、建置套件，在GitHub上亦有开放范例程式原始码可参考，可藉此研究Watson API服务中，适合于营运商务的应用。此外，在GitHub平台上亦可取得微软Cognitive Service旗下的Bot Framework开放原始码范例程式。微软最有价值专家（Microsoft MVP）董是明在T客邦创客Night讲座中分享提到，Bot Framework是2016年微软提出的新服务，协助开发者快速地打造可运行于多平台的聊天机器人。目前Bot Framework为免费提供，以Azure平台帐号登入即可试用。

　　微软Bot Framework服务中包含三大元素。首先是Bot开发工具，微软官方释出的开放原始码SDK，透过GitHub来提供，目前支援的语言，除了微软自家的。NetC#，亦包含网页开发者相当熟悉的Node。js环境。同时，开发工具本身具备模拟器功能，可协助测试与侦错。

　　其次是Bot Connector，可说是整个开发框架中最核心概念。其实Bot Framework设计思维，主要是让开发者尽可能只撰写一次程式码，就得以串接后端多种技术平台的聊天机器人，Bot Connector即扮演很重要的角色；第三是BotDirectory，汇集来自全球开发者自行打造的聊天机器人，透过发布到Bot Framework官方网站上，即可让用户搜寻、直接取用。

　　对开发人员而言，聊天机器人的应用并非为全新技术，主要运行关键是透过个人打造的Web Service介接整合通讯软体，由API来决定Request与Response内容。但问题是，现代使用者采用的通讯平台相当多元，例如Facebook、Skype、Slack等，程式运行逻辑皆有各自规则，无法开发一次即可全数套用。

　　董是明说明，其实通讯软体背后的原理都是透过API传递，但问题是各家的API格式皆不同，例如发送讯息的JSON格式中，描述资料结构的物件名称并未统一，因此Messenger JSON Payload无法直接递送给Skype辨识。如今微软推出的Bot Connector，可在Web Service与通讯平台之间执行转译，亦可排除过去开发Web Service时，直接接取通讯平台造成绑定原生格式的状况。

　　Bot Connector包含在Bot Framework提出的Bot Builder SDK中，可支援.NetC#、Node.js开发环境，并且提供传送讯息撰写Payload格式的规则。开发人员只要完成Web Service开发后，在Bot Framework官方网站上设定串接Facebook、Skype等通道，之后即可交由Bot Connector传送至各个通讯平台。如此一来，只要采用共通的SDK建立各项机制，例如基本传送讯息与回应，根本无须研究各种不同通道的JSON格式，即可最大化重复使用程式码，甚至可能只要撰写一次，就有机会在不同通道上建立聊天机器人。当然，Bot Framework仍有保留特定的属性，让开发人员自行定义更符合企业商业应用场景，抑或是通讯软体本身内建特有的功能项目，在Bot Connector的介接协助下皆可辨识。

　　至于设定方式，只须在Bot Framework官方网站上设定，点选注册聊天机器人，之后须取得API Token的位置、提供的设定参数，皆有线上图文教学，即使以往从未开发过相关应用，也可简单上手，藉此降低进入门槛。