偏好使用控制台?相同功能位於 模擬
(
/dashboard/simulations),其中包括人工智慧情境生成——請參閱
模擬通話。本頁說明程式化使用方式。- 每次編輯提示後,在部署前執行冒煙測試
- 串接至 CI 的迴歸測試套件(掛接
test-call.completedwebhook → 若分數下降則使建置失敗) - 壓力測試並行數限制
單次執行:單一測試
mode 為唯讀,並由 target_type 衍生:agent 會產生
mode="bot",而 phone_number 會產生 mode="sip"。
回應為 status="queued" 的模擬執行物件。
輪詢直到 status 變為 completed 或 failed;設定 call_id 後,
透過 GET /v1/calls/{call_id}/transcript
載入逐字稿。
批次:平行情境
同時執行 N 個情境——適合讓迴歸測試套件平行測試每個已知的 邊界情況:run_ids 清單。取得批次狀態:
run_count 上限為 20;stagger_seconds 會間隔啟動時間,
以避免對智慧體造成過大負載(0–60 秒)。
將其串接至 CI
在 模擬 頁面 (/dashboard/simulations)建立發行閘門套件——選擇智慧體、手動新增情境,或
點選 使用 AI 產生情境,根據智慧體的提示詞草擬情境
(可選擇額外進行邊緣案例檢查),再將它們分組為套件。
套件會固定其情境與智慧體,以及最低通過率和可選的零關鍵失敗規則。通過的執行結果會成為已接受的基準;後續從通過→失敗的變化會回傳為迴歸問題。
在 CI 中使用組織 API 金鑰。
此指令碼會觸發套件、輪詢直到評分與比較完成,並在判定結果不是 pass 時以非零狀態碼結束:
POST /v1/orgs/{org_id}/suites/{suite_id}/run 會以執行 ID 回傳 202。
GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id} 會回傳
status、verdict、pass_rate、critical_failure_count,以及基準的
regressions 清單。兩個端點都會將 URL 中的組織綁定至 API 金鑰所屬的組織。
模式
每個提示詞的迴歸測試語料庫
維護一個包含{name, scenario_prompt, expected_outcome}
元組的 JSON 檔案。每次提示詞變更時,將完整集合以批次方式執行;並將通話記錄與評分和前一次執行結果進行差異比較。
每次發行的冒煙測試
每次部署後執行一批包含五個正常路徑情境的測試。此測試對延遲敏感,因此請保持stagger_seconds: 0。
延遲效能評測
針對不同產品層級(spark、
bolt、storm-base)執行相同情境。比較 call.graded 分數,以及每筆產生的通話紀錄中的 duration_seconds。
後續步驟
測試通話參考資料
所有查詢參數、狀態碼與批次格式。
AI 評分
自動為每次測試執行評分,以長期追蹤品質。
問題報告
標記特定測試以供人工審查。
test-call.completed Webhook
將結果串流至你的 CI / Slack / PagerDuty。
