Teststrategie für KI-Agenten: Tests in Production

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.

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.

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

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

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.