Тествайте агент от край до край (API)
Итерирането на AI агент означава итериране на неговата подкана, инструментите му и начина, по който обработва гранични случаи. API за симулации извършва реални обаждания към агент, като използва предоставена от вас подкана за сценарий. Насочването към агент създава изпълнение бот към бот; насочването към телефонен номер създава SIP loopback изпълнение. Всяко изпълнение създава реален дневник на обаждането с транскрипция, оценяване и таксуване, така че да виждате точно как се държи агентът и колко струва това.
Използвайте го за:
- Бързи тестове преди внедряване след всяка редакция на подканата
- Регресионни пакети, свързани с CI (закачете webhook
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
}'
Полета:
| Поле | Тип | Задължително | Описание |
|---|---|---|---|
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".
Отговорът е обект за изпълнение на симулация
с 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) — изберете агента, добавете сценарии ръчно или
щракнете върху Генериране на сценарии с AI, за да ги създадете от
подканата на агента (с незадължителна проверка на крайни случаи), и ги
групирайте в пакет. Пакетът фиксира своите сценарии и агент, както и
минимален процент на успешно преминаване и незадължително правило за
нулев брой критични неуспехи. Успешните изпълнения стават приетата базова
линия; последващите преходи от успешно преминаване към неуспех се връщат
като регресии.
Използвайте 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 ключа.
Модели
Корпус за регресии за всяка подкана
Поддържайте JSON файл с кортежи {name, scenario_prompt, expected_outcome}.
При всяка промяна на подканата изпълнявайте целия набор като пакет; сравнявайте
транскрипциите и оценките с предходното изпълнение.
Бърз тест за всяко издание
Един пакет от пет сценария по щастливия път, който изпълнявате след всяко
разгръщане. Чувствителен към латентност, затова запазете stagger_seconds: 0.
Измерване на латентността
Изпълнявайте идентични сценарии спрямо различни продуктови нива (spark,
bolt, storm-base). Сравнявайте оценките call.graded и
duration_seconds от всеки получен журнал на обаждане.
Следващи стъпки
Всеки параметър на заявката, код на състоянието и структура на пакет.
Оценявайте автоматично всяко тестово изпълнение, за да проследявате качеството във времето.
Маркирайте конкретни тестове за преглед от човек.
Предавайте резултатите към вашите CI / Slack / PagerDuty.