DEV Community

Cover image for KI Agenten testen: So vermeiden Sie Datenverlust beim API-Test
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

KI Agenten testen: So vermeiden Sie Datenverlust beim API-Test

Ein KI-Programmieragent führte ein Skript aus, sah einen Erfolg und beobachtete danach, wie eine Produktionstabelle verschwand. Der Hacker-News-Post-Mortem wurde viral: „Die KI hat deine Datenbank nicht gelöscht, du hast es getan.“ Der Punkt sitzt, weil er stimmt: Der Agent folgte einer Tool-Definition, das Tool traf einen echten Endpunkt, der Endpunkt hatte keine Schutzvorkehrungen, und ein Mensch hatte produktive Schlüssel an einen Prozess übergeben, der nicht stoppt, wenn DELETE FROM users verdächtig aussieht. Ein r/ClaudeAI-Thread beschrieb denselben Fehlertyp aus der Kostenperspektive: Ein Agent lief in eine Abrechnungsschleife und verbrannte Hunderte Euro an Tokens. Andere Oberfläche, gleiche Ursache: Niemand hatte die API ausreichend getestet.

Teste Apidog noch heute

💡 Wenn Sie autonome Agenten bereitstellen, die APIs aufrufen, testen Sie nicht nur Prompts. Testen Sie Tool-Schemas, API-Verträge, destruktive Operationen, Budgets, Idempotenz und Fehlerszenarien. In diesem Leitfaden verwenden wir Apidog, weil es OpenAPI nativ importiert, Mock-Server ohne Glue-Code bereitstellt und Szenario-Tests für Tool-Aufrufsequenzen unterstützt.

Kurz gesagt

Agenten scheitern in Produktion meistens nicht, weil das Modell „dumm“ ist, sondern weil die API-Schicht zu viel erlaubt:

  • keine Ratenbegrenzungen
  • keine Idempotenz
  • produktive Schreibrechte in Entwicklungsloops
  • fehlerhafte Tool-Schemas
  • keine Mock- oder Sandbox-Umgebung
  • keine Budgetobergrenzen

Die praktische Lösung besteht aus vier Schritten:

  1. Tool-Definitionen gegen Ihre OpenAPI-Spezifikation testen.
  2. Destruktive Endpunkte über Mock-Server oder Sandboxes ausführen.
  3. Idempotenzschlüssel und Soft-Deletes erzwingen.
  4. Budgets und Fehlerszenarien in CI testen.

Apidog kombiniert OpenAPI-Import, Mocks und Szenario-Runner in einem Projekt.

Warum Agentenfehler wie API-Fehler aussehen

Ein Agent handelt über Tools. Diese Tools sind letztlich API-Aufrufe. Wenn etwas schiefgeht, liegt der relevante Kontrollpunkt daher meistens nicht im Prompt, sondern an der API-Grenze.

Beispiel 1: Prompt-Injektion trifft Admin-Endpunkt

Ein Benutzer lädt ein PDF mit versteckten Anweisungen hoch. Der Agent liest es und ruft danach einen internen Endpunkt auf:

POST /admin/users/delete
Content-Type: application/json

{
  "delete_all": true
}
Enter fullscreen mode Exit fullscreen mode

Das Modell hat nicht „bösartig entschieden“. Es hat eine Anweisung befolgt. Die API hätte den Aufruf verhindern müssen.

Besser:

  • Benutzerkontext serverseitig prüfen.
  • Admin-Endpunkte nicht über normale Agenten-Tokens verfügbar machen.
  • Schreiboperationen hinter Genehmigungen legen.
  • Produktive Schlüssel nie direkt an Agenten geben.

OWASP behandelt diese Klasse in den LLM Top 10 als Prompt-Injection-Risiko. Die Gegenmaßnahme ist aber nicht nur Prompt-Härtung, sondern API-seitige Autorisierung.

Beispiel 2: Tool-Schema driftet von OpenAPI ab

Ihre OpenAPI-Spezifikation sagt:

amount:
  type: integer
  description: Betrag in Cent
