Комплексне тестування агента (API)

Запускайте одноразові симуляції, паралельні пакети сценаріїв і набори перевірок перед випуском через API ThunderPhone, щоб виявляти регресії агента до того, як їх почують клієнти.

Ітераційна робота з агентом ШІ означає ітераційну роботу з його промптом, інструментами та способом обробки крайніх випадків. API симуляцій виконує реальні виклики до агента за сценарним промптом, який ви надаєте. Якщо ціллю є агент, створюється запуск бот-до-бота; якщо ціллю є номер телефону, створюється SIP-замкнений запуск. Кожен запуск створює реальний журнал виклику з транскриптом, оцінюванням і білінгом, тож ви точно бачите, як поводиться агент і скільки це коштує.

Використовуйте це для:

• Smoke-тестів перед розгортанням після кожного редагування промпта
• Регресійних наборів, підключених до CI (підключіть вебхук test-call.completed → зупиняйте збірку, якщо оцінка знижується)
• Стрес-тестування лімітів одночасності

Одноразовий запуск: один сценарій#

curl -X POST https://api.thunderphone.com/v1/simulations \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_type":     "agent",
    "target_id":       12,
    "direction":       "outbound",
    "scenario_prompt": "You are a polite caller asking about refund policy for order 12345.",
    "consent_to_charge": true
  }'

Поля:

mode доступний лише для читання та визначається з target_type: agent створює mode="bot", тоді як phone_number створює mode="sip".

Відповідь містить об’єкт запуску симуляції зі status="queued". Опитуйте стан, доки status не стане completed або failed; щойно буде задано call_id, завантажте транскрипт через GET /v1/calls/{call_id}/transcript.

Пакети: паралельні сценарії#

Запускайте N сценаріїв одночасно — це корисно для регресійних наборів, які паралельно перевіряють кожен відомий крайній випадок:

curl -X POST https://api.thunderphone.com/v1/simulations/batches \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "target_type":     "agent",
    "target_id":       12,
    "direction":       "outbound",
    "run_count":       5,
    "stagger_seconds": 2,
    "scenario_prompts": [
      "Ask about refund policy.",
      "Ask for hours of operation.",
      "Complain about a delayed shipment.",
      "Ask to speak with a human.",
      "Ask an unrelated trivia question."
    ],
    "consent_to_charge": true
  }'

Відповідь містить список run_ids ідентифікаторів дочірніх запусків. Отримайте стан пакета:

curl https://api.thunderphone.com/v1/simulations/batches/{batch_id} \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY"

Для run_count установлено обмеження 20; stagger_seconds розподіляє запуск у часі, щоб не перевантажувати агента (0–60 с).

Підключіть до CI#

Створіть набір контрольних перевірок релізу на сторінці Симуляції (/dashboard/simulations) — виберіть агента, додайте сценарії вручну або натисніть Згенерувати сценарії за допомогою ШІ, щоб створити їх на основі промпту агента (за потреби з додатковою перевіркою крайніх випадків), і згрупуйте їх у набір. Набір фіксує свої сценарії та агента, а також мінімальний показник успішності й необов’язкове правило нульової кількості критичних збоїв. Успішні запуски стають прийнятим базовим рівнем; подальші переходи успішно→невдало повертаються як регресії.

Використовуйте API-ключ організації у CI. Цей скрипт запускає набір, опитує стан до завершення оцінювання та порівняння й завершується з ненульовим кодом, якщо вердикт не pass:

#!/usr/bin/env bash
set -euo pipefail
 
: "${THUNDERPHONE_API_KEY:?Set THUNDERPHONE_API_KEY}"
: "${THUNDERPHONE_ORG_ID:?Set THUNDERPHONE_ORG_ID}"
: "${THUNDERPHONE_SUITE_ID:?Set THUNDERPHONE_SUITE_ID}"
 
