工作階段代表 Dialogflow CX 代理程式和使用者之間的對話。您可以在對話開始時建立一個工作階段，並將其用於每一回合的對話。當對話結束，您便停止使用該工作階段。
您不該將同一工作階段用於與不同使用者的並行對話。最後一項要求傳送完畢之後，工作階段會持續運作 30 分鐘，並儲存這段期間內的所有資料。
每個工作階段都是由系統產生的工作階段 ID 所決定。 您可以在偵測意圖要求和其他工作階段方法中提供新的工作階段 ID，藉此建立新的工作階段。工作階段 ID 是長度最多 36 個位元組的字串。您的系統負責產生不重複的工作階段 ID，其可以是隨機數字、經過雜湊處理的使用者 ID，或是方便產生的任何其他值。
如要瞭解工作階段名稱中的 Location ID 值，請參閱區域化說明文件。
長時間工作階段
根據預設，Dialogflow CX 會保留工作階段資料 30 分鐘。延長工作階段生命週期的方法有兩種：
- (建議) 使用
QueryParameters.session_ttl設定工作階段存留時間。允許的最大值為 24 小時。 您可以設定
DetectIntentRequest中的QueryParameters.current_page和QueryParameters.parameters，還原先前的工作階段狀態。工作流程範例如下：
- 使用者在工作階段 A 中與代理程式對話。
- 您的程式碼會記錄與 API 回應中傳回的工作階段 A 相關聯的狀態，也就是
QueryResult.current_page和QueryResult.parameters。 - 使用者在 50 分鐘後停止與代理互動。
- 使用者再次與服務專員對話。
- 您的程式碼會將使用者輸入內容，連同先前在要求中記錄的
QueryParameters.current_page和QueryParameters.parameters，一併傳送至 Dialogflow，以偵測先前工作階段狀態的意圖。您不需要使用與工作階段 A 相同的會期 ID。
參考資料
如要瞭解工作階段定價，請參閱定價頁面。
如要進一步瞭解工作階段：
選取工作階段參照的通訊協定和版本：
| 通訊協定 | V3 | V3beta1 |
|---|---|---|
| REST | 工作階段資源 | 工作階段資源 |
| RPC | 工作階段介面 | 工作階段介面 |
| C++ | SessionsClient | 不適用 |
| C# | SessionsClient | 不適用 |
| Go | SessionsClient | 不適用 |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | 不適用 | 不適用 |
| Python | SessionsClient | SessionsClient |
| Ruby | 不適用 | 不適用 |