Agent Tracing

Agent Tracing bezeichnet die strukturierte Aufzeichnung eines KI-Agenten-Laufs als Span-Baum (ein Ablaufprotokoll aus einzelnen Arbeitsschritten in Eltern-Kind-Beziehung). Jeder Schritt wird als eigener Span erfasst: der Modellaufruf an ein Large Language Model (LLM), der Aufruf eines externen Werkzeugs (Tool-Call), ein Nachschlage-Schritt in einer Wissensquelle (Retrieval) sowie untergeordnete Agenten. Zu jedem Schritt gehören Zeitstempel, Ein- und Ausgaben und ein Erfolgs- oder Fehlerstatus. Diese Aufzeichnungen (Traces) sind die Rohdaten für Diagnose, Kostenanalyse und Qualitätsauswertung eines Agent-Betriebs.

Was ist Agent Tracing?

Agent Tracing entsteht aus einem konkreten Betriebsproblem. Ein KI-Agent führt pro Anfrage eine variable Kette aus Modellaufrufen (LLM-Calls), dem Aufruf externer Werkzeuge (etwa eine CRM-Abfrage) und dem Nachschlagen in einer Wissensquelle (Retrieval) aus; teils delegiert er Teil-Aufgaben an untergeordnete Agenten. Ohne strukturierte Aufzeichnung bleibt der Ablauf eine Blackbox (ein System, dessen Innenleben von außen nicht sichtbar ist): Der Vorfall im Support-Ticket ist nicht rekonstruierbar, die Kosten pro Modell-Aufruf (gemessen in Tokens, den Textbausteinen, in denen LLMs abrechnen) sind keiner Anwendungs-Schnittstelle zurechenbar, und ein Ausschlag in der Antwortzeit hat keine Verbindung zum konkreten Aufruf, der ihn ausgelöst hat.

Die Mechanik übernimmt das Modell aus dem Distributed Tracing der Cloud-native-Welt und erweitert es um LLM-Semantik. Die Instrumentierung erzeugt pro Anfrage einen Root-Span (typisch agent.run) und darunter Child-Spans für jeden Schritt: llm.call für einen Modellaufruf, tool.call für einen Werkzeugaufruf, retrieval.call für einen Retrieval-Schritt in einem RAG-Setup. Sub-Agenten hängen als eigener Sub-Tree unter dem Root-Span. Jeder Span trägt Attribute (Modellname, Prompt, Response, Token-Verbrauch, Tool-Argumente, Latenz, Fehlerstatus) und ist über die Trace-ID mit dem Rest des Laufs verbunden.

Der Standard für diese Attribute hat sich 2026 stabilisiert. Die [OpenTelemetry GenAI Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/) definieren Attribute wie gen_ai.request.model, gen_ai.usage.input_tokens und gen_ai.usage.output_tokens. [OpenInference](https://github.com/Arize-ai/openinference) ergänzt das Vokabular um Agent-, Tool- und Retrieval-Spans und ist mit OpenTelemetry kompatibel. Die Trace-ID propagiert über [W3C Trace Context](https://www.w3.org/TR/trace-context/) zwischen Framework-Grenzen (LangGraph, OpenAI Agents SDK, eigener Code und MCP-Server) und hält den kompletten Lauf in einer gemeinsamen Trace zusammen. Auf diesem Fundament setzen die etablierten Backend-Plattformen auf: Langfuse, LangSmith, Arize Phoenix, Datadog LLM Observability, Braintrust, Helicone und Laminar.

Abgrenzung zu Observability, Evaluation und klassischem Tracing

Agent Tracing wird häufig mit angrenzenden Disziplinen gleichgesetzt. Die Begriffe messen unterschiedliche Dinge und sitzen an unterschiedlichen Stellen im Betriebs-Stack.

Tracing liefert die Rohdaten, Observability baut das Signal-Modell darüber. Ein Trace-Backend zeigt einzelne Läufe; eine Observability-Plattform aggregiert Metriken pro Endpoint, hält SLOs und weckt on-call bei Ausschlägen. Evaluation trifft ein Qualitätsurteil gegen ein Dataset und speist ihr Ergebnis als Quality-Signal in die Observability-Sicht ein; Traces sind eine Datenquelle für Online-Evaluation, ersetzen die Evaluation aber nicht. Klassisches Distributed Tracing beherrscht die Span-Mechanik, kennt jedoch weder den Begriff Token noch das Konzept einer Tool-Trajectory. Logging erfasst einzelne Ereignisse ohne Eltern-Kind-Struktur; ein Log-Eintrag kennt seine Position in der Aufruf-Kette nicht, ein Span kennt sie.

Beispiel: Multi-Agent-Support-System mit LangGraph und MCP

Ein produktives Support-System aus einem LangGraph-Orchestrator, drei Sub-Agenten und einem MCP-Server für CRM-Zugriff instrumentiert seine Aufrufe über die OpenTelemetry GenAI Conventions. Jede Kundenanfrage erzeugt einen Root-Span agent.run mit Child-Spans für llm.call (Modellname, Prompt-Länge, Token-Verbrauch), tool.call (Tool-Name, Argumente, Antwort, Fehlerstatus) und retrieval.call (Query, Anzahl Chunks, Scoring). Die Sub-Agenten hängen als Sub-Trees unter dem Root-Span, die Trace-ID propagiert über W3C Trace Context zwischen dem LangGraph-Prozess, dem eigenen Orchestrator-Code und dem MCP-Server.

Bei einem Vorfall (ein Kunde erhält eine falsche Bestellnummer im Antwort-Text) zeigt die Trace in Langfuse den kompletten Pfad: den Root-Span mit Ein- und Ausgabe, den halluzinierten tool.call mit dem konkreten Argument-Diff zwischen erwartet und tatsächlich übergeben, den Token-Verbrauch verteilt auf die Sub-Agenten und die Latenz jedes Schritts. Die drei Fragen des Debuggings (wo entstand der Fehler, mit welchen Argumenten, was hat der Lauf gekostet) sind in einer Sicht beantwortet, ohne dass Log-Zeilen aus drei Systemen korreliert werden müssen.