Der KI-Agent, den ich veröffentlicht habe, bestand 23 Unit-Tests, aber innerhalb einer Stunde nach dem Livegang erfand er eine Produktfunktion und nannte einen Preis, der dreimal niedriger war als die Realität. Als der Nutzer ihn darauf ansprach, beharrte der Bot stur auf seiner Aussage, das Gespräch endete und ich verlor einen Kunden. Dieser Fehler bewies, dass eine Suite von deterministischen Unit-Tests die Zuverlässigkeit eines Agenten nicht garantieren kann.

Warum Unit-Tests für KI-Agenten nicht ausreichen

Unit-Tests funktionieren für traditionellen Code, weil derselbe Input immer denselben Output liefert. „2 + 2 = 4“ ist eine Garantie, die man mit einem einfachen Gleichheitscheck verifizieren kann. Ein LLM-gesteuerter Agent hingegen verändert seinen Output durch den Prompt, den umgebenden Kontext und den Zustand der aufgerufenen externen Tools. Ein Test, der auf exakte String-Gleichheit prüft, übersieht Halluzinationen, Tonfalländerungen oder Verstöße gegen die Guardrails. Das stille Versagen, das mich einen Kunden kostete, zeigt, dass man die gesamte Interaktion bewerten muss und nicht nur isolierte Funktionen.

Entwicklung eines Evaluations-Frameworks vor dem eigentlichen Feature-Code

Ich habe die Reihenfolge der Entwicklung umgekehrt: Zuerst entwerfe ich ein vierstufiges Evaluations-Framework, dann schreibe ich den Agenten. Das Framework führt 131 Tests in einem einzigen Durchlauf aus, kostet etwa drei Cent pro Durchlauf und ist in etwa elf Minuten fertig. Ich weise jedem Test das kleinste Modell zu, das ihn bewältigen kann, und behalte größere, teurere Modelle für Momente auf, in denen sie wirklich einen Mehrwert bieten.

Ebene 1 – Tool-Funktionalität

Die erste Verteidigungslinie prüft, ob der Agent seine Tools korrekt aufrufen kann. Die Tests decken erfolgreiche Suchen, absichtlich fehlerhaft formatierte Abfragen und simulierte API-Fehler ab. Da die Tool-Nutzung weitgehend deterministisch ist – entweder wird die Anfrage korrekt formatiert oder die API gibt einen Fehler zurück – reichen einfache Python-Assertions aus. Das Abfangen einer fehlerhaften Anfrage an dieser Stelle verhindert nachgelagerte Verwirrung.

Ebene 2 – Befolgen von Anweisungen

Als Nächstes verifiziert das Framework, ob der Agent die Guardrails einhält. Ein kleineres LLM fungiert als Evaluator und scannt die Antwort des Agenten auf Konformität: das Einhalten der Rolle, das Vermeiden verbotener Themen und die Ausgabe des erforderlichen JSON-Schemas. Diese Ebene erkennt semantische Abweichungen, die Unit-Tests entgehen, wie etwa das Verfallen in eine unbeabsichtigte Persona oder das Durchsickern interner Prompts.

Ebene 3 – Zielorientiertes Verhalten

Die dritte Ebene ist die kritischste. Sie prüft, ob der Agent tatsächlich seinen Zweck erfüllt. Für einen Lead-Generierungs-Bot bedeutet das zu bestätigen, dass er die richtigen Qualifizierungsfragen stellt und bei Bedarf an einen Menschen übergibt. Ich verwende hier ein reasoning-orientiertes Modell, da es den gesamten Ablauf bewerten kann, ohne die Kosten in die Höhe zu treiben. Wenn der Bot sein Ziel nicht erreicht – selbst wenn er die ersten beiden Ebenen besteht – wird er für eine Neugestaltung markiert.

Ebene 4 – Performance

Schließlich zeichnet das Framework Latenz und die Geschwindigkeit der Token-Generierung auf. Langsame Antworten beeinträchtigen die Benutzererfahrung, insbesondere im Echtzeit-Chat. Indem ich diese Metriken zusammen mit der funktionalen Korrektheit verfolge, stelle ich sicher, dass der Agent sowohl präzise als auch reaktionsschnell ist.

Kosteneinsparungen

Der Wert von 0,03 $ pro Durchlauf ist kein Marketing-Gag; er ergibt sich daraus, dass die Komplexität der Tests auf die Modellgröße abgestimmt ist. Deterministische Tool-Checks laufen auf der günstigsten Laufzeitumgebung, die Einhaltung der Anweisungen nutzt ein leichtgewichtiges Modell, und nur die zielorientierten Bewertungen rufen ein leistungsfähigeres, wenn auch teureres Modell auf. Dieser gestufte Ansatz hält die Gesamtkosten niedrig genug, um die vollständige Suite bei jeder Codeänderung auszuführen.

Der Kompromiss: Geschwindigkeit versus Sicherheit

Die Einführung eines Frameworks verursachte anfängliche Reibungsverluste. Die Entwicklungszyklen verlängerten sich und der Zeitplan für den Launch verschob sich.

Worauf man als Nächstes achten sollte

  • Modellgesteuerte Evaluatoren: Mit der Verbesserung von LLMs kann der Evaluator in Ebene 2 nuancierter werden, wodurch Fehlalarme reduziert werden, während subtile Richtlinienverstöße weiterhin erkannt werden.

Fazit

Wenn Sie KI-Agenten für den Produktivbetrieb entwickeln, ist ein mehrstufiges Evaluations-Framework keine Option, sondern die Grundlage. Indem Sie die Kosten für umfassende Tests vorziehen – 0,03 $ pro Durchlauf, elf Minuten pro Suite –, schützen Sie sich vor den stillen Fehlern, die Unit-Tests schlichtweg nicht erkennen können.