Warum KI-Agenten in der Produktion versagen: Teststrategien für jeden Ausfallmodus

Ihr Agent funktionierte in der Demo. Er las das Ticket, rief drei APIs auf und veröffentlichte eine saubere Zusammenfassung. Dann haben Sie ihn ausgeliefert. Eine Woche später schickte er demselben Kunden zweimal eine E-Mail, verbrauchte das Token-Budget eines Tages für eine Wiederholungsschleife und übergab Ihrem Frontend eine Nutzlast, die es nicht parsen konnte.

Diese Lücke zwischen einem funktionierenden Prototyp und einem zuverlässigen Agenten ist der Punkt, an dem die meisten Teams stecken bleiben. Das Modell ist selten der Übeltäter. Das Problem liegt in dem Teil, der als „Plumbing“ behandelt wird: den API-Aufrufen, die der Agent auf dem Weg zu einer Antwort tätigt. Ein Agent ist eine Schleife von Tool-Aufrufen, und jeder Tool-Aufruf ist eine HTTP-Anfrage, die fehlschlagen, gedrosselt werden, ein Timeout erhalten oder etwas Unerwartetes zurückgeben kann. Wenn Sie das Testen dieser Aufrufe so überspringen, wie Sie jede Produktions-API testen würden, ist Ihr Agent nur eine schlechte Antwort von einem Vorfall entfernt.

Hier kommt der beruhigende Teil: Die Zuverlässigkeit von Agenten ist testbar. Sie müssen dem Modell nicht vertrauen, dass es sich richtig verhält. Sie üben die Fehlerpfade absichtlich, bevor Ihre Benutzer sie für Sie finden. Dieser Leitfaden unterteilt Agentenfehler in fünf Modi und zeigt, wie Sie jeden einzelnen abfangen können. Die Arbeit findet an der API-Grenze statt, daher benötigen Sie eine Plattform, die Sie auf die Abhängigkeiten des Agenten richten können, um den Vertrag zu entwerfen, die Fehler zu simulieren und zu überprüfen, was zurückkommt. Apidog übernimmt diese Aufgabe und führt Sie durch die folgenden Beispiele.

Agenten scheitern an der API-Grenze, nicht an der Aufforderung (Prompt)

Wenn ein Agent in der Produktion Fehlverhalten zeigt, ist der Instinkt, den Prompt zu bearbeiten. Manchmal hilft das. Oft hat der Fehler jedoch nichts mit der Formulierung zu tun. Der Agent hat eine echte API um etwas gebeten, und die Antwort war langsam, fehlerhaft, ratenbegrenzt oder hatte eine andere Form, als der Agent erwartet hatte. Das Modell schloss dann aus falschen Eingaben und tat etwas Zuversichtliches und Falsches.

Betrachten Sie, was ein einzelner Agentenschritt beinhaltet. Das Modell wählt ein Tool. Ihr Code wandelt diese Wahl in eine HTTP-Anfrage um. Ein externer Dienst antwortet. Ihr Code führt das Ergebnis dem Modell zurück. Vier Übergaben, und drei davon sind gewöhnliche API-Integration, nicht maschinelles Lernen. Das ist eine gute Nachricht, denn API-Integration ist ein gelöstes Testproblem. Sie wissen bereits, wie man einen langsamen Endpunkt simuliert oder ein JSON-Schema prüft. Agenten erhöhen den Einsatz, denn das Modell reagiert auf alles, was es empfängt, anstatt eine saubere Ausnahme auszulösen.

Die Frage der Zuverlässigkeit ist also nicht „ist das Modell intelligent genug“, sondern „habe ich jede Art und Weise getestet, wie die API-Aufrufe des Agenten schiefgehen können“. Fünf Modi decken das meiste davon ab.

Fehlermodus 1: Tool-Aufrufe, die vom Vertrag abweichen

Der häufigste Agentenfehler ist ein Tool-Aufruf, der nicht zur aufgerufenen API passt. Das Modell erfindet einen Parameter, lässt ein erforderliches Feld weg, sendet einen String, wo das Schema eine Ganzzahl erwartet, oder ruft den richtigen Endpunkt mit Argumenten auf, die keinen Sinn ergeben. Nehmen wir an, ein Buchungsagent ruft POST /reservations mit guests: "two" anstelle von guests: 2 auf. Die API gibt einen 400er-Fehler zurück oder, schlimmer noch, einen 200er mit einem im Body versteckten Fehler, und der Agent fährt fort, als ob der Aufruf erfolgreich gewesen wäre.

