Testa en agent från början till slut (API)

Kör engångssimuleringar, parallella scenariobatcher och sviter för releasegrindar via ThunderPhone API så att regressionsfel i agenten fångas upp innan kunderna hör dem.

Att iterera på en röstagent innebär att iterera på dess prompt, dess verktyg och hur den hanterar kantfall. Simulerings-API:t kör riktiga samtal mot en agent med hjälp av en scenarioprompt som du tillhandahåller. Om du riktar in dig på en agent skapas en bot-till-bot-körning; om du riktar in dig på ett telefonnummer skapas en SIP-loopback-körning. Varje körning ger en riktig samtalslogg med transkript, betygsättning och debitering, så att du ser exakt hur agenten beter sig och vad den kostar.

Använd det för:

• Smoke-tester före driftsättning efter varje promptändring
• Regressionstester kopplade till CI (anslut webhooken test-call.completed → låt bygget misslyckas om poängen sjunker)
• Belastningstestning av samtidighetsgränser

Engångskörning: en enskild körning#

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

Fält:

mode är skrivskyddat och härleds från target_type: agent ger mode="bot", medan phone_number ger mode="sip".

Svaret är ett simuleringskörningsobjekt med status="queued". Polla tills status blir completed eller failed; när call_id har angetts läser du in transkriptet via GET /v1/calls/{call_id}/transcript.

Batchar: parallella scenarier#

Kör N scenarier samtidigt — användbart för regressionstester som träffar alla kända kantfall parallellt:

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

Svaret innehåller en run_ids-lista med underordnade körnings-id:n. Hämta batchstatus:

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

run_count är begränsat till 20; stagger_seconds fördelar starten för att undvika att överbelasta agenten (0–60 s).

Koppla det till CI#

Skapa en svit för versionsgrindar på sidan Simuleringar (/dashboard/simulations) — välj agenten, lägg till scenarier manuellt eller klicka på Generera scenarier med AI för att utforma dem från agentens prompt (med en valfri genomgång av kantfall), och gruppera dem i en svit. En svit låser sina scenarier och sin agent, samt en lägsta godkännandegrad och en valfri regel om noll kritiska fel. Godkända körningar blir den accepterade baslinjen; senare övergångar från godkänd→underkänd returneras som regressioner.

Använd en API-nyckel för organisationen i CI. Det här skriptet startar sviten, kontrollerar tills betygsättning och jämförelse är klara och avslutas med en kod skild från noll om inte bedömningen är 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 returnerar 202 med körnings-id:t. GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id} returnerar status, verdict, pass_rate, critical_failure_count och baslinjens lista med regressions. Båda slutpunkterna kopplar organisationen i URL:en till API-nyckelns organisation.

Kör en svit enligt ett schema#

Öppna agentens flik Simulera, välj Sviter för versionsgrindar och skapa eller redigera en svit. Aktivera Kör enligt ett schema, välj Frekvens och Tidszon, och ställ sedan in Minut efter hel timme, Lokal tid eller Dag enligt anvisningarna. Välj Spara svit. Om du avmarkerar Kör enligt ett schema tas dashboardschemat bort.

Via API#

Skicka en PATCH-begäran till sviten för att lägga till eller ersätta dess schema. Se Sviter (versionsgrindar) för det fullständiga svitobjektet och slutpunkterna.

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 kan vara hourly, daily eller weekly. Använd en IANA-tidszon. Scheman per timme använder minute; dagliga scheman använder hour och minute; veckovisa scheman använder även weekday, där måndag är 0 och söndag är 6. Svitsvaret innehåller next_run_at och last_run_at.

Tider följer den valda tidszonens ändringar för sommartid. Schemalagda körningar visas i svitens körningshistorik och använder dess aktuella agent, scenarier, kriterier och accepterade baslinje. Varje genererat testsamtal skickar test-call.completed; det finns ingen webhook för slutförande på svitnivå. Schemalagda samtal debiteras enligt samma simuleringspris som manuella svitkörningar och registrerar trigger: "schedule" på svitkörningen.

Om du vill pausa ett schema utan att ändra dess tid skickar du en PATCH-begäran med hela det befintliga schemaobjektet och "enabled": false. frequency krävs; utelämnade fält för tidszon och tid återställs till sina standardvärden, så inkludera de befintliga värdena. Skicka "schedule": null för att ta bort schemat.

Mönster#

Regressionstestkorpus per prompt#

Underhåll en JSON-fil med tuplerna {name, scenario_prompt, expected_outcome}. Kör hela uppsättningen som en batch vid varje promptändring; jämför transkriptionerna och betygen med föregående körning.

Röktest per lansering#

En enda batch med fem scenarier för lyckade standardflöden som du kör efter varje distribution. Latenskänsligt, så behåll stagger_seconds: 0.

Latensbenchmarking#

Kör identiska scenarier mot olika produktnivåer (spark, bolt, storm-base). Jämför poängen för call.graded och duration_seconds från varje resulterande samtalslogg.

Nästa steg#