base="https://api.thunderphone.com/v1/orgs/${THUNDERPHONE_ORG_ID}/suites/${THUNDERPHONE_SUITE_ID}"
auth="Authorization: Bearer ${THUNDERPHONE_API_KEY}"
 
run_id="$(curl --fail --silent --show-error -X POST "${base}/run" \
  -H "$auth" -H "Content-Type: application/json" -d '{}' | jq -r '.id')"
 
deadline=$((SECONDS + 1800))
while (( SECONDS < deadline )); do
  result="$(curl --fail --silent --show-error \
    "${base}/runs/${run_id}" -H "$auth")"
  status="$(jq -r '.status' <<<"$result")"
  if [[ "$status" == "completed" ]]; then
    jq . <<<"$result"
    [[ "$(jq -r '.verdict' <<<"$result")" == "pass" ]]
    exit
  fi
  sleep 10
done
 
echo "ThunderPhone suite timed out" >&2
exit 1

POST /v1/orgs/{org_id}/suites/{suite_id}/run повертає 202 з ідентифікатором запуску. GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id} повертає status, verdict, pass_rate, critical_failure_count і список базових regressions. Обидві кінцеві точки прив’язують організацію в URL до організації API-ключа.

Запускайте набір за розкладом#

Відкрийте вкладку Симулювати агента, виберіть Набори контрольних перевірок релізу та створіть або відредагуйте набір. Увімкніть Запускати за розкладом, виберіть Частоту та Часовий пояс, а потім установіть Хвилину після початку години, Місцевий час або День, як показано. Виберіть Зберегти набір. Зняття позначки Запускати за розкладом видаляє розклад у панелі керування.

Через API#

Надішліть PATCH-запит до набору, щоб додати або замінити його розклад. Дивіться Набори (контрольні перевірки релізу), щоб переглянути повний об’єкт набору та кінцеві точки.

curl -X PATCH https://api.thunderphone.com/v1/suites/{suite_id} \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "schedule": {
      "enabled": true,
      "frequency": "daily",
      "timezone": "America/Chicago",
      "hour": 6,
      "minute": 30
    }
  }'

frequency може мати значення hourly, daily або weekly. Використовуйте часовий пояс IANA. Щогодинні розклади використовують minute; щоденні розклади використовують hour і minute; щотижневі розклади також використовують weekday, де понеділок — 0, а неділя — 6. Відповідь набору містить next_run_at і last_run_at.

Час відповідає переходам на літній і зимовий час у вибраному часовому поясі. Запуски за розкладом відображаються в історії запусків набору та використовують його поточного агента, сценарії, критерії й прийнятий базовий рівень. Кожен згенерований тестовий виклик надсилає test-call.completed; вебхука завершення на рівні набору немає. Заплановані виклики оплачуються за тим самим тарифом симуляції, що й ручні запуски набору, і записують trigger: "schedule" у запуск набору.

Щоб призупинити розклад без зміни його часу, надішліть PATCH-запит із повним наявним об’єктом розкладу та "enabled": false. frequency є обов’язковим; пропущені поля часового поясу та часу скидаються до значень за замовчуванням, тому включіть наявні значення. Надішліть "schedule": null, щоб видалити розклад.

Шаблони#

Регресійний корпус для кожного промпту#

Підтримуйте JSON-файл із кортежами {name, scenario_prompt, expected_outcome}. Після кожної зміни промпту запускайте весь набір пакетно; порівнюйте транскрипти й оцінки з попереднім запуском.

Smoke-тест для кожного релізу#

Єдиний пакет із п’яти сценаріїв успішного проходження, який ви запускаєте після кожного розгортання. Чутливий до затримки, тому залишайте stagger_seconds: 0.

Бенчмаркінг затримки#

Запускайте ідентичні сценарії для різних рівнів продукту (spark, bolt, storm-base). Порівнюйте оцінки call.graded і duration_seconds із журналу кожного отриманого виклику.

Наступні кроки#