Dies fangen Sie ab, indem Sie den Tool-Aufruf als Vertrag testen. Definieren Sie das Schema für jedes Tool, das der Agent aufrufen kann, und stellen Sie dann sicher, dass die ausgehende Anfrage übereinstimmt: erforderliche Felder vorhanden, Typen korrekt, Enums gültig. Wenn der Agent einen Aufruf erzeugt, der den Vertrag bricht, möchten Sie, dass dies in einem Test laut fehlschlägt und nicht stillschweigend in der Produktion. Unser Leitfaden zum Testen von Tool-Aufrufen eines KI-Agenten geht hier ins Detail, und die umfassendere Methode zum Testen von Agenten, die Ihre APIs aufrufen, deckt die Einrichtung von Anfang bis Ende ab.

Der praktische Schritt: Erfassen Sie die Tool-Schemata, die Ihr Agent verwendet, laden Sie sie in Apidog und führen Sie die echten Tool-Aufrufe des Agenten gegen diese Definitionen aus. Abweichungen zeigen sich als Validierungsfehler, die das genaue fehlerhafte Feld benennen.

Fehlermodus 2: Upstream-Fehler und Ratenbegrenzungen

Jeder externe Aufruf, den der Agent tätigt, kann einen 429er, einen 500er oder vor einem Timeout überhaupt nichts zurückgeben. Ein gut gebauter Agent behandelt diese mit Wiederholungsversuchen und Backoff. Ein fragiler gibt entweder beim ersten Fehler auf oder, gefährlicher, versucht so hart, dass er weitere Drosselung auslöst und in einer Schleife dreht, die Ihr Budget aufbraucht. Die am häufigsten gestellte Frage im Anthropic SDK Diskussionsforum handelt buchstäblich von Mustern für die Fehlerbehebung von Agenten, was Ihnen zeigt, wie verbreitet dieses Problem ist.

Sie können die Wiederherstellung nicht gegen eine fehlerfreie API testen, da eine fehlerfreie API niemals die Fehler zurückgibt, die Sie behandeln müssen. Hier zahlt sich Mocking aus. Erstellen Sie ein Mock der Abhängigkeit des Agenten und programmieren Sie eine Sequenz: einen 429er mit einem Retry-After-Header, dann einen 500er, dann einen Erfolg. Beobachten Sie nun, was Ihr Agent tut. Zieht er sich mit Jitter zurück? Respektiert er den Header? Gibt er nach einer angemessenen Anzahl von Versuchen anmutig auf oder öffnet er einen Schutzschalter, damit er einen Dienst, der eindeutig ausgefallen ist, nicht mehr bombardiert? Und wenn eine wiederholte Aktion nicht idempotent ist, führt eine Wiederholung zu einer doppelten Abbuchung oder einem doppelten Senden? Ein Idempotenzschlüssel macht einen Wiederholungsversuch sicher.

Ratenbegrenzungen verdienen eine eigene Probe. Wenn Sie nicht gesehen haben, wie sich Ihr Agent verhält, wenn ein Anbieter ihn drosselt, lesen Sie unseren Leitfaden dazu, was eine "rate-limit-exceeded"-Antwort bedeutet, und simulieren Sie es dann. Der spezielle Leitfaden zur Fehlerbehebung von KI-Agenten behandelt Wiederholungsversuche, Timeouts, Backoff- und Schutzschalter-Muster ausführlich.

Fehlermodus 3: Nicht-deterministische Ausgabe

Selbst wenn Sie die Temperatur auf null setzen, erhalten Sie bei verschiedenen Durchläufen keine byte-identische Ausgabe. Entwickler entdecken dies ständig neu; es gibt einen langen vLLM-Thread darüber, dass Seeds und Temperatur nicht ausreichen, um Reproduzierbarkeit zu gewährleisten. Hardware, Batching und Anbieter-seitige Änderungen führen alle zu Variationen. Wenn Ihre Tests auf exakte Strings prüfen, werden sie instabil ("flaky"), und instabile Tests werden ignoriert, was schlimmer ist als keine Tests. Unsere Zusammenfassung was instabile Tests verursacht, trifft hier direkt zu.

Die Lösung besteht darin, die Struktur und Bedeutung zu prüfen, nicht den exakten Text. Überprüfen Sie, ob die Antwort einem JSON-Schema entspricht. Überprüfen Sie, ob der Tool-Aufruf die richtige Form und das richtige Ziel hat. Überprüfen Sie, ob eine numerische Antwort in einen sinnvollen Bereich fällt. Überprüfen Sie, ob erforderliche Schlüssel vorhanden und verbotene Felder nicht vorhanden sind. Ein Test, der besagt „die Antwort enthält einen Gesamtbetrag zwischen 0 und dem Warenkorbwert“, überlebt die natürliche Variation des Modells und fängt dennoch eine echte Regression ab. Der Leitfaden zum Testen nicht-deterministischer KI-Agenten legt den vollständigen Satz von Strategien dar, und der Artikel über wie der Agenten-Speicher funktioniert zeigt, warum der Zustand dies erschwert.

