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

<Note>
  Віддаєте перевагу панелі керування? Така сама можливість доступна в **Симуляціях**
  (`/dashboard/simulations`), зокрема з генеруванням сценаріїв за допомогою ШІ — див.
  [Симулювання виклику](/uk/guides/simulate-a-call). На цій сторінці описано
  програмний спосіб.
</Note>

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

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

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

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

```bash
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
  }'
```

Поля:

| Поле | Тип | Обов’язкове | Опис |
|-------|------|----------|-------------|
| `target_type` | рядок | так | `agent` або `phone_number` |
| `target_id` | ціле число | так | Ідентифікатор агента (або ідентифікатор номера телефону) |
| `direction` | рядок | ні | `outbound` (за замовчуванням; тестовий абонент здійснює дзвінок) або `inbound` (тестовий абонент відповідає) |
| `scenario_prompt` | рядок | ні | Визначає, що говорить тестовий бот |
| `language` / `primary_language` | рядок | ні | Мова тестового абонента; непідтримувані коди відхиляються |
| `simulator_product` | рядок | ні | `testing` (за замовчуванням) або `spark` для більш схожого на людину змодельованого абонента, наприклад для тестів консультації під час теплого переведення |
| `consent_to_charge` | логічне значення | **так** | Має бути `true`. За оцінкою тарифікуються і вибраний агент, і змодельований абонент за фіксованою похвилинною ставкою, а також будь-яке телефонне з’єднання |
| `target_number` | рядок | ні | Перевизначення E.164 для віддаленої сторони; інакше використовується тестовий номер платформи |

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

Відповідь містить [об’єкт запуску симуляції](/api-reference/test-calls#test-call-run-object)
зі `status="queued"`. Опитуйте стан, доки `status` не стане `completed` або
`failed`; щойно буде задано `call_id`, завантажте транскрипт через
[`GET /v1/calls/{call_id}/transcript`](/api-reference/calls#get-transcript).

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

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

```bash
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` ідентифікаторів дочірніх запусків. Отримайте
стан пакета:

```bash
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-ключ організації](/api-reference/developer-api-keys) у CI.
Цей скрипт запускає набір, опитує стан до завершення оцінювання та порівняння
й завершується з ненульовим кодом, якщо вердикт не `pass`:

```bash
#!/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-запит до набору, щоб додати або замінити його розклад. Дивіться [Набори
(контрольні перевірки релізу)](/api-reference/test-scenarios#suites-release-gates), щоб переглянути повний
об’єкт набору та кінцеві точки.

```bash
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` із журналу кожного отриманого виклику.

---

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

<CardGroup cols={2}>
  <Card title="Довідник тестових викликів" icon="flask" href="/api-reference/test-calls">
    Усі параметри запиту, коди стану та структури пакетів.
  </Card>
  <Card title="Оцінювання ШІ" icon="chart-line" href="/api-reference/calls#ai-call-grading">
    Автоматично оцінюйте кожен тестовий запуск, щоб відстежувати якість з часом.
  </Card>
  <Card title="Звіти про проблеми" icon="triangle-exclamation" href="/api-reference/issue-reports">
    Позначайте конкретні тести для перевірки людиною.
  </Card>
  <Card title="Вебхук test-call.completed" icon="bolt" href="/uk/webhooks/events">
    Передавайте результати у ваші CI / Slack / PagerDuty.
  </Card>
</CardGroup>