Ein Agent ist keine Funktion, die bei gleicher Eingabe denselben Wert zurückgibt. Er wählt seine Schritte selbst, ruft Werkzeuge auf und trifft Entscheidungen, die niemand vorher festgeschrieben hat. Divya Santhanam vom LangSmith-Team bei LangChain hat in einem ausführlichen Beitrag die Fragen gesammelt, die ihm in den vergangenen Jahren am häufigsten gestellt wurden. Die Antworten stehen unten.
Am ehesten lässt sich das mit einem Prüfstand vergleichen. Dort simulieren Ingenieure Kurven, Steigungen und Bremsmanöver, lange bevor ein Fahrzeug im echten Verkehr fährt. Später kommen Testfahrten unter realen Bedingungen dazu, mit Wetter, Stau und Fahrbahnschäden. Für den Vergleich zweier Fahrzeuge greift man auf genormte Strecken zurück, die immer dieselben Bedingungen vorgeben. Dieselben drei Ebenen kennt die Agent Evaluierung: Offline Evals, Online Evals und Benchmarks. Ein einzelner Unit-Test reicht dafür nicht.
Was Agent Evals leisten und warum Unit-Tests zu kurz greifen
In klassischer Software führen gleiche Eingaben zu gleichen Ausgaben, deshalb kann ein Unit-Test auf ein exaktes Ergebnis prüfen. Agenten entziehen sich diesem Muster aus drei Gründen. Erstens variieren die Ausgaben zwischen zwei Läufen, selbst wenn die Anfrage identisch ist. Zweitens kann mehr als eine Antwort richtig sein, ein exakter Abgleich fällt damit als Kriterium weg. Drittens wählt der Agent seine eigenen Schritte, weshalb ein korrektes Ergebnis trotzdem aus einem falschen Weg entstehen kann.
Der dritte Punkt ist der unangenehmste. Ein Agent könnte ein Werkzeug aufrufen, das er gar nicht braucht, oder eine Aktion ausführen, für die er keine Berechtigung hatte. Das Ergebnis sieht auf den ersten Blick gut aus, der Prozess dahinter nicht. Hier setzen Agent Evals an: Sie bewerten einzelne Läufe mit Prüfungen, die diese Streuung einplanen, statt sie als Störung zu behandeln. Eine Prüfung kann sich also auf das Ergebnis beziehen, auf den Weg dorthin oder auf beides.
Was Agent Evals konkret sind, hängt vom Produkt ab. Die passende Sammlung von Prüfungen sieht bei jedem Team anders aus, weil jedes Team etwas anderes optimieren will. Ein Reiseassistent braucht andere Kriterien als ein Coding-Agent oder ein System, das Tickets sortiert. Eine Standardlösung, die man einfach übernimmt, gibt es nicht.
Der Einstieg: ein Verhalten, ein kleines Dataset, eine Baseline
Jede Evaluierung beginnt mit der Frage, was der Agent überhaupt tut. Ein Trace ist die Aufzeichnung eines einzelnen Laufs, mit Eingaben, Ausgaben und jedem Modell- und Werkzeugaufruf dazwischen. Wer eine Stichprobe solcher Traces liest, sieht, wie der Agent Anfragen behandelt und wo er danebengreift. Was auffällt, gibt vor, was zuerst geprüft werden sollte.
Der Aufbau folgt vier Schritten, und Santhanam rät ausdrücklich dazu, klein anzufangen. Zuerst wird ein Verhalten ausgewählt, das wirklich zählt, etwa beim Reiseassistenten die Frage, ob der Agent tatsächlich den gewünschten Zeitraum und die genannte Preisspanne bucht. Danach entsteht ein kleines Dataset aus Traces. Zehn bis zwanzig Beispiele genügen für den Anfang. In LangSmith lassen sich Traces direkt aus der Trace-Ansicht in ein Dataset übernehmen, was den Schritt kurz hält.
Ist der Agent noch nicht im Produktivbetrieb, empfiehlt Santhanam, ihn zunächst im eigenen Team oder mit einer kleinen Gruppe vertrauter Testnutzer laufen zu lassen (Dogfooding) und aus diesen Traces zu arbeiten. Anschließend wird eine Baseline gefahren: Der aktuelle Agent läuft gegen das Dataset, das Ergebnis wird als Experiment gespeichert. Ein Experiment enthält die Resultate einer Agentenversion auf einem Dataset samt den Bewertungen der Evaluatoren. Spätere Versionen werden dagegen gemessen.
Der letzte Schritt trägt am meisten. Jeder Fehler, der in Produktion oder beim Testen auffällt, wird zu einem neuen Beispiel im Dataset. So entsteht ein Kreislauf aus Fehler finden, Beispiel ergänzen, Agent verbessern und erneut auswerten. Mit der Zeit kommen weitere Verhaltensweisen dazu, die nach demselben Muster geprüft werden.
Offline und Online Evals: Prüfstand und Straße
Evaluierungen gehören auf beide Seiten des Auslieferns. Vor einem Release zeigen sie, ob eine Änderung den Agenten besser oder schlechter gemacht hat. Danach zeigen sie, wie er sich mit echten Nutzern schlägt. Das ist der Unterschied zwischen Prüfstand und Straße, und beide haben ihre Berechtigung.
Offline Evals laufen gegen ein Dataset, bevor eine Änderung ausgeliefert wird. Die Beispiel-Eingaben wählt man selbst, erwartete Ausgaben kann man ergänzen. Damit lassen sich Experimente über mehrere Agentenversionen hinweg vergleichen. Sie eignen sich, um neue Prompts, Modelle oder Werkzeuge zu prüfen und Regressionen abzufangen, bevor sie Nutzer erreichen. Auch Benchmarks wie Terminal-Bench sind Offline Evals, nur mit festem Aufgabensatz und eigenem Umfeld.
Online Evals bewerten echte Produktions-Traces, während sie eintreffen. Meist gibt es keine Referenzausgabe zum Vergleich, also stützen sie sich auf Code-Prüfungen und LLM Judges, die einen Lauf für sich bewerten können. Sie testen Agenten in Produktion, beobachten die Qualität und finden die Probleme, die das Dataset übersehen hat. Beide Formen brauchen einander: Was Online Evals als Fehler markieren, wandert als neues Beispiel ins Offline-Dataset.
Ein Dataset aus Traces für Agenten zu erstellen, geht in LangSmith auf mehreren Wegen. Beispiele lassen sich von Hand schreiben, aus vorhandenen Traces übernehmen, aus einer Annotation Queue einsammeln, als CSV oder JSONL hochladen oder aus wenigen vorhandenen Beispielen synthetisch erzeugen. Wächst die Sammlung, stellt sich die Frage, ob ein bestehendes Dataset erweitert oder ein neues angelegt wird. Die Faustregel: gleiches Verhalten mit gleichen Evaluatoren gehört ins selbe Dataset, damit Experimente vergleichbar bleiben. Ein neues Dataset ist sinnvoll, wenn die Eingaben anders aussehen (einzelne Anfragen statt ganzer Gespräche), wenn andere Evaluatoren nötig sind oder wenn der Zweck ein anderer ist, etwa ein kleines Set für jeden Pull Request gegenüber einem größeren vor einem Release. Innerhalb eines Datasets lassen sich Teilmengen über Splits fahren.
Vier Arten von Evaluatoren und worauf sie zielen
Ein Evaluator ist die Logik, die einen Lauf bewertet. Vier Typen haben sich durchgesetzt, und die meisten Teams beginnen mit ein oder zwei davon. Code-Evaluatoren prüfen deterministisch, etwa ob der gebuchte Preis unter dem Budget liegt. Sie sind schnell, günstig und konsistent, brauchen aber eindeutige Ein- und Ausgaben, was ihren Einsatzbereich begrenzt.
LLM-as-a-Judge nutzt ein Modell für alles, was Code nicht erfassen kann, etwa die Frage, ob die Antwort die Flugdaten klar bestätigt. Human Review lässt das Team oder Fachexperten direkt bewerten. Das ist langsamer, liefert aber das beste Signal für subjektive Qualität und dient zugleich als Kontrolle der anderen Evaluatoren. Häufig wird es an einer kleinen Stichprobe eingesetzt, um die Urteile eines LLM Judges zu kalibrieren. Pairwise Evaluatoren schließlich stellen zwei Ausgaben nebeneinander und entscheiden, welche besser ist. Das hilft, wenn man zwischen zwei Prompts oder Modellen wählen muss.
Jeder dieser Evaluatoren kann auf unterschiedliche Teile eines Laufs zeigen. Möglich ist die Bewertung eines einzelnen Schritts, etwa ob die Suchfunktion mit dem richtigen Datum aufgerufen wurde. Möglich ist die abschließende Antwort, etwa ob sie den tatsächlich gebuchten Flug bestätigt. Möglich ist ein ganzes Gespräch, etwa ob die finale Buchung jede Änderung aus mehreren Runden widerspiegelt. Und möglich ist der Endzustand einer Umgebung, also die Buchungsdatensätze in einem simulierten System, nachdem der Agent in seinem eigenen Container gelaufen ist. Diese letzte Variante steckt hinter Benchmarks und wird gelegentlich containerisierte Evaluierung genannt.
Wann ein LLM Judge belastbar wird
Ein LLM Judge kommt dort zum Einsatz, wo Code an Grenzen stößt, etwa bei der Frage, ob eine Antwort durch die abgerufenen Dokumente wirklich gedeckt ist. Solche Judges sind flexibel, aber sie können schwanken und von der Einschätzung des Teams abweichen. Ein paar Gewohnheiten machen sie zuverlässiger.
Die erste: den Judge gegen menschliche Bewertungen prüfen. Jemand aus dem Team bewertet eine Stichprobe von Läufen, und man schaut gezielt nach, wo der Judge widerspricht. Prompt oder Beispiele werden so lange angepasst, bis beide Seiten übereinstimmen. Annotation Queues in LangSmith machen diesen Abgleich überschaubar.
Die zweite Gewohnheit sind enge Fragen. Ob eine Antwort jeden Zwischenstopp erwähnt, ist leichter zu beurteilen als ob eine Antwort gut ist. Die dritte betrifft die Skala. Bestanden oder nicht bestanden, oder eine kleine Menge beschrifteter Kategorien, ist deutlich reproduzierbarer als eine Bewertung von eins bis zehn. Ein Modell hat Mühe, eine sechs von einer sieben zu unterscheiden.
Benchmarks, Container und Harbor: lange Aufgaben mit LangSmith
Ein Benchmark ist eine besondere Form der Offline Evaluierung und besteht aus einer Menge von Aufgaben. Jede Aufgabe enthält Anweisungen, eine Umgebung in einem Container und ein Testskript, das das Ergebnis bewertet. Der Unterschied zu einfachen Judges und Code-Prüfungen liegt im Umfang: Eine einzelne Aufgabe kann Dutzende Werkzeugaufrufe umfassen, in denen der Agent Pakete installiert, Dateien bearbeitet und Befehle ausführt.
Weil Agenten inzwischen Code ausführen und mit Diensten sprechen, bringt jede Aufgabe ihr eigenes isoliertes Umfeld mit. Bewertet wird nicht der Text einer Antwort, sondern der Zustand, den der Agent hinterlässt. Ein Testskript prüft, ob Tests durchlaufen oder ob die richtige Datei existiert. Den Trace kann man zusätzlich lesen, die Punktzahl kommt aber aus den Aktionen und dem Ergebnis. Für den Reiseassistenten könnte eine Aufgabe lauten, dass ein Sturm den Flug nach Denver gestrichen hat, der Reisende umgebucht und das Hotel passend verschoben werden soll. Danach schaut das Testskript in die Buchungsdatensätze.
Harbor ist ein Open-Source-Eval-Harness, das genau diese längeren Aufgaben möglich macht. Es treibt Terminal-Bench an, und dasselbe Aufgabenformat lässt sich für einen eigenen Benchmark verwenden. Über die Integration mit LangSmith wird jeder Harbor-Lauf als Experiment protokolliert. Harbor baut für jede Aufgabe einen Container, und mit LangSmith-Traces lässt sich jede Umgebung näher an das bringen, was der Agent im Produktivbetrieb sieht. Die Ergebnisse stehen dann neben allen anderen Evaluierungen, und jeder Lauf lässt sich mit vollem Trace neben seiner Bewertung öffnen. Das Team nutzte dieses Vorgehen, um Deep Agents auf Terminal-Bench 2.0 zu verbessern, indem es Traces nach Fehlermustern durchsuchte und anschließend das Harness änderte. Auf demselben Weg entstand IssueBench für LangSmith Engine, wo jede Aufgabe dem System einen Stapel Traces übergibt und bewertet, ob die richtigen zu passenden Fehlerclustern gruppiert werden.
Ein eigener Benchmark folgt denselben Schritten wie jede andere Evaluierung. Aufgaben werden aus Traces gesammelt, aus Fehlern abgeleitet und mit Umgebung und Testskript versehen, bis ein Satz entsteht, der sich wiederholt fahren lässt.
Kosten, Fertigbausteine und mehrstufige Gespräche
Online Evals laufen auf Live-Traffic, ihre Kosten wachsen also mit jedem Nutzer. LangSmith begrenzt das über Stichproben und Filter (etwa nur Traces mit negativem Feedback), über günstige Code-Prüfungen und über einen billigeren Richter: In einem Test mit Jev von TypeSafe als Judge traf das Modell jede Bestanden-oder-nicht-Entscheidung wie ein Mensch und kostete insgesamt 0,34 Dollar – gegenüber 28,17 Dollar für Claude Sonnet 4.6.
Man muss Evals nicht von Grund auf selbst bauen: LangSmith bringt vorgefertigte Evaluator-Vorlagen für typische Fälle wie Halluzination oder PII-Lecks mit, dazu das Open-Source-Paket agentevals für Nachrichten und Werkzeugaufrufe. Mehrstufige Gespräche werden über eine Thread-ID gebündelt und als Ganzes bewertet („Spiegelt die finale Buchung jede Änderung wider?“). LangSmith ist framework-agnostisch – es tracet auch Agenten ohne LangChain, LangGraph oder Deep Agents, etwa über das OpenAI Agents SDK, das Claude Agent SDK oder den @traceable-Dekorator. Und für die Berichterstattung vergleicht man Experimente direkt oder baut eigene Dashboards für Tokenkosten, Latenz und Evaluator-Werte über die Zeit.
Der rote Faden des Beitrags ist, klein anzufangen: ein einziges Verhalten, zehn bis zwanzig Beispiele aus echten Traces und ein gespeichertes Experiment als Baseline. Von dort aus wächst die Sammlung von selbst, weil jeder Produktionsfehler ein neues Beispiel liefert. Evaluierung ist kein Tor, durch das ein Agent am Ende hindurchmuss. Sie ist ein Kreislauf, der ihn mit der Zeit verlässlicher macht.
Quelle: langchain.com
