AI Agent Evaluation: Zuverlässigkeit, Tool Calls & Regressionen messen

Ein AI Agent kann am Ende die richtige Antwort liefern und trotzdem einen unsicheren oder ineffizienten Weg genommen haben. Agent Evaluation muss deshalb den gesamten Ausführungsweg bewerten – nicht nur den finalen Text.

Die Kernfrage lautet:

Erfüllt der Agent die Aufgabe zuverlässig, mit den richtigen Tools, innerhalb der erlaubten Grenzen und reproduzierbar genug für den produktiven Betrieb?

Für die vorgelagerte Architekturentscheidung siehe KI-Agent vs. Workflow vs. Automation. Wenn bereits ein Agent-PoC existiert, ist KI Production Readiness die passende Anschlussleistung.

Die Kurzfassung

| Ebene | Was wird geprüft? | | --- | --- | | Outcome | Wurde die reale Aufgabe korrekt abgeschlossen? | | Planning | War die gewählte Vorgehensweise sinnvoll und effizient? | | Tool Use | Wurden richtige Tools mit richtigen Parametern verwendet? | | Permissions | Blieb der Agent innerhalb seiner Rechte? | | Guardrails | Wurden verbotene oder riskante Aktionen blockiert? | | Human Gates | Wurden notwendige Freigaben eingeholt? | | Recovery | Kann der Agent Tool-Fehler und unvollständige Daten behandeln? | | Regression | Bleibt Verhalten nach Modell-, Prompt- oder Tool-Änderungen stabil? |

Anthropic beschreibt Agent-Evaluation 2026 als besonders anspruchsvoll, weil Agents über mehrere Schritte handeln, Tools aufrufen, Zustand verändern und ihre Strategie anhand von Zwischenergebnissen anpassen. Quelle: Anthropic – Demystifying evals for AI agents.

Warum finale Antwortqualität nicht reicht

Bei einem normalen Chat-Use-Case kann die finale Antwort ein großer Teil des Qualitätsziels sein.

Ein Agent kann zusätzlich:

• Daten lesen,
• APIs aufrufen,
• Dateien verändern,
• Nachrichten senden,
• Transaktionen vorbereiten,
• Entscheidungen eskalieren,
• mehrere Systeme koordinieren.

Damit können zwei Läufe denselben finalen Text erzeugen, aber sehr unterschiedliche Risiken haben.

Beispiel:

Lauf A

1. Agent liest erlaubte CRM-Daten.
2. Verwendet freigegebenes Pricing-Tool.
3. Erstellt Angebot.
4. Wartet auf Freigabe.

Lauf B

1. Agent liest zusätzlich sensible Notizen.
2. Verwendet falsches Tool.
3. Überschreibt einen Datensatz.
4. Erstellt danach dasselbe Angebot.

Nur die finale Antwort zu bewerten würde diesen Unterschied übersehen.

Das Agent-Evaluation-Framework

1. Task Success

Hat der Agent das gewünschte Business-Ergebnis erreicht?

Beispiele:

• Ticket korrekt gelöst,
• Datensatz vollständig vorbereitet,
• Recherche mit belastbaren Quellen abgeschlossen,
• Anfrage korrekt eskaliert,
• kein Ergebnis produziert, wenn Evidenz fehlt.

Task Success sollte näher am realen Prozess liegen als an sprachlicher Schönheit.

2. Tool Selection

Hat der Agent das richtige Tool ausgewählt?

Fehlerklassen:

• unnötiges Tool,
• falsches Tool,
• nicht erlaubtes Tool,
• Tool-Aufruf fehlt,
• Tool-Aufruf zu früh oder zu spät.

Bei mehreren ähnlich klingenden Tools ist das besonders wichtig.

3. Tool Arguments

Auch mit dem richtigen Tool können falsche Parameter gefährlich sein.

Prüfen Sie:

