KI-Agenten testen: Eine Evaluations-Harness bauen

Jedes Unternehmen, mit dem wir 2026 sprechen, hat dasselbe Problem. Es gibt ein Dutzend Agenten-Piloten, die in der Demo glänzen, und eine Geschäftsleitung, die sie in der Produktion sehen will. Die Lücke zwischen diesen beiden Zuständen ist nicht die Modellqualität. Es ist das Fehlen einer Antwort auf eine täuschend einfache Frage: Ist dieser Agent wirklich gut genug — und bleibt er es nach der nächsten Änderung?

Genau diese Frage beantwortet eine Harness zur KI-Agenten Evaluation. Dieser Beitrag ist das Vorgehen, das wir bei CC Conceptualise nutzen, um eine solche aufzubauen — Architektur, Bewertungsstrategie, CI-Integration und die Konformitätsnachweise, die sie erzeugt. Er setzt unsere Begleitbeiträge zur Architektur des Microsoft Agent Framework 1.0 und zu den A2A-Protokollmustern für Agent-zu-Agent-Kommunikation voraus; die Evaluation ist die Disziplin, die diese Muster produktionsreif macht.

TL;DR / Die Kernpunkte

Eine Agenten Test-Harness ist automatisierte Maschinerie, die Agentenverhalten gegen kuratierte Datensätze bewertet und Deployments in der CI freischaltet — der größte Unterschied zwischen Pilot und Produktionssystem.
Bewerten Sie die Trajektorie (Tool-Calls, Reasoning-Schritte, Retrievals), nicht nur die finale Antwort. Die meisten Agentenfehler sind falsche Tool-Auswahl oder falscher Kontext, nicht schlechte Prosa.
Kombinieren Sie drei Scorer-Typen: deterministische Assertions, kalibriertes LLM-as-Judge und menschliche Prüfung für Hochrisikofälle. Verlassen Sie sich nie auf nur einen.
Behandeln Sie Ihr Golden Dataset als versioniertes, wachsendes Asset. Jeder Produktions-Incident wird zu einem dauerhaften Fall für Agenten-Regressionstests.
Eine Harness ist zugleich ein Compliance-Instrument: Sie erzeugt die dokumentierten Test- und Monitoring-Nachweise, die EU AI Act und DORA erwarten.

Warum Agenten das alte Testmodell sprengen

Klassisches Softwaretesten beruht auf Determinismus. Gegeben Eingabe X, prüfe Ausgabe Y. Agenten zerstören diese Annahme. Derselbe Prompt kann bei jedem Lauf andere Formulierungen, eine andere Tool-Reihenfolge oder andere Retrieval-Ergebnisse liefern, und mehrere davon können gleichermaßen korrekt sein. Ein Test, der Byte-für-Byte-Gleichheit fordert, ist entweder dauerhaft rot oder so locker, dass er nichts fängt.

Die prägende Verschiebung von 2026 heißt Pilot-zu-Produktion, und die Arbeit, die sie verlangt, ist wenig glamourös: Zuverlässigkeit, Observability, Sicherheit, Kostensteuerung und vor allem LLM-Evals. Mit der allgemeinen Verfügbarkeit des Microsoft Agent Framework im April 2026 und Azure AI Foundry als Plattform für Aufbau und Governance von Agenten sind die meisten Laufzeit-Ausreden entfallen. Was bleibt, ist die Ingenieursdisziplin, einen Agenten als funktionierend nachzuweisen und ihn funktionierend zu halten.

Eine Harness muss vier Fehlerflächen abdecken, und die Qualität der finalen Antwort ist nur eine davon:

Fehlerfläche	Was schiefgeht	Was die Harness prüft
Finale Ausgabe	Falsche, ungetreue oder unsichere Antwort	Korrektheit, Faithfulness, Groundedness, Sicherheit
Trajektorie	Falsches Tool, falsche Reihenfolge, fehlender Schritt	Tool-Auswahl-Genauigkeit, Schritt-Assertions, Schleifenerkennung
Retrieval / Kontext	Irrelevanter oder veralteter Kontext ans Modell	Kontext-Relevanz, Recall, Korrektheit von Zitationen
Betrieb	Zu langsam, zu teuer, instabil	Latenz, Token-Kosten, Fehlerrate, Stabilität der Bestehensquote

