Testing agentischer Systeme: Neue Qualitätsmaßstäbe für Enterprise AI

Der DPD-Chatbot schrieb auf Anfrage ein Haiku darüber, wie nutzlos DPD sei. Der Chatbot von Air Canada behauptete fälschlicherweise, ein Passagier könne einen Flug zum regulären Preis buchen und innerhalb von 90 Tagen nachträglich einen Trauerfallrabatt beantragen – für diese Falschauskunft wurde die Airline später haftbar gemacht. Der Chatbot eines Chevrolet-Autohauses ließ sich durch eine manipulierte Anfrage dazu bringen, dem Verkauf eines SUVs im Wert von 50.000 US-Dollar für nur einen Dollar zuzustimmen und diese Zusage sogar als rechtsverbindlich zu bezeichnen. Geschichten wie diese sind unterhaltsam – zumindest solange man nicht selbst für das System verantwortlich ist.

Wer heute agentische Systeme für Versicherungen, Banken oder die Automobilbranche entwickelt, bewegt sich in einem völlig anderen Umfeld. Hier können Fehler nicht nur unangenehm, sondern teuer werden – oder sogar Haftungsfragen aufwerfen. Früher oder später stellt sich deshalb eine zentrale Frage: Wie testet man solche Systeme eigentlich?

Testing ist etabliert, Agentic Testing dagegen Neuland. Agentische Systeme stellen neue Anforderungen an die Qualitätssicherung, denen viele bewährte Ansätze und Tools aus klassischen CI/CD-Pipelines nicht mehr gerecht werden. Dass agentische Projekte genau im Übergang vom funktionierenden Prototyp zur produktionstauglichen Lösung scheitern, ist dabei kein Zufall. Im ersten Teil dieser Serie habe ich beschrieben, warum 80% der AI-Projekte an dieser Hürde scheitern und warum Plattformstrategie die strukturelle Antwort darauf ist. Dieser Artikel geht einen Schritt weiter: Wie testet man agentische Systeme, die auf einer solchen Plattform entstehen und betrieben werden?

Warum `assertEquals` nicht mehr reicht

Ein klassischer Unit-Test prüft: Für diesen Input produziert die Funktion exakt diesen Output. Das funktioniert, weil die Funktion deterministisch ist. Ein LLM ist es nicht. Es erzeugt eine Wahrscheinlichkeitsverteilung über mögliche Antworten. Selbst bei identischem Prompt kann deshalb beim nächsten Aufruf eine andere Antwort entstehen. Ein Test, der auf exakter Stringgleichheit besteht, ist damit strukturell ein Flaky Test.

Das ist die erste Hürde. Die zweite Hürde ist die Subjektivität: Abhängig von Kontext und Nutzerpräferenzen kann dieselbe Antwort korrekt, unvollständig oder im falschen Ton formuliert sein. Die dritte Hürde ist die Latenz. Ein Test, der 20 Sekunden auf die Antwort eines Agenten wartet, erfüllt die Eigenschaften eines Unit-Tests nicht mehr. Und die vierte, oft unterschätzte Hürde ist der Scope: Was wird eigentlich getestet?

Agentische Systeme sind keine einzelne Funktion. Sie bestehen aus einem System-Prompt, dem LLM, dem Conversation State, Tool-Calls über MCP-Server, Guardrails und der Control Loop des Agenten. Ändert sich eine dieser Komponenten – und Änderungen sind in der Softwareentwicklung unvermeidlich –, muss das Gesamtsystem erneut evaluiert werden.

Die richtigen Fragen stellen, bevor Metriken entstehen

Bevor Testfälle definiert werden, muss klar sein, was überhaupt gemessen werden soll. Für agentische Systeme sind das andere Fragen als die klassische Prüfung, ob ein Rückgabewert korrekt ist.

Ist die abgerufene Information für die Anfrage tatsächlich relevant? Halluziniert der Agent – oder genauer: konfabuliert er, indem er Fakten erfindet, die nicht in den verfügbaren Informationen enthalten sind? Ist die Antwort vollständig? Entspricht ihr Ton der gewünschten Kommunikation? Ein Chatbot sollte beispielsweise keinen Unternehmenskunden anschreien oder ungefragt duzen. Antwortet der Agent in der Sprache des Nutzers? Verwendet er die Fachbegriffe, die in der Organisation oder beim Kunden verbindlich sind?

