---
title: "Test en agent fra ende til anden (API)"
description: "Kør enkeltstående simuleringer, parallelle scenariebatches og release-gate-suiter gennem ThunderPhone API'et, så regressioner i agenten opdages, før kunderne hører dem."
---

<Note>
  Foretrækker du dashboardet? Den samme funktion findes under **Simuleringer**
  (`/dashboard/simulations`), herunder AI-scenariegenerering — se
  [Simuler et opkald](/da/guides/simulate-a-call). Denne side dækker den
  programmatiske metode.
</Note>

At iterere på en AI-agent betyder at iterere på dens prompt, dens værktøjer
og den måde, den håndterer særlige tilfælde på. **Simulerings-API'et** kører rigtige
opkald mod en agent ved hjælp af en scenarieprompt, du angiver. Målretning
mod en agent opretter en bot-til-bot-kørsel; målretning mod et telefonnummer opretter en
SIP-loopback-kørsel. Hver kørsel producerer en rigtig opkaldslog med
transskription, bedømmelse og fakturering, så du kan se præcis, hvordan agenten
opfører sig, og hvad den koster.

Brug det til:

- Smoke-tests før implementering efter hver promptredigering
- Regressionstest integreret i CI (tilknyt webhookpen `test-call.completed`
  → lad bygningen fejle, hvis scoren falder)
- Belastningstest af samtidighedsgrænser

## Engangskørsel: enkelt kørsel

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

Felter:

| Felt | Type | Påkrævet | Beskrivelse |
|-------|------|----------|-------------|
| `target_type` | streng | ja | `agent` eller `phone_number` |
| `target_id` | heltal | ja | Agent-id'et (eller telefonnummer-id'et) |
| `direction` | streng | nej | `outbound` (standard; testopkalderen ringer op) eller `inbound` (testopkalderen besvarer opkaldet) |
| `scenario_prompt` | streng | nej | Styrer, hvad testbotten siger |
| `language` / `primary_language` | streng | nej | Sprog for testopkalderen; ikke-understøttede koder afvises |
| `simulator_product` | streng | nej | `testing` (standard) eller `spark` for en mere menneskelignende simuleret opkalder, f.eks. konsultationstests ved varm viderestilling |
| `consent_to_charge` | boolesk | **ja** | Skal være `true`. Estimatet fakturerer både den valgte agent og den simulerede opkalder til en fast takst pr. minut plus eventuelle telefoni-led |
| `target_number` | streng | nej | E.164-tilsidesættelse for den eksterne side; ellers bruges platformens testnummer |

`mode` er skrivebeskyttet og afledes af `target_type`: `agent` producerer
`mode="bot"`, mens `phone_number` producerer `mode="sip"`.