Die meisten Teams instrumentieren nur die erste Zeile. Nach unserer Liefererfahrung entstehen die teuren Produktions-Incidents fast immer in den mittleren beiden — ein Agent, der still das falsche Tool wählt oder seine Antwort im falschen Dokument verankert.

Anatomie der Harness

Eine gute Harness besteht aus fünf Komponenten. Halten Sie sie entkoppelt, damit Sie Modelle, Scorer oder Laufzeiten austauschen können, ohne alles neu zu schreiben.

Loading diagram...

1. Die Datensatz-Ebene

Das ist das Fundament. Ein Golden Dataset ist eine versionierte Sammlung von Testfällen, die je eine Eingabe (samt erforderlichem Zustand) mit einem erwarteten Ergebnis oder einer Rubrik verbinden. Speisen Sie es aus vier Quellen:

Repräsentativer Verkehr — reale, anonymisierte Eingaben aus dem Normalbetrieb.
Schwierige Grenzfälle — mehrdeutige, mehrstufige oder Long-Context-Eingaben.
Adversariale Fälle — Prompt Injection, Jailbreaks, Anfragen außerhalb des Scopes.
Regressionsfälle — jeder vergangene Produktionsfehler, wortgetreu erfasst.

Speichern Sie es als Daten, nicht als Code (JSONL oder Tabelle), und versionieren Sie es im Repository neben dem Agenten. Das Entscheidende ist die Disziplin: Bei jedem neuen Fehlermodus aus der Produktion ergänzen Sie einen Fall. Die Suite wird monoton härter.

2. Der Runner

Der Runner führt den Agenten gegen jeden Datensatzeintrag in einer isolierten, reproduzierbaren Umgebung aus. Fixieren Sie Modellversionen, Temperaturen, System-Prompts und Tool-Definitionen. Erfassen Sie den vollständigen Trace jedes Laufs — Eingaben, Zwischenschritte des Reasonings, jeden Tool-Call und sein Ergebnis, die finale Ausgabe, Latenz und Token-Zahlen. Dieser Trace ist es, den Sie bewerten — und später Prüfern übergeben.

3. Die Scorer

Hier wohnt das Urteilsvermögen. Nutzen Sie drei Ebenen:

Deterministische Prüfungen — Schema-Validierung, Regex, "wurde refund_tool genau einmal aufgerufen", "parst und läuft das erzeugte SQL nur lesend". Günstig, schnell, eindeutig. Setzen Sie diese für alles Sicherheits- oder Compliance-Kritische ein.
LLM-as-Judge — ein Modell, das Faithfulness, Nützlichkeit, Tonalität oder Rubrik-Treue im großen Maßstab bewertet. Mächtig, aber fehlbar; kalibrieren Sie es (siehe unten).
Human-in-the-Loop — periodische Expertenprüfung einer Stichprobe, um den Judge zu kontrollieren und neue Ground Truth zu labeln.

4. Das Gate

Scores speisen eine Richtlinie, die über Bestehen oder Durchfallen entscheidet. Definieren Sie Schwellen je Metrik und je Umgebung — Staging akzeptiert vielleicht 92 % Korrektheit, die Produktion verlangt 98 % bei null Sicherheitsverletzungen. Das Gate läuft in der CI, sodass keine Agentenänderung ohne bestandene Qualitätssicherung der KI-Agenten gemergt wird.

5. Observability und Tracing

Dieselbe Instrumentierung, die Sie offline nutzen, muss in der Produktion laufen. Verteiltes Tracing der Agentenläufe erlaubt es, Live-Verkehr zu sampeln, Drift zu erkennen und frische Fehler direkt in den Datensatz zurückzuführen. Das Tracing und das Evaluation-SDK von Azure AI Foundry machen diese Schleife auf Azure konkret; das Muster selbst ist plattformunabhängig.

LLM-as-Judge kalibrieren

LLM-as-Judge ist der einzige wirtschaftlich tragfähige Weg, tausende offene Ausgaben zu bewerten — doch ein unkalibrierter Judge ist ein selbstbewusster Lügner. Unsere Checkliste:

