---
title: "Тествайте агент от край до край (API)"
description: "Изпълнявайте еднократни симулации, паралелни пакети от сценарии и набори за контрол преди пускане чрез ThunderPhone API, така че регресиите на агента да бъдат откривани, преди клиентите да ги чуят."
---

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

Итерирането на ИИ агент означава итериране на неговата подкана, инструментите му
и начина, по който обработва гранични случаи. **API за симулации** извършва реални
обаждания към агент, като използва предоставена от вас подкана за сценарий. Насочването
към агент създава изпълнение бот към бот; насочването към телефонен номер създава
SIP loopback изпълнение. Всяко изпълнение създава реален журнал на обаждането с
транскрипция, оценяване и таксуване, така че да виждате точно как се държи агентът
и каква е цената.

Използвайте го за:

- Бързи тестове преди внедряване след всяка редакция на подканата
- Регресионни пакети, свързани с 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`) — изберете агента, добавете сценарии ръчно или
щракнете върху **Генериране на сценарии с AI**, за да ги създадете от
подканата на агента (с незадължителна проверка за крайни случаи), и ги
групирайте в набор. Наборът фиксира своите сценарии и агент, както и
минимален процент на успешно преминаване и незадължително правило за нула
критични неуспехи. Успешните изпълнения стават приетата базова линия;
последващите преходи от успешно към неуспешно преминаване се връщат като
регресии.

Използвайте [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="AI оценяване" icon="chart-line" href="/api-reference/calls#ai-call-grading">
    Оценявайте автоматично всяко тестово изпълнение, за да проследявате качеството с течение на времето.
  </Card>
  <Card title="Доклади за проблеми" icon="triangle-exclamation" href="/api-reference/issue-reports">
    Маркирайте конкретни тестове за преглед от човек.
  </Card>
  <Card title="Webhook test-call.completed" icon="bolt" href="/bg/webhooks/events">
    Предавайте резултатите поточно към вашите CI / Slack / PagerDuty.
  </Card>
</CardGroup>