Agenten- und Tool-Evaluation

Ein Agent tut Dinge. Diese eine Eigenschaft verändert die Evaluation stärker als alles andere in diesem Leitfaden. Denn ein System, das in der Welt handelt, lässt sich an der Welt messen. Man muss es nicht an einer Meinung über Text messen.

Die meisten Teams nutzen diese Chance nicht. Sie bewerten die letzte Nachricht.

Den Zustand bewerten, nicht den Satz

Befund: Anthropics Leitlinie zu Agenten-Evals beginnt mit diesem Satz: "A flight agent can say 'your flight is booked' while the database shows no reservation. For agent products, the database state is usually more important than the final sentence."

Quelle: Anthropic, Demystifying evals for AI agents

Diese Unterscheidung trennt ein Demo-Eval von einem Produktions-Eval. Ein Demo-Eval fragt, ob die Antwort richtig klingt. Ein Produktions-Eval prüft, ob das System die Arbeit erledigt hat.

Konkret bewerten Sie:

• Die Zeile in der Datenbank. Gibt es die Erstattung? Mit dem richtigen Betrag? Zur richtigen Bestellung?
• Die Datei auf der Platte. Gibt es sie? Lässt sie sich parsen? Enthält sie das Richtige?
• Die Testsuite. Bei Coding-Agenten ist sie der ganze Grader. Und sie kostet nichts.
• Die externen Nebenwirkungen. E-Mail verschickt, Ticket weitergestellt, Kalendereintrag angelegt. Und sonst nichts angefasst.

Der letzte Punkt zählt genauso viel wie der Rest. Ein Agent bucht den Flug und storniert eine unbeteiligte Reservierung. Dieser Agent ist gescheitert. Eine reine Ergebnisprüfung schaut auf eine Zeile und nennt das bestanden. Prüfen Sie deshalb auch, was sich nicht ändern durfte.

Den Endtext bewerten Sie erst danach, wenn überhaupt. Nutzer lesen diesen Text, also ist er nicht wertlos. Aber er ist auch der Teil, den man am leichtesten richtig aussehen lässt.

Agenten-Evals sind Systemtests

Ein Chat-Modell zu bewerten ist eine reine Funktion: Text rein, Text raus, benoten. Bei einem Agenten geht das nicht. Der Agent verändert Dinge, und der nächste Testlauf erbt diese Veränderungen. Damit ist ein Agenten-Eval ein Systemtest. Sie testen eine ganze laufende Umgebung, nicht eine einzelne Funktion.

An diesem Fehler lernt man das. Ihr Eval hat eine Aufgabe: „Buche den letzten freien Platz auf Flug LH441.“

• Versuch 1 läuft. Der Agent bucht den Platz. Bestanden.
• Versuch 2 läuft gegen dieselbe Umgebung. Es ist kein Platz mehr frei, denn Versuch 1 hat ihn genommen. Der Agent scheitert.
• Versuch 3 scheitert aus demselben Grund.

Ihr Agent hat 33 % erreicht. Mit seinem Können hat das nichts zu tun. Schlimmer noch: Ordnen Sie die Versuche anders an, liefert derselbe Code eine andere Zahl. Genau das bedeutet „Ergebnisse hängen von der Ausführungsreihenfolge ab“. Das ist quälend zu debuggen, weil nichts kaputt ist. Jedes einzelne Teil verhält sich korrekt.

Daraus folgen die praktischen Konsequenzen:

Umgebungen müssen zurücksetzbar und isoliert sein. Jeder Versuch startet aus einem bekannten Zustand. Er darf die Nebenwirkungen eines anderen Versuchs nicht sehen. Die billige Variante ist ein transaktionales Fixture: Vor dem Versuch öffnen Sie eine Datenbank-Transaktion, danach rollen Sie sie zurück. Die Änderungen verschwinden. Die gründliche Variante ist ein Container je Versuch. Ohne Isolation hängen die Ergebnisse von der Ausführungsreihenfolge ab. Die Suite wird dann unreproduzierbar, und zwar auf eine schwer zu debuggende Art. Praktisch heißt das: ein Container oder ein transaktionales Fixture je Versuch, keine gemeinsame Staging-Datenbank.

Versuche sind langsam und teuer. Ein Agenten-Versuch dauert Minuten und braucht viele Modellaufrufe, nicht einen. Das prägt, wie Sie die Suite staffeln. Siehe Evals in der CI.

Speichern Sie jedes Transkript. Ein Transkript ist die vollständige Aufzeichnung eines Versuchs: jede Nachricht, jeder Tool-Aufruf mit Argumenten und Ergebnis, in der Reihenfolge, in der sie passiert sind. Es ist für einen Agenten das, was der Trace für ein Chat-System ist. Bewegt sich ein Gesamtwert, sind die Transkripte der einzige Weg zur Ursache. Anthropics Leitlinie empfiehlt, wöchentlich Transkripte zu ziehen. Besonders nach jeder Wertänderung.