Svaret er et [simuleringskørselsobjekt](/api-reference/test-calls#test-call-run-object)
med `status="queued"`. Poll, indtil `status` bliver `completed` eller
`failed`; når `call_id` er angivet, kan du indlæse transskriptionen via
[`GET /v1/calls/{call_id}/transcript`](/api-reference/calls#get-transcript).

## Batchkørsler: parallelle scenarier

Kør N scenarier samtidig — nyttigt til regressionssuiter, der
rammer alle kendte særlige tilfælde parallelt:

```bash
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 indeholder en `run_ids`-liste med id'er for underkørsler. Hent batchstatus:

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

`run_count` er begrænset til 20; `stagger_seconds` fordeler opstarten
for at undgå at overbelaste agenten (0–60 s).

## Kobl det til CI

Opret en release gate-pakke på siden **Simuleringer**
(`/dashboard/simulations`) — vælg agenten, tilføj scenarier manuelt, eller
klik på **Generer scenarier med AI** for at udarbejde dem ud fra agentens
prompt (med en valgfri gennemgang af kanttilfælde), og gruppér dem i en pakke.
En pakke fastlåser sine scenarier og sin agent samt en minimumsbeståelsesrate
og en valgfri regel om nul kritiske fejl. Beståede kørsler bliver den
accepterede basislinje; senere overgange fra bestået→ikke bestået returneres
som regressioner.

Brug en [organisations-API-nøgle](/api-reference/developer-api-keys) i CI.
Dette script udløser pakken, forespørger løbende, indtil vurdering og
sammenligning er fuldført, og afslutter med en ikke-nul-status, medmindre
afgørelsen er `pass`:

```bash
#!/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` returnerer `202` med
kørsels-id'et. `GET /v1/orgs/{org_id}/suites/{suite_id}/runs/{run_id}`
returnerer `status`, `verdict`, `pass_rate`, `critical_failure_count` og
basislinjens liste over `regressions`. Begge endpoints knytter organisationen
i URL'en til API-nøglens organisation.

## Kør en pakke efter en tidsplan

Åbn agentens fane **Simuler**, vælg **Release gate-pakker**, og opret eller
redigér en pakke. Slå **Kør efter en tidsplan** til, vælg **Frekvens** og
**Tidszone**, og angiv derefter **Minut efter timen**, **Lokal tid** eller
**Dag** som vist. Vælg **Gem pakke**. Hvis du fjerner markeringen af **Kør
efter en tidsplan**, fjernes tidsplanen i dashboardet.

### Via API

PATCH pakken for at tilføje eller erstatte dens tidsplan. Se [Pakker
(release gates)](/api-reference/test-scenarios#suites-release-gates) for det
fulde pakkeobjekt og endpoints.

```bash
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 være `hourly`, `daily` eller `weekly`. Brug en IANA-tidszone.
Timebaserede tidsplaner bruger `minute`; daglige tidsplaner bruger `hour` og
`minute`; ugentlige tidsplaner bruger også `weekday`, hvor mandag er `0`, og
søndag er `6`. Pakkesvaret indeholder `next_run_at` og `last_run_at`.

Tidspunkter følger den valgte tidszones ændringer for sommertid. Planlagte
kørsler vises i pakkens kørselshistorik og bruger dens aktuelle agent,
scenarier, kriterier og accepterede basislinje. Hvert genereret testopkald
udsender `test-call.completed`; der findes ingen webhook for fuldførelse på
pakkeniveau. Planlagte opkald faktureres til samme simuleringspris som manuelle
pakkekørsler og registrerer `trigger: "schedule"` på pakkekørslen.

Hvis du vil sætte en tidsplan på pause uden at ændre dens tidspunkt, skal du
PATCH det komplette eksisterende tidsplanobjekt med `"enabled": false`.
`frequency` er påkrævet; udeladte tidszone- og tidsfelter nulstilles til deres
standardværdier, så inkludér de eksisterende værdier. Send `"schedule": null`
for at fjerne tidsplanen.

## Mønstre

### Regressionkorpus pr. prompt

Vedligehold en JSON-fil med tuplerne `{name, scenario_prompt, expected_outcome}`.
Ved hver promptændring skal du køre hele sættet som en batch; sammenlign
transskriptionerne og vurderingerne med den forrige kørsel.

### Smoke-test pr. udgivelse

En enkelt batch med fem happy-path-scenarier, som du kører efter hver
udrulning. Latensfølsom, så behold `stagger_seconds: 0`.

### Latensbenchmarking

Kør identiske scenarier mod forskellige produktniveauer (`spark`,
`bolt`, `storm-base`). Sammenlign `call.graded`-scorerne og
`duration_seconds` fra hver resulterende opkaldslog.

---

## Næste trin

<CardGroup cols={2}>
  <Card title="Reference for testopkald" icon="flask" href="/api-reference/test-calls">
    Alle forespørgselsparametre, statuskoder og batchformater.
  </Card>
  <Card title="AI-vurdering" icon="chart-line" href="/api-reference/calls#ai-call-grading">
    Giv automatisk score til hver testkørsel for at følge kvaliteten over tid.
  </Card>
  <Card title="Problemrapporter" icon="triangle-exclamation" href="/api-reference/issue-reports">
    Markér specifikke tests til menneskelig gennemgang.
  </Card>
  <Card title="test-call.completed-webhook" icon="bolt" href="/da/webhooks/events">
    Stream resultater til din CI / Slack / PagerDuty.
  </Card>
</CardGroup>