Enter fullscreen mode Exit fullscreen mode

Die Tool-Definition des Agenten sagt:

{
  "amount": {
    "type": "number",
    "description": "Amount in dollars"
  }
}
Enter fullscreen mode Exit fullscreen mode

Ergebnis: Aus 19 Cent können 19 Dollar werden.

Das Modell war nicht „falsch“. Es hat das Schema verwendet, das Sie ihm gegeben haben. Deshalb müssen Tool-Schemas wie API-Verträge behandelt und in CI getestet werden.

Beispiel 3: Wiederholungsschleifen ohne Budget

Ein Agent ruft einen E-Mail-Endpunkt auf, bekommt einen Timeout und versucht es erneut. Und erneut. Und erneut.

Ohne Limits entstehen schnell:

  • hohe Token-Kosten
  • API-Kosten
  • Spam an Kunden
  • gesperrte Anbieter-Konten

Die API muss hier mit Rate Limits, Budgets und strukturierten Fehlern reagieren.

Beispiel 4: Fehlende Idempotenz bei Zahlungen

Der Agent ruft auf:

POST /payments
Enter fullscreen mode Exit fullscreen mode

Dann kommt ein Netzwerk-Timeout. Der Agent weiß nicht, ob die Zahlung verarbeitet wurde, und versucht es erneut. Ohne Idempotenz wird der Kunde doppelt belastet.

Mit Idempotenz:

POST /payments
Idempotency-Key: refund-123e4567
Enter fullscreen mode Exit fullscreen mode

Die API erkennt den zweiten Versuch und gibt dieselbe Antwort zurück, statt die Operation erneut auszuführen.

Die vier Schutzvorkehrungen für Agenten-APIs

1. Vertragstests für Tool-Schemas

Ihre OpenAPI-Spezifikation sollte die einzige Quelle der Wahrheit sein. Tool-Definitionen für Claude, GPT oder eigene Agenten-Harnesses müssen dagegen validiert werden.

Minimaler Python-Check:

import json
from jsonschema import Draft202012Validator

def validate_tool_against_openapi(tool_def: dict, openapi_spec: dict) -> list[str]:
    """Return a list of mismatch errors. Empty list = pass."""
    errors = []

    op = openapi_spec["paths"][tool_def["path"]][tool_def["method"].lower()]
    api_schema = op["requestBody"]["content"]["application/json"]["schema"]
    tool_schema = tool_def["input_schema"]

    api_props = set(api_schema.get("properties", {}).keys())
    tool_props = set(tool_schema.get("properties", {}).keys())

    for missing in api_props - tool_props:
        if missing in api_schema.get("required", []):
            errors.append(f"Tool missing required field: {missing}")

    for extra in tool_props - api_props:
        errors.append(f"Tool defines field not in API: {extra}")

    for prop, api_def in api_schema.get("properties", {}).items():
        if prop in tool_schema.get("properties", {}):
            tool_def_prop = tool_schema["properties"][prop]

            if api_def.get("type") != tool_def_prop.get("type"):
                errors.append(
                    f"Type mismatch on {prop}: "
                    f"API={api_def.get('type')} "
                    f"tool={tool_def_prop.get('type')}"
                )

    return errors
Enter fullscreen mode Exit fullscreen mode

Beispiel für GitHub Actions:

name: agent-api-contracts

on:
  pull_request:
    paths:
      - "openapi.yaml"
      - "agent-tools/**"

jobs:
  validate-contracts:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - run: pip install jsonschema pyyaml

      - run: python scripts/validate_agent_tools.py
Enter fullscreen mode Exit fullscreen mode

Regel: Wenn Tool-Schema und OpenAPI-Schema abweichen, schlägt der Build fehl. Keine Warnung. Fehler.

2. Mock- und Sandbox-Umgebungen für destruktive Endpunkte

Agenten brauchen eine Trainingsumgebung. Diese darf nicht Produktion sein.

Muster:

Umgebung Zweck Daten
Mock schnelle Agentenentwicklung keine echten Daten
Sandbox Integrationstest isolierte Testdaten
Staging produktionsnaher Test kontrollierte Daten
Produktion echte Ausführung echte Daten, mit Limits

