實用Bot開發指南：基于Node.js與Bot架構設計并建構聊天機器人
Practical Bot Development: Designing and Building Bots with Node.js and Microsoft Bot Framework
［美］ 西蒙·羅茲加（Szymon Rozga） 著
陶 陽 董曉甯 吳吉慶 譯
第1章
聊天機器人概述
最近幾年，聊天機器人（chat bot）及人工智能（Artificial Intelligence，AI）成了科技行業的熱門話題和大衆最感興趣的内容之一。聊天機器人是使用自然語言進行互動的計算機程式。它們正在做越來越多的事情，從預定比薩到買衣服，再到停車罰單申訴、談判等。最初，開發一個聊天機器人和開發帶有消息平台的系統一樣，沒有簡單的方法來代表代碼中的對話流。但當微軟建立了Bot架構和Bot Builder SDK時，這種情況發生了變化。微軟為開發者建立了一個豐富的開發環境，該開發環境使開發者得以從與各獨立通道內建的關注中解放出來，并專注于編寫執行聊天機器人需要完成的對話任務的代碼。微軟提供的Bot Builder SDK提供了一種開發對話體驗的通用方法；Bot Connector實作了把通用消息格式轉換成特定通道的業務邏輯。
這也使聊天機器人開發對廣大開發者來說變得更加容易和便捷。工程師不再需要了解輸入輸出與諸如Facebook的Messenger API或Slack的Web API之類的開發接口進行內建的細節。相反，開發人員隻需專注于核心的機器人邏輯和對話體驗，其餘的事情由微軟提供的開發工具來解決。
Bot Builder SDK支援.NET和Node.js，并且以MIT開源軟體許可協定在GitHub上開發維護。微軟的機器人開發團隊在版本開發以及響應開發者提出的各種問題方面非常積極活躍，同時他們對新手非常友好。
2017年12月，微軟宣布Bot架構和語言了解智能服務（Language Understanding Intelligence Service，LUIS）在Azure門戶對開發者公開釋出。LUIS是微軟提供的自然語言服務，它使開發者開發的機器人能夠了解自然語言，具備對話方面的智能；Bot架構現在也稱為Azure Bot Service，二者含義相同。顧名思義，Azure Bot Service現在是Microsoft Azure雲産品的成熟部分。此外，微軟還提供了免費的服務層次，是以我們可以根據自己的内容來使用架構。本書所有的樣例和技術都可以在Azure上免費試驗。
過去幾年，微軟、Facebook、Google等科技巨頭以及很多小型公司一直在緻力于建立最好且最易于使用的聊天機器人開發架構（chat bot development framework）。可以看到，這個領域的變化性很強，各種架構來來去去，似乎日新月異。然而盡管領域一直在動态變化，微軟的Bot架構始終是開發功能強大、快速且靈活的聊天機器人的最佳平台。我很激動能帶大家使用此工具進行聊天機器人開發之旅。
1.1 對機器人的期望
兩年多以來，我與客戶的大部分溝通都集中在讨論機器人功能，它們是什麼以及（尤其重要的是）它們不是什麼。事實上，目前的現狀是人們在很大程度上可能會把聊天機器人的能力與人工智能混淆。原因很容易了解：一些聊天機器人使用豐富的自然語言功能，這使人們對它們有更高、更多的期望；此外，基于語音的數字助理（如Cortana、Alexa和Google智能助理）出現在人們的家中，并且人們會将其當作真人來進行對話。那麼，聊天機器人為什麼不能展現出更多的智能呢？
除此以外，相關新聞也激發了人們極大的興趣。比如，IBM的Watson在美國著名的益智問答電視節目《Jeopardy》上進行挑戰；谷歌大腦（Google Brain）團隊在語言翻譯方面使用深度學習所取得的成績登上了《紐約時報》專題；自動駕駛技術；AlphaZero僅使用四個小時學習如何下國際象棋便打敗了世界第一國際象棋引擎Stockfish。
這些新聞加大了社會對這些技術的投資和興趣，也預示着我們正走向人工智能驅動的人機互動方式。AI領域的技術發展改變了我們的互動方式，同樣改變了我們對技術的期望和要求，為裝置賦予人的屬性和能力變得越來越普遍。科幻小說家阿西莫夫的“機器人三定律”是機器人遵守的一套可以確定機器人友善待人而不會追逐傷害人類的規則，認知和科幻領域中的思想家一直在努力解決該定律所述内容的可能性。目前在現實世界中已經有一些明确而具體的人工智能執行個體，我們離科幻小說裡的那種現實似乎更加接近了。
然而，現實與人工智能在一些非常具體的問題領域所取得的成就并不相符。盡管我們已經在自然語言處理、計算機視覺、情感檢測等方面取得了巨大飛躍，但我們還沒有把握将這些技術組合在一起來形成一個類似人的智能，即通用人工智能（Artificial General Intelligence，AGI）。同樣，讓聊天機器人實作通用人工智能也不是一個切實可行的目标。對于每一篇慶祝人工智能領域巨大成就的文章，都有一篇相關的文章對該技術的炒作進行了抨擊，并且舉出執行個體說明為什麼這種類型的AI距離完美、通用的人工智能依舊任重而道遠（比如那篇展示計算機視覺算法在文中所有執行個體圖像上均無法正确分類的文章）。是以，對于任何被媒體炒作的技術，我們必須為其設定合理的期望和要求。
機器人在和使用者對話時能達到具有人類水準的智能嗎？答案是不能！給定相應的技術和任務，機器人可以很好地完成這些任務嗎？答案是當然可以！本書旨在為讀者提供必要的技能，以建構引人注目、引人入勝且有用的聊天機器人。工程師可以自己決定在開發聊天機器人的過程中加入多少最新的AI技術。不過，這些技術對于一個好的聊天機器人來說也不是必需的。
1.2 什麼是聊天機器人
在最基本的層面上，聊天機器人（在本書後續内容中簡稱為機器人）是一種計算機程式，可以将使用者的自然語言作為輸入并将文本或富媒體作為輸出傳回給使用者。使用者通過消息傳遞應用與聊天機器人交流，比如Facebook Messenger、Skype、Slack等；或者通過語音喚醒裝置進行交流，比如Amazon Echo、Google Home以及由微軟Cortana提供支援的Harmon Kardon Invoke等。
圖1-1展示的是我們使用微軟Bot架構建構的第一個機器人。該機器人在輸入資訊前加上“echo:”字首，再傳回給使用者，在Bot架構上可以輕松實作這種像Hello World一樣簡單的業務。
這個機器人非常基礎，而且沒什麼功能。我們可以繼續建立一個Youtube機器人，它接受使用者的文本輸入，搜尋該主題的視訊，并将視訊的連結傳回給使用者（如圖1-2和圖1-3所示）。
和圖1-1的機器人一樣，Youtube機器人隻能做一件事，也非常基礎。它的邏輯是通過與YouTube API內建，将使用者的文本輸入用作搜尋參數，然後将Bot架構中稱為卡片（card）的内容傳回給使用者，我們将在本書的後面部分對此進行探讨。給使用者提供圖像可以使應用更豐富、更具吸引力，這些應用很有趣，但依然非常基礎。
Youtube機器人的代碼實作如下，它向Youtube發送請求，并将接收的響應從YouTube格式轉換成Bot架構的卡片格式。
我們還可以繼續建立第三個機器人，給定一段陳述，它能區分出這段陳述是中性的、積極的還是消極的，并進行相應的應答，如圖1-4所示。這個機器人和前面兩個例子一樣簡單：我們調用情感REST API擷取情感得分值，并使用該得分值作為答案進行應答，該機器人的實作代碼不再贅述。
根據該示例可以看出，在機器人中內建AI是一件容易的事。另外，機器人不必拘泥于提問-應答模式（question-response pattern），也能主動和使用者溝通，比如我們可以建立一個欺詐報警的機器人，如圖1-5所示。
機器人可以更多地由任務驅動。例如，月曆機器人可以建立約會、檢視是否有時間、編輯或删除約會，并将使用者的個人月曆進行歸納總結，如圖1-6所示。
上面的例子都是一些簡單任務，下面我們将把自然語言了解功能納入到機器人中。
1.3 為什麼是現在
為什麼機器人現在變得越來越重要？其實，在以前的應用程式中就存在機器人的影子，比如IRC和美國線上（AOL）的Instant Messenger。IRC機器人誕生時間比較早，我也在IRC上試過與很多機器人進行互動。由于當時在技術方面積澱不深，我最初認為有一個真實的人回應我的資訊，但我很快意識到是一個程式在答複我寫的東西；和IRC機器人互動得越多，我越覺得這種互動就像是在執行某些指令行操作。然而，這在當時都是非常小衆的技術，并且人們也不需要每天都和機器人互動，是以當時的機器人根本沒必要滿足能用自然語言進行互動的需求。
現在，新技術帶來了與以前完全不同的互動方式，新技術主要有以下三種：AI技術、将消息應用程式（messaging app）作為智能對話平台的理念，以及語音喚醒的對話接口。
1.3.1 人工智能取得的進步
縱觀整個20世紀，計算機科學家、生物學家、語言學家和經濟學家在認知、人工智能、人工生命、機器學習和深度學習等領域取得了巨大進步。用計算機程式執行計算機指令的概念，通用圖靈機（Universal Turing Machine），存儲代碼并通過接收輸入和産生輸出來執行代碼的計算機體系結構的思想，以及馮·諾依曼體系結構，這些都是人類曆史中的新興“标準”，但也是我們利用計算機進行工作的基石。1943年，McCulloch和Pitts在論文“A Logical Calculus of the Ideas Immanent in Nervous Activity”中首次發表神經網絡（neural network）的思想。1950年，科幻小說家阿西莫夫在小說《我，機器人》中從想象的角度總結了“機器人三定律”。同年，第一篇描述計算機如何下象棋的論文“Programming a Computer for Playing Chess”發表了，論文作者Claude Shannon同時也開創了資訊論這一計算機學科領域。1960年以來，計算機科學研究中所取得的進步令人興奮，從媒體封面對最新AI應用的報道就可見一斑。
自1960年以來，機器學習和使用算法構模組化型的特性都得到了提升，并且更加可用；Python機器學習庫scikit-learn和谷歌Tensor Flow的開發者社群活躍度非常高，文檔支援十分完善；科技巨頭公司在提升計算能力方面不斷加大投入，以保證能用可接受的合理時間完成一些計算密集型任務；Microsoft、Amazon、Google、IBM通過不同的方式投入雲平台的建設中，并且下一步在雲上提供機器學習算法。比如在編寫本書時，微軟認知服務（Microsoft Cognitive Service）僅提供30多個API供開發者調用。開放的API包括人臉識别、情感檢測、内容稽核、光學字元識别（OCR）等計算機視覺工具，也包括諸如自然語言處理、語言和文本分析、自然語言了解等工具，甚至還包括推薦引擎（recommendation engine）、語義搜尋（sematic search）等檢索和知識了解工具。開發者通過合理的成本就能接入微軟認知服務、實作更強大的功能，這種可用性使得目前的智能系統在大衆的生活中越來越普遍，同時也是我們在開發機器人時利用的最重要的底層基礎設施。我們将在第10章介紹微軟認知服務。
1.3.2 作為智能對話平台的消息應用程式
移動消息應用近年來非常流行和普及，Snapchat、Slack、Telegram、iMessage、FB Messenger、WhatsApp以及微信（WeChat）成為使用者手機移動端上最常用的應用程式，它們的使用率甚至超過了像Facebook這樣的社交網絡。Business Insider分析顯示，移動消息應用的使用率在2015年第一季度首次超過社交網絡，并持續至今。我們也發現亞洲的消息應用程式（如微信和LINE）已經找到了通過聊天應用增加使用率的方式，以及從流量中獲利的方式；Apple、Twitter和Facebook等公司通過向開發人員開放開發者接口甚至內建支付功能等方式一直在引領潮流。總體而言，開放消息平台通路接口的趨勢十分流行。
在消息平台上托管機器人可以吸引更多開發者加入；應用程式開發需要考慮使用者體驗（UX），而機器人開發者不需要像移動應用開發者那樣關注記憶體管理、UI動畫互動等内容，隻需關注機器人和使用者之間的對話即可。值得注意的是，機器人并不僅僅包含文本資訊互動，還包括圖像、視訊、聲音以及調用其他指令的按鈕等内容。機器人的對話受消息平台所支援的功能的限制，微軟的Bot架構中內建了必需的開發元件，可以最大化利用消息平台支援的功能。
1.3.3 語音喚醒的智能助理
另一個使對話智能迅速興起的原因是語音喚醒裝置的快速發展。虛拟語音助理Siri于2011年由Apple推出，現在早已家喻戶曉，它由Dragon NaturallySpeaking這一最著名的桌面語音識别系統支援。該系統由Nuance開發，以幫助Siri實作“語音-文本”轉換。
Siri是第一個進入市場的語音助理，并推動了其他科技巨頭的參與熱情。微軟在2014年釋出了語音助理Cortana（微軟小娜）；同年，亞馬遜推出Amazon Echo。Cortana最初僅在Windows Phone和Windows系統上發行，後來移動端甚至Xbox也都可用；亞馬遜的Echo采用Alexa語音助理，是第一款成功商業化的語音硬體裝置，亞馬遜由此主導了早期語音助理的市場。在随後幾年，Facebook和Google分别推出了M（已經于2018年初關閉）和Google Assistant。Google同時推出了Google Home并加入到語音裝置市場的争奪戰中。Harman Kardon釋出了由Microsoft Cortana支援的語音裝置Invoke。還有更多的公司正在持續地進入語音裝置的市場，進一步推動技術創新。
語音助理市場之是以活躍是因為人工智能、語音識别、自然語言處理、自然語言了解技術發展迅速。這些技術為在消息平台上建立自定義功能提供了标準、架構和工具。我們會在後文中看到，這些自定義功能均可以在機器人中實作。
1.4 建立聊天機器人的動機
我們為什麼要編寫機器人，并且使用消息應用程式作為對話平台？我們明明可以編寫一個移動應用程式，然後釋出到應用程式商店，這樣不可以麼？因為使用者的行為中存在各種傾向，是以這種方法不可行。
對于一些廣為使用的事務，下載下傳相應的應用程式自然是最快捷的方式。比如，想使用Facebook可以直接下載下傳該應用程式；想查閱郵件可以直接下載下傳郵件應用程式。但是，對于一些輕量級的事務，比如使用者想了解附近花店的一些資訊，此時根本不需要一個專門的應用程式來做這件事，為每個單一的事務下載下傳一個應用程式對使用者而言是不可接受的。顯然，隻需要向花店緻電或者發送短信就足夠了。
很多公司的業務中包含了B2C。以Facebook為例，一家當地花店可以注冊一個Facebook首頁，并在首頁上釋出消息，業務員可以對某一客戶的查詢請求做出回複；無獨有偶，Twitter則對外提供了全新的Direct Message API，它為Twitter帶來了巨大的商業價值。這種不需要下載下傳應用的方式讓業務更簡單、快捷，機器人就是這種免下載下傳免安裝模式，消息平台在這個過程中負責使用者識别、身份驗證、整體應用穩定性等。
機器人同樣改變了其他用例場景，比如效率工具Slack。Slack是一個出色的工作協作平台，能夠讓大家在不同的聊天主題中交流和協作。機器人可以讓Slack更加高效，圖1-7展示了Slack平台上一些排名靠前的機器人，這類機器人專注于工作中的任務，比如待辦事項、站會（站立式會議）、任務配置設定等。顯然，如果工作團隊完全使用Slack來溝通協作，那麼将普通的工作任務交給機器人去做可能比建立專門的網站去做更加高效。
雖然Slack的清單中包含一個名為Bots的特定類别，但事實上所有這些應用程式都是機器人。其中一些可能更擅長對話，而另一些則可能給人以更多的指令行感覺；就我們而言，機器人隻是在聽取消息并對其采取行動。針對比較擅長對話的聊天機器人，自然語言了解的内容以及與了解人類語言有關的學科，對使用者體驗來說至關重要。是以，我們将第2章和第3章專門用于探讨這項内容。
1.5 機器人的組成
我們将機器人的開發分解成獨立的部分。在下面的介紹中，本書采用在開發時最常使用的概念進行描述，并重點介紹在微軟Bot架構中開發機器人的方式。具體包括以下内容：
- 機器人運作庫
- 自然語言了解引擎
- 對話引擎
- 通道內建
1.5.1 機器人運作庫
最基本的，聊天機器人是一個響應使用者請求的Web服務。盡管內建的消息平台有所差異、實作細節有所不同，但核心思路是相同的：都是消息平台通過HTTP端點來調用機器人，并在消息中包含使用者的輸入。機器人處理收到的消息，并做出響應，響應消息中包含了附件内容和與消息平台相關的資料。圖1-8描述了一種通用的處理方法。依據消息平台的特點，使用者可能會收到對應的異常，異常裡包含HTTP狀态代碼或其他異常代碼。機器人處理消息時，通過調用通道（channel）的HTTP端點來響應。然後，該通道将響應消息傳遞給使用者。
圖1-8中所示方法的缺點在于它将機器人局限于一個特定的消息釋出通道。實際上，我們希望開發的機器人具有與通道無關的特性，以便最大限度地重複使用機器人中的邏輯。Bot架構通過在消息平台和機器人之間提供一個通道連接配接器（channel connector）服務來彌補該缺點，是以實際應用中的互動過程更像如圖1-9所示的過程。可以看到，通道連接配接器掌管了機器人與消息平台的連接配接、通信，并将消息轉換成機器人可以識别的通用資料格式。我們将在1.5.4節對通道進行更為詳細的介紹。
由于機器人運作庫本質上就是一個監聽HTTP端點請求的程式，是以開發者可以使用任何允許我們接收HTTP消息的技術來開發機器人，比如.NET、Node.js、Python和PHP。盡管連接配接器為開發者提供了開發便利和優勢，并且開發者可以自由地選擇實作HTTP端點的方法，但是我們可以繼續使用Bot架構的另一個元件Bot Builder SDK，以使開發更便捷。我們将在1.5.3節介紹Bot Builder SDK。
1.5.2 自然語言了解引擎
由于人類的語言是非結構化的輸入資料，語言内容非常靈活并且沒有一緻的規則，是以編寫一個能了解人類說話内容的機器人是一項非常具有挑戰性的工作。機器人要具備可用性就必須能接收人類的語言輸入并了解語言内容。自然語言了解（Natural Language Understanding，NLU）引擎可以幫助開發者解決了解自然語言過程中的兩大問題：意圖分類（intent classification）和實體抽取（entity extraction）。
下面通過一個例子來說明意圖和實體是什麼。假設我們要開發一個恒溫控制機器人，并且設定四個動作：開關打開、開關關閉、設定模式（制冷或加熱）、設定溫度。使用者語言中描述的這四個動作類型就是意圖；而其所處的模式（冷、熱）和溫度值就是實體。自然語言了解引擎支援開發者自定義一系列與機器人應用相關的意圖和實體。表1-1列舉了一些典型的“語言-意圖-實體”映射的例子。
顯然，我們的代碼更容易處理基于意圖和實體實作的邏輯關系，而不是直接基于原始的使用者語言。
機器人開發者可以通過多種服務實作自然語言了解功能。目前，許多雲端API都提供了自然語言了解功能，如LUIS、Wit.ai和Dialog f?low等，其中LUIS是我們認為提供功能最為豐富、性能表現最好的，第3章将深入探讨自然語言了解的主題。
1.5.3 對話引擎
在建構機器人時，我們通常會設計一個工作流程來實作我們想要機器人完成的任務。比如，接着上面恒溫控制機器人的例子，它的架構和邏輯如圖1-10所示。
機器人的工作流程總是從監聽使用者的自然語言輸入開始，使用者說出的話語将被解析成表1-1中的意圖：如果意圖是“開關打開”或者“開關關閉”，那麼機器人就能正确地執行邏輯，并且響應一個确認資訊；如果意圖是“設定溫度”，那麼機器人會驗證溫度實體是否存在，如果不存在則會請求一個溫度值（即實體），在使用者用語言輸入溫度值之後，機器人同樣會正确地執行邏輯，并且響應一個确認資訊。“設定模式”和“設定溫度”的邏輯相似，因為它同樣會驗證明體的存在性，并且在不存在的時候向使用者請求實體。
在聊天機器人中，對話就是機器人對使用者的輸入做出響應；對輸入、輸出和轉換的類型進行設計的過程稱為對話體驗設計（conversational experience design），我們将在第4章深入介紹該部分内容。
對話引擎負責監聽輸入消息、處理消息，以及執行兩個對話節點之間的轉換。對話引擎獨立處理每個使用者的消息輸入，并且存儲使用者的對話狀态，在使用者下一次發起對話時可直接查詢到使用者的對話狀态。微軟Bot架構在Bot Builder SDK元件中提供了性能優秀的對話引擎。
旁白：意圖、實體、行動、老虎機，哦，我的天！
機器人的開發方法可以總結為兩類：機器人引擎和機器人對話即服務（bot conversation as a service）。機器人引擎方法在前文已講述過：我們将機器人作為Web服務運作，根據需要調用NLU平台，并使用對話引擎将消息傳遞給對話框。下面講述機器人對話即服務的方法，該方法得到了Dialogf?low之類的廣泛推廣。機器人對話即服務方法将NLU解析、對話映射（conversation mapping）等流程全部內建在雲端Dialogf?low的基礎設施上，然後，Dialogf?low調用機器人來修改響應或與其他系統內建。
使用者的語言映射到意圖和一系列定義的實體上的過程稱為動作（action），一個動作包含一個意圖和一系列動作參數。再次回到恒溫器機器人的例子中，我們可以定義一個“SetTemperatureAction”的動作，該動作包含一個“SetTemperature”意圖和一個“Temperature”實體。當Dialogf?low解析一個動作時，它可以調用機器人來執行動作。在第二種方法中，對話引擎的功能被外包給NLU服務，機器人在這種方法中更加關注NLU服務的執行邏輯。
機器人對話即服務的機器人開發方法的一個關鍵内容是插槽填充（slot f?illing）。插槽填充是一個過程：一個服務會檢測到動作（意圖和動作參數）僅被使用者輸入填充了一部分，并自動地要求使用者填充未被填充的剩餘部分—動作參數。表1-2和表1-3展現了兩個動作示例。
圖1-11描述了使用者、消息平台、連接配接器、NLU服務以及機器人這一完整的端到端流程，機器人在該對話中為服務模型。
機器人對話即服務的開發方法運作更快，但靈活性稍差，使用Bot架構可以讓我們掌控機器人引擎，進而解決這些問題。
1.5.4 通道內建
建構機器人時要考慮與多種消息平台進行內建。舉個例子，你的老闆讓你負責編寫一個Facebook Messenger機器人，你完成并釋出了它，老闆為你的工作喝彩，但接着又提出了新需求：“能否把這個機器人作為網絡聊天機器人嵌入到公司的FAQ頁面上？”Facebook Messenger機器人的代碼是與Messenger Webhooks和Send API相關聯的，怎麼實作第二個任務呢？我們可以将一些與Messenger通信的邏輯獨立出來，建立同一接口的第二個實作—通過Web套接字與聊天機器人通信，此時我們便實作了機器人和消息平台之間的接口抽象。
通過上面的例子，可以看出我們希望讓機器人盡可能地與消息平台獨立。這樣，如果開發者不是機器人架構底層的基礎設施開發人員，不負責建構不同消息平台下的連接配接器，那他們就不需要關注如何從通道接收消息以及發送響應等細節。本書面向的對象是機器人開發工程師，而不是基礎設施開發者。幸運的是，市場上不同的機器人架構都幫我們實作了與消息平台獨立這一需求，如圖1-12所示。這些架構都允許我們編寫與通道無關的機器人，然後通過一些簡單的操作連接配接到這些通道。這種與通道無關的功能通常稱作通道內建。
因為消息平台版本功能太新或者消息平台過于特定，是以無論哪種機器人架構都做不到面面俱到—都有無法支援某些功能或某個消息平台的短闆，這種短闆與許多通用架構的情況類似。此時，機器人架構應該支援開發者以原生格式與平台進行通信。微軟機器人架構（Microsoft Bot Framework）就提供了這樣的機制。
此外，機器人架構應該非常柔性靈活，以支援開發者建立自定義通道的連接配接器。舉兩個例子，如果開發者想建立一個提供聊天機器人界面的移動應用，那麼機器人架構應該支援該功能；如果企業使用的即時消息通道不被内建的連接配接器支援，那麼機器人架構應該支援讓開發者自己建立一個對應該消息平台的連接配接器。微軟機器人架構通過Direct Line API支援這種級别的內建。
我們将在第9章和第10章深入介紹有關通道和自定義通道內建的内容。
1.6 結束語
在本章中，我們快速浏覽了用于建構機器人的幾個元件。在我個人的實際工作中，使用對話即服務方法的微軟Bot架構明顯勝過其他的機器人架構，它的靈活性能滿足諸多企業場景的需求；Bot架構同時提供了更好、更豐富的抽象概念，以及更深層次的通道內建和非常開放、活躍、多元的技術社群。微軟的Bot架構團隊為開發者創造了一個功能十分強大的開發套件，它可以作為任何聊天機器人的底層開發架構。我和我的團隊使用微軟Bot架構已經超過了2年，Bot架構的對話引擎和連接配接器特性已經被證明可以适用于我們所采用的任何用例。
考慮到上述原因，本書使用微軟Bot架構作為首選架構進行介紹。微軟Bot架構支援C#/.NET和Node.js，在本書中我們使用Node.js；另外，不需要使用像TypeScript或CoffeeScript之類的其他工具，我們隻需使用簡單的JavaScript即可展示使用Node.js版的微軟Bot架構SDK（即Bot Builder）時，編寫機器人是多麼簡單和直接。
無論是否存在技術炒作，與機器人相關的開發技術确實發展迅猛，令人驚歎。本書不僅涵蓋了機器人開發的基礎知識，還帶領讀者了解了一些背後的基礎技術和方法。當然，本書不會深入研究背後的底層技術，隻保證讓讀者大緻了解如何實作聊天機器人中的智能，以便更輕松地探索更複雜的使用場景。另外，對于涉及的重點内容，本書将提供參考連結和文獻作為補充性閱讀材料，以友善讀者了解。我雖然不是資料科學家，但我在本書中盡力引入了相關的機器學習概念。
我們即将開始技術之旅：對話設計、自然語言了解、與機器人相關的機器學習……在我們介紹這些内容以及建構機器人時，請記住這些技術不僅适用于聊天機器人，同樣适用于語音助理。随着自然語言互動和語音互動在家庭和工作場所變得越來越普遍，我保證本書中的技術既會應用于目前的工程項目也會在未來應用到與自然語言相關的應用程式中。讓我們開始吧！