设计和控制会话流

适用于： SDK v4

在传统应用程序中，用户界面（UI）由一系列屏幕组成，单个应用或网站可以根据需要使用一个或多个屏幕来与用户交换信息。 大多数应用程序都从用户最初登陆的主屏幕开始，该屏幕提供导航，从而为各种功能（例如启动新订单、浏览产品或查找帮助）提供其他屏幕。

与应用和网站一样，机器人有一个 UI，但它由 消息 而不是屏幕组成。 消息可能包含按钮、文本和其他元素，或者完全基于语音。

虽然传统应用程序或网站可以同时请求屏幕上的多个信息片段，但机器人将使用多个消息收集相同的信息量。 通过这种方式，从用户收集信息的过程是一个积极的体验，其中用户与机器人进行积极交流。

设计良好的机器人将拥有一个显得自然的对话流程。 机器人应能够无缝处理核心对话，并能够正常处理中断或切换主题。

过程会话流

与机器人的对话可以专注于机器人尝试实现的任务，这称为过程流。 机器人询问用户一系列问题，以收集处理任务之前所需的所有信息。

在过程聊天流中，定义问题的顺序，机器人将按照定义的顺序提问。 可以将问题组织到逻辑组中，以保持代码 cMicrosoft Entralized，同时专注于指导对话。 例如，可以设计一个模块来包含帮助用户浏览产品的逻辑和单独的模块，以包含帮助用户创建新订单的逻辑。

可以以您喜欢的任何方式组织这些模块，使它们的流动方式从自由形式到顺序。 Bot Framework SDK 提供了一个对话框库，可用于构造机器人所需的任何聊天流。 该库包含瀑布对话，用于创建一系列步骤并通过提示询问用户问题。 有关详细信息，请参阅 对话框库。

在传统应用程序中，一切都从 主 屏幕开始。 主屏幕打开 新订单 界面。 新订单屏幕将保持控制状态，直到它关闭或调用其他屏幕，例如 产品搜索 屏幕。 如果新订单屏幕关闭，用户将返回到主屏幕。

在使用对话的机器人中，所有内容都以 根对话开头。 根对话调用 新的订单对话框。 此时，新订单对话将控制对话，并一直处于控制状态，直到它关闭或调用另一个对话，例如 产品搜索对话。 如果新的订单对话框关闭，则对话的控制将返回根对话。

有关如何使用对话库实现聊天流的示例，请参阅 “实现顺序聊天流”。

处理中断

假设用户将以整洁有序的方式逐个地执行过程任务，这很诱人。 例如，在使用对话框的流程对话流中，用户将从初始对话开始并调用新建订单对话。 在新的订单对话框中，调用产品搜索对话框。 然后，选择产品搜索对话框中列出的结果之一时，会调用新订单对话框。 完成订单后，他们返回到根对话。

尽管用户总是遵循如此线性的逻辑路径会很理想，但这种情况很少发生。 人们并不总是按顺序进行通信。 他们往往经常改变他们的想法。 请看下面的示例：

虽然机器人可能以流程为中心，但用户可能会决定执行完全不同的操作，或者提出一个可能与当前主题无关的问题。 在上面的示例中，用户提出问题，而不是提供机器人预期的是/否响应。 机器人应如何响应？

• 坚持用户先回答问题。
• 忽略用户之前所做的一切，重置整个对话堆栈，然后从头开始尝试回答用户的问题。
• 尝试回答用户的问题，然后返回到“是/否”问题，然后尝试从那里恢复。

此问题没有 正确的 答案，因为最佳解决方案将取决于方案的具体细节，以及用户如何合理地期望机器人做出响应。 了解如何处理为处理某些类型中断而设计的机器人中的用户交互中断。

结束对话

有时，从头开始重启对话会很有用。 例如，在用户有特定的一段时间未响应时。 结束对话的不同方法包括：

• 跟踪上次从用户收到消息的时间，如果该时间大于预配置的时长，则在收到用户的下一条消息时清除状态。
• 使用存储层功能（如 Cosmos DB 的 生存时间 功能）清除预配置时长后的状态。

有关详细信息，请参阅如何 设置对话过期。

后续步骤

管理用户跨对话导航和设计对话流的方式，使用户能够实现其目标（即使是以非线性方式）是机器人设计的根本挑战。 设计机器人导航文章回顾了设计不佳的导航的一些常见陷阱，并讨论了避免这些陷阱的策略。