Jeder zustandsändernde Endpunkt braucht ein Mock-Äquivalent:

  • POST
  • PUT
  • PATCH
  • DELETE

Mit Apidog können Sie Mocks direkt aus OpenAPI generieren. Das passt zum Contract-First Development: Erst Vertrag definieren, dann Mocks, Tests und Implementierung daran ausrichten.

3. Idempotenzschlüssel und Soft-Deletes

Jeder Schreib-Endpunkt, den ein Agent aufrufen darf, sollte einen Idempotenzschlüssel verlangen.

Express-Beispiel:

const idempotencyCache = new Map();

function idempotency(req, res, next) {
  const key = req.headers["idempotency-key"];

  if (!key) {
    return res.status(400).json({
      error: "Missing Idempotency-Key header"
    });
  }

  if (idempotencyCache.has(key)) {
    const cached = idempotencyCache.get(key);
    return res.status(cached.status).json(cached.body);
  }

  const originalJson = res.json.bind(res);

  res.json = function (body) {
    idempotencyCache.set(key, {
      status: res.statusCode,
      body
    });

    setTimeout(() => {
      idempotencyCache.delete(key);
    }, 24 * 60 * 60 * 1000);

    return originalJson(body);
  };

  next();
}

app.post("/payments", idempotency, createPayment);
Enter fullscreen mode Exit fullscreen mode

Für produktive Systeme sollte der Cache nicht in Memory liegen, sondern z. B. in Redis oder einer Datenbank mit TTL.

Zusätzlich:

  • DELETE standardmäßig als Soft-Delete implementieren.
  • Hard-Deletes nur über separaten Pfad erlauben.
  • Hard-Deletes mit menschlicher Freigabe schützen.

Beispiel:

DELETE /users/123
Enter fullscreen mode Exit fullscreen mode

setzt intern nur:

{
  "deleted_at": "2026-05-06T12:00:00Z",
  "deleted_by": "agent:support-triage"
}
Enter fullscreen mode Exit fullscreen mode

Ein echter Hard-Delete läuft über:

POST /admin/users/123/permanent-delete
Enter fullscreen mode Exit fullscreen mode

und erfordert menschliche Bestätigung.

4. Pro-Agenten-Budgetobergrenzen

Jeder Agent braucht harte Limits:

  • Token pro Sitzung
  • API-Aufrufe pro Minute
  • Kosten pro Aufgabe
  • maximale Tool-Aufruftiefe
  • maximale Laufzeit

Beispielwerte für den Start:

Limit Startwert
Tokens pro Sitzung 50.000
API-Aufrufe pro Minute 30
Kosten pro Aufgabe 5 Dollar
Verschachtelte Tool-Aufrufe 10
Laufzeit pro Aufgabe 5 Minuten

Wenn ein Limit erreicht wird, sollte die API strukturiert antworten:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-Budget-Exceeded: api_calls_per_minute
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "error": "budget_exceeded",
  "limit": "api_calls_per_minute",
  "retry_after_seconds": 60,
  "requires_human_review": true
}
Enter fullscreen mode Exit fullscreen mode

Der Agent kann dann stoppen, eskalieren oder die Aufgabe verkleinern.

API-Aufrufe von Agenten mit Apidog testen

Für den praktischen Workflow benötigen Sie:

  • eine OpenAPI-3.x-Spezifikation
  • die Tool-Definitionen Ihres Agenten
  • eine Liste der destruktiven Endpunkte
  • Test-Credentials für Mock oder Sandbox

Apidog wird hier als Testgerüst verwendet.

Agenten-Test-Workflow mit Apidog

Schritt 1: OpenAPI-Spezifikation importieren

Öffnen Sie Apidog, erstellen Sie ein neues Projekt und importieren Sie Ihre OpenAPI-Datei.

