Agent Skills aus Traces systematisch evaluieren

Ein Agent Skill kann sauber dokumentiert sein und trotzdem im entscheidenden Moment versagen. Der Agent übersieht die Anweisung, erfindet einen Befehl oder erreicht ein plausibles Ergebnis über einen unzulässigen Weg. Wer nur die Endantwort prüft, erklärt einen solchen Lauf womöglich zum Erfolg.

Traces schließen diese Lücke. Sie zeigen nicht bloß, was der Agent geantwortet hat, sondern wie er dorthin kam: Welche Werkzeuge wurden aufgerufen, in welcher Reihenfolge, und an welcher Stelle griff eine Anweisung nicht? Aus dem Bauchgefühl „der Skill wirkt besser“ wird so eine überprüfbare Aussage.

Der Trace wird zum Regressionstest

Laut LangChain-Dokumentation lassen sich in LangSmith aufgezeichnete Läufe in Evaluationsdatensätze überführen, getrennt nach finalen Antworten, einzelnen Schritten, vollständigen Trajektorien und RAG-Fällen. Eine Trajektorie bildet den Weg des Agenten durch seine Aktionen ab. Sie wird entscheidend, wenn neben dem Ergebnis auch Werkzeugwahl und Reihenfolge stimmen müssen.

Der praktische Gewinn beginnt bei einem echten Fehler. Ein Agent soll etwa ein vorhandenes Werkzeug verwenden, ruft stattdessen aber eine erfundene Aktion auf. Erwartet war ein definierter Tool-Call, im Trace steht ein nicht erlaubter Name. Dieser Lauf gehört mit Prompt, relevanten Trace-Schritten und einer klaren Erwartung in den Datensatz. Nach der nächsten Änderung am Skill läuft derselbe Fall erneut und besteht nur, wenn auch der erlaubte Pfad eingehalten wird.

Die Dokumentation unterscheidet codebasierte Evaluatoren und LLM-as-a-Judge. Beide lassen sich offline an Datensätze oder online an Projekte hängen. Für eindeutige Bedingungen reicht Code: Wurde das vorgesehene Werkzeug aufgerufen, ist ein Pflichtfeld vorhanden, traten nur erlaubte Aktionen auf? Fachliche Vollständigkeit braucht eher einen Modellbewerter, dessen Spielraum feste Kriterien und Beispiele begrenzen.

Zwei Fehler, zwei Reparaturen

In Traces tauchen häufig zwei grundverschiedene Fehlerbilder auf. Beim ersten wird der Skill aktiviert, doch der Agent ergänzt fehlende Angaben eigenmächtig oder erfindet Parameter. Beim zweiten bleibt die Aktivierung ganz aus: Eine zu abstrakte Beschreibung führt den Agenten zu einem anderen Werkzeug oder in lokale Logs, obwohl der Skill zuständig wäre.

Beide Fälle brauchen unterschiedliche Reparaturen. Erfundenes Werkzeugverhalten deutet auf unscharfe Grenzen, fehlende Pflichtangaben oder unzureichende Referenzen hin. Eine ausgelassene Aktivierung spricht eher für eine unklare Beschreibung des Einsatzbereichs. Daraus folgt eine Prüfregel, die oft fehlt: Die Beschreibung eines Skills ist kein Begleittext. Sie gehört in denselben Testumfang wie seine Anweisungen. Eine Diagnose wie „schlechte Antwort“ ist dafür zu grob.

Ein kleiner Eval-Zyklus reicht für den Start

Fünf bis zehn Aufgaben genügen als Startdatensatz. Eine Aufgabe sollte den Skill eindeutig verlangen, eine zweite denselben Bedarf mehrdeutig formulieren und eine dritte einen nicht vorhandenen Befehl provozieren. Dazu kommt mindestens ein Fall, den der Agent bewusst ohne diesen Skill lösen soll.

Die Auswertung sollte vier Ebenen trennen:

• Aktivierung: Verwendet der Agent den Skill bei den vorgesehenen Aufgaben?
• Ablauf: Bleiben Werkzeugwahl und Aktionsfolge innerhalb der erlaubten Grenzen?
• Ergebnis: Ist die Antwort fachlich korrekt und vollständig?
• Robustheit: Bleibt das Verhalten bei ähnlich formulierten Aufgaben stabil?

Jeder fehlgeschlagene Fall braucht Expected und Actual, den auslösenden Prompt, die relevanten Tool-Calls und die Stelle, an der der Lauf abwich. Lässt sich ein Fehler nicht reproduzieren, gilt er nicht stillschweigend als behoben, sondern bleibt als instabiler Fall markiert.

Aktivierung und Ablauf lassen sich direkt aus den Traces ablesen. Robustheit verlangt Wiederholungen. Eine einzelne gelungene Demo sagt wenig über Stabilität.

Fazit: Produktionsfehler werden zu Testfällen

Ein Eval-System rettet keine unklare Skill-Definition. Es zeigt aber, ob deren Anweisungen zur Laufzeit wirken und ob eine Reparatur am richtigen Fehler ansetzt. Auch ein fehlerfreier Lauf ist nicht automatisch effizient: Zusätzliche Sicherheitsprüfungen können Fehlversuche verhindern und zugleich die Zahl der Aktionen erhöhen. Deshalb gehören neben der Erfolgsquote auch Laufzeit, Tool-Aufrufe und unnötige Wiederholungen in die Auswertung.

Die Mindestregel lautet: Jeder bestätigte Produktionsfehler wird zu einem reproduzierbaren Testfall. Eine Änderung zählt erst als Fortschritt, wenn mehrere vergleichbare Läufe weniger erfundene Aktionen, weniger ausgelassene Skills und weniger falsche Werkzeugfolgen zeigen, nicht nur schönere Endantworten.