Keine dieser Fragen lässt sich mit einer einfachen Ja-/Nein-Prüfung beantworten. Außerdem sind nicht alle Qualitätskriterien für jeden Anwendungsfall gleichermaßen relevant. Welche davon priorisiert werden, ist bereits Teil der eigentlichen Entwicklungsarbeit.

Danach folgt die entscheidende Frage: Was bedeutet eigentlich „gut“? Ist 80% Lösungsquote für einen Customer-Support-Agent gut? Oder müssen es 90% sein? Für viele Anwendungsfälle wären solche Werte durchaus akzeptabel. Für andere sind sie völlig unzureichend.

Ein anschauliches Praxisbeispiel verdeutlicht dies: Wird Software zur Zugsteuerung in einem Schienennetz eingesetzt, muss sie absolute Zuverlässigkeit gewährleisten und verhindern, dass sich überschneidende Fahrwege gleichzeitig freigegeben werden. Eine Erfolgsquote von 95 Prozent reicht in diesem Fall keineswegs aus, da schon einzelne Fehlentscheidungen direkte, sicherheitskritische Konsequenzen haben.

Die Definition von „gut“ ist deshalb kein technisches Detail. Sie ist eine fachliche Entscheidung und muss getroffen werden, bevor der erste Testfall geschrieben oder die erste Metrik definiert wird.

Frameworks: Welches Werkzeug für welche Aufgabe?

Es gibt mittlerweile einen wachsenden Markt an Frameworks, die für verschiedene Aspekte des AI-Testings gebaut wurden.

DeepEval ist ein pytest-natives Python-Testframework, das sich nahtlos in bestehende CI/CD-Pipelines integrieren lässt. Es ermöglicht Entwicklern und SDETs, LLM-Ausgaben wie klassische Unit-Tests mit automatisierten Pass/Fail-Schwellenwerten zu überprüfen. Mit über 50 integrierten Metriken – darunter G-Eval für qualitative Bewertungsraster, Halluzinations- und Bias-Prüfungen sowie spezifische Metriken für Agenten und RAG-Pipelines – eignet es sich ideal für automatisierte Regressionstests und Quality-Gate-Checks vor jedem Deployment.

Ragas (Retrieval Augmented Generation Assessment) ist ein spezialisiertes Python-Framework, das konzipiert wurde, um Retrieval-Augmented Generation (RAG)-Pipelines präzise zu bewerten und das ohne Referenzantworten (Ground Truth) auskommt. Es zerlegt die Evaluierung in die Kernkomponenten Retrieval und Generation und misst standardisierte Metriken wie Faithfulness (wie gut die Antworten mit dem Kontext übereinstimmen), Answer Relevancy (Relevanz der Antwort auf die Nutzerfrage), Context Precision und Context Recall. Dadurch können Teams gezielt diagnostizieren, ob Schwachstellen aus einer fehlerhaften Retrieval-Logik oder aus der Generierung resultieren.

Promptfoo ist ein CLI- und YAML-getriebenes Open-Source-Framework, das sich primär auf das Testen von Prompts, den direkten Vergleich verschiedener Modellprovider (Multi-Model-A/B-Testing) sowie auf automatisiertes Red-Teaming und Sicherheitstests spezialisiert hat. Es scannt AI-Anwendungen systematisch auf Schwachstellen wie Prompt-Injections, Jailbreaks und Sicherheitsrisiken, wodurch es als verlässlicher Schutzwall vor dem Gang in die Produktion dient.

In der Praxis ergänzen sich diese Werkzeuge optimal: Während Promptfoo für die Absicherung und das Prompt-Engineering eingesetzt wird, deckt DeepEval die automatisierte CI/CD-Qualitätssicherung ab und Ragas liefert die nötige Tiefe für die Evaluierung von RAG-Architekturen.

Continuous Testing: Der Agent läuft auf der Plattform, der Test auch.

Die eigentliche Herausforderung beginnt nicht mit dem ersten Testlauf, sondern mit der kontinuierlichen und automatisierten Evaluierung des Systems. Denn Änderungen gehören zum Alltag: ein neues Modell, eine aktualisierte Tool-Version oder ein angepasster System-Prompt. Jede dieser Änderungen kann das Verhalten des Agenten beeinflussen.