• IDs,
• Beträge,
• Empfänger,
• Filter,
• Zeiträume,
• Schreib-/Leseoperationen,
• Scope,
• Mandant,
• Zielsystem.

Für kritische Parameter sind deterministische Assertions oft besser als rein semantische Grader.

4. Execution Trace

Ein Agent arbeitet über eine Folge von Beobachtungen und Aktionen.

Die Trace sollte mindestens erfassen:

• Nutzerinput,
• relevante Systeminstruktionen,
• ausgewählte Tools,
• Tool-Argumente,
• Tool-Ergebnisse,
• Modellentscheidungen,
• Freigaben,
• Fehler,
• finales Outcome.

Nicht jede interne Modellrepräsentation muss gespeichert werden. Entscheidend ist eine technisch nachvollziehbare Audit- und Debugging-Spur.

Snowflake beschreibt Agent Evaluation ebenfalls als Bewertung des vollständigen Ablaufs – inklusive Tool-Nutzung, Zwischenschritten, Policy-Konformität und finalem Ergebnis. Quelle: Snowflake – Agent Evaluation.

5. Permission Correctness

Ein Agent darf nicht nur „die richtige Antwort“ liefern. Er muss sie mit zulässigen Daten und Aktionen erzeugen.

Testfälle sollten daher verschiedene Rollen enthalten:

• normaler Nutzer,
• Teamleiter,
• Admin,
• anderer Mandant,
• Nutzer ohne Zugriff.

Prüfen Sie sowohl positive als auch negative Fälle.

Beispiel:

Der Agent soll für Nutzer A erkennen, dass Dokument X existiert, aber dessen Inhalt nicht offenlegen.

Das ist ein anderer Qualitätsfall als ein Retrieval-System ohne Berechtigungen.

6. Guardrail Effectiveness

Guardrails sind nur dann relevant, wenn sie getestet werden.

Beispiele:

• verbotene Aktion,
• Prompt Injection in einem Dokument,
• manipulierte Tool-Ausgabe,
• unerwartete externe URL,
• Versuch, Scope zu erweitern,
• sensible Daten in externen Kanal senden.

Ein Guardrail, der nur in der Architekturzeichnung existiert, ist kein nachgewiesener Kontrollmechanismus.

7. Human-in-the-loop

Human Gates brauchen eigene Tests.

Prüfen Sie:

• Wird die Freigabe tatsächlich ausgelöst?
• Werden alle relevanten Informationen für die Entscheidung angezeigt?
• Kann der Mensch ablehnen oder korrigieren?
• Wird nach Ablehnung nicht trotzdem weitergearbeitet?
• Ist die Freigabe revisionssicher protokolliert?

Ein Agent, der eine Freigabe „vergisst“, kann funktional stark und trotzdem produktionsuntauglich sein.

8. Recovery & Stop Conditions

Reale Systeme scheitern.

Testen Sie:

• API Timeout,
• Tool liefert Fehler,
• Daten fehlen,
• widersprüchliche Ergebnisse,
• Rate Limit,
• Benutzer bricht ab,
• kein sicherer nächster Schritt existiert.

Ein guter Agent muss nicht jede Situation autonom lösen. Sicher stoppen oder eskalieren ist oft das korrekte Verhalten.

Golden Dataset für Agents

Ein Agent-Testset sollte mehr enthalten als Prompt + Referenzantwort.

Ein Testfall kann beispielsweise so aussehen:

| Feld | Inhalt | | --- | --- | | Aufgabe | Reklamation prüfen und Lösung vorbereiten | | Rolle | Support-Mitarbeiter | | erlaubte Tools | CRM read, Order API read, Draft Email | | verbotene Tools | Refund execute | | erwartetes Outcome | Lösungsvorschlag + Entwurf | | Human Gate | vor Erstattung | | Fehlerfall | Bestellung nicht gefunden | | erwartete Eskalation | manuelle Prüfung |