Zuverlässigkeit ist eine andere Messung als Fähigkeit

Lassen Sie dieselbe Aufgabe einmal laufen. Vielleicht hat der Agent Glück. Lassen Sie sie noch einmal laufen. Vielleicht nicht. Ein einzelner Anlauf sagt fast nichts. Also lassen Sie dieselbe Aufgabe k-mal laufen und bewerten den ganzen Satz. k heißt nur „wie viele Anläufe“, üblich sind 3, 5 oder 8. Jeder Anlauf heißt Versuch.

Diesen Satz kann man auf zwei Arten bewerten. Die Schreibweisen sehen sich unglücklich ähnlich:

• pass@k: War mindestens einer der k Versuche erfolgreich?
• pass^k: Waren alle k Versuche erfolgreich?

Das Dach ist eine gute Eselsbrücke. Bei einer einzelnen Aufgabe ist pass^k buchstäblich die Erfolgsquote hoch k, denn alle k Versuche müssen gelingen. Wegen dieses Exponenten bricht der Wert so schnell ein.

Die beiden Kennzahlen beantworten verschiedene Fragen.

pass@k: Mindestens einer von k Versuchen war erfolgreich. Das misst, ob der Agent es kann. Passend, wenn ein Mensch es erneut probiert. Oder wenn das Produkt selbst wiederholt und das Ergebnis prüft.

pass^k: Alle k Versuche waren erfolgreich. Das misst, ob der Agent es zuverlässig tut. τ-bench hat diese Kennzahl eingeführt. Der Grund: pass@k schmeichelt Agenten, die nur gelegentlich brillant sind.

Nehmen Sie einen Agenten mit 75 % Erfolgsquote. Lassen Sie ihn dreimal laufen und bewerten Sie ihn nach beiden Maßen:

pass@3 = 1 − (Chance, dass alle drei scheitern)
       = 1 − 0,25³  = 1 − 0,016  ≈ 98 %     „er kann das"

pass^3 = Chance, dass alle drei gelingen
       = 0,75³      = 0,42       ≈ 42 %     „er kann das zuverlässig"

Derselbe Agent, dieselben Versuche, derselbe Tag. 98 % und 42 %. Keine der beiden Zahlen ist falsch. Sie beantworten verschiedene Fragen. Welche Sie nennen, entscheidet darüber, ob Ihr Agent produktionsreif oder unbrauchbar klingt.

Eine Einschränkung zeigt die Rechnung nicht. Die 42 % gelten für eine Aufgabe, bei der jeder Versuch ein unabhängiger Münzwurf mit 75 % ist. Über eine Aufgabenmenge ist pass^k der Mittelwert von p^k je Aufgabe. Dieser Mittelwert liegt immer über der Rechnung mit dem Durchschnitt, im Extremfall deutlich. Beispiel: Ein Agent löst 75 % der Aufgaben jedes Mal und 25 % nie. Sein pass^3 ist 75 %, nicht 42 %. Die Münzwurf-Rechnung ist der schlechteste Fall. Wo Ihr Agent dazwischen liegt, verrät keine Formel. Deshalb fahren Sie k Versuche wirklich, statt sie aus der Einzelquote hochzurechnen.

Befund: Die Rechnung ist gnadenlos, und man sollte sie verinnerlichen. τ-bench hat pass^k eingeführt. Für die damaligen Spitzenagenten berichtete es pass^8 unter 25 % in der Retail-Domäne. Diese Agenten wirken bei einem einzelnen Versuch kompetent. Achtmal hintereinander sind sie unbrauchbar.

Quelle: τ-bench (Yao et al., 2024)

Ein Agent mit drei Erfolgen aus vier Versuchen wirkt in einer Demo akzeptabel. Braucht ihn ein Nutzer dreimal hintereinander, scheitert er öfter, als er gelingt. Für alles, was unbeaufsichtigt läuft, ist pass^k die ehrliche Zahl. Der Abstand zwischen beiden Kennzahlen ist die Größe des Zuverlässigkeitsproblems. Gemessen, nicht hochgerechnet.

Berichten Sie beide. Sie konkurrieren nicht. Sie begrenzen verschiedene Produktaussagen.

Trajektorie gegen Endergebnis

Die Endergebnis-Bewertung benotet das Ergebnis. Die Bewertung der Trajektorie benotet den Weg: Welche Tools wurden aufgerufen? Mit welchen Argumenten? In welcher Reihenfolge? Wie viele Schritte? Hat sich der Agent von einem Fehler erholt?

Eine Trajektorie ist schlicht das Protokoll dessen, was der Agent getan hat, der Reihe nach. Bei einer Erstattungsanfrage könnte es so aussehen:

