热水bot协议_如何设计Bot协议
热水bot协议
by Alex Bunardzic
由Alex Bunardzic
如何设计Bot协议 (How to Design a Bot Protocol)
One of the biggest fallacies about the present bot craze is that bots need to be capable of offering nuanced, sophisticated conversational experience (How does your bot say ‘ketchup’?). That sentiment is completely unsubstantiated, and is probably based on seeing too many fancy Hollywood sci-fi movies.
当前机器人热潮最大的谬误之一是，机器人必须能够提供细微的，复杂的对话体验( 您的机器人怎么说“番茄酱”？ )。 这种情绪完全没有根据，可能是因为看了太多看中的好莱坞科幻电影。
In reality, bots are merely an extension of the regular human behavior that we can observe in various social situations. And because bots are yet another of the many ways we go about automating information processing, they obey the exact same constraints that other software products obey as well. In a word, bots obey certain behavioral pattern known as communication protocol.
实际上，机器人只是人类在各种社会情况下可以观察到的常规人类行为的延伸。 而且由于bot是我们实现信息处理自动化的众多方式中的另一种，因此它们遵循与其他软件产品完全相同的约束。 一言以蔽之，机器人遵循某些被称为通信协议的行为模式。
什么是协议？ (What is a Protocol?)
When two parties communicate, they do so by exchanging messages. That process of messaging could be primitive, as in sending smoke signals:
当两方通信时，他们通过交换消息进行通信。 消息传递过程可能很原始，例如发送烟雾信号时：
Or, it could be more advanced, less messy, such as for example making a phone call, or sending a text message.
或者，它可以更高级，更不混乱，例如打个电话或发送短信。
Regardless of the mechanism being used to exchange messages, what is really critical is the mutual agreement and understanding by all involved parties regarding the meaning of each message. What is of paramount importance in all such scenarios is avoiding free form, loosey-goosey chitchat.
无论使用哪种机制来交换消息，真正关键的是所有相关各方之间就每个消息的含义达成共识并达成共识。 在所有此类情况下，最重要的是避免自由形式，松散的混音。
Consider a typical exchange of messaging that occurs when a pilot is approaching the air traffic control tower. It would be extremely hazardous in such dangerous situations to allow for the pilot and the air traffic control operator to engage in open-ended, unstructured banter. Instead, they follow a predefined, predetermined communication protocol.
考虑当飞行员接近空中交通管制塔时发生的典型消息交换。 在这种危险情况下，让飞行员和空中交通管制操作员从事不限成员名额，无组织的玩笑将是极其危险的。 相反，它们遵循预定义的，预定的通信协议。
Each sentence uttered by either the pilot or the traffic control officer always ends with the keyword ‘over’. That keyword signals to the other party that the person who was talking has finished talking and is now listening with undivided attention. Furthermore, the person who was doing the listening always begins their talking with the keyword ‘roger’ (or ‘roger so far’), signalling that they have fully understood what the other person was saying (sometimes ‘roger’ can be replaced with ‘wilco’, implying ‘will comply’, meaning that the message was received loud and clear).
飞行员或交通管制员说的每句话总是以关键字“ over”结尾。 该关键字向另一方发出信号，表示正在通话的人已经结束通话，现在正在全神贯注地聆听。 此外，正在聆听的人总是以关键字“ roger”(或“ roger so到目前为止”)开始交谈，表示他们已经完全理解了对方在说什么(有时可以用“ roger”代替“ wilco”，表示“将遵守”，表示该消息已被清晰清晰地接收到。
As is quite obvious from the above example, communication protocol that is implemented in highly hazardous situations (such as landing an airplane) must by necessity be extremely constrained and rigid. No deviation in the syntax of the messages being exchanged is allowed. Strict adherence to such rules assures clear, unencumbered communication.
从以上示例中可以很明显地看出，必须在高度危险的情况下(例如，降落飞机)实施的通信协议必须严格限制和严格执行。 不允许交换消息的语法。 严格遵守此类规则可确保清晰，无障碍的沟通。
紧急情况下的协议 (Protocols in Less Critical Situations)
Not all situations where people communicate are as critical and potentially dangerous as landing an airplane. Still, it does not necessarily mean that it is okay to throw all caution to the wind when dealing with communication issues in less intense situations.
并非所有与人交流的情况都像降落飞机一样关键和潜在危险。 但是，这并不一定意味着在不那么紧张的情况下处理沟通问题时，可以全力以赴。
Consider for a moment how people communicate when crossing the border. Upon approaching the border, travellers get interrogated by the border crossing officer. It is the officer who sets the tone of the conversation, and travellers are best advised to comply and follow the officer’s lead. That means answering all questions with short, pointed sentences, often with terse ‘yes’ or ‘no’ statements. Such an impromptu established protocol ensures smooth and efficient border crossing, while allowing security officers to perform their duties without a hitch.
考虑一下人们越过边界时如何交流。 接近边界后，过境人员对旅客进行了讯问。 谈话的基调是官员，最好建议旅客遵守并遵循官员的领导。 这意味着用简短而尖锐的句子回答所有问题，通常用简洁的“是”或“否”陈述。 这种即兴建立的协议可确保顺利和有效地过境，同时使安全人员能够顺利完成任务。
Most people don’t seem to have any problems picking up on such cues, and are typically following the proposed impromptu protocol without any difficulties.
大多数人似乎都没有遇到任何问题，并且通常遵循提议的即兴协议而没有任何困难。
Or, consider an even less critical situation, such as the communication protocol that occurs when we enter a social function of some sorts (for example, an evening at the theatre). Upon entering the theatre, we get greeted by the concierge. It is the concierge that sets the tone of the conversation, and most people gladly comply. This compliance ensures smooth and effective service, as we get greeted and subsequently get ushered into the building. A few short, courteous sentences get exchanged before we are shown the coat check area and are then led to our seats.
或者，考虑一个不太紧要的情况，例如当我们进入某种社交功能(例如，在剧院的一个晚上)时发生的通讯协议。 进入剧院后，礼宾部迎接我们。 礼宾部决定了谈话的基调，大多数人都乐于遵守。 当我们受到欢迎并随后被引入大楼时，这种合规性确保了流畅，有效的服务。 在向我们展示大衣检查区，然后将它们引导到我们的座位之前，我们交换了一些简短的礼貌用语。
协议设定了对话的基调 (Protocol Sets the Tone of the Conversation)
Regardless of how intense, or how relaxed the conversation may be, there is always an underlying, often times tacit communication protocol. Even when doing some leisure shopping, we notice how the conversation between the customers and the staff obeys certain more or less formal communication protocol.
无论对话有多激烈或多么轻松，总会有一个基础的，通常是默认的默认通信协议。 即使在休闲购物时，我们也会注意到客户与员工之间的对话是如何遵循某种或多或少正式的通信协议的。
It is usually that people who lack social skills and who disobey those tacit protocols get viewed and judged as being obnoxious and unpleasant. So we see that complying with pre-established protocols is a sign of well adjusted behaviour.
通常，缺乏社交技能并且不遵守这些默契的人会被视作并被判断为令人讨厌和不愉快。 因此，我们看到遵守预先建立的协议是行为得到良好调整的标志。
It is also usually the serving side of the interaction (such as a receptionist at the doctor’s office, or a host at the social function etc.) who sets the protocol and the tone of the conversation. If there are any hard and fast rules that must be interjected into the conversation, such rules are brought up at the very outset of the conversation. By bringing up any rules, the serving party sets the formal tone of the conversation, and is also then responsible for handling any issues, exceptions and oddities that may occur during the session.
通常，交互的服务方(例如，医生办公室的接待员或社交功能的主持人等)设置会话的协议和语气。 如果必须在对话中插入任何严格的规则，那么这些规则会在对话开始时就提出来。 通过提出任何规则，服务方可以设置会话的正式语调，然后还负责处理会话期间可能发生的任何问题，例外和奇怪情况。
The important thing to note is how natural, how normal this upfront setting of the tone feels to us. Whenever we find ourselves in a situation where no tacit rules and no specific protocol had been set, we tend to feel uneasy, unsure what our next move should be.
需要注意的重要一点是，这种音调的前期设置对我们来说感觉有多自然，多正常。 每当我们发现自己没有设置默认规则和特定协议的情况时，我们都会感到不安，不确定下一步应该采取什么行动。
机器人必须设置协议 (Bots must set the Protocol)
Despite some of the recent excitable and exaggerated claims, mainstream emergence of bots is not a revolutionary technological advancement. Mainstream bots are a mere evolutionary extension of our regular and ongoing attempts to automate as many mundane tasks as possible.
尽管最近有一些令人兴奋和夸大的说法，但机器人的主流出现并不是革命性的技术进步。 主流机器人只是我们对常规和正在进行的尝试进行的扩展，这些尝试是使尽可能多的普通任务自动化。
As a matter of fact, bots are not really all that different from the good old crusty GUI applications. Recall how, any time we login to a GUI app, we are obeying certain communication protocol. The app sets the tone, and is guiding us through the experience. The only difference between the GUI apps and the bots is that with the GUI (as the name implies), most of the messages that are presented to us by the underlying service are pictorial/graphical. With bots, most of the messages presented to us by the underlying service are textual.
实际上，僵尸程序与旧的硬壳GUI应用程序并没有太大区别。 回想一下，每次登录GUI应用程序时，我们都遵循某些通信协议。 该应用程序设定了基调，并通过经验指导了我们。 GUI应用程序和机器人之间的唯一区别在于，使用GUI(顾名思义)，底层服务向我们提供的大多数消息都是图形/图形的。 借助漫游器，基础服务向我们提供的大多数消息都是文本消息。
And if we scratch the surface on GUI apps, we realize that all those graphical representations actually get translated into textual commands and then get sent to the back-end service for processing. For example, if I am communicating with a bot, I can say: “Get me the status of my order.” And if I am communicating with a GUI app, I can click/tap on the “Order status” link, and that action will get converted by the browser into a textual statement — something like “GET http://domain.com/user/1/order?id=42 HTTP/1.1”. In both cases (GUI and the bot), the response will come back as text. Same difference, really.
而且，如果我们在GUI应用程序上抓了表面，我们就会意识到，所有这些图形表示实际上都已转换为文本命令，然后被发送到后端服务进行处理。 例如，如果我正在与机器人通信，则可以说：“获取我的订单状态。” 而且，如果我正在与GUI应用程序通信，则可以单击/点击“订单状态”链接，然后该操作将被浏览器转换为文本语句，例如“ GET http://domain.com/user” / 1 / order？id = 42 HTTP / 1.1”。 在这两种情况下(GUI和漫游器)，响应都将以文本形式返回。 真的一样。
The only substantial difference is, when communicating with bots, I can rely on my intuitive grasp of the natural language, while if I wanted to send a text message to the GUI app, I would have to gain formal training in how to formulate syntactically correct string which the back-end service will understand.
唯一的实质区别是，当您与机器人进行交流时，我可以依靠对自然语言的直观了解，而如果我想向GUI应用发送文本消息，则必须接受有关如何正确表达语法的正式培训。后端服务将理解的字符串。
But the main point remains — both the GUI apps and the bots set the communication protocol and set the tone. It is definitely not the user who sets the tone. The user either obeys the proposed protocol and complies with the tone of the conversation, or abandons in frustration all attempts to enjoy the available service.
但是要点仍然是-GUI应用程序和机器人均设置通信协议并设置基调。 绝对不是由用户来设置音调的。 用户要么遵守提议的协议并遵守对话的语调，要么沮丧地放弃所有尝试享受可用服务的尝试。
This may sound rude and inconsiderate on the first pass, but it is actually a desirable thing. As we’ve seen, clear, unambiguous and coherent communication is absolutely not possible without establishing crisp boundaries by setting the tone and defining some ground rules. Otherwise we risk the danger of ending up with some blabbering mess of a system that is neither good for the end-users nor for the businesses offering the services.
乍一看，这听起来可能很粗鲁和不加考虑，但实际上这是可取的事情。 如我们所见，如果不通过设置基调和定义一些基本规则来建立明确的界限，则绝对不可能实现清晰，明确和一致的沟通。 否则，我们冒着最终导致系统混乱的危险，这既不利于最终用户，也不利于提供服务的企业。
企业看重什么？ (What do Businesses Value?)
If you’re responsible for running a business, then you’re most likely going to agree with the statement that one of the most important things in business is predictability. No one likes to be in the position of uncertainty, especially if a lot of other people’s future might be at stake.
如果您负责开展业务，那么您很可能会同意这样的说法，即业务中最重要的事情之一就是可预测性 。 没有人喜欢处于不确定的位置，尤其是在其他人的未来可能处于危险之中的情况下。
This is why it is of utmost importance that trust be established when offering automation services to a business. Any service that a business would be willing to invest in must offer ironclad assurances of predictability and repeatability. In summary, the automation services must offer coherent, consistent, fully controllable behavior.
这就是为什么在为企业提供自动化服务时建立信任至关重要。 企业愿意投资的任何服务都必须提供可预测性和可重复性的坚定保证。 总之，自动化服务必须提供一致，一致，完全可控制的行为。
It is precisely because of such primary business values that service bots must come with fully baked, crisp communication protocols which unambiguously set the tone of the conversation. As bot builders, we must be able to demonstrate to the businesses that our bots are fully predictable. We can only accomplish that by demonstrating how they exhibit repeatable, fully controllable behavior.
正是由于这样的主要业务价值，服务漫游器必须带有完全烘焙的清晰的通信协议，这些协议明确地设置了对话的基调。 作为机器人的构建者，我们必须能够向企业证明我们的机器人是完全可预测的。 我们只能通过演示它们如何表现出可重复的，完全可控制的行为来实现这一目标。
机器人跟踪用户互动 (Bots Keep Track of User Interaction)
One important facet of the bots that differentiates them from the traditional GUI apps is their undivided attention to the human user. While GUI apps don’t care who is operating them, bots definitely do care. Unlike GUI apps, which propose the ‘one size fits all’ approach to offering automated services, bots propose highly personalized services. The personalization is embodied within the conversation thread that transpires between the human user and the bot.
僵尸程序与传统GUI应用程序区别的一个重要方面是它们对人类用户的关注。 尽管GUI应用程序不在乎谁在操作它们，但机器人肯定会在乎。 不同于GUI应用程序提出了“一刀切”的方式来提供自动化服务，而机器人则提出了高度个性化的服务。 个性化体现在人类用户和机器人之间发生的对话线程中。
Despite the fact that different users are interacting with the same bot, the history of their interaction is totally unique. There couldn’t possibly be two discussion threads alike, and the variety of information exchange is endless.
尽管有不同的用户与同一个机器人进行交互，但他们的交互历史却完全不同。 不可能有两个相同的讨论线程，并且信息交换的多样性是无限的。
Another important point is that bots retain the memory of each individual step of each individual user, and can recollect and summarize what transpired in a given context. GUI apps were never designed with similar intentions, which makes them appear really crude, almost barbaric in comparison.
另一个重要的一点是，僵尸程序保留每个用户的每个步骤的记忆，并且可以重新收集和总结在给定上下文中发生的情况。 GUI应用程序从来没有设计有类似的意图，这使得它们看起来确实很粗糙，相比之下几乎是野蛮的。
漫游器和上下文切换 (Bots and Context Switching)
When humans communicate, they use their common-sense skills to signal to each other when the context of the conversation changes. For example, upon the initial contact, the short-lived context (often called ‘meet and greet’) gets established. That context is usually set by using common opening lines, such as “Hi, how are you?”, “Hello there!”, “How do you do?”, “How are you doing?” etc. Depending on whether the meet-and-greet session happens between strangers or between old friends, the opening lines may change. But the overall tone remains pretty much predictable, as is the tacit intention to quickly end the ephemeral meet-and-greet situation and move on to a more concrete interaction.
当人们交流时，他们会使用常识技能在对话的上下文发生变化时相互发信号。 例如，在初次接触时，会建立短暂的上下文(通常称为“见面和问候”)。 通常使用常见的开头行来设置上下文，例如“嗨，你好吗？”，“你好！”，“你好吗？”，“你好吗？”。 等等。根据是在陌生人之间还是在老朋友之间进行见面会，开场白线可能会发生变化。 但是总体的语气仍然是可以预见的，默认的意图是Swift结束短暂的见面情况，并进行更具体的互动。
Following the initial greeting, the context usually switches very abruptly and that switching is signalled by the change of the tone of the conversation. Depending on whether the meeting is informal, or a more formal business or even legal session, the appropriate tone will take over and prevail.
在初始问候之后，上下文通常会非常突然地切换，并且该切换是通过会话音调的变化来发出的。 视会议是非正式会议，正式会议还是法律会议而定，适当的语气将占据上风。
A bot that is incapable of detecting and performing similar context switching is a completely useless bot. Building a bot that is only capable of behaving in a simplistic, knee-jerk fashion by always maintaining the same tone of the conversation is not going to garner much attention among the user base.
无法检测和执行类似上下文切换的漫游器是完全无用的漫游器。 通过始终保持相同的会话音调来构建仅能够以简单的，易怒的方式表现的机器人，不会在用户群中引起广泛关注。
Because of that danger, we need to establish some guidelines on how to implement a sturdy, viable bot protocol.
由于存在这种危险，我们需要就如何实施坚固，可行的机器人协议建立一些准则。
Bot协议指南 (Bot Protocol Guidelines)
Generally speaking, any bot offering conversational experiences to human users must provide four levels of communication protocol:
一般来说，任何向人类用户提供对话体验的漫游器都必须提供四个级别的通信协议：
Command protocol
命令协议
Keyword protocol
关键字协议
Structured phrase protocol
结构化短语协议
Free form (informal) protocol
自由格式(非正式)协议
The above four protocols are ordered with regards to their strictness and rigidity — from the most constrained, strict and rigidly formal (i.e. command protocol) down to the least strict and least formal (casual chitchat, or banter).
上面的四个协议在其严格性和刚性方面是有序的-从最受约束，最严格和最严格的形式(即命令协议)到最不严格和最不正式的(临时聊天或戏ban)。
命令协议 (Command Protocol)
With commands, we’re back to the command line interface (CLI). Using a command line interface is usually the domain of computer programmers and system administrators. It does require certain level of formal training, as computer operating systems are not built with conversational experiences in mind. The strictness of the command syntax is required so that the underlying operating system can execute commands with the least possible amount of ambiguity.
使用命令后，我们回到命令行界面( CLI )。 使用命令行界面通常是计算机程序员和系统管理员的工作范围。 它确实需要一定程度的正规培训，因为计算机操作系统的构建并不是考虑到对话经验。 需要严格的命令语法，以便底层操作系统可以以尽可能少的歧义执行命令。
In the world of bots, this strictness must be softened because the intended audience is not highly trained professionals. Casual users must not be expected to know how to formulate syntactically correct commands. A bot must serve as an intermediary broker, or a concierge. This broker must be able to accept commands issued by users. The broker will then translate the commands into a more syntactically correct form. Syntactically correct form is needed for the back-end machinery so it can process the request without the risk of introducing unwanted side effects.
在机器人世界中，必须放宽这种严格性，因为目标受众不是训练有素的专业人员。 不能期望临时用户知道如何制定语法正确的命令。 机器人必须充当中介经纪人或礼宾服务。 该代理必须能够接受用户发出的命令。 然后代理将命令转换为语法上更正确的形式。 后端机器在语法上需要正确的形式，以便它可以处理请求而不会带来不必要的副作用。
For that reason, commands offered by the bots must be single word commands. Keeping in mind that bots are also expected to respond to single word messages that may not be strict commands, we must design bot commands in such a way that they immediately stand out. Typically, that means that a bot command must be constructed in such a way that it starts with a special character. For example, a command requesting a reminder from the bot about what commands it understands would typically start with a ‘/’ (forward slash) character. There is a semantic difference between saying ‘help’ and ‘/help’. The first message (a simple ‘help’) is not interpreted by a bot as a command. The second message (so-called slash command ‘/help’) gets interpreted by a bot as a command. The outcome of processing that command would be vastly different from the outcome of processing a simple ‘help’ message.
因此，机器人提供的命令必须是单字命令。 请记住，机器人还应响应可能不是严格命令的单个单词消息，因此，我们必须以使其立即脱颖而出的方式设计机器人命令。 通常，这意味着必须以一种特殊字符开头的方式构造bot命令。 例如，从机器人请求提示的命令通常会以'/'(正斜杠)字符开头，该命令会向机器人发出有关其理解的命令的提醒。 说“帮助”和“ /帮助”之间在语义上有所不同。 bot不会将第一条消息(简单的“帮助”)解释为命令。 机器人将第二条消息(称为斜杠命令 “ / help”)解释为命令。 处理该命令的结果与处理简单的“帮助”消息的结果会有很大不同。
关键字协议 (Keyword Protocol)
Unlike bot commands, keywords are less formalized, less strict messages that users send to the bot. Unlike bot commands, the main responsibility of keywords is to govern the switching of the conversation context.
与漫游器命令不同，关键字的形式化程度较低，用户发送给漫游器的消息也不那么严格。 与bot命令不同，关键字的主要职责是控制对话上下文的切换。
In the case of bot commands, there is no context switching — the bot recognizes the command and simply executes it. The user may ask the bot for /help as many times as the user wishes to, the bot will always reply with exact same list of commands it understands. Depending on the nature of the command issued by the user, the bot may ask for subsequent confirmation. But there will always be commands that simply get executed in a knee-jerk fashion (for example, it would be ludicrous if the bot were to ask the user “Are you sure you want me to execute the /help command?”)
对于bot命令，没有上下文切换-bot会识别命令并简单地执行它。 用户可以向机器人请求/ help次数不限，机器人将始终以其理解的相同命令列表进行回复。 根据用户发出的命令的性质，机器人可能会要求进行后续确认。 但是总会有一些命令以膝关节方式执行(例如，如果该漫游器询问用户“您确定要我执行/ help命令会很可笑)”
Keywords are different from commands in that they are meant to alert the bot that the context of the conversation has changed. Similar to commands, keywords are formatted as single word instructions, punctuated with a special character (typically a ‘@’ character).
关键字与命令的不同之处在于，它们的目的是向bot发出警告，通知对话上下文已更改。 与命令相似，关键字被格式化为单个单词指令，并以特殊字符(通常为“ @”字符)标点。
For example, a user may be in the middle of a conversation with the bot discussing best places to have lunch, when the user interrupts the context by saying “Bot, please check with my @doctor when is she available for an appointment?” In this message, the word @doctor is the keyword that triggers bot’s understanding that the context must change. Upon receiving the message containing that keyword, the bot will switch the context from discussing places for lunch to working on figuring out the next available slot for the doctor’s appointment.
例如，当用户通过说“ Bot，请何时与我的@doctor进行约会？”打断上下文时，用户可能正在与机器人进行对话，讨论讨论午餐的最佳地点。 在此消息中，单词@doctor是触发bot理解上下文必须更改的关键字。 收到包含该关键字的消息后，机器人会将上下文从讨论午餐的地方切换为研究下一个可供医生预约的空位。
Unlike commands, the keywords communication protocol often implies that the bot may ask subsequent questions. Those subsequent questions, triggered by the presence of the pre-established @keyword, will always be asked within the newly established context. In the above example, since the user pulled the @doctor keyword and abruptly switched the context, the bot may reply with a subsequent question (or a series of subsequent questions, as the case may be).
与命令不同，关键字通信协议通常暗示机器人可能会询问随后的问题。 由预先建立的@keyword的存在触发的那些后续问题将始终在新建立的上下文中提出。 在上面的示例中，由于用户拉出@doctor关键字并突然切换了上下文，因此漫游器可以回答后续问题(或视情况而定的一系列后续问题)。
Depending on how the bot was trained, the followup question may be: “Is this an urgent matter?”, or it could be: “Is it necessary that you see your doctor? Would another doctor in the office be okay, in case your doctor happens to be absent?” Or, if the bot is simplistic, it may merely just go ahead and schedule the appointment for the earliest available slot, without doing any further consulting with the user.
取决于机器人的培训方式，后续问题可能是：“这是紧急事件吗？”，也可能是：“是否有必要看医生？ 如果您的医生碰巧不在办公室，办公室里的另一位医生可以吗？” 或者，如果漫游器过于简单，则可能只是继续进行并为最早可用的时间安排约会，而无需与用户进行任何进一步的协商。
结构化短语协议 (Structured Phrase Protocol)
Typical human conversation very rarely consists of terse, one word exchanges. Most of the time, we converse by exchanging various idioms and phrases that serve as building blocks for more elaborate sentences.
典型的人类对话很少包含简短的单词交换。 在大多数情况下，我们通过交换各种习语和短语进行交流，这些习语和短语是构建更精细句子的基础。
In order to make the experience of chatting with the bot feel intuitive and natural, we must enable our bots to deal with short phrases, and even short sentences. Similar to commands and keywords, those structured phrases and sentences must be predefined and engineered by the bot creators.
为了使与机器人聊天的体验直观而自然，我们必须使我们的机器人能够处理简短的短语，甚至简短的句子。 与命令和关键字相似，那些结构化的短语和句子必须由机器人创建者预先定义和设计。
Because idioms and phrases imply more casual tone of the conversation, the outcome resulting from processing a structured phrase will, out of necessity, be less deterministic than the outcome of a command or a single keyword. If you recall how businesses frown upon unpredictability and non-deterministic outcomes, you will more readily understand why we prefer to relegate less critical processing to structured phrases. It goes without saying that the less structured, less formalized a message sent to the bot is, the less capable will the bot be to process the message in a predictable, deterministic fashion.
因为习惯用语和短语表示会话的语调更加随意，所以处理结构化短语所产生的结果将比命令或单个关键字的结果具有更少的确定性。 如果您回想起企业如何对不可预测性和不确定性结果感到不满意，您将更容易理解为什么我们更喜欢将不太重要的处理委托给结构化短语。 不用说，发送给机器人的消息结构越不规范，形式化程度越低，机器人以可预测的确定性方式处理消息的能力就越差。
Here we are towing a fine line between opening up our services to a more casual mode of communication vs. guaranteed minimum quality of service in terms of accuracy, precision, correctness, consistency, coherence and repeatability. Acknowledging the importance of casual mode of communication, we are nevertheless apprehensive when it comes to delegating any critical processing to those less formalized messages.
在准确性，准确性，正确性，一致性，连贯性和可重复性方面，我们在开放我们的服务以更随意的通信模式与保证最低的服务质量之间划出一条细线。 认识到随意交流方式的重要性，但是，在将任何关键处理委托给那些形式较不正式的消息时，我们仍然感到担忧。
Another thing that makes structured phrase processing important is the necessity for establishing assertive pace when servicing user requests. If we were to insist on only staying within the confines of highly formalized, one word commands and keywords, we would in effect end up with stilted conversation threads. Users will not feel compelled to return to chatting with bots if the conversation feels so rigid and cold; we need to establish a flow and a definitive pace that will keep users engaged and ultimately satisfied with the quality of service.
使结构化短语处理变得重要的另一件事是，在服务用户请求时必须确立果断的步调。 如果我们要坚持只停留在高度形式化的，一个单词的命令和关键字的范围内，那么我们实际上将最终陷入僵硬的对话线程。 如果对话变得如此僵硬和冷漠，用户将不会被迫回到与机器人聊天。 我们需要建立流程和确定的节奏，以保持用户的参与度并最终对服务质量感到满意。
That’s why it is of paramount importance to enable our bots to deal with a number of common phrases that people tend to use in everyday parlance. Phrases such as “What do you know about…” or “Can you tell me about…” etc. is something that all of us use throughout our daily activities. It only feels normal and natural to send messages starting with such structured phrases. The bots will then recognize that the message they’ve received is formulated as an inquiry, and will process that inquiry by reaching deep into the back-end resources.
这就是为什么使我们的机器人能够处理人们在日常用语中倾向于使用的一些常用短语的重要性。 诸如“您对……了解什么”或“您能告诉我有关……”等短语是我们所有人在日常活动中都会使用的短语。 发送以这种结构化短语开头的消息是正常且自然的感觉。 然后，僵尸程序将认识到他们收到的消息被构造为查询，并将通过深入了解后端资源来处理该查询。
It is also natural that a less officially sounding phrase, such as “what do you know about…” will set the tone where the answer doesn’t have to be 100% correct. The overall intention of the conversation is much looser than is the conversation containing a command or a keyword.
当然，听起来不太正式的短语(例如“您知道些什么……”)可以为不必一定是100％正确答案的语气定下基调。 对话的总体意图比包含命令或关键字的对话要宽松得多。
自由格式(非正式)协议 (Free Form (Informal) Protocol)
Finally, we must expect that users will send messages that do not comply with any of the above three protocols. There will be many messages that do not contain commands, keywords, nor structured, predefined phrases. It is up to us, bot creators, to decide how to deal with such unstructured messages.
最后，我们必须期望用户将发送不符合以上三个协议中任何一个的消息。 将有许多消息不包含命令，关键字或结构化的预定义短语。 僵尸程序的创造者应由我们决定如何处理此类非结构化消息。
One way to handle such unstructured, fuzzy scenarios is to be outright honest and to always politely reply with “I don’t know”, or “I’m not sure I understand” phrase. It’s a copout, to be sure, but at least it is 100% honest.
处理这种非结构化，模糊场景的一种方法是坦率诚实，并始终用“我不知道”或“我不确定我能理解”这样的短语礼貌地回答。 可以肯定的是，这是对策，但是至少它是100％诚实的。
However, if the bots are always going to field any unstructured messages with a blunt “I don’t know”, they will quickly lose any charisma and attractiveness for the users. It is therefore much more desirable to make attempts to meet the user halfway, and at least try to reply to some of the unstructured messages.
但是，如果僵尸程序总是以“我不知道”的钝语来发送任何非结构化消息，它们将很快失去对用户的吸引力和吸引力。 因此，更加希望尝试中途与用户见面，并至少尝试回复一些非结构化消息。
We are now entering the territory that is sometimes called ‘chitchat’, or ‘banter’. Banter and chitchat happen a lot in everyday life, even in some of the more formalized situations. So long as we train our bots to project a clear signal to the users that their chitchat answers to the unstructured messages are also light hearted, informal messages thrown back at the users, the risk of being misunderstood gets minimized.
我们现在正在进入有时被称为“ chitchat”或“ banter”的领土。 在日常生活中，即使在某些较为形式化的情况下，玩笑和闲聊也经常发生。 只要我们训练我们的漫游器向用户发出清晰的信号，即他们对非结构化消息的选择回答也会轻松愉快，非正式消息会退还给用户，那么被误解的风险就会降到最低。
Here is where humor plays a useful role. If the dosage of humor is appropriate, chatting with bots can be quite amusing and entertaining. Also, throwing in a bit of trivia could go a long way toward breaking the ice and maintaining the always important pace of the conversation.
这是幽默发挥作用的地方。 如果幽默的用法适当，与机器人聊天可能会很有趣和有趣。 此外，进行一些琐事可能会大大打破僵局并保持对话的始终重要的步伐。
避开兔子洞 (Avoiding the Rabbit Hole)
When bots are engaged in informal chatting with users, there is always clear and present danger that the focus and momentum could fizzle out at any moment. Reaching an impasse in the conversation is never desirable, so we must take precautionary measures to avoid going down the proverbial rabbit hole.
当僵尸程序与用户进行非正式聊天时，始终存在明显的危险，即随时可能失去焦点和动力。 在对话中陷入僵局永远是不可取的，因此我们必须采取预防措施，避免陷入众所周知的兔子洞。
Bots must be designed to keep track of the informal chitchat with the user and to detect when the chitchat reaches the much dreaded point of no return. Depending on the context (and on the particular user profile as well), that point of no return will vary widely. In general, any conversation session that ends up with a lot of informal, semi-joking messages and overall banter is at a risk of becoming meaningless. Once the user becomes aware that their chat with the bot is not only meaningless but also a waste 0f time, the user will develop a tendency to avoid future interactions.
机器人的设计必须能够与用户保持非正式的闲聊，并检测闲聊何时达到令人恐惧的无可挽回的地步。 根据上下文(以及特定的用户配置文件)，无回报的点也会有很大的不同。 通常，任何以大量非正式，半开玩笑的消息和开玩笑为结尾的会话都可能会变得毫无意义。 一旦用户意识到与机器人的聊天不仅毫无意义，而且浪费了0f的时间，那么用户就会倾向于避免未来的交互。
What may be useful from the bot design blueprint standpoint is to work on allocating the ‘banter budget’ per conversation thread. This ‘banter budget’ should be expressible in the number of consecutive informal messages exchanged between the user and the bot. The ‘banter budget’ should also be configurable, so that the bot can be calibrated in real time, as the situation dictates.
从机器人设计蓝图的角度来看，可能有用的是为每个会话线程分配“预算”。 该“预算预算”应以用户与机器人之间交换的连续非正式消息的数量来表示。 “封包预算”也应该是可配置的，以便可以根据情况实时对机器人进行校准。
When the given conversation thread exhausts its ‘banter budget’, the bot must break the proverbial glass and push the proverbial panic button. This event that is tripping the wire must not be visible to the user. All the bot does when pushing the panic button is issue a message that will attempt to bring the conversation back to the more structured path. There are many possible ways to accomplish that, for example one way would be for the bot to interject and politely remind the user about some of the more structured services available to them. The bot could also at that point offer a refresher on the available commands, available keywords, or even common structured phrases. This is actually a very useful behavioural pattern, because in most cases the users have most certainly forgotten those annoying details.
当给定的对话线程耗尽其“预算预算”时，漫游器必须打破众所周知的障碍并按下众所周知的紧急按钮。 用户跳线此事件一定是不可见的。 当按下紧急按钮时，机器人会做的所有事情都是发出一条消息，尝试将对话带回到结构更清晰的路径上。 有许多可能的方法可以实现这一目标，例如，一种方法是让机器人进行干预并礼貌地提醒用户有关其可用的一些结构化服务。 那时，机器人还可以提供有关可用命令，可用关键字甚至常见结构化短语的更新。 这实际上是一个非常有用的行为模式，因为在大多数情况下，用户肯定会忘记那些烦人的细节。
Useful phrases such as “hey, did you know you can ask me to notify you of any deals on such-and-such?” could be used to pull the conversation out of the doldrums created by sending one too many lame knock-knock jokes.
有用的短语，例如“嘿，您知道您可以要求我将某某某事的交易通知您吗？” 可以用来使对话摆脱因发送太多la脚敲门笑话而造成的低迷。
机器人必须是非侵入式的 (Bots must be Non-Intrusive)
As I was building my first bots and trying them out in the wild, I’ve noticed that most people would primarily struggle with the issue of trust. Part of those issues were down to people plainly not understanding that bots are merely an extension of the already existing automated services.
在构建我的第一个机器人并在野外试用它们的过程中，我注意到大多数人主要是在信任问题上挣扎。 这些问题的一部分归咎于人们，他们显然不了解机器人只是对现有自动化服务的扩展。
To my astonishment, some people confided in me how they don’t like the fact that the bot is sitting there, eavesdropping on all their activities. They failed to understand that bots only have access to messages sent directly to them, so that was yet another hurdle I had to pass in order to get them to try the bots.
令我惊讶的是，有些人向我吐露他们不喜欢该机器人坐在那里，偷听了他们所有活动的事实。 他们无法理解，机器人只能访问直接发送给他们的消息，所以这是我不得不经过的另一个障碍，以便让他们尝试使用机器人。
One way that I found works when appeasing people’s anxieties regarding the bots is to offer a very clear service level agreement (SLA) with the bots. The moment the user approaches a bot, it is that bot’s duty to explain to the user that the bot will only have access to messages sent directly to it. Also, it helps if the bot very clearly explains that it will never send a message to the user unless the user first sends the message to it.
在缓解人们对机器人的焦虑时，我发现可行的一种方法是为机器人提供非常清晰的服务水平协议(SLA)。 用户接近机器人时，机器人有责任向用户解释该机器人只能访问直接发送给它的消息。 此外，如果僵尸程序非常清楚地解释说它将永远不会向用户发送消息，除非用户首先向其发送消息，否则它会有所帮助。
选择加入和退出 (Opting In and Out)
Similar to how the market is regulated to give us, the consumers, the power to opt in or out of being contacted by businesses (be it via telemarketing or email spam etc.), bots must also offer the same ability. By default, bots are not supposed to ever send us any messages. They are there only to respond to the messages we send to them.
类似于市场如何规范给我们，消费者，企业选择加入或退出(通过电话销售或电子邮件垃圾邮件等)联系的权力一样，机器人也必须提供相同的功能。 默认情况下，机器人不应向我们发送任何消息。 他们在那里只是为了回应我们发送给他们的消息。
However, there are many scenarios where we, the end-users, would benefit from being contacted by a bot. But in order to make that happen, a bot must be configured to explicitly ask the user for the permission to send them the message out of the blue. Furthermore, it is bot’s obligation to enable users to set their preference as to when and how should the message coming from the bot be delivered.
但是，在很多情况下，我们(最终用户)将从与机器人联系中受益。 但是，为了实现这一点，必须配置一个漫游器以明确要求用户授予向其发送消息的权限。 此外，僵尸程序有义务使用户能够设置关于何时以及如何传递来自僵尸程序的消息的首选项。
结论 (Conclusion)
The only way bots will be embraced by the marketplace at large is by establishing a clear, predictable communication protocol. In this article I have argued that a bot protocol can and must be nuanced, from the most rigid and constrained one (commands) down to the most flexible, unconstrained banter.
机器人被整个市场所接受的唯一方法是建立清晰，可预测的通信协议。 在本文中，我认为，从最严格，最受约束的(命令)到最灵活，不受约束的玩笑，僵尸程序协议都可以而且必须有所细化。
The reasons for this constraint lie in the pressing need for establishing and maintaining predictability, repeatability and consistency. These features help businesses make projections and plan for the future, hence the prevalent disdain for bots who are ‘innovative’, ‘creative’, full of surprises (both pleasant and unpleasant).
这种限制的原因在于迫切需要建立和保持可预测性，可重复性和一致性。 这些功能可帮助企业制定计划和未来计划，因此，对于那些充满创新(令人愉悦和不愉快)的“创新”，“创意”的机器人，他们普遍不屑一顾。
Unless we are building a bot that would offer some entertainment value (such as a standup comedian bot, for example), we must make sure that our bot implements very strict set of commands, keywords, structured phrases and other features that can reliably be demonstrated to the users.
除非我们构建的机器人可以提供娱乐价值(例如，单口喜剧演员机器人)，否则我们必须确保我们的机器人实现了非常严格的命令，关键字，结构化短语以及其他可以可靠地演示的功能给用户。
Intrigued? Want to learn more about the bot revolution? Read more detailed explanations here:
感兴趣吗？ 想更多地了解机器人革命？ 在此处阅读更多详细说明：
The Age of Self-Serve is Coming to an EndOnly No Ux Is Good UXStop Building Lame Bots!Four Types Of BotsIs There A Downside To Conversational Interfaces?Are Bots just a Fad? Are GUIs really Superior?Breaking The Fourth Wall In SoftwareBots Are The Anti-AppsHow Much NLP Do Bots Need?Screens Are For Consumption, Not For Interaction
自助服务的时代即将结束， 只有UX才是好的UX 停止建立La脚的机器人！ 四种类型的Bot 对话界面有不利之处吗？ 机器人只是一种时尚吗？ GUI真的优越吗？ 打破软件 僵尸程序 的第四道墙React用程序 需要多少NLP？ 屏幕用于消费而非交互
翻译自: https://www.freecodecamp.org/news/how-to-design-a-bot-protocol-4b7584fc8d2c/
热水bot协议