Inhalt
Sie haben ein Multi-Agent-System verdrahtet, ihm Tools gegeben und es mit dem Agent SDK laufen lassen – aber wie messen Sie, ob der Agent seine Aufgabe tatsächlich erfüllt? Bei einem einzelnen Output können Sie ihn mit KI-Evals bewerten. Doch ein Agent plant über viele Schritte, ruft Tools auf und handelt mit Zustand. Selbst wenn der letzte Satz richtig aussieht, könnte er unterwegs eine gefährliche Brücke überquert haben. Genau hier rücken Agent Evals in den Mittelpunkt.
Dieser Artikel legt auf Basis offizieller Informationen dar, was Agent Evals sind, wie sie sich von LLM-Evals unterscheiden, was man misst (5 Dimensionen), wie man bewertet (3 Grader), die einzigartigen Fallstricke sowie den praktischen Workflow und die Benchmarks. Die Kernpunkte vorab. ① Agent Evals messen nicht nur den "finalen Output", sondern die "trajectory" der Handlungen. ② Anthropic empfiehlt, das Ergebnis (den finalen Zustand) zu bewerten, nicht den Weg – denn ein stures Schritt-für-Schritt-Abhaken ist fragil. ③ Beginnen Sie mit einem kleinen Eval-Set von 20–50 Aufgaben aus echten Fehlern und führen Sie eine automatisierte Bewertung durch.
Messen Sie sowohl "die finale Antwort" als auch "den zurückgelegten Weg"
— Output-Evals reichen nicht; Agenten sind mehrstufig, tool-nutzend, zustandsbehaftet
Anthropic empfiehlt, das Ergebnis über den Weg zu bewerten – aber die trajectory verrät Ihnen, warum es scheiterte. Nutzen Sie beides, je nach Aufgabe.
1. Was sind Agent Evals?
Agent Evals sind der Prozess, systematisch zu messen, ob ein "Agent" – einer, der Tools nutzt und mehrere Schritte unternimmt, um ein Ziel zu erreichen – seine Aufgaben tatsächlich erfüllen kann. Sie sind eine Weiterentwicklung der LLM-Evals, die die Qualität eines einzelnen Prompts beurteilen; das Ziel erweitert sich von "einem Output" zu "einer Abfolge von Handlungen".
Warum das wichtig ist: In ihrem Leitfaden zu Agent Evals merkt Anthropic an, dass "Evals umso schwerer zu bauen werden, je länger man wartet. Früh übersetzen sich Produktanforderungen ganz natürlich in Testfälle", und empfiehlt, dass "20–50 einfache Aufgaben aus echten Fehlern ein hervorragender Anfang sind". Mit anderen Worten: Agent Evals verwandeln "es scheint zu funktionieren" in reproduzierbare Zahlen. Das geht Hand in Hand mit KI-Observability (dem Beobachten des Laufs) – die Traces, die Sie beobachten, werden zum Material für die Bewertung.
2. Warum sie sich von LLM-Evals unterscheiden (Output vs. trajectory)
Klassische LLM-Evals bewerten im Wesentlichen "Input → ein Output". Doch ein Agent plant, ruft Tools auf, betrachtet die Ergebnisse, entscheidet über den nächsten Schritt und aktualisiert den Zustand. Daher reicht es nicht, nur den finalen Output zu betrachten. Google erklärt ebenso, dass es "nicht genügt, einfach die Outputs zu prüfen; wir müssen das 'Warum' hinter den Handlungen eines Agenten verstehen", und teilt die Bewertung in zwei Familien auf: "final response" und "trajectory". Auch Microsoft sagt, man müsse "nicht nur den finalen Output bewerten, sondern auch die Qualität und Effizienz jedes Schritts", und unterteilt sie in System- (end-to-end) und Prozess- (Schritt für Schritt) Bewertung.
💡 Die Kernidee: Eine "korrekte finale Antwort" kann einen kaputten Prozess verbergen. Umgekehrt kann die Antwort richtig sein, aber durch Glück, Zufall oder eine gefährliche Abkürzung zustande gekommen sein. Bei Agenten betrachtet man daher sowohl das "Ergebnis" als auch den "Prozess". Zu den Grundlagen der Bewertung einzelner Outputs und zu LLM-as-judge siehe den Artikel über KI-Evals.
3. Was man misst: 5 Dimensionen
Hier sind fünf häufig genutzte Blickwinkel für die Agent-Bewertung.
Wurde das Ziel erreicht? Beurteilen Sie es am finalen Zustand – ob eine Reservierung in der DB existiert –, nicht an der Äußerung "Ich habe gebucht".
Hat er sinnvolle Schritte unternommen? Hat er die richtigen Tools in der richtigen Reihenfolge und Anzahl verwendet? Sinnlose Umwege oder gefährliche Schritte?
Hat er das richtige Tool gewählt und die richtigen Argumente übergeben? Prüfen Sie Funktionsnamen, Argumenttypen und -werte (und erkennen Sie unnötige Aufrufe).
Wie viele Schritte, Tokens, Dollar und Sekunden? Eine korrekte Antwort ist unpraktikabel, wenn die Kosten explodieren. Muss mit beobachteten Metriken verknüpft werden.
Ist der Output relevant, korrekt und vollständig? Bewerten Sie offene Inhalte mit LLM-as-judge oder einer Rubrik.
Hinweis: 4. Effizienz (Tokens, Kosten, Latenz) ist von keinem einzelnen Anbieter formal als "Eval-Metrik" kodifiziert; in der Praxis sind es oft Observability-Signale, die in die Bewertung einfließen. Dennoch ist es eine essenzielle Dimension, um einen Agenten zu stoppen, der in einer Schleife durchdreht.
4. Wie man bewertet: 3 Grader und "Ergebnis vs. Weg"
Es gibt grob drei Arten von Grader. Nach Anthropics Rahmen hat jede ihre Kompromisse.
| Grader | Stärken | Schwächen |
|---|---|---|
| Code (programmatisch) | Schnell, günstig, objektiv, reproduzierbar | Fragil gegenüber gültigen Variationen / Alternativen |
| LLM-as-judge (Modell) | Flexibel, skalierbar, erfasst Nuancen | Nicht deterministisch, teurer, braucht Kalibrierung mit Menschen |
| Mensch | Goldstandard für Qualität | Teuer, langsam (möglichst vermeiden) |
Das Standardvorgehen: Bewerten Sie mit Code, was Sie können, übergeben Sie nur die subjektiven, offenen Teile an ein anderes Modell als LLM-as-judge, und nutzen Sie Menschen für Stichproben an wichtigen Stellen. Das Design von LLM-as-judge (detaillierte Rubriken, diskrete Outputs, Judge-Bias) wird ausführlich im Artikel über LLM-Evals behandelt.
Stures "trajectory matching" ist fragil
Wie bewertet man also die trajectory? Hier bezieht Anthropic eine klare Position: "Es gibt einen verbreiteten Instinkt, zu prüfen, ob Agenten sehr spezifische Schritte wie eine Folge von Tool-Aufrufen in der richtigen Reihenfolge befolgt haben. Wir haben festgestellt, dass dieser Ansatz zu starr ist und zu übermäßig fragilen Tests führt, da Agenten regelmäßig gültige Vorgehensweisen finden, die Eval-Designer nicht antizipiert haben. Um Kreativität nicht unnötig zu bestrafen, ist es oft besser, das zu bewerten, was der Agent produziert hat, nicht den Weg, den er gegangen ist." Bei einer Flugbuchung etwa messen Sie als finalen Zustand, ob tatsächlich eine Reservierung in der SQL-DB der Umgebung existiert – nicht die Äußerung "Ich habe gebucht".
Google und Microsoft hingegen bieten trajectory-match-Grade (exact / in-order / any-order usw.) als formale Metriken an. Die beiden widersprechen sich nicht – trajectory-Evals sind gut darin, zu diagnostizieren, "warum es scheiterte", und Ergebnis-Evals vermeiden es, gültige Kreativität zu bestrafen. In der Praxis ist der realistische Mittelweg, einen strikten exact match zu vermeiden und auf eine Schlüssel-Handlungs-Prüfung zu lockern: "Wurden die kritischen Tools aufgerufen?"
5. Probleme, die nur Agent Evals haben
Agent Evals bringen Schwierigkeiten mit sich, die die Bewertung einzelner Outputs nicht hat.
- Nicht-Determinismus (derselbe Input nimmt verschiedene Wege): Ein Erfolg bedeutet nicht, dass er sich reproduziert. Sie brauchen Zuverlässigkeitsmetriken wie, ob er über alle k Läufe erfolgreich ist (pass^k). Das τ-bench-Paper berichtet, dass "Modelle erheblich abbauen, wenn k steigt, was ihre Unzuverlässigkeit offenbart" (die Zahlen sind eine Momentaufnahme).
- Sich verstärkende Fehler: Wenn ein einzelner Schritt mit Wahrscheinlichkeit p gelingt, gelingen t Schritte mit etwa pt. Je länger die Kette, desto schneller bricht sie zusammen – weshalb der Erfolg bei langfristigen Aufgaben stark abfällt.
- Reward Hacking / Specification Gaming: Verhalten, das den Buchstaben des Graders erfüllt, ohne das eigentliche Ziel zu erreichen. In DeepMinds Beispiel positionierte sich ein Roboterarm zwischen Kamera und Objekt und täuschte den Evaluatoren vor, er habe den Gegenstand gegriffen, obwohl er es nicht hatte. Um "sieht richtig aus, aber gefährlicher Weg" zu erkennen, muss man die trajectory und die Nebenwirkungen bewerten.
- Veraltende Eval-Sets / Kontamination: Wenn ein Benchmark in die Trainingsdaten durchsickert (Kontamination), spiegeln die Ergebnisse keine echte Fähigkeit mehr wider. Sie müssen Ihre Regressions-Evals laufend aktualisieren, während der Agent reift.
Das Problem des "gefährlichen Wegs" geht nahtlos in KI-Guardrails über. Eine Eval, die nur die finale Antwort betrachtet, läuft an diesen Fallen direkt vorbei.
6. Der Workflow und die Benchmarks
An Anthropics Empfehlungen ausgerichtet, ist der Workflow einfach.
- Klein aufbauen, aus echten Fehlern: Sie brauchen keine Hunderte. Verwandeln Sie 20–50 Fehler, die in der Produktion passiert sind, in Testfälle.
- Automatisierte Bewertung durchführen: zuerst Code, LLM-as-judge nur für die offenen Teile. Priorisieren Sie Menge vor handbewerteter Qualität.
- Zwei Arten trennen: Capability-Evals (worin ist er gut?) und Regressions-Evals (kann er noch, was er konnte?).
- In einen Lebenszyklus einbetten: ① automatisierte Pre-Launch-Evals (in CI eingebaut) → ② Produktionsmonitoring → ③ A/B-Tests → ④ Nutzer-Feedback und Trace-Review, schichtweise aufgebaut.
- Früh schreiben: Evals werden umso schwerer zu bauen, je länger man wartet.
Bekannte Agent-Benchmarks sind ebenfalls nützliche Referenzen für den Aufbau eigener Evals (entscheidend ist, zu lesen, "was jeder misst"; die Ergebnisse bewegen sich je nach Modell und Version, nehmen Sie sie also nicht für bare Münze).
| Benchmark | Was er misst |
|---|---|
| SWE-bench / Verified | Echte GitHub-Issues mit einem Patch lösen, bewertet als pass/fail durch die Testsuite (ausführungsbasiert) |
| τ-bench / τ²-bench | Mehrstufiger Dialog Tool×Nutzer in Einzelhandel, Airline usw. + Befolgung von Richtlinien; bewertet am finalen DB-Zustand |
| WebArena | Erledigung von Aufgaben zur autonomen Web-Bedienung auf realistischen Website-Nachbildungen |
| GAIA | General-Assistant-Aufgaben, die für Menschen leicht, für KI schwer sind (Reasoning + Tools + Browsing) |
| OSWorld | Computer-Use mit Bedienung einer GUI auf einem echten OS, ausführungsbasiert bewertet |
| BFCL | Genauigkeit des Function/Tool-Callings (Funktionsnamen, Argumentstruktur, Ausführbarkeit) |
Was das Tooling betrifft, unterstützen LangSmith, Braintrust, DeepEval und Arize Phoenix die Bewertung von trajectory und Tool-Aufrufen. Die meisten bauen auf Traces auf und bewerten auf Schritt-, Lauf- und Datensatzebene. Beachten Sie, dass Claude Managed Agents eine ergebnisbasierte Bewertung – bei der ein separater Grader gegen Ihre Rubrik bewertet – bereits eingebaut mitbringt.
Zusammenfassung
Agent Evals sind der Prozess, zu messen, ob ein tool-nutzender, mehrstufiger Agent seine Aufgaben tatsächlich erfüllen kann. Anders als LLM-Evals, die einen einzelnen Output betrachten, untersuchen sie sowohl "die finale Antwort (Ergebnis)" als auch "den zurückgelegten Weg (trajectory)". Die Dimensionen sind ① Ergebnis ② trajectory ③ Tool-Nutzung ④ Effizienz ⑤ finale Qualität. Bewerten Sie mit Code → LLM-as-judge → Mensch, und Anthropic empfiehlt: "Bewerten Sie das Ergebnis (den finalen Zustand), nicht den Weg" (stures Schritt-Abhaken ist fragil).
Die einzigartigen Fallstricke sind Nicht-Determinismus (pass^k), sich verstärkende Fehler, Reward Hacking und veraltete Eval-Sets. In der Praxis ist das Standardvorgehen, klein mit 20–50 Fällen aus echten Fehlern zu beginnen, die automatisierte Bewertung in CI laufen zu lassen, Capability- und Regressions-Evals zu trennen und sie früh zu schreiben. Verwandt: KI-Evals, Observability, wie man ein Multi-Agent-System baut, Managed Agents.
FAQ
Q. Was sind Agent Evals?
A. Der Prozess, systematisch zu messen, ob ein tool-nutzender, mehrstufiger Agent seine Aufgaben tatsächlich erfüllen kann. Sie sind eine Weiterentwicklung der LLM-Evals, die einen einzelnen Prompt bewerten; das Ziel erweitert sich von "einem Output" zu "einer Abfolge von Handlungen". Das Kennzeichen ist, nicht nur die finale Antwort zu betrachten, sondern die trajectory, die dorthin führte (welche Tools wie aufgerufen wurden).
Q. Wie unterscheiden sie sich von gewöhnlichen LLM-Evals?
A. Darin, ob man "einen Output" oder "eine Kette von Handlungen" betrachtet. Weil ein Agent plant, Tools aufruft und Zustand aktualisiert, reicht der finale Output allein nicht aus. Eine korrekte Antwort kann einen kaputten Prozess verbergen, und eine richtige Antwort kann über eine gefährliche Abkürzung zustande gekommen sein. Daher bewertet man sowohl das Ergebnis (finaler Zustand) als auch die trajectory (Prozess).
Q. Was sollte ich messen?
A. Die üblichen fünf Dimensionen: ① Ergebnis (Aufgabenerfolg = passt der finale Zustand zum Ziel?) ② trajectory (sinnvolle Schritte?) ③ Korrektheit der Tool-Nutzung (richtiges Tool, richtige Argumente?) ④ Effizienz (Schritte, Tokens, Kosten, Latenz) ⑤ Qualität der finalen Antwort (relevant, korrekt, vollständig?). Dimension 4 bringt Observability-Signale ein und ist wichtig, um Durchdrehen zu stoppen.
Q. Sollte ich die trajectory (Schritte) auf exact match prüfen?
A. Nein – strikter exact match neigt dazu, fragil zu sein. Anthropic empfiehlt: "Zu prüfen, ob Tool-Aufrufe der richtigen Reihenfolge folgten, ist zu starr und fragil; Agenten finden gültige Alternativen, daher ist es besser, das Ergebnis zu bewerten, nicht den Weg." In der Praxis vermeiden Sie exact match und lockern auf eine Schlüssel-Handlungs-Prüfung: "Wurden die kritischen Tools aufgerufen?" Allerdings ist die trajectory nützlich, um zu diagnostizieren, warum es scheiterte – nutzen Sie also jede dort, wo sie passt.
Q. Wie fange ich an?
A. Beginnen Sie damit, 20–50 Produktionsfehler in Testfälle zu verwandeln. Wie Anthropic es ausdrückt: "Sie brauchen keine Hunderte; 20–50 einfache Aufgaben aus echten Fehlern sind ein hervorragender Anfang." Bewerten Sie automatisch – Code für das, was Code messen kann, ein LLM-as-judge mit separatem Modell nur für offene Teile – und bauen Sie es in CI ein, um Regressionen zu fangen. Trennen Sie Capability-Evals (worin er gut ist) von Regressions-Evals (Bewahren, was funktionierte), und schreiben Sie Ihre Evals früh.
