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

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

Итерация ИИ-агента означает итерацию его промпта, инструментов и обработки пограничных случаев. API симуляций выполняет реальные звонки агенту с использованием заданного вами промпта сценария. Выбор агента создаёт запуск «бот — бот»; выбор номера телефона создаёт SIP-лупбэк. Каждый запуск создаёт реальный журнал звонка с расшифровкой, оценкой и тарификацией, поэтому вы точно видите, как ведёт себя агент и во сколько это обходится.

Используйте его для:

• Дымовых тестов перед развёртыванием после каждого изменения промпта
• Регрессионных наборов, подключённых к 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 из каждого полученного журнала вызова.

Следующие шаги#