Das zentrale Problem bei der Integration von AI-Tests in klassische CI/CD-Pipelines ist der entstehende Flaschenhals. Während traditionelle Unit-Tests in Millisekunden durchlaufen, erfordern AI-Evaluierungen – insbesondere LLM-gestützte Beurteilungen (LLM-as-a-Judge) und aufwendige RAG- oder Agenten-Testläufe – erhebliche Ausführungszeiten. Werden diese langlaufenden AI-Evaluierungen direkt blockierend in die Standard-CI/CD-Pipeline eingebunden, verzögern sich Feedbackschleifen und Deployments massiv. Um diesen Engpass zu vermeiden, sind eine Entkopplung der AI-Tests von der primären Build-Pipeline sowie eine skalierbare, asynchrone Testausführung auf dedizierter Infrastruktur erforderlich.

Hier kommt TestKube ins Spiel. TestKube ist ein cloud-natives Testing-Framework, das Testausführung direkt in Kubernetes integriert. Der entscheidende Vorteil: Tests laufen auf derselben Infrastruktur wie der Agent. Keine APIs, die man nur für Tests nach außen öffnen müsste. Kein Testclient, der von außen gegen ein Staging-System hämmert. Der Ragas-Test läuft im selben Cluster, direkt neben dem Agenten.

TestKube reagiert auf Kubernetes-Events und startet automatisch die passenden Tests, sobald sich das Agent-Deployment, die ConfigMap oder der MCP-Service ändert. So entsteht eine vollständig automatisierte Qualitätsschleife: Code wird eingecheckt, der Build läuft, GitOps-Tools wie Argo CD oder Flux übernehmen das Deployment, TestKube erkennt die Änderung und führt die definierten Tests aus. Die Ergebnisse fließen anschließend in ein zentrales Quality-Dashboard.

Mehr als Tests: Die Agentic Control Plane

Testen ist notwendig, aber nicht ausreichend - insbesondere in regulierten Branchen. Wer Systeme für Versicherungen, Banken oder andere stark regulierte Bereiche entwickelt, benötigt mehr als Testberichte. Gefragt sind Audit-Trails: Welcher Agent hat welche Backend-Daten geändert? Wer hat eine Aktion autorisiert? Für diese Anforderungen reicht ein Test-Framework allein nicht aus.

Unser Open-Source-Projekt Agentic Layer adressiert genau das. Es ist eine k8s-native Referenzimplementierung einer Agentic Control Plane - die drei Gateways (Agent Gateway, AI Gateway, Tool Gateway) und das Zusammenspiel der Architekturkomponenten habe ich im  zweiten Teil dieser Serie ausführlich beschrieben.

Aus der Perspektive der Qualitätssicherung bildet die Testbench das Herzstück: Sie ist keineswegs als nachträglicher Anbau gedacht, sondern fungiert als universelle Querschnittsfunktion der gesamten Control Plane. Sämtliche Evaluierungen finden fortlaufend direkt am aktiven System statt – ereignisgesteuert, auf derselben Infrastruktur und zentral gebündelt im Observability-Backend.

Das Projekt steht unter Apache-2.0-Lizenz und ist unter github.com/agentic-layer frei verfügbar. Es ist kein fertiges Produkt, sondern ein Set konzeptioneller Ideen und Referenzimplementierungen, nutzbar für Teams, die eine AI-Plattform für Enterprise-Kontext aufbauen wollen.

Was das für Teams bedeutet

Agentische Systeme erfordern keine grundsätzlich neuen Qualitätsstandards. Die bewährten Prinzipien der Softwarequalität gelten weiterhin. Sie müssen allerdings um zusätzliche Metriken und Testmethoden erweitert werden, um die Qualität auch bei nicht-deterministischen, autonomen Systemen sicherzustellen.

Die gute Nachricht: Vieles von dem, was sich in den vergangenen Jahren im Cloud-Native-Umfeld etabliert hat, bleibt gültig. CI/CD, GitOps und Continuous Testing bilden weiterhin das Fundament. Neu sind die Metriken, die Evaluierungsmethoden und das Verständnis davon, was „korrekt“ bedeutet.

Teams, die eine Testbench von Beginn an in ihre Plattform integrieren, schaffen die Voraussetzung dafür, agentische Systeme zuverlässig, nachvollziehbar und sicher in Produktion zu betreiben.