设计和控制会话流

适用于：SDK v4

在传统应用程序中，用户界面 (UI) 由一系列屏幕组成，单个应用或网站可以根据需要使用一个或多个屏幕与用户交换信息。 在大多数应用程序启动主屏幕中，用户可以进行初始登录，该屏幕还提供指向其他屏幕以使用各种功能（如启动新的订单、浏览产品，或寻求帮助）的导航。

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

虽然传统应用程序或网站可以在屏幕上同时请求多条信息，但机器人将使用多条消息收集相同数量的信息。 通过这种方式，从用户处收集信息的过程成为一种积极的体验：用户可以与机器人进行活动会话。

一个设计良好的机器人将拥有一个自然的会话流。 机器人应该能够无缝地处理核心会话，并且能够从容地处理中断或切换会话主题。

程序会话流

与机器人的会话集中在机器人试图实现的任务上，这个称为程序流程。 机器人向用户询问一系列问题，以收集在处理任务之前所需的所有信息。

在程序会话流中，可以定义问题的顺序，机器人将按你定义的顺序提出问题。 可以将问题组织到逻辑组中，保持代码的集中性，同时专注于引导会话。 例如，你可能会设计一个模块，其中包含可帮助用户浏览产品的逻辑，以及一个单独的模块，其中包含可帮助用户创建新订单的逻辑。

可以按照自己喜欢的任何方式将这些模块构建到流程中，自由格式或顺序格式均可。 Bot Framework SDK 提供了对话框库，使用这些库可以构造机器人所需的任何会话流。 该库包含用于创建一系列步骤的瀑布对话框 ，并提示用户提出问题。 有关详细信息，请参阅对话框库。

在传统应用程序中，一切都从主页面开始。 主屏幕调用新建订单页面。 新建订单页面在关闭或调用其他页面（例如产品搜索页面）之前一直处于受控状态。 如果新建订单页面关闭，用户将返回主页面。

在使用对话框的机器人中，一切都以根对话框开头。 根对话框调用新建订单对话框。 此时，新建订单对话框控制会话并保持控制状态，直到它关闭或调用其他对话框（例如产品搜索对话框）。 如果新建订单对话框关闭，对话框的控制权会返回给根对话框。

有关如何使用对话框实现对话流的示例，请参阅 实现顺序会话流。

处理中断

假设用户将以整齐有序的方式逐一执行程序任务，这可能非常具有吸引力。 例如，在过程对话流中，用户将从根对话框开始，并调用新建订单对话框。 在新建订单对话框中，它们调用产品搜索对话框。 然后，在选择产品搜索对话框中列出的其中一个结果时，它们将调用新建订单对话框。 完成订单后，它们将返回根对话框。

如果用户始终能够完成这样一个线性逻辑路径，那将是再好不过了，但很少能够实现。 用户不一定按顺序进行通信。 他们往往会频繁地改变主意。 请考虑以下示例：

虽然机器人可能以程序化为重点，但用户可能会决定做一些完全不同的事情，或者询问可能与当前主题无关的问题。 在上述示例中，用户询问问题而不是提供机器人期望的是/否响应。 机器人应如何响应？

• 坚持让用户先回答问题。
• 忽略用户之前完成的所有操作，重置整个对话框堆栈，并从头开始尝试回答用户的问题。
• 尝试回答用户的问题，然后返回到是/否问题并尝试从该位置继续。

此问题没有正确答案，因为最佳解决方案将取决于你的具体应用场景，以及用户如何合理地期望机器人做出响应。 请参阅如何处理用于处理某些类型的中断的机器人的用户中断 。

使对话失效

有时需要从头开始重新聊天。 例如，在用户有特定的一段时间后未响应时。 结束会话的不同方法包括：

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

有关详细信息，请参阅如何使会话过期。

后续步骤

在对话框中管理用户的导航，并通过使用户能够实现其目标的方式（甚至是以非线性方式）设计会话流，这是机器人设计的一个基本挑战。 设计机器人导航一文回顾了设计不良导航的一些常见缺陷，并讨论了避免这些问题的策略。