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, hält einen solchen Lauf leicht für erfolgreich.

Genau deshalb gehören Traces in die Evaluation. LangSmith und Langfuse zeigen, wie sich Agentenläufe aufzeichnen, auffällige Abläufe als Testfälle sichern und nach einer Änderung erneut ausführen lassen. Aus dem Bauchgefühl „der Skill wirkt besser“ wird damit eine Aussage, die sich prüfen lässt.

Der Trace wird zum Regressionstest

In LangSmith lassen sich Traces für unterschiedliche Aufgabentypen in Evaluationsdatensätze überführen. Erfasst werden können finale Antworten, einzelne Schritte, vollständige Trajektorien und RAG-Fälle. Eine Trajektorie bildet den Weg des Agenten durch seine Aktionen ab. Das zählt, sobald nicht allein das Ergebnis, sondern auch Werkzeugwahl und Reihenfolge korrekt sein müssen.

Der praktische Gewinn zeigt sich bei einem echten Fehler. Das Team protokolliert den Vorfall nicht bloß, sondern übernimmt den Lauf in einen Datensatz und ergänzt eine prüfbare Erwartung. Nach der nächsten Änderung am Skill läuft derselbe Fall erneut. Jeder bestätigte Fehler erweitert so die Regression-Suite.

Für eindeutige Bedingungen eignen sich codebasierte Evaluatoren: Wurde das vorgesehene Werkzeug aufgerufen? Ist ein Pflichtfeld vorhanden? Sind ausschließlich erlaubte Aktionen aufgetreten? Fachliche Vollständigkeit oder Verständlichkeit können zusätzlich einen Modellbewerter benötigen. Sein Spielraum sollte durch feste Kriterien und nachvollziehbare Beispiele begrenzt bleiben.

Zwei Fehler, zwei Reparaturen

Ein von Langfuse dokumentierter Praxistest arbeitete mit gespeicherten Nutzer-Prompts, gestarteten Coding-Agenten und aufgezeichneten Abläufen. Dieselben Aufgaben wurden nach Änderungen am Skill erneut ausgeführt. Dabei traten zwei Fehlerklassen hervor: Manche Agenten erfanden nicht vorhandene CLI-Ressourcen oder Aktionen, andere verwendeten den vorgesehenen Skill gar nicht.

Beide Fälle können eine überzeugende Endantwort hervorbringen, verlangen aber unterschiedliche Reparaturen. Ein erfundener Befehl deutet auf unscharfe Werkzeuggrenzen, mangelhafte Referenzen oder eine fehlende Prüfung erlaubter Aktionen hin. Ein ausgelassener Skill spricht eher für eine unklare Aktivierungsbedingung. Die pauschale Diagnose „schlechte Antwort“ hilft hier wenig und lenkt die Arbeit womöglich an die falsche Stelle.

Für mich ist das der wichtigste Grund, Traces in Skill-Evals einzubeziehen: Sie zeigen, welche Fähigkeit tatsächlich versagt hat. Die Endantwort allein verrät das häufig nicht.

Ein kleiner Eval-Zyklus reicht für den Start

Für den Einstieg genügt ein überschaubarer Ablauf. Zuerst braucht es Aufgaben, bei denen der Skill eine erkennbare Rolle spielt. Dann werden die Läufe einschließlich der Werkzeugaufrufe erfasst. Auffällige Traces wandern als feste Fälle in einen Datensatz und erhalten wenige klare Kriterien. Nach jeder relevanten Änderung wird derselbe Satz erneut ausgeführt.

Als redaktionelle Faustregel würde ich mit fünf bis zehn Aufgaben und unterschiedlichen Auslösern beginnen. Eine Aufgabe sollte den Skill eindeutig verlangen. Eine zweite formuliert denselben Bedarf mehrdeutig. Eine dritte provoziert einen nicht vorhandenen Befehl. Hinzu kommt mindestens ein Fall, den der Agent bewusst ohne diesen Skill lösen soll. So zeigt der Datensatz, ob der Skill im passenden Moment greift und in unpassenden Situationen still bleibt.

Die Auswertung sollte vier Ebenen auseinanderhalten:

• 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?

Aktivierung und Ablauf sind direkt in den Traces sichtbar. Für das Ergebnis eignen sich je nach Aufgabe feste Regeln, Referenzantworten oder ein eng geführter Modellbewerter. Robustheit verlangt mehrere Läufe; eine einzelne gelungene Demo liefert dafür keine belastbare Aussage.

Fazit: Jeder Produktionsfehler wird zum Testfall

Ein Eval-System kann eine unklare Skill-Definition nicht retten. Es zeigt aber, ob deren Anweisungen zur Laufzeit die gewünschte Wirkung entfalten. Traces, Datensätze und Evaluatoren liefern dafür das Gerüst; konkrete Fehlerszenen zeigen, wo eine Reparatur ansetzen muss.

Meine Mindestregel ist deshalb einfach: Jeder bestätigte Produktionsfehler wird zu einem reproduzierbaren Testfall. Dazu kommen wenige Kriterien, die Aktivierung, Ablauf und Ergebnis getrennt bewerten. Eine Änderung gilt erst dann als Fortschritt, wenn sie über mehrere vergleichbare Läufe weniger erfundene Aktionen, ausgelassene Skills und falsche Werkzeugfolgen erzeugt.