Tracely: fehlgeschlagene Agentenläufe werden zu Regressionstests

Warum ein Trace kein Dashboard-Eintrag bleiben sollte

Der Auslöser ist ein wiederkehrendes Muster im Agentenbetrieb: Ein Lauf schlägt in Produktion fehl, die Ursache wird im Dashboard sichtbar, und danach passiert nichts Strukturelles. Das README formuliert die Lücke als Frage: Beobachtbarkeit endet an der Oberfläche, und dann? Tracely setzt an dieser Stelle an und behandelt den aufgezeichneten Lauf selbst als Testfall. Statt Fragen und Wunschantworten von Hand zu erfinden, wird der exakt fehlgeschlagene Lauf mit Eingabe, Tool-Aufrufen und Modellantworten eingefroren. Zielgruppe sind Teams, die Agentsysteme betreiben und bereits Traces erzeugen, aber keine gepflegten Evaluationsdatensätze besitzen. Das ist eine engere Zielgruppe als der Begriff Agentenobservability vermuten lässt. Wer nur Dashboards braucht, bekommt hier einen zusätzlichen Betriebsteil: Worker, Objektspeicher und eine Spalten-Datenbank.

OTLP hinein, Spalten heraus

Die Aufnahme läuft laut Dokumentation über einfaches OTLP. Der interessante Teil ist die Ablage: Agentensemantik wird zu indizierten Spalten erhoben. Genannt werden agent.id, conversation.id, turn und step. Dadurch lassen sich Läufe zu Gesprächsverläufen gruppieren statt als flache Spansammlung. Die Wasserfallansicht zeigt die Kette agent, thinking, skill, generation und Hand-off, der fehlerhafte Span wird rot markiert und mit seinen Ein- und Ausgaben daneben dargestellt. Evaluatoren sind Spalten der Trace-Tabelle, keine separate Ansicht, und schreiben ihr Urteil direkt in das Raster. Bewertungen kommen live per SSE herein, während die Judges fertig werden. Diese Entscheidung für Spalten statt separater Bewertungsseite ist der eigentliche architektonische Griff: Bewertung wird Teil des Datenmodells und nicht ein nachgelagerter Bericht.

Fehler werden gruppiert, nicht gelesen

Online-Evaluatoren bewerten jeden Lauf beim Eintreffen, laut README als LLM-as-Judge auf Gesprächs-, Lauf- oder Span-Ebene, ergänzt um strukturelle Prüfungen, die kein Modell benötigen. Fehlschläge werden anschließend strukturell und semantisch geclustert. Das README nennt das Beispiel, dass 31 kaputte Läufe zu einem Issue mit Zähler werden statt zu 31 Zeilen. Jeder Cluster kann den Evaluator vorschlagen, der ihn erkannt hätte. Das ist der Übergang von Beobachtung zu Arbeit: Ein Cluster ist adressierbar, eine Liste einzelner Fehlläufe nicht. Die Einschränkung steckt im Verfahren selbst. Clustering ist eine Heuristik, und das Material sagt nicht, nach welchen Kriterien gruppiert wird oder wie mit Grenzfällen umgegangen wird. Bei seltenen, aber schweren Fehlern kann ein Cluster mit Zähler 1 leicht übersehen werden.

Der Fail-to-Pass-Vertrag als Vertrauensgrenze

Ein Klick macht aus einem fehlerhaften Trace einen hermetischen Fall: aufgezeichnete Eingabe sowie Tool- und LLM-Ausgaben liegen als Fixtures gebündelt vor. Dazu kommt ein Fail-to-Pass-Vertrag. Der Fall muss auf dem alten Code scheitern und auf der Korrektur bestehen, sonst gilt die Übernahme als nicht vertrauenswürdig. Das ist die stärkste Idee im Projekt, weil sie das offensichtliche Problem eingefrorener Traces adressiert: Ein Test, der immer besteht, beweist nichts. Für mehrstufiges Verhalten gibt es Szenarien, entweder ein geskriptetes Gespräch oder ein gegnerisches Ziel, das ein Red-Team-Modell improvisiert. Der Preis für diese Strenge ist Reibung. Wer einen Fehler promoten will, dessen Fix noch nicht existiert, kann den Vertrag nicht erfüllen. Tracely belohnt damit einen Arbeitsablauf, in dem der Fix bereits vorhanden oder zumindest klar umrissen ist.

Der Gate-Lauf kostet kein Geld, aber Determinismus

