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

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

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

Еднократно: единично изпълнение

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


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