KI-Agenten-Evaluierung

Was ist KI-Agenten-Evaluierung?

KI-Agenten-Evaluierung ist die Praxis zu messen, ob ein KI-Agent Aufgaben durchgängig korrekt abschließt, wobei die gesamte Abfolge von Entscheidungen, Tool-Aufrufen und Zwischenschritten ebenso bewertet wird wie das Endergebnis. Sie erweitert die Bewertung einzelner Antworten auf mehrstufige autonome Arbeit, bei der ein Agent über einen fehlerhaften Prozess zur richtigen Antwort gelangen oder zehn Schritte nach einem guten Start scheitern kann. Der Einsatz steigt stetig, weil Agenten immer leistungsfähiger werden: METR maß 2025, dass Frontier-Modelle wie Claude 3.7 Sonnet einen Zeithorizont von etwa 50 Minuten bei 50 Prozent Erfolgsquote erreichen – ein Horizont, der sich seit 2019 etwa alle sieben Monate verdoppelt hat [1].

Die wichtigsten Punkte

• Agenten brauchen eine Evaluierung auf Trajektorien-Ebene, nicht nur auf Output-Ebene. Eine korrekte Endantwort, die durch Löschen und Neuanlegen eines Kundendatensatzes erreicht wurde, bleibt ein Fehlschlag.
• Die drei Standardebenen sind Ergebnis (wurde die Aufgabe abgeschlossen), Trajektorie (waren die Schritte sinnvoll und sicher) und Tool-Nutzung (richtiges Tool, richtige Argumente, Ergebnisse tatsächlich genutzt).
• Kleine Fehlerquoten pro Schritt summieren sich: 95 Prozent Genauigkeit pro Schritt über zwanzig Schritte hinweg ergibt eine Aufgaben-Fehlschlagsrate von rund eins zu drei, weshalb sich Agenten weniger zuverlässig anfühlen als die Modelle darin.
• Umgebungsdesign ist die halbe Arbeit. Reproduzierbare, sandboxed Umgebungen mit überprüfbaren Endzuständen machen Agenten-Evals vertrauenswürdig; Ad-hoc-Demos nicht.
• Kombinieren Sie Offline-Evals mit Produktions-Tracing. Die Eval-Suite sagt Verhalten voraus; KI-Observability bestätigt es anhand von echtem Traffic.

So funktioniert es

Einen Agenten zu evaluieren bedeutet, eine Schleife zu evaluieren, keine einzelne Antwort. Der Agent erhält eine Aufgabe, plant, ruft Tools auf, liest Ergebnisse und iteriert, weshalb die Evaluierung den gesamten Ablauf erfassen muss. Ergebnisprüfungen sind der Ankerpunkt: Definieren Sie einen verifizierbaren Endzustand – das Ticket ist mit dem richtigen Lösungscode geschlossen, der Pull Request besteht die Tests, die Zeile existiert in der Datenbank – und prüfen Sie ihn programmatisch. Das ist das Agenten-Äquivalent eines Abnahmetests, und genau das messen die meisten veröffentlichten Agenten-Benchmarks im Stil von SWE-bench. Diese Benchmarks zeigen auch, wie schnell sich der Boden bewegt: Als SWE-bench 2023 startete, löste das leistungsstärkste Modell, Claude 2, nur 1,96 Prozent der echten GitHub-Issues durchgängig [2], und Stanfords AI Index 2025 verzeichnete einen Anstieg der SWE-bench-Werte um 67,3 Prozentpunkte in nur einem Jahr [3].

Ergebnisprüfungen allein verbergen gefährliches Verhalten, weshalb ausgereifte Suiten eine Trajektorien-Bewertung ergänzen. Hier bewerten Sie, wie der Agent dorthin gelangt ist: Anzahl der Schritte im Vergleich zu einer angemessenen Baseline, ob destruktive Tools aufgerufen wurden, die nicht nötig waren, ob sich der Agent von einem fehlgeschlagenen Tool-Aufruf erholt hat oder sich darin verfangen hat, ob Tool-Argumente erfunden wurden. Ein Teil davon ist regelbasiert (prüfen, dass der Delete-Endpunkt nie aufgerufen wurde), der qualitative Rest geht an einen LLM-Judge, der den Ablauf anhand einer Rubrik liest. Darunter liegen Tool-Nutzungs-Metriken: korrekte Tool-Auswahlrate, Gültigkeit der Argumente und ob zurückgegebene Daten den nächsten Schritt tatsächlich beeinflusst haben.

Die Infrastruktur-Anforderung, die Teams überrascht, ist die Umgebung. Jeder Eval-Fall braucht einen reproduzierbaren Ausgangszustand, eine vorbefüllte Datenbank, ein Fixture-Repository, eine gemockte API, damit Durchläufe über Modell- und Prompt-Änderungen hinweg vergleichbar sind. Weil Agenten nichtdeterministisch sind, führen einzelne Durchläufe in die Irre; jeden Fall mehrfach auszuführen und Erfolgsraten zu berichten (das aus der Code-Generierungsforschung entlehnte pass@k-Muster) liefert vertrauenswürdige Zahlen.