So wird die Architektur selbst testbar.

Metriken für Agenten

Nicht jede Kennzahl passt zu jedem Agenten. Typische Dimensionen sind:

• Task Success,
• Tool Selection Accuracy,
• Argument Correctness,
• Policy Compliance,
• Human Escalation Correctness,
• Anzahl unnötiger Tool Calls,
• Latenz,
• Kosten,
• Recovery Success,
• unerlaubte Aktionen,
• Regressionen pro Failure Class.

Wichtiger als ein einzelner Score ist eine Failure Map, die zeigt, warum Tasks scheitern.

Deterministische Checks + LLM-Grader + Human Review

Agent Evaluation braucht meist mehrere Bewertungsmethoden.

Deterministisch

Geeignet für:

• Toolname,
• erlaubte Aktion,
• ID,
• Betrag,
• JSON-Schema,
• Anzahl Aufrufe,
• Reihenfolge bestimmter Gates.

LLM-Grader

Geeignet für:

• inhaltliche Qualität,
• Vollständigkeit,
• Angemessenheit einer Eskalation,
• semantische Übereinstimmung.

Human Review

Geeignet für:

• kritische Grenzfälle,
• fachliche Ambiguität,
• neue Failure Classes,
• Bewertung von Business-Nutzen.

Keiner dieser Ansätze sollte allein alles übernehmen.

Regression Testing bei Agents

Agenten reagieren empfindlich auf Änderungen an:

• Modell,
• Systemprompt,
• Tool-Beschreibung,
• Tool-Schema,
• Reihenfolge sichtbarer Tools,
• Retrieval,
• Memory,
• Guardrails,
• Berechtigungen.

Deshalb sollte jede relevante Änderung gegen dasselbe Testset laufen.

Besonders wichtig: Prüfen Sie nicht nur, ob die Erfolgsquote steigt. Eine neue Version kann mehr Tasks lösen und gleichzeitig mehr riskante Aktionen versuchen.

Production-Readiness-Matrix

| Frage | Muss vor Go-Live beantwortet sein | | --- | --- | | Reale Aufgaben getestet? | ja | | Kritische Tool Calls geprüft? | ja | | Rechtefälle enthalten? | ja | | Human Gates getestet? | ja | | Fehler und Stop-Bedingungen geprüft? | ja | | Regression-Suite vorhanden? | ja | | Audit-Trace verfügbar? | ja | | Kosten/Latenz gemessen? | ja | | Owner für Incidents definiert? | ja |

Wenn mehrere Punkte fehlen, ist der Agent noch im Experimentierstadium.

Anti-Patterns

„Der Agent löst 9 von 10 Demo-Aufgaben“

Ohne realistische Tool-, Rechte- und Fehlerfälle sagt das wenig über Produktion aus.

„Das Modell ist stärker geworden, also brauchen wir weniger Tests“

Ein stärkeres Modell kann neue Verhaltenspfade eröffnen. Mehr Capability reduziert nicht automatisch das Betriebsrisiko.

„Wir testen nur den Endzustand“

Dann bleiben falsche Tools, unnötige Aktionen und Policy-Verstöße unsichtbar.

„Human-in-the-loop ist unser Fallback“

Nur wenn der Gate technisch definiert und getestet ist.

Nächster Schritt

Wenn bereits ein AI Agent oder agentischer Workflow existiert, aber niemand belastbar sagen kann, ob er zuverlässig genug für produktive Daten und Prozesse ist, sollte nicht zuerst weiterentwickelt werden.

Zuerst braucht es Testset, Failure Taxonomy, Trace-Auswertung, Guardrail-Tests und Go-Live-Kriterien.

Genau dafür ist KI Production Readiness gedacht.

Wenn Sie noch vor der Architekturentscheidung stehen, beginnen Sie bei KI-Agent vs. Workflow vs. Automation oder bei AI Architecture Consulting.