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

<Note>
  Предпочитаете панель управления? Та же возможность доступна в разделе **Симуляции**
  (`/dashboard/simulations`), включая генерацию сценариев с помощью ИИ — см.
  [Симуляция звонка](/ru/guides/simulate-a-call). На этой странице описан
  программный способ.
</Note>

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

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

- Дымовых тестов перед развёртыванием после каждого изменения промпта
- Регрессионных наборов, подключённых к 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="/ru/webhooks/events">
    Передавайте результаты в CI / Slack / PagerDuty.
  </Card>
</CardGroup>