Labeln Sie ein Kalibrierungsset von 100–300 Ausgaben mit menschlichen Experten.
Lassen Sie den Judge dasselbe Set bewerten und messen Sie die Übereinstimmung (z. B. Cohens Kappa).
Iterieren Sie Judge-Prompt und Rubrik, bis die Übereinstimmung für das Risikoniveau ausreicht.
Fixieren Sie Judge-Modell und Prompt-Version; ein Judge, der sich still ändert, entwertet Ihre Trendlinien.
Validieren Sie die Übereinstimmung neu, sobald Sie den Judge ändern oder das Modell aktualisieren.

Bei Hochrisiko-Entscheidungen darf der Judge nie das alleinige Gate sein. Koppeln Sie ihn mit deterministischen Prüfungen und leiten Sie Scores mit niedriger Konfidenz an die menschliche Prüfung weiter.

Einbindung in CI/CD

Eine Harness, die manuell läuft, läuft selten. Machen Sie die Evaluation zur erstklassigen CI-Stufe mit zwei Tiers:

Tier	Wann sie läuft	Umfang	Budget
Smoke-Evals	Bei jedem Pull Request	30–80 schnelle, deterministische Fälle	Sekunden–Minuten, geringe Kosten
Volle Regression	Vor Release / nächtlich	Gesamtes Golden Dataset inkl. Judge-Scoring	Minuten, kontrollierter Token-Verbrauch

Der Smoke-Tier hält die innere Schleife schnell; die volle Suite für Agenten-Regressionstests ist das Release-Gate. Entscheidend: Verfolgen Sie Scores über die Zeit, nicht nur Bestehen/Durchfallen. Eine Korrektheitsmetrik, die über drei Releases von 97 % auf 94 % driftet, ist ein Signal, das Sie lange vor dem Incident sehen wollen. Auch Tools und Orchestrierung zählen hier: Agenten, die von externen Tools abhängen, sollten gegen die Verträge getestet werden, die wir in unserem Beitrag zum MCP-Server-Design für Unternehmen beschreiben — in gemockten und Live-Varianten.

Die Harness als Compliance-Instrument

Für europäische Unternehmen ist das keine optionale Hygiene, sondern regulatorischer Nachweis. KI-Systeme mit höherem Risiko müssen unter dem EU AI Act dokumentierte Tests, Genauigkeit, Robustheit und laufendes Post-Market-Monitoring belegen. Finanzunternehmen unter DORA müssen Resilienztests und Nachvollziehbarkeit nachweisen. Eine versionierte Harness mit gespeicherten Datensätzen, Traces und Scores beantwortet die drei Fragen des Prüfers direkt: Was haben Sie getestet, wann, und mit welchem Ergebnis? Sie deckt damit zentrale Nachweispflichten ab.

Wir haben dies für regulierte Kunden geliefert, bei denen das Evaluations-Repository — und nicht ein Foliensatz — zum primären Artefakt in der Konformitätsbewertung wurde. Die Lehre: Gestalten Sie die Harness so, dass ihre Ergebnisse exportierbar, mit Zeitstempel versehen und an eine konkrete Agenten- und Modellversion gebunden sind. Nachweise, die Sie im Nachhinein rekonstruieren müssen, werden Sie falsch rekonstruieren.

Ein pragmatischer Rollout in fünf Schritten

Erfassen Sie 50 Golden-Fälle aus realem Verkehr und bekannten Schmerzpunkten. Warten Sie nicht auf den perfekten Datensatz; fangen Sie klein an und wachsen Sie.
Bauen Sie Runner und Trace-Erfassung mit fixierten Modell- und Prompt-Versionen.
Fügen Sie zuerst deterministische Scorer hinzu, danach einen kalibrierten LLM-Judge für die offenen Dimensionen.
Setzen Sie CI-Gates mit expliziten Schwellen je Umgebung und Trend-Tracking.
Schließen Sie die Schleife — speisen Sie Produktions-Traces wöchentlich in den Datensatz zurück, damit die Suite die Realität widerspiegelt.

Diese Abfolge liefert ein nutzbares Gate innerhalb von Tagen und eine reife, drift-bewusste Harness innerhalb eines Quartals.

Fazit

