Тествайте агент от край до край (API)

Изпълнявайте еднократни симулации, паралелни пакети от сценарии и набори за контрол преди пускане чрез ThunderPhone API, така че регресиите на агента да бъдат откривани, преди клиентите да ги чуят.

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

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

• Бързи тестове преди внедряване след всяка редакция на подканата
• Регресионни пакети, свързани с 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) — изберете агента, добавете сценарии ръчно или щракнете върху Генериране на сценарии с 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 ключа.

Изпълнявайте набор по график#

Отворете раздела Симулиране на агента, изберете Набори за шлюз за издание и създайте или редактирайте набор. Включете Изпълнение по график, изберете Честота и Часова зона, след което задайте Минута след часа, Местно време или Ден, както е показано. Изберете Запазване на набора. Премахването на отметката от Изпълнение по график премахва графика в таблото за управление.

Чрез 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 от всеки получен журнал на обаждане.

Следващи стъпки#