Idee in 30 Sekunden
Das Testen von AI-Agenten unterscheidet sich vom klassischen Software-Testing, weil das Verhalten eines Agenten nicht nur vom Code abhängt, sondern auch von LLM, Kontext, Tools und Schrittfolge.
Darum nutzen Production-Systeme meist eine mehrstufige Teststrategie: Unit-Tests, Evaluation-Datasets, Regression-Vergleiche gegen Baseline und Replay realer Traces.
Dieser Ansatz hilft, Fehler vor dem Release zu finden und Degradation im Zeitverlauf zu kontrollieren.
Problem
Klassische Testansätze funktionieren bei AI-Agenten schlecht. Bei normalem Code liefert derselbe Input fast immer dasselbe Ergebnis. In LLM-Systemen kann sich Verhalten ändern je nach:
- Prompt-Formulierung;
- Modellversion;
- Kontext;
- Tool-Ergebnissen.
Dadurch können lokale Tests grün sein, aber in Production kann der Agent:
- unnötige Schritte machen und token cost aufblasen;
- im komplexen Szenario das falsche Tool wählen;
- nach Modell- oder Prompt-Wechsel instabil werden.
Ohne strukturierte Teststrategie werden solche Probleme meist erst nach Release gefunden.
Kernkonzept / Modell
Die Teststrategie für Agenten wird als mehrere Prüfebenen aufgebaut, nicht als ein Testtyp. Jede Ebene fängt ihre eigene Risikoklasse im Systemverhalten ab.
| Methode | Was geprüft wird | Wann verwenden |
|---|---|---|
| Unit testing | Lokale Agentenlogik: Tool-Auswahl, Output-Schema, grundlegende runtime-Regeln | Bei jeder Änderung an Code, Prompt oder Policy-Regeln |
| Golden datasets | Stabiler Satz von Fällen für reproduzierbare Eval-Läufe | Wenn vergleichbare Ergebnisse zwischen Baseline und Candidate nötig sind |
| Eval harness | Systemverhalten in einer standardisierten Eval-Pipeline | Vor dem Release und für die Release-Validierung |
| Regression testing | Unterschiede (Diff) zwischen Versionen auf denselben Evaluation- und Replay-Fällen | Nach Änderungen an Modell, Prompt, Tools oder Policy |
| Replay & debugging | Production-Incidents und Failure-Traces zur Analyse von Ausfällen | Wenn ein Incident reproduziert und die Ursache der Degradation gefunden werden muss |
Je höher die Prüfebene, desto teurer der Lauf, daher wird sie meist seltener ausgeführt.
Wie es funktioniert
In Production-Agent-Systemen ist Testing meist als release pipeline organisiert: Änderungen an Code, Prompts, Modellversion oder Tools laufen durch Unit-Tests, Evaluation-Datasets, Regression-Vergleich mit Baseline und Replay realer Szenarien.
Wie eine Änderung durch die Pipeline läuft
- Change — jede Änderung an Code, Prompt, Modellversion oder Tools startet einen neuen Lauf.
- Unit — lokale Logik wird geprüft: Tool-Auswahl, Ergebnisverarbeitung, grundlegende runtime-Regeln.
- Eval — der Agent läuft auf Evaluation-Szenarien, Qualität wird über Metriken wie
tool correctnessundtask completiongemessen. - Regression — Candidate-Ergebnisse werden mit Baseline verglichen, um unerwünschte Verhaltensänderungen zu finden.
- Gate — CI blockiert Release, wenn Schlüsselmetriken fallen oder kritische Szenarien brechen.
- Replay — Replay wird sowohl vor Release (gespeicherte Traces in Staging) als auch nach Release (Monitoring von Degradation) genutzt.
Test-Pyramide für Agenten
In vielen Teams wird Agent-Testing als Pyramide organisiert:
Regression ist hier keine eigene Schicht, sondern eine Vergleichsmethode zwischen neuer Version und Baseline auf denselben Evaluation- und Replay-Tests.
- Unit tests — schnell und günstig, laufen häufig.
- Evaluation — langsamer, prüft aber Agentenverhalten.
- Replay — am teuersten, zeigt dafür echte Production-Szenarien.
Umsetzung
In der Praxis besteht das meist aus mehreren automatischen Prüfungen in der Pipeline. Die Beispiele unten sind schematisch: sie zeigen Prüflogik und sind nicht an ein konkretes Framework API gebunden.
1. Unit-Test der Agentenlogik
Wir prüfen, ob der Agent das richtige Tool auswählt.
def test_tool_selection():
tools = FakeTools(price_api_response={"symbol": "BTC", "price": 65000})
agent = Agent(tools=tools)
result = agent.run("What is the price of BTC?")
assert result.selected_tool == "crypto_price_api"
assert result.output["symbol"] == "BTC"
In echten Unit-Tests werden externe Tool-Aufrufe meist gestubbt/gemockt, damit die Agentenlogik geprüft wird und nicht Netzwerk-Abhängigkeiten.
2. Evaluation auf Szenario-Dataset
Der Agent wird auf einem Satz von Testanfragen ausgeführt.
test_cases = [
{"input": "Find BTC price", "expected_tool": "crypto_price_api"},
{"input": "Search latest AI news", "expected_tool": "web_search"}
]
for case in test_cases:
result = agent.run(case["input"])
assert result.tool == case["expected_tool"]
Evaluation-Qualität wird über Qualitäts-, Stabilitäts- und Kostenmetriken bewertet (Detailübersicht in Metriken für Agent-Testing unten). Für offene oder komplexe Aufgaben werden Ergebnisse oft zusätzlich per LLM-as-a-judge geprüft. In Production werden während Evaluation auch token cost, latency und Anzahl Agentenschritte verfolgt, damit neue Versionen nicht teurer, langsamer oder übermäßig vielschrittig werden.
Das Evaluation-Dataset selbst sollte ebenfalls versioniert werden, sonst ist mit der Zeit unklar, ob sich Agentenverhalten geändert hat oder der Szenario-Satz.
3. Regression-Test nach Änderungen
Wenn Modell oder Prompt geändert werden, läuft derselbe Evaluation-Satz.
run_eval_suite(model="baseline-model")
run_eval_suite(model="candidate-model")
Wenn Ergebnisse deutlich abweichen, muss die Änderung vor Release geprüft werden.
In der Praxis vergleicht man Candidate auch auf Replay-Datasets mit Baseline, nicht nur auf synthetischen Evaluation-Fällen.
4. Replay von Production-Szenarien
Production-Anfragen werden gespeichert und sowohl vor Release (staging replay) als auch nach Release (post-release replay) genutzt. Viele Teams speichern Failure-Traces automatisch und ergänzen sie im Regression-Dataset.
for trace in production_traces:
result = agent.run(trace.input)
evaluate(result, trace.expected_behavior)
Dieser Ansatz prüft Agentenverhalten auf realen Szenarien statt nur auf synthetischen Tests.
5. Was üblicherweise den Release in CI blockiert
In der Praxis werden Agent-Tests oft in deterministische Prüfungen (lokale Logik, Routing, Output-Format) und nicht-deterministische Prüfungen (Antwortqualität, Vollständigkeit, Angemessenheit der Begründung) geteilt. Für letztere nutzt man Eval-Metriken oder LLM-as-a-judge.
In CI wird Release meist blockiert, wenn kritische Szenarien ausfallen, task success rate sinkt, hallucination rate steigt oder latency und token cost stark wachsen.
Typische Fehler
Nur Prompts testen
Team prüft ein paar manuelle Beispiele und hält die Änderung für sicher, aber das deckt Agentenverhalten im echten Ausführungszyklus nicht ab.
Typische Ursache: kein systematischer Evaluation-Prozess mit klaren Metriken.
In Production führt das oft zu AI agent drift nach Release.
Keine Evaluation-Datasets für Szenarien
Ohne kontrollierten Szenario-Satz lassen sich Baseline und Candidate schwer objektiv vergleichen.
Typische Ursache: keine golden datasets aufgebaut.
Folge: Antwortqualität wird instabil, Regressionen werden zu spät gefunden.
Keine Regression-Prüfung
Nach Modell- oder Prompt-Änderung kann das System formal "funktionieren", aber ein anderes Verhaltensprofil zeigen.
Typische Ursache: kein regelmäßiges regression testing.
In Production zeigt sich das meist als zunächst unauffälliger AI agent drift.
Keine Fixierung der Modellversion
LLM-Provider aktualisieren Modelle manchmal ohne Änderung des generischen Modellnamens.
Wenn Version nicht fixiert ist (zum Beispiel gpt-4o-2024-08-06), können Tests heute bestehen und morgen ausfallen.
Typische Ursache: Konfiguration nutzt einen "floating" Modellnamen ohne pinning.
In Production-Systemen wird daher meist eine konkrete Modellversion oder Snapshot-Version fixiert.
Keine Replay-Tests
Ein Incident passiert in Production einmal, aber das Team kann ihn lokal nicht stabil reproduzieren.
Typische Ursache: Failure-Traces werden nicht gespeichert und agent replay and debugging wird nicht genutzt.
Folge: derselbe Fehler kehrt nach späteren Releases zurück.
Nur Happy-Path-Szenarien testen
Evaluation-Datasets enthalten nur "saubere" Anfragen, während reale Anfragen oft unvollständig, mehrdeutig oder unter partiellen Ausfällen kommen.
Typische Ursache: keine Szenarien mit Tool-Fehlern und degradierenden Abhängigkeiten.
In Production zeigt sich das häufig als tool failure oder partial outage.
Metriken für Agent-Testing
| Metrik | Was sie zeigt |
|---|---|
| Tool accuracy | Korrektheit der Tool-Auswahl |
| Task success rate | Abschluss der Aufgabe |
| Hallucination rate | Häufigkeit falscher Fakten |
| Token cost | Ausführungskosten |
| Latency | Ausführungszeit der Aufgabe |
| Reasoning steps | Anzahl Agentenschritte |
Grenzen des Ansatzes
Mehrstufiges Testing entfernt Nicht-Determinismus nicht vollständig, da LLM-Systeme nicht vollständig deterministisch sind. Es reduziert nur das Risiko und macht Verhaltensänderungen früher sichtbar.
Evaluation und Replay sind außerdem teuer: Sie erhöhen Laufzeit, CI-Last und Modellkosten.
Darum teilen reale Teams den vollständigen Prüfsatz oft in schnelle pre-merge Tests und schwerere nightly oder pre-release Läufe.
Kurzfassung
- Für AI-Agenten reicht ein Testtyp nicht.
- Unit-Tests prüfen lokale Logik.
- Evaluation und Regression kontrollieren Verhaltensqualität nach Änderungen.
- Replay hilft, reale Production-Fehler zu reproduzieren.
FAQ
Q: Reichen Unit-Tests allein für Agenten?
A: Nein. Unit-Tests finden lokale Fehler gut, aber Verhaltensrisiken decken Evaluation, Regression und Replay ab.
Q: Was ist Evaluation für Agenten?
A: Agent läuft auf einem Satz von Testszenarien, Ergebnisse werden über zentrale Qualitäts-, Stabilitäts- und Kostenmetriken bewertet.
Q: Wann sollte man Regression-Tests ausführen?
A: Nach jeder Änderung, die Agentenverhalten beeinflussen kann: Modell-Update, Prompt-Änderung, neue Tools oder Änderungen in runtime-Logik.
Q: Warum Replay von Production-Traces nutzen?
A: Replay reproduziert reale Production-Anfragen und prüft, ob das System sich nach Änderungen gleich verhält. Das hilft bei Fehlern, die mit synthetischen Tests schwer reproduzierbar sind.
Was als Nächstes
Wenn ihr diese Strategie in eine funktionierende Pipeline bringen wollt, startet mit Unit Testing, ergänzt danach Golden Datasets, und standardisiert Ausführung und Bewertung über Eval Harness. Diese Reihenfolge liefert schnelles Feedback in der Entwicklung und stabile Qualitätskontrolle in CI.
Wenn ihr Modell, Prompts oder Tools aktualisiert, wird Regression Testing zentral. Und wenn das Problem bereits in Production auftrat, funktioniert Replay and Debugging meist am besten: realen Trace reproduzieren und prüfen, wo sich Agentenverhalten geändert hat.
Für Multi-Agent-Systeme mit Orchestrator Agent ergänzt eigene Tests für Schrittreihenfolge, Abhängigkeiten zwischen Zweigen und partielle Ausfälle. In solchen Szenarien treten klassische Production-Risiken am häufigsten auf: Infinite Loop, Tool Spam und Cascading Failures.