Ein Agent ohne Evaluations-Harness ist ein Prototyp, egal wie beeindruckend seine Demo ist. Die Harness — Datensätze, Runner, geschichtete Scorer, CI-Gates und Live-Tracing — verwandelt ein nichtdeterministisches Modell in Software, die Sie steuern, ausliefern und gegenüber einer Aufsichtsbehörde verteidigen können. Das Tooling von 2026 ist reif genug, dass keine Ausrede mehr bleibt; was bleibt, ist die Ingenieursdisziplin, die Schleife zu bauen und zu füttern.

Wenn Sie Agenten vom Pilot in die Produktion bringen und eine Harness wollen, die zugleich als Ihr Compliance-Nachweis dient, unterstützt Sie unser Team für KI- und Data-Platform-Engineering bei Design und Aufbau. Kein Body-Shop — ein strategischer Engineering-Partner, der genau das geliefert hat.

FAQ

Was ist eine Evaluations-Harness für KI-Agenten?

Eine Evaluations-Harness ist die automatisierte Maschinerie, die das Verhalten eines Agenten gegen einen kuratierten Datensatz aus Eingaben und erwarteten Ergebnissen bewertet. Sie kombiniert deterministische Prüfungen, LLM-as-Judge-Bewertung, Trajektorien-Analyse und Tool-Call-Assertions und schaltet Deployments in der CI frei. Ohne sie liefern Sie nichtdeterministische Software nach Bauchgefühl aus.

Wie unterscheidet sich Agenten-Evaluation von klassischem Softwaretest?

Klassische Tests prüfen exakte Ausgaben; Agenten sind nichtdeterministisch, dieselbe Eingabe kann unterschiedliche, aber gleichermaßen valide Antworten erzeugen. Die Evaluation bewertet daher Qualität über viele Dimensionen — Korrektheit, Faithfulness, Tool-Auswahl, Latenz und Kosten — und denkt in akzeptablen Bandbreiten und Bestehensquoten statt in Byte-für-Byte-Gleichheit. Bewertet wird zudem die Trajektorie, nicht nur die finale Antwort.

Was gehört in ein Golden Dataset für die Agenten-Evaluation?

Es sollte repräsentative reale Eingaben, bekannte schwierige Grenzfälle, adversariale Prompts und Regressionsfälle aus vergangenen Incidents enthalten. Jeder Eintrag verbindet eine Eingabe mit erwarteten Ergebnissen oder Rubrik-Kriterien. Wir versionieren es gemeinsam mit dem Code und erweitern es bei jedem Produktionsfehler, sodass die Suite über die Zeit härter wird.

Kann ich LLM-as-Judge-Bewertungen vertrauen?

LLM-as-Judge ist nützlich und skalierbar, aber fehlbar. Kalibrieren Sie Judges gegen von Menschen gelabelte Stichproben, messen Sie die Übereinstimmung, fixieren Sie Modell- und Prompt-Versionen und reservieren Sie deterministische Prüfungen für alles Sicherheits- oder Compliance-Kritische. Behandeln Sie Judge-Scores als Signale innerhalb einer größeren Harness, niemals als alleiniges Gate für Hochrisiko-Entscheidungen.

Wie unterstützt Agenten-Evaluation die Konformität mit EU AI Act und DORA?

Für Systeme mit höherem Risiko erwartet der EU AI Act dokumentierte Tests, Nachweise zu Genauigkeit und Robustheit sowie laufendes Monitoring; DORA verlangt Resilienztests und Nachvollziehbarkeit für Finanzunternehmen. Eine versionierte Harness mit gespeicherten Traces und Scores liefert genau diese Nachweispflichten — eine belastbare Prüfspur darüber, was wann mit welchem Ergebnis getestet wurde.

Welche Rolle spielt Azure AI Foundry in einer Evaluations-Harness?

Azure AI Foundry bietet eingebaute Evaluatoren, Tracing und ein Evaluation-SDK, das sich in die CI einbinden lässt, und integriert sich mit dem Microsoft Agent Framework, das im April 2026 GA erreichte. Für Microsoft-zentrierte Landschaften ist es eine starke Standardwahl, doch das Harness-Muster — Datensätze, Scorer, Gates, Observability — ist plattformunabhängig und sollte jedes einzelne Werkzeug überdauern.