Beispiel

Ein Team baut einen Support-Agenten, der Rückerstattungsanfragen durchgängig bearbeitet: Bestellung nachschlagen, Rückerstattungsrichtlinie prüfen, Rückerstattung über die Zahlungs-API auslösen und den Kunden per E-Mail informieren. Ihre Eval-Suite enthält 60 Szenarien, jedes eine vorbefüllte Sandbox mit einer fiktiven Bestelldatenbank und einer gemockten Zahlungs-API. Ein Szenario: eine Bestellung außerhalb des 30-Tage-Fensters. Die Ergebnisprüfung stellt sicher, dass keine Rückerstattung ausgelöst wurde und die Kunden-E-Mail die Richtlinie erklärt. Die Trajektorien-Prüfung stellt sicher, dass der Agent das Richtlinien-Tool konsultiert hat, bevor er entschied, statt zu raten. Als sie ein günstigeres Modell für die innere Schleife testen, bleibt die Ergebnis-Erfolgsrate bei 92 Prozent, aber die Trajektorien-Bewertung zeigt, dass es in einem Viertel der Durchläufe den Richtlinien-Abruf überspringt und aus dem Gedächtnis antwortet – richtige Antworten durch Zufall. Sie behalten das günstigere Modell, fügen aber einen Guardrail hinzu, der einen Richtlinien-Abruf vor jeder Rückerstattungsentscheidung erzwingt, und die Abkürzung verschwindet.

Häufige Missverständnisse

Der klassische Fehler ist, das Chat-Transkript des Agenten statt seiner tatsächlichen Auswirkungen zu bewerten. Teams lesen eine geschliffene Konversation, sehen, wie der Agent behauptet, das CRM aktualisiert zu haben, und werten das als Erfolg, ohne das CRM zu prüfen. Agenten erzählen selbstbewusst von Arbeit, die sie nicht oder falsch erledigt haben, und eine Bewertung auf Transkript-Ebene übersieht genau diese Fälle. Ground Truth liegt in der Umgebung: prüfen Sie die Datenbankzeile, das API-Aufruf-Log, den Datei-Diff. Wenn Ihr Eval den Endzustand nicht programmatisch prüfen kann, ist es ein Vibe Check mit ein paar Extraschritten.

FAQ

Wie unterscheidet sich Agenten-Evaluierung von LLM-Evals? Standard-LLM-Evals bewerten einen Input gegen einen Output. Agenten-Evaluierung bewertet eine Sequenz: Planung, Tool-Aufrufe, Zustandsänderungen und Recovery-Verhalten über viele Modellaufrufe hinweg, beurteilt anhand des Endzustands einer Umgebung. Die Methoden für einzelne Antworten gelten weiterhin innerhalb jedes Schritts, sind aber notwendig statt hinreichend.

Welche Metriken sollte ein Agenten-Eval ausweisen? Die Aufgaben-Erfolgsrate ist die Schlagzeile, idealerweise als pass@k über wiederholte Durchläufe. Darunter: Schritt-Effizienz gegenüber einer Baseline-Trajektorie, Tool-Aufruf-Fehlerrate, Anzahl unsicherer Aktionen (die bei null die Freigabe verhindern sollte), Kosten pro Aufgabe in Token und Latenz. Kosten spielen eine größere Rolle, als Teams erwarten, denn ein Agent, der durch das Brute-Forcen von vierzig Schritten erfolgreich ist, kann wirtschaftlich nicht tragbar sein.

Ändern Multi-Agenten-Systeme den Ansatz? Die Ebenen bleiben gleich, aber die Zuordnung wird schwieriger. Wenn ein Orchestrator an Spezial-Agenten delegiert, bewerten Sie zunächst das System durchgängig und dann die Übergaben zwischen den einzelnen Agenten, um herauszufinden, wo Fehler entstehen. Die Trace-Struktur aus Ihrer Orchestrierungs-Ebene liefert dafür das Rohmaterial für beides.

Quellen

1. METR. "Frontier models show a 50% task-completion time horizon of about 50 minutes, doubling roughly every seven months since 2019." https://arxiv.org/abs/2503.14499. Abgerufen im August 2026.
2. Jimenez et al., Princeton. "SWE-bench launch results: best model (Claude 2) resolved 1.96% of real GitHub issues." https://arxiv.org/abs/2310.06770. Abgerufen im August 2026.
3. Stanford HAI. "2025 AI Index Report: SWE-bench scores rose 67.3 percentage points in one year." https://hai.stanford.edu/ai-index/2025-ai-index-report. Abgerufen im August 2026.