Bot Framework 一般常見問題

某些通道不支援其用戶端中的暫時性輸入更新。

連線or 程式庫是 REST API 的說明。 Builder 程式庫會新增對話對話程式設計模型和其他功能，例如提示、瀑布圖、鏈結和引導式表單完成。 建立器程式庫也提供 Azure AI 服務的存取權，例如自然語言理解。

當使用者透過通道傳送訊息時，Bot Framework Web 服務會向 Bot 的 Web 服務端點發出 HTTPS POST。 Bot 可以針對它所傳送的每個訊息，向 Bot Framework 發出個別的 HTTPS POST，以將零、一或多個訊息傳回給該通道上的使用者。

從 Bot 的觀點來看，「反應」表示使用者藉由將訊息傳送至 Bot 來起始交談，而 Bot 會回應該訊息。 相反地，「主動」表示 Bot 會藉由傳送第一則訊息給使用者來起始交談。 例如，Bot 可能會傳送主動式訊息，以在計時器到期或事件發生時通知使用者。

如需示範如何傳送主動式訊息的範例，請參閱 GitHub 上 BotBuilder-Samples 存放庫中的 C# V4 範例 和 Node.js V4 範例 。

ETag 是開放式並行控制的機制。 Bot 資料袋儲存體會使用 ETag 來防止資料更新衝突。 HTTP 狀態碼為 412「前置條件失敗」的 ETag 錯誤表示 Bot 可以完成第一個作業之前，已平行接收多個訊息。 對話方塊堆疊和狀態會儲存在 Bot 資料袋中。 例如，如果您的 Bot 在收到該交談的新訊息時仍在處理先前的訊息，您可能會看到「前置條件失敗」ETag 錯誤。

Bot Framework 服務必須保護自己及其客戶免于濫用呼叫模式（例如，阻斷服務攻擊），讓任何 Bot 都無法對其他 Bot 的效能產生負面影響。 為了達到這種保護，我們已將速率限制（也稱為節流）新增至端點。 藉由強制執行速率限制，我們可以限制用戶端或 Bot 可以進行特定呼叫的頻率。 例如：啟用速率限制時，如果 Bot 想要張貼大量的活動，它必須將其隔開一段時間。 速率限制的目的不是限制 Bot 的總磁片區。 其設計目的是防止濫用未遵循人類對話模式的對話基礎結構。 例如，洪水淹沒兩個與超過兩個人可能取用的內容交談。

我們會持續調整速率限制，使其盡可能寬大，同時保護我們的服務和使用者。 因為臨界值偶爾會變更，所以我們目前不會發佈數位。 最後，如果您要在 App Service 上裝載 Bot，Bot 就會系結至 App Service 的限制。 如需詳細資訊，請參閱 Azure 服務的 SLA 摘要 如果您受到速率限制的影響，請放心地與我們 bf-reports@microsoft.com 連絡。

某些通道對可以傳送的檔案大小或類型有限制。 例如，Direct Line 和 Facebook 都會將活動承載限制為 262,144 個位元組 ，而 Bot Framework 模擬器則沒有限制。 通道會強制執行這類限制。 如果您傳送超過此限制的訊息，您可能會收到錯誤，例如： 要求內容長度超過 262,144 個位元組 的限制。 不過，您可以提供資源的連結做為網際網路附件。 如需傳送附件的詳細資訊，請參閱 如何將媒體新增至訊息 。

您不太可能遇到速率限制，即使在大量的情況下也是如此。 大部分速率限制只會因為大量傳送活動（從 Bot 或用戶端傳送）、極端負載測試或 Bug 而發生。 當要求受到節流處理時，會傳回 HTTP 429（太多要求）回應，並傳回 Retry-After 標頭，指出重試要求成功之前等待的時間量（以秒為單位）。 您可以透過 Azure 應用程式 Insights 啟用 Bot 的分析，以收集此資訊。 或者，您可以在 Bot 中新增程式碼來記錄訊息。

速率限制是由下列任何條件所造成：

• Bot 太頻繁地傳送訊息
• Bot 的用戶端太頻繁地傳送訊息
• Direct Line 用戶端要求新的 Web 通訊端太頻繁

有時，必須將交談從 Bot 轉移至人類，例如當 Bot 不了解使用者或要求無法自動化時。 在這些情況下，Bot 會提供轉換給人類。 Bot Framework SDK 支援交接給人類。 有一些 事件種類 可用於發出信號交接作業。 這些事件會在 Bot 與代理程式中樞之間 交換，也稱為參與中樞 。 此代理程式中樞定義為應用程式或系統，可讓代理程式通常是人類接收及處理來自使用者的要求，以及從 Bot 呈報要求。 如需詳細資訊，請參閱 將交談從 Bot 轉換至人類 一文。