Danach sollten Sie prüfen:

  • Sind alle Pfade vorhanden?
  • Sind Request-Bodies vollständig beschrieben?
  • Sind required-Felder korrekt?
  • Sind Enums gepflegt?
  • Gibt es Beispiele für Erfolgs- und Fehlerantworten?

Wenn Ihre API noch nicht sauber in OpenAPI dokumentiert ist, beginnen Sie mit einem Design-First-Workflow. Der Design-First API Workflow Guide beschreibt diesen Ansatz.

Schritt 2: Mock-Antworten für Schreib-Endpunkte definieren

Markieren Sie alle zustandsändernden Endpunkte:

POST   /tickets/{id}/triage
POST   /notifications
PATCH  /users/{id}
DELETE /users/{id}
POST   /payments/refund
Enter fullscreen mode Exit fullscreen mode

Für jeden Endpunkt legen Sie eine Mock-Antwort an. Verwenden Sie bewusst erkennbare Testdaten:

{
  "id": "mock_user_1970_001",
  "email": "mock_user@example.test",
  "status": "deleted",
  "deleted_at": "1970-01-01T00:00:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Warum so offensichtlich?

  • Mock-Daten sind in Logs sofort erkennbar.
  • Lecks in Staging oder Produktion fallen schneller auf.
  • Entwickler verwechseln sie nicht mit echten Nutzerdaten.

Starten Sie anschließend den Mock-Server. Apidog stellt eine stabile Mock-URL bereit, z. B.:

https://mock.apidog.com/m1/your-project-id/
Enter fullscreen mode Exit fullscreen mode

Setzen Sie diese URL als Base URL Ihres Agenten:

AGENT_API_BASE_URL="https://mock.apidog.com/m1/your-project-id/"
Enter fullscreen mode Exit fullscreen mode

Keine Mock-URL in Prompts hartkodieren. Verwenden Sie Umgebungsvariablen, damit derselbe Agent gegen Mock, Staging und Produktion laufen kann.

Weitere Teststrategien finden Sie unter API-Tests für QA-Ingenieure.

Schritt 3: Agenten-Aufrufsequenz als Szenario abbilden

Ein Agent, der Support-Tickets triagiert, könnte diese API-Sequenz ausführen:

  1. POST /auth/token
  2. GET /tickets?status=open
  3. POST /tickets/{id}/triage
  4. POST /notifications

In Apidog bilden Sie daraus ein Szenario mit Assertions.

Beispiel-Assertions:

POST /auth/token
- Status ist 200
- response.access_token existiert

GET /tickets?status=open
- Status ist 200
- response.items[0].id existiert

POST /tickets/{id}/triage
- Status ist 200
- response.category ist einer von ["billing", "bug", "account", "other"]

POST /notifications
- Status ist 200
- response.message_id existiert
Enter fullscreen mode Exit fullscreen mode

Damit testen Sie nicht nur einzelne Endpunkte, sondern den Ablauf, den der Agent wirklich nutzt.

Wenn ein Entwickler das Ticket-Schema ändert und category plötzlich anders heißt, schlägt das Szenario fehl, bevor der Agent Produktion erreicht. Das gleiche Playbook wird in API-Tests für QA-Ingenieure ausführlicher behandelt.

Schritt 4: Szenarien in CI ausführen

Apidog stellt eine CLI bereit, mit der Sie Szenarien aus CI ausführen können:

apidog run -t scenario-id --env test
Enter fullscreen mode Exit fullscreen mode

Beispiel für eine Pipeline:

name: apidog-agent-api-tests

on:
  pull_request:
    paths:
      - "openapi.yaml"
      - "agent-tools/**"
      - "src/api/**"

jobs:
  api-scenarios:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run Apidog scenarios
        run: apidog run -t ${{ secrets.APIDOG_SCENARIO_ID }} --env test
Enter fullscreen mode Exit fullscreen mode

Empfohlene CI-Regel:

  • OpenAPI geändert → Szenarien ausführen.
  • Tool-Definition geändert → Vertragstest und Szenarien ausführen.
  • API-Implementierung geändert → Szenarien ausführen.
  • Modellversion geändert → Trace-Vergleich ausführen.

Schritt 5: Modellversionen vergleichen

Wenn Sie von Modell A auf Modell B wechseln, testen Sie nicht nur Antwortqualität. Vergleichen Sie die Tool-Aufrufe.

Vorgehen:

  1. Agent mit Modell A gegen Mock-Szenario ausführen.
  2. Tool-Trace speichern.
  3. Agent mit Modell B gegen dasselbe Szenario ausführen.
  4. Tool-Trace speichern.
  5. Requests vergleichen.

Achten Sie auf:

  • fehlende Felder
  • andere Enums
  • anderes Datumsformat
  • zusätzliche Tool-Aufrufe
  • andere Reihenfolge
  • neue Schreiboperationen

Beispiel-Diff:

POST /tickets/123/triage

{
- "priority": "medium",
+ "priority": "urgent",
  "category": "billing"
}
Enter fullscreen mode Exit fullscreen mode

Das kann fachlich korrekt sein — oder ein unerwarteter Verhaltenswechsel. Wichtig ist, dass Sie ihn vor dem Rollout sehen.

Dieses Muster ist auch bei Modell-Upgrades relevant, wie im Beitrag zur GPT-5.5 API-Integration beschrieben.

Fortgeschrittene Techniken

Temperatur in Tests auf 0 setzen

Wenn Sie Tool-Verhalten testen, wollen Sie deterministische Ausgaben.

{
  "temperature": 0,
  "top_p": 1
}
Enter fullscreen mode Exit fullscreen mode

Sie testen nicht Kreativität, sondern:

  • Tool-Auswahl
  • Argumentstruktur
  • Reihenfolge
  • Fehlerbehandlung

Tool-Aufruf-Traces snapshotten

Speichern Sie pro Testlauf:

[
  {
    "tool": "get_open_tickets",
    "arguments": {
      "status": "open"
    }
  },
  {
    "tool": "triage_ticket",
    "arguments": {
      "ticket_id": "mock_ticket_001",
      "category": "billing"
    }
  }
]
Enter fullscreen mode Exit fullscreen mode

Vergleichen Sie den aktuellen Trace mit der Baseline.

Wenn der Agent plötzlich delete_user aufruft, soll der Build fehlschlagen.

Keine Produktionszugangsdaten für Agenten

Agenten sollten niemals allgemeine Produktions-Credentials erhalten.

Besser:

  • aufgabenspezifische Service-Konten
  • kurzlebige Tokens
  • Proxy mit serverseitiger Signatur
  • getrennte Lese- und Schreibschlüssel
  • Secret Storage statt .env im Agentenkontext

Lese- und Schreibrechte trennen

Viele Agentenaufgaben sind primär lesend. Geben Sie solchen Agenten nur Leseschlüssel.

Beispiel:

AGENT_READ_API_KEY=...
AGENT_WRITE_API_KEY=...
Enter fullscreen mode Exit fullscreen mode

Schreibschlüssel nur aktivieren, wenn:

  • die Aufgabe Schreibzugriff wirklich braucht
  • Budgetlimits gesetzt sind
  • Idempotenz aktiv ist
  • Genehmigungsregeln definiert sind

HTTP 423 für menschliche Freigaben verwenden

Für Operationen mit menschlicher Bestätigung ist 423 Locked oft sauberer als 403 Forbidden.

HTTP/1.1 423 Locked
Content-Type: application/json
Enter fullscreen mode Exit fullscreen mode 
{
  "error": "human_confirmation_required",
  "confirmation_url": "https://internal.example.com/approve/abc123",
  "expires_at": "2026-05-06T13:00:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Semantik:

  • 403: Du darfst das nicht.
  • 423: Du darfst das noch nicht.

Der Agent kann die URL an einen Menschen weitergeben und warten.

Bei Schemaabweichung geschlossen fehlschlagen

Wenn Tool-Schema und OpenAPI-Schema nicht übereinstimmen:

  • kein Soft Warning
  • kein „später reparieren“
  • kein automatisches Deployment

Der Build muss fehlschlagen. Die Kosten eines fehlgeschlagenen Builds sind geringer als ein Produktionsvorfall.

Häufige Fehler vermeiden

  • Mock-URLs in Prompts hartkodieren.
  • Idempotenz bei „kleinen“ Schreiboperationen überspringen.
  • vollständige Request-Bodies mit PII loggen.
  • Agenten direkten Datenbankzugriff geben.
  • Konfidenzwerte des Modells mit API-Sicherheit verwechseln.
  • Produktions- und Test-Credentials im selben Agenten-Kontext mischen.
  • DELETE ohne Soft-Delete oder Freigabe erlauben.

Wenn Agenten mit mehreren internen Diensten arbeiten, helfen die Microservices-Testmuster, Szenarien über Service-Grenzen hinweg aufzubauen.

Alternativen und Tools

Ansatz Einrichtungszeit Stärke Schwäche Am besten geeignet für
Manuelle Unit-Tests niedrig volle Kontrolle, keine Herstellerbindung hoher Wartungsaufwand, Drift zur echten API möglich kleine Projekte, Einzelentwickler
LangSmith / LangGraph Bewertungs-Harness mittel Trace-Wiedergabe, modellbewusste Metriken Fokus eher auf Agenten- als API-Schicht KI-Teams mit starkem Eval-Fokus
Postman + Postbot mittel vertraute UI, viele Vorlagen Mock-Server als Add-on, Szenario-Syntax weniger modern Teams, die bereits Postman nutzen
Apidog Szenarien + Mocks mittel native OpenAPI, Mocks, Szenario-CLI für CI weniger Markenbekanntheit als Postman Teams, die Design, Mocks und Tests in einem Tool wollen

Wenn Sie bereits LangSmith verwenden, behalten Sie es für Prompt- und Agenten-Evals. Ergänzen Sie aber eine API-seitige Testschicht.

Wenn Sie Postman ersetzen möchten, ist Apidog ein starker Ersatz.

Viele Teams kombinieren beides:

  • LangSmith für Modell- und Prompt-Evaluierung
  • Apidog für OpenAPI-Verträge, Mocks und Szenario-Tests

Anwendungsfälle aus der Praxis

Agent aktualisiert Produktionsdatenbankzeilen

Ein Customer-Success-Team baut einen Agenten, der Kontofelder aus Support-Tickets aktualisiert.

Vor dem Launch:

  • jeder Schreib-Endpunkt verlangt einen Idempotenzschlüssel
  • PATCH /accounts/{id} validiert Enums strikt
  • Apidog-Szenarien laufen gegen eine Sandbox-Datenbank
  • 200 Wiederholungen prüfen typische Ticketfälle

Die Tests finden zwei Fälle, in denen der Agent subscription_status auf einen ungültigen String setzt. Das Team ergänzt Schema-Validierung und liefert ohne Vorfall aus.

Agent ruft Zahlungs-API auf

Ein Fintech-Team baut einen Rückerstattungsagenten.

Schutzregeln:

  • maximal 5 Rückerstattungen pro Sitzung
  • maximal 50 Dollar pro Rückerstattung
  • Idempotenz für jeden Refund
  • menschliche Freigabe für Grenzfälle
  • Vertragstests gegen die Zahlungs-OpenAPI

Die Vertragstest-Suite läuft bei jedem PR.

Agent triagiert GitHub-Issues

Ein Plattform-Team entwickelt einen Issue-Triage-Agenten, inspiriert von Clawsweeper.

Testfälle:

  • gelöschte Issues
  • fehlende Labels
  • ungültige Benutzereingaben
  • Rate Limits
  • leere Suchergebnisse
  • doppelte Kommentare

Die GitHub-API wird in Apidog simuliert. Vor dem Start finden die Szenarien mehrere Crash-Fälle, die in Produktion schwer zu debuggen gewesen wären.

Fazit

Wenn Sie Agenten mit API-Zugriff ausliefern, behandeln Sie die API als Sicherheits- und Zuverlässigkeitsschicht.

Die wichtigsten Regeln:

  • Tool-Schemas sind Verträge.
  • OpenAPI ist die Quelle der Wahrheit.
  • Destruktive Endpunkte gehören in Mock und Sandbox.
  • Jeder Schreibvorgang braucht Idempotenz.
  • Jeder Agent braucht Budgetlimits.
  • Szenarien müssen in CI laufen.
  • Produktionszugangsdaten gehören nicht in Agenten-Kontexte.

Die viralen Agenten-Vorfälle werden nicht die letzten sein. Teams, die schnell reagieren, haben ihre API-Grenzen vorher getestet.

Laden Sie Apidog herunter und starten Sie mit dem Mock-Server-Schritt. Für QA-Perspektiven siehe API-Testwerkzeuge für QA-Ingenieure. Für sichere Tool-Definitionen siehe wie man AGENTS.md-Dateien schreibt.

Häufig gestellte Fragen

Wie teste ich API-Aufrufe von KI-Agenten, ohne Geld für Tokens auszugeben?

Führen Sie Entwicklungs- und Regressionstests gegen einen Mock-Server aus. Apidog-Mocks liefern realistische Antworten ohne echte API-Kosten. Verwenden Sie feste Prompts, Temperatur 0 und gespeicherte Tool-Traces. Die Test-Checkliste des QA-Ingenieurs beschreibt die Einrichtung.

Was ist der Unterschied zwischen Agenten-Tests und API-Tests?

Agenten-Tests prüfen, ob das Modell das richtige Tool auswählt und Argumente korrekt ausfüllt.

API-Tests prüfen, ob der Endpunkt korrekt reagiert, validiert, limitiert und Fehler sauber zurückgibt.

Sie brauchen beides. Ein guter Agent kann durch eine schlechte API trotzdem Schaden verursachen.

Benötige ich Idempotenzschlüssel an jedem Endpunkt?

An jedem Schreib-Endpunkt: ja.

Leseoperationen sind normalerweise idempotent. Schreiboperationen nicht. Agenten wiederholen Aufrufe bei Timeouts, 500ern oder unklaren Zuständen. Idempotenz verhindert doppelte Zahlungen, doppelte E-Mails und doppelte Datensätze.

Wie verhindere ich, dass Prompt-Injektionen schlechte API-Aufrufe auslösen?

Verlassen Sie sich nicht nur auf Prompts. Erzwingen Sie Autorisierung serverseitig anhand des ursprünglichen Benutzerkontexts.

Wenn ein Benutzer keinen Zugriff auf /admin/delete-all-users hat, darf auch ein Agent im Namen dieses Benutzers diesen Endpunkt nicht aufrufen.

Kann ich Apidog direkt mit Claude oder GPT verwenden?

Sie richten die Base URL der Tool-Definition während der Entwicklung auf die Apidog-Mock-URL. Beim Wechsel zu Staging oder Produktion ändern Sie nur die Umgebungsvariable.

Beispiel:

AGENT_API_BASE_URL="https://mock.apidog.com/m1/your-project-id/"
Enter fullscreen mode Exit fullscreen mode

Was ist die richtige Budgetobergrenze für einen Agenten?

Starten Sie streng und lockern Sie mit Daten.

Gute Startwerte:

  • 50.000 Tokens pro Sitzung
  • 30 API-Aufrufe pro Minute
  • 5 Dollar pro Aufgabe
  • 10 Tool-Aufrufe pro Kette
  • 5 Minuten Laufzeit

Überwachen Sie zwei Wochen lang, welche Limits legitim erreicht werden, und passen Sie sie danach an.

Wie erkenne ich Schemaabweichungen zwischen Agenten-Tools und API?

Führen Sie bei jedem PR einen Schema-Diff in CI aus. Vergleichen Sie die JSON-Schema-Tool-Definition mit dem OpenAPI-Request-Schema desselben Endpunkts. Wenn Typen, Pflichtfelder oder Enums abweichen, schlägt der Build fehl. Der Python-Code im Abschnitt zu Vertragstests ist ein minimaler Startpunkt.

Top comments (0)