1. suche_bestellungen(kunden_id="4417")            → 3 Bestellungen
2. hole_bestellung(bestell_id="A-2231")            → 89,00 €, zugestellt
3. lies_richtlinie("erstattungen")                 → Rückgabe binnen 14 Tagen
4. erstatte(bestell_id="A-2231", betrag=89)        → ok

Die Endergebnis-Bewertung liest nur die letzte Zeile und die Nachricht an den Kunden. Die Trajektorien-Bewertung liest alle vier Zeilen. Sie würde bemerken, wenn Schritt 4 890 € erstattet hätte. Oder wenn der Agent Schritt 3 übersprungen hätte. Oder wenn sich die Schritte 1 bis 3 elfmal wiederholt hätten.

Beides ist nötig. Jede Methode übersieht, was die andere fängt. Ein Beispiel: Die Antwort ist richtig, aber der Agent brauchte 20 Schritte, und zwei Zwischenaufrufe verstießen gegen die Richtlinie. Das ist eine gescheiterte Trajektorie mit bestandenem Ergebnis. Für einen Agenten mit echten Berechtigungen zählt die Trajektorie.

Diese Eigenschaften lohnen sich bei einer Trajektorie:

Umstritten: Wie streng man Trajektorien bewerten sollte. Eine exakte Tool-Reihenfolge zu verlangen, fängt echte Prozessfehler. Es bestraft aber auch neue, gültige Lösungen. Das Eval prüft dann nur noch, ob der Agent Ihre erste Implementierung nachahmt. Der tragfähige Kompromiss: Prüfen Sie auf Invarianten statt auf eine exakte Reihenfolge. Also auf Tools, die aufgerufen werden müssen, Tools, die tabu sind, und Budgets, die halten müssen. Die Frage „War dieser Weg sinnvoll?“ überlassen Sie einer menschlichen Stichprobe statt einem automatischen Judge.

Kosten und Latenz sind Eval-Metriken

Bei Agenten sind das keine betrieblichen Fußnoten. Ein Agent löst die Aufgabe in 90 Schritten und vier Minuten. Damit hat er eine Produktanforderung verfehlt, auch wenn die Ergebniszeile stimmt.

Erfassen Sie je Versuch: Schritte, Tool-Aufrufe, Gesamttokens, Laufzeit und Kosten. Berichten Sie diese Werte neben der Erfolgsquote, nie an ihrer Stelle.

Befund: Genau das ist das Argument des Holistic Agent Leaderboard über öffentliche Agenten-Benchmarks: Die Erfolgsquote in der Überschrift verbirgt große Unterschiede bei Kosten und Zuverlässigkeit. Und das zwischen Agenten, die vergleichbar wirken.

Quelle: Holistic Agent Leaderboard, 2025

Intern gilt dasselbe. Eine Prompt-Änderung hebt den Erfolg um 2 Punkte und verdoppelt die Schrittzahl. Das ist meist eine Regression.

Zwei Suiten, nicht eine

Anthropics Leitlinie trennt sie. Diese Trennung trägt das Ganze:

Regressionssuite. Stabil, schnell, an echte Produktfehler gebunden. Deterministische Grader, wo immer möglich. Sie blockiert Releases. Sie sollte nahe 100 % liegen. Jeder Rückgang ist ein Vorfall.

Fähigkeitssuite. Schwere Aufgaben, darunter absichtlich solche, an denen der Agent scheitert. Sie berichtet, statt zu blockieren. Sie sollte nicht nahe 100 % liegen. Sonst misst sie nicht mehr die Grenze dessen, was Ihr Agent kann, und braucht härtere Aufgaben.

Teams mit nur einer Suite bekommen etwas, das beide Aufgaben schlecht erfüllt: zu sprunghaft, um Releases daran zu binden, und zu leicht, um daraus zu lernen.

Öffentliche Agenten-Benchmarks und was man mitnimmt

Das sind Benchmarks der Ebene A. Sie messen die agentische Fähigkeit eines Foundation-Modells, nicht Ihren Agenten. Gerüst, Tools, Prompts und Domäne machen den Großteil seines Verhaltens aus. Nichts davon steckt im Benchmark.

Kennen sollten Sie sie trotzdem. Die Techniken übertragen sich, auch wenn die Aufgaben es nicht tun:

Nehmen Sie pass^k von τ-bench mit, den AST-Abgleich von BFCL und die zustandsbasierte Bewertung von OSWorld. Nehmen Sie nicht deren Aufgaben. Und berichten Sie deren Werte nicht als Beleg über Ihr Produkt.

Häufiger Fehler: Ein Agenten-Eval, das nur die letzte Nachricht prüft. Der Grund: So sieht ein Chat-Eval aus, und der Agent hat eine Chat-Oberfläche. Aber die Oberfläche ist Text. Das Produkt ist die Zustandsänderung. Wenn Ihr Eval nie die Datenbank abfragt, bewertet es nicht den Agenten.