ThunderPhone 2.0 è arrivato.Parti in autonomia, da 2¢/min.Leggi l’annuncio

Developer cookbook

Testa un agente end-to-end (API)

Esegui simulazioni singole, batch paralleli di scenari e suite di controllo del rilascio tramite l

Iterare su un agente IA significa iterare sul prompt, sugli strumenti e sul modo in cui gestisce i casi limite. L'API delle simulazioni esegue chiamate reali a un agente usando un prompt di scenario fornito da te. Se scegli come destinazione un agente, viene creata un'esecuzione bot-to-bot; se scegli un numero di telefono, viene creata un'esecuzione loopback SIP. Ogni esecuzione produce un registro di chiamata reale con trascrizione, valutazione e fatturazione, così puoi vedere esattamente come si comporta l'agente e quanto costa.

Usala per:

  • Test smoke prima del deploy dopo ogni modifica al prompt
  • Suite di regressione integrate nella CI (collega il webhook test-call.completed → fai fallire la build se il punteggio diminuisce)
  • Test di carico dei limiti di concorrenza

Esecuzione singola: una sola chiamata

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
  }'

Campi:

CampoTipoObbligatorioDescrizione
target_typestringagent o phone_number
target_idintegerL'ID dell'agente (o l'ID del numero di telefono)
directionstringnooutbound (predefinito; il chiamante di test effettua la chiamata) o inbound (il chiamante di test risponde)
scenario_promptstringnoDetermina cosa dice il bot di test
language / primary_languagestringnoLingua del chiamante di test; i codici non supportati vengono rifiutati
simulator_productstringnotesting (predefinito) o spark per un chiamante simulato più umano, ad esempio per test di consultazione durante trasferimenti a caldo
consent_to_chargebooleanDeve essere true. La stima fattura sia l'agente selezionato sia il chiamante simulato, oltre a qualsiasi tratta telefonica
target_numberstringnoOverride E.164 per il lato remoto; altrimenti viene usato il numero di test della piattaforma

mode è di sola lettura e deriva da target_type: agent produce mode="bot", mentre phone_number produce mode="sip".

La risposta è un oggetto di esecuzione della simulazione con status="queued". Esegui il polling finché status non diventa completed o failed; una volta impostato call_id, carica la trascrizione tramite GET /v1/calls/{call_id}/transcript.

Batch: scenari paralleli

Esegui N scenari contemporaneamente: utile per suite di regressione che coprono in parallelo ogni caso limite noto:

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
  }'

La risposta contiene un elenco run_ids di ID delle esecuzioni figlie. Recupera lo stato del batch:

curl https://api.thunderphone.com/v1/simulations/batches/{batch_id} \
  -H "Authorization: Bearer sk_live_YOUR_API_KEY"

run_count è limitato a 20; stagger_seconds distanzia gli avvii per evitare di sovraccaricare l'agente (0–60 s).

Integralo nel CI

Crea una suite di gate per le release nella pagina Simulazioni (/dashboard/simulations): seleziona l'agente, aggiungi scenari manualmente oppure fai clic su Genera scenari con l'IA per crearne una bozza a partire dal prompt dell'agente (con un passaggio facoltativo sui casi limite), quindi raggruppali in una suite. Una suite fissa gli scenari e l'agente, oltre a una percentuale minima di superamento e a una regola facoltativa di zero errori critici. Le esecuzioni superate diventano la baseline accettata; le successive transizioni da superato a non superato vengono restituite come regressioni.

Usa una chiave API dell'organizzazione nel CI. Questo script avvia la suite, esegue il polling finché la valutazione e il confronto non sono completi, quindi termina con un codice diverso da zero a meno che il verdetto non sia 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 restituisce 202 con l'ID dell'esecuzione. GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id} restituisce status, verdict, pass_rate, critical_failure_count e l'elenco delle regressions della baseline. Entrambi gli endpoint associano l'organizzazione nell'URL all'organizzazione della chiave API.

Modelli

Corpus di regressione per prompt

Mantieni un file JSON di tuple {name, scenario_prompt, expected_outcome}. A ogni modifica del prompt, esegui l'intero insieme come batch; confronta le trascrizioni e le valutazioni con l'esecuzione precedente.

Smoke test per release

Un singolo batch di cinque scenari nel percorso ideale, da eseguire dopo ogni deploy. Sensibile alla latenza, quindi mantieni stagger_seconds: 0.

Benchmark della latenza

Esegui scenari identici su diversi livelli di prodotto (spark, bolt, storm-base). Confronta i punteggi call.graded e duration_seconds di ogni log di chiamata risultante.


Passaggi successivi