Bot Framework 的一般常见问题解答

某些通道不支持在其客户端中进行临时输入状态更新。

连接器库是 REST API 的展示。 Builder 库提供了对话式对话框编程模型以及其他功能，如提示、瀑布式流程、链式处理和引导式表单填写。 生成器库还提供对 Azure AI 服务（如自然语言理解）的访问权限。

当用户通过通道发送消息时，Bot Framework Web 服务将向机器人的 Web 服务终结点发出 HTTPS POST。 机器人可以在该通道上向用户回复零条、一条或多条消息；方法是它每发送一条消息，就向 Bot Framework 单独发起一次 HTTPS POST 请求。

从你的机器人的角度来看，“响应式”意味着用户通过向机器人发送消息来发起对话，而机器人则对该消息作出响应。 相反，“主动”意味着机器人通过先向用户发送第一条消息来启动会话。 例如，机器人可以发送主动消息以在计时器过期或事件发生时通知用户。

有关演示如何发送主动消息的示例，请参阅 GitHub 上的 BotBuilder-Samples 存储库中的 C# V4 示例和 Node.js V4 示例。

ETag 是一种用于乐观并发控制的机制。 机器人数据包存储使用 ETag 来防止对数据进行冲突更新。 如果出现 ETag 错误并显示 HTTP 状态代码 412“不满足前提条件”，则表明在机器人完成第一个操作之前，已并行接收了多个消息。 对话框堆栈和状态均存储在机器人数据包中。 例如，如果机器人在收到该会话的新消息时仍在处理上一条消息，则可能会看到“不满足前提条件”ETag 错误。

Bot Framework 服务必须保护其自身及其客户免受滥用呼叫模式攻击（例如，拒绝服务攻击），这样一来，没有一个机器人可以对其他机器人的性能产生负面影响。 为了提供这种保护，我们已为端点添加了速率限制（也称为节流）。 通过强制执行速率限制，我们可以限制客户端或机器人进行特定呼叫的频率。 例如：启用速率限制后，如果机器人想要发布大量活动，则必须在一段时间内将它们分开。 速率限制的目的并不是给单个机器人的总请求量设定上限。 它旨在防止滥用不遵循人类会话模式的会话架构。 例如，向两段对话中大量灌入内容，多到两个人无论如何都看不过来。

在为我们的服务和用户提供保护的同时，我们也不断调整速率限制，使其尽可能宽松。 由于阈值有时会发生变化，因此，我们目前不会公布这些数字。 最后，如果你在应用服务上托管机器人，该机器人需遵守应用服务的限制。 有关详细信息，请参阅 Azure 服务的 SLA 摘要。如果你受到速率限制的影响，请随时通过 bf-reports@microsoft.com 与我们联系。

某些通道对可发送文件的大小或类型实施了限制。 例如，Direct Line将活动有效负载限制为 4,194,304 字节（4 MB），而 Bot Framework Emulator 没有限制。 这些限制是由通道施加的。 如果发送超过此限制的消息，可能会收到错误，例如： 请求内容长度超出限制 4,194,304 字节。 但是，可将资源的链接作为 Internet 附件提供。 有关发送附件的详细信息，请参阅如何在消息中添加媒体。

即使在数据量较大时，你也不太可能遇到速率限制。 大多数限流情况通常只会由于机器人或客户端批量发送活动消息、极端负载测试或程序缺陷而发生。 当请求受到限制时，将返回 HTTP 429（请求过多）响应以及 Retry-After 标头，指示在重试请求成功之前等待的时间（以秒为单位）。 可以通过 Azure 应用程序 Insights 为你的机器人启用分析，从而收集此信息。 或者，可以在机器人中添加代码来记录消息。

速率限制是由下列任一情况造成的：

• 机器人发送消息的频率过高
• 机器人客户端发送消息的频率过高
• Direct Line 客户端过于频繁地请求新的 WebSocket

有时，需要将聊天从机器人转移到人类，例如当机器人不了解用户或请求无法自动执行时。 在这些情况下，机器人会转接给人工客服。 Bot Framework SDK 支持向人类用户交接聊天。 有几个事件类型可以指示交接操作。 这些事件是在机器人与代理中心（也称为参与中心）之间交换的。 此代理中心定义为允许代理（通常是人类）接收和处理来自用户的请求，以及升级来自机器人的请求的应用程序或系统。 有关详细信息，请参阅将聊天从机器人移交给人类用户一文。