Im CI spielt die Suite gegen aufgezeichnete Fixtures ab: deterministisch, offline, ohne API-Schlüssel und ohne Modellkosten. Das README beschreibt tracely gate so, dass der Befehl mit einem Exit-Code ungleich null endet, einen Commit-Status setzt und einen PR-Kommentar aktualisiert. Die Aussage, dass ein Replay 0 Dollar kostet, gilt für genau diese Fixture-Wiedergabe und nicht für die Online-Bewertung in Produktion, die sehr wohl Modellaufrufe erzeugt. Der zweite Punkt ist Determinismus als Nebeneffekt der Aufzeichnung. Sobald sich das Verhalten eines Tools oder eines Modells ändert, prüft der eingefrorene Fall nicht mehr die Realität, sondern den Stand vom Zeitpunkt der Aufzeichnung. Das Material beschreibt diesen Alterungsprozess nicht und nennt keinen Mechanismus, um Fälle regelmäßig neu aufzunehmen. Wer den Ansatz wählt, übernimmt diese Pflege selbst.

Installation und der Betriebsteil, den man mitbekommt

Der Python-Anteil ist über PyPI als tracely-ai verfügbar und setzt Python 3.10 oder neuer voraus. Für den vollständigen Betrieb nennt das README API, Worker, UI, Postgres, ClickHouse, Redis und MinIO. Ein Ein-Klick-Deployment auf Railway wird verlinkt, die Lizenz ist MIT. Das ist mehr Infrastruktur als bei einer reinen Bibliothek, und das sollte man vor der Evaluierung einplanen: ClickHouse für Spaltenabfragen, MinIO für die Fixtures, Redis für den Worker. Zur Wartung liefert das Material wenig Konkretes. Es gibt keine abgerufenen Releases, und die Aktualisierung von Fällen, Evaluatoren und Clustern wird nicht als Prozess beschrieben. Die MIT-Lizenz erlaubt Weitergabe und Änderung, verlangt aber die Beibehaltung des Urheberrechtshinweises und des Lizenztextes. Das ist eine technische Einordnung, keine Rechtsberatung; wer den Dienst kommerziell anbietet, muss die Weitergabepflichten selbst prüfen.

Datensatz zuerst oder Trace zuerst

Die naheliegende Alternative ist der datensatzgetriebene Ansatz, wie ihn Evaluationswerkzeuge üblicherweise verfolgen: Ein Team verfasst Fragen und ideale Antworten und hält diesen Datensatz aktuell. Der Unterschied liegt nicht im Umfang, sondern in der Herkunft der Fälle. Ein handgeschriebener Datensatz ist eine Vermutung darüber, was brechen könnte. Ein promoteter Trace ist der Nachweis, dass etwas gebrochen ist, samt der exakten Eingabe. Dafür hat der Datensatzansatz einen Vorteil, den Tracely nicht ersetzt: Er kann Verhalten abdecken, das in Produktion noch nie aufgetreten ist, etwa neue Fähigkeiten oder Missbrauchsszenarien. Tracelys Antwort darauf sind Szenarien mit geskriptetem Gespräch oder improvisiertem Red-Team-Ziel, doch das ist eine Ergänzung, kein Ersatz für kuratierte Abdeckung. Ein weiterer Unterschied: Tracely blockiert den Pull Request, während datensatzgetriebene Werkzeuge typischerweise eine Zahl in einem Dashboard bewegen. Diese Durchsetzung ist der Kern des Produkts und zugleich der Grund, weshalb ein fehlerhaft konfigurierter Evaluator den Entwicklungsfluss direkt anhält.

Redaktionelles Fazit

Tracely passt zu Teams, die Agenten bereits im Produktivbetrieb haben, OTLP senden können und wiederkehrende Fehler nicht länger von Hand in Testdatensätze übertragen wollen. Wer noch keine Traces sammelt oder Agentsysteme mit strikten Datenresidenz-Anforderungen betreibt, sollte zuerst die eigene Trace-Pipeline und die Rechtslage prüfen. Vor dem Rollout: prüfen, ob der eigene Agentenspan die Attribute agent.id, conversation.id, turn und step trägt, denn ohne sie bleiben die Ansichten flach; ob der Trace-Export auf einen selbst gehosteten OTLP-Endpunkt zeigt; und ob ein Self-Hosting-Ziel für API, Worker, UI, Postgres, ClickHouse, Redis und MinIO vorhanden ist. Der Gate-Befehl tracely gate gehört in eine eigene CI-Stufe, deren Exit-Code den Merge blockiert.

Offizielle Quellen

1. Issues
2. Jwuthri/Tracely-ai on GitHub
3. License: MIT
4. Project website
5. README