Fehlermodus 4: Ausufernde Kosten

Agenten durchlaufen Schleifen, und Schleifen kosten Geld. Ein einzelner festgefahrener Agent, der einen fehlgeschlagenen Aufruf ein paar tausend Mal wiederholt, kann eine kleine Rechnung über Nacht in eine große verwandeln. Ein Feldbericht in den SDK-Diskussionen beschrieb die Senkung der Kosten eines Agenten von 500 Dollar pro Monat auf 80, ohne Qualitätsverlust, was sowohl zeigt, wie schnell die Kosten steigen, als auch wie viel Spielraum normalerweise im Design verborgen ist.

Kosten sind ein Zuverlässigkeitsproblem, nicht nur ein finanzielles, denn die Fehler, die Geld verschwenden (Schleifen, redundante Aufrufe, überdimensionierter Kontext), machen den Agenten auch langsam und unberechenbar. Verfolgen Sie Token pro Lauf, begrenzen Sie das Budget pro Aufgabe und cachen Sie, was Sie können. Für die Kommandozeilen-Seite davon bietet unser Leitfaden zur Reduzierung der Token-Kosten von Agenten konkrete Hebel. Wenn Sie Wiederherstellungspfade gegen ein Mock testen, achten Sie auch auf die Anzahl der Aufrufe. Ein Agent, der erfolgreich ist, aber vierzig Aufrufe benötigt, um dorthin zu gelangen, ist ein potenzieller Kosten-Vorfall.

Fehlermodus 5: Fehlende Schutzmaßnahmen (Guardrails)

Die schmerzhaftesten Fehler sind jene, bei denen der Agent genau das tut, was ihm gesagt wurde, und das Ergebnis dennoch schlecht ist. Er sendet die E-Mail, löscht den Datensatz oder platziert die Bestellung, weil nichts zwischen der Entscheidung des Modells und der Live-Aktion stand. Die SDK-Foren haben einen denkwürdigen Thread über einen Agenten, der um drei Uhr morgens eine E-Mail an den Chef von jemandem verschickte. Einmal lustig, zweimal teuer.

Guardrails sind der Sicherheitsgurt. Legen Sie eine Positivliste (Allowlist) für Aktionen an, die ein Agent ohne Genehmigung ausführen darf. Sichern Sie destruktive oder irreversible Aufrufe hinter einer menschlichen Bestätigung ab. Geben Sie dem Agenten einen Trockenlaufmodus, der beschreibt, was er tun würde, ohne es tatsächlich zu tun. Testen Sie dann, ob die Guardrail hält: Simulieren Sie den seitenbehafteten Endpunkt, lassen Sie den Agenten laufen und stellen Sie sicher, dass er den Bestätigungspfad einschlägt und nicht die Live-Aktion. Sicherheitsrichtlinien wie die OWASP Top 10 für LLM-Anwendungen sind eine solide Checkliste dafür, was zu schützen ist. Der Leitfaden zu KI-Agenten-Guardrails behandelt Genehmigungstore und die Kontrolle des „Blast-Radius“ ausführlich.

Wie man einen Agenten-Test strukturiert

Die fünf Modi teilen eine Testform, die Sie wiederverwenden können:

1. Erfassen Sie die Tool-Schemata, die Ihr Agent aufrufen kann, damit Sie einen Vertrag haben, gegen den Sie prüfen können.
2. Simulieren Sie jede Abhängigkeit, um Timing, Statuscodes und Bodies zu kontrollieren und um echte Nebeneffekte zu vermeiden.
3. Führen Sie den Agenten durch das Szenario, einschließlich der Fehlerpfade, die eine Live-API nicht auf Abruf erzeugen wird.
4. Prüfen Sie, was der Agent gesendet und wie er reagiert hat: Anforderungsform, Wiederherstellungsverhalten, Aufrufsanzahl und ob Schutzmaßnahmen (Guardrails) ausgelöst wurden.

Führen Sie diese Schleife für ein Tool aus, dann fügen Sie das nächste hinzu. Der Aufbau zahlt sich das erste Mal aus, wenn er einen fehlerhaften Tool-Aufruf abfängt, bevor ein Benutzer dies tut.

Die Checkliste für die Zuverlässigkeit von Agenten

Bevor ein Agent in Produktion geht, prüfen Sie diese Liste:

• Jeder Tool-Aufruf wird gegen ein Schema validiert, und Vertragsverletzungen führen zu einem Fehler im Test.
• Upstream-Antworten mit 429, 500 und Timeout werden simuliert, und der Agent erholt sich mit Backoff.
• Wiederholte Aktionen sind idempotent, sodass eine Wiederholung nicht zu einer doppelten Abbuchung oder einem doppelten Senden führen kann.
• Tests prüfen auf Struktur und Bedeutung, nicht auf exakte Strings, sodass normale Variationen keine Instabilität verursachen.
• Die Token-Nutzung pro Lauf wird gemessen, und eine Budgetobergrenze stoppt ausufernde Schleifen.
• Destruktive Aktionen befinden sich hinter einer Positivliste (Allowlist) oder einem menschlichen Genehmigungstor.
• Der Guardrail-Pfad wird mit einem Mock getestet, nicht angenommen.

Haken Sie alle sieben Punkte ab, und Sie haben die Arten getestet, wie Agenten in der Produktion fehlschlagen können.

Wo Apidog passt (und wo nicht)

Machen Sie sich klar, welche Aufgabe das Tool hat. Apidog ist kein Agenten-Framework, kein Modell-Host und keine Evaluierungs-Umgebung. Es baut oder betreibt Ihren Agenten nicht. Was es tut, ist die API-Schicht zu verwalten, von der Ihr Agent abhängt, und genau dort treten diese Fehler auf.

In der Praxis bedeutet das drei Dinge. Sie entwerfen und speichern die Verträge für die Tools, die Ihr Agent aufruft, sodass Sie ausgehende Anfragen dagegen validieren können. Sie simulieren diese Abhängigkeiten und programmieren die Fehlerantworten (429, 500, Timeout, fehlerhafter Body), die eine Live-API nicht auf Abruf produzieren wird, damit Sie die Wiederherstellung üben können. Und Sie schreiben Prüfungen (Assertions) für die Antworten (Schema, Form, Bereiche, erforderliche Schlüssel), die eine nicht-deterministische Ausgabe überleben. Das ist die ehrliche Passung: Apidog testet die APIs, die Ihr Agent aufruft, simuliert die Fehler, die Sie behandeln müssen, und überprüft, was zurückkommt. Unser Überblick über agentisches KI-Testen ordnet dies in das größere QA-Bild ein.

Häufig gestellte Fragen

Ist die Zuverlässigkeit von Agenten ein Modell- oder ein Engineering-Problem? Meistens Engineering. Die Modellwahl ist wichtig, aber die Fehler, die zu Vorfällen führen (schlechte Tool-Aufrufe, unbehandelte Ratenbegrenzungen, fehlende Schutzmaßnahmen), sind Integrations- und Testprobleme, die Sie lösen können, ohne das Modell zu ändern.

Kann ich einen Agenten testen, ohne die echten APIs aufzurufen, die er nutzt? Ja, und das sollten Sie auch. Simulieren Sie die Abhängigkeiten, damit Sie Fehlerantworten erzwingen, das Timing kontrollieren und Nebeneffekte vermeiden können. Das ist der einzige zuverlässige Weg, um Wiederherstellungs- und Schutzpfade zu testen.

Wie schreibe ich Tests, wenn sich die Ausgabe bei jedem Lauf ändert? Prüfen Sie auf Struktur und Bedeutung anstelle von exaktem Text. Validieren Sie die Antwort gegen ein Schema, überprüfen Sie die Form des Tool-Aufrufs und verwenden Sie Bereiche für Zahlen. Der Leitfaden zum Testen nicht-deterministischer KI-Agenten behandelt dies ausführlich.

Was sollte ich zuerst testen? Schutzmaßnahmen bei destruktiven Aktionen, dann die Fehlerbehebung. Diese beiden schützen Sie vor den teuersten Fehlern: einem Agenten, der eine schädliche Aktion ausführt, oder einem Agenten, der in einer Schleife Ihr Budget aufbraucht.

Beginnen Sie mit einem Fehlermodus

Sie müssen nicht alle fünf Modi auf einmal testen. Wählen Sie den aus, der Ihnen am meisten Angst macht, in der Regel Schutzmaßnahmen (Guardrails) oder Fehlerbehebung, und proben Sie ihn diese Woche gegen ein Mock. Programmieren Sie den Fehler, lassen Sie den Agenten laufen und beobachten Sie, was er tut. Wenn Sie zum ersten Mal sehen, wie Ihr Agent einen simulierten 429er-Fehler mit sauberem Backoff statt einer budgetzehrenden Schleife behandelt, werden Sie ihm mehr vertrauen, und das aus einem besseren Grund als einer grünen Demo.

Laden Sie Apidog herunter, um die Verträge zu entwerfen, die Fehler zu simulieren und die Antworten zu prüfen, von denen Ihr Agent abhängt.