Agent-Observability und Tracing — Spans, Logs und Debugging von KI-Agenten
Ein Agent, der zehn Schritte lang plant, Werkzeuge aufruft und Zwischenergebnisse bewertet, liefert am Ende entweder ein brauchbares Resultat — oder eben nicht. Ohne Einblick in die einzelnen Schritte bleibt dabei unsichtbar, wo es schiefging: falscher Tool-Aufruf, ein zu knapper Prompt, eine Endlosschleife aus Retries, oder schlicht ein teures Modell an der falschen Stelle. Agent-Observability ist die Praxis, genau diesen Ablauf sichtbar zu machen — durch Tracing, das jeden einzelnen Schritt als strukturierten Datensatz festhält, statt nur Anfang und Ende eines Laufs zu kennen.
Traces und Spans: die Grundeinheit der Sichtbarkeit
Ein Trace ist die vollständige Aufzeichnung eines einzelnen Agenten-Laufs, von der ersten Nutzeranfrage bis zur finalen Antwort. Er besteht aus Spans — einzelnen Zeitabschnitten, die je einen Schritt abbilden: ein LLM-Aufruf, ein Tool-Call, eine Retrieval-Abfrage, der Aufruf eines Sub-Agenten. Jeder Span trägt einen Start- und Endzeitpunkt, Input und Output, Metadaten wie das verwendete Modell und Token-Zahlen — und einen Verweis auf seinen Eltern-Span. So entsteht ein verschachtelter Baum, der die tatsächliche Ausführungsstruktur eines Agenten abbildet, nicht nur dessen Text-Ausgabe.
Seit 2024 arbeitet die GenAI-Arbeitsgruppe von OpenTelemetry an standardisierten GenAI Semantic Conventions — einheitliche Attributnamen für genau diese Spans: gen_ai.request.model für das aufgerufene Modell, gen_ai.usage.input_tokens und gen_ai.usage.output_tokens für Token-Zahlen je Aufruf, gen_ai.response.finish_reasons für den Abschlussgrund (etwa stop oder tool_calls). Stand 2026 gilt der Großteil dieser Konventionen noch als experimentell, wird aber bereits von Google Cloud, AWS, Azure, Datadog und den gängigen Agenten-Frameworks unterstützt — ein Trace lässt sich damit zunehmend werkzeugübergreifend lesen, statt an ein einzelnes Tool gebunden zu sein.
Warum Debugging ohne Tracing kaum funktioniert
Ein Agenten-Fehler zeigt sich fast nie an der Stelle, an der er entsteht. Ein LLM wählt im dritten Schritt das falsche Werkzeug, das Ergebnis wird trotzdem an den nächsten Schritt weitergereicht, und erst zwei Schritte später kippt die Antwort spürbar. Ohne Spans sieht man nur: Endergebnis falsch. Mit Tracing lässt sich der exakte Prompt jedes Schritts, die exakten Tool-Argumente, das exakte Tool-Ergebnis und die Latenz jedes einzelnen Spans nachträglich inspizieren — und oft direkt gegen ein anderes Modell oder einen geänderten Prompt erneut abspielen (Replay).
Das wiegt bei Multi-Agent-Systemen doppelt schwer: Fällt eine Aufgabe an einen Sub-Agenten, verzweigt sich die Ausführung, teilweise parallel. Ohne durchgängige Trace-Kontext-Weitergabe (Distributed Tracing) über alle Sub-Agenten hinweg zerfällt der Zusammenhang in lauter isolierte Einzel-Logs, aus denen sich kaum mehr rekonstruieren lässt, welcher Sub-Agent für welchen Teil der finalen Antwort verantwortlich war. Wer beim Bau eines Agenten Tracing von Anfang an mit einplant, spart sich genau diese Rekonstruktionsarbeit später im Störfall.
Kostenkontrolle: sichtbar machen, was ein Lauf wirklich kostet
Ein Agentenlauf ist selten ein einzelner LLM-Aufruf. Planung, Tool-Auswahl, Zwischenbewertung von Ergebnissen und gegebenenfalls mehrere Sub-Agenten-Aufrufe summieren sich schnell auf ein Vielfaches der Kosten einer einzelnen Anfrage — und ohne Aufschlüsselung je Span bleibt unklar, welcher Schritt den größten Anteil trägt. Ein einzelner Agenten-Request mit mehreren Tool-Aufrufen kann bei manchen Observability-Anbietern bereits zehn bis dreißig einzelne Trace-Einheiten erzeugen; genau diese Granularität ist aber nötig, um zu erkennen, ob eine Retry-Schleife, ein zu langer Tool-Output im Kontext oder ein unnötig teures Modell die Rechnung treibt.
Tracing macht diese Kosten pro Span sichtbar und lässt sich mit einem Token-Budget koppeln: Schwellenwerte je Trace, Alarme bei Ausreißern, und die Möglichkeit, gezielt den teuersten Schritt eines Workflows zu optimieren, statt pauschal das gesamte System zu drosseln. Ohne diese Aufschlüsselung bleibt Kostenkontrolle bei Agenten reine Schätzung auf Basis der Monatsrechnung — nachträglich, ungenau und ohne Hebel für die nächste Optimierung.
Logging vs. Tracing — Ergänzung, kein Ersatz
Klassisches Logging schreibt zeitgestempelte Textzeilen oder Events, meist flach und ohne eingebaute Beziehung zueinander. Das reicht für einzelne Fehlermeldungen, scheitert aber an der eigentlichen Struktur eines Agenten: verschachtelte Schritte, parallele Zweige, Wiederholungen. Tracing bildet genau diese Struktur ab — als Baum aus Spans mit Eltern-Kind-Beziehung und Timing. In der Praxis ergänzen sich beide: Der Trace liefert die Form des Ablaufs, einzelne Log-Zeilen oder Events an einem Span liefern die Diagnose-Details innerhalb eines Schritts (etwa eine Warnung, dass ein Tool-Ergebnis leer zurückkam). Ein Agent-Observability-Setup, das nur lose Logs ohne Trace-Struktur sammelt, bleibt bei komplexeren Läufen faktisch blind für den Ablauf selbst.
Werkzeuge im Vergleich: LangSmith, Langfuse, OpenTelemetry
Zwei Plattformen dominieren 2026 den praktischen Einsatz:
- LangSmith ist LangChains kommerzielle Observability-Plattform, historisch eng mit LangChain und LangGraph verzahnt: Node-für-Node-Zustandsvergleiche, vollständige Ausführungsgraphen, eine Aufschlüsselung nach Modell- und Tool-Aufrufen sowie Replay gegen eine andere Modellversion. Über das
langsmith[otel]-Paket lässt sich LangSmith mittlerweile auch außerhalb des LangChain-Ökosystems per OpenTelemetry anbinden. Seit Mai 2026 läuft die US-Cloud-Ingestion über SmithDB, eine eigens entwickelte Rust-Datenschicht. - Langfuse ist Open Source (MIT-Kern), self-hostbar und baut hierarchische Traces aus LLM-Aufrufen, Tool-Invocations, Embeddings und Retrieval-Schritten — unabhängig vom genutzten Framework. Im Januar 2026 wurde Langfuse von ClickHouse übernommen. Die Abrechnung erfolgt pro Einheit (Trace, Observation oder Score), was bei komplexen Agenten-Workflows mit vielen Tool-Aufrufen beachtet werden sollte.
- OpenTelemetry selbst ist kein Produkt, sondern der zunehmend gemeinsame Unterbau: Wer per OTel-Konventionen instrumentiert, kann Traces an mehrere Backends (Langfuse, LangSmith, Datadog, selbstgehostete Lösungen) gleichzeitig oder wechselweise schicken, statt sich früh an ein proprietäres SDK zu binden.
Die Wahl hängt vom Kontext ab: Wer stark in LangChain/LangGraph investiert ist und eine ausgereifte kommerzielle Suite will, ist bei LangSmith gut aufgehoben. Wer Datenhoheit, Self-Hosting oder Framework-Unabhängigkeit priorisiert, greift eher zu Langfuse oder einer OTel-basierten Eigenlösung.
Stolperfallen in der Praxis
- Datenvolumen und Kosten der Observability selbst. Lange Agenten-Läufe mit Dutzenden Tool-Aufrufen erzeugen entsprechend viele Spans — bei nutzungsbasierter Abrechnung wächst die Beobachtungs-Rechnung mit der Komplexität des Agenten mit, nicht nur mit der Nutzerzahl.
- Sensible Daten in Traces. Prompts und Tool-Ergebnisse enthalten häufig personenbezogene oder vertrauliche Inhalte. Ohne Redaction/Masking vor der Speicherung landen diese Daten dauerhaft im Trace-Store — datenschutzrechtlich relevant, sobald echte Nutzerdaten betroffen sind.
- Verwaiste Spans bei paralleler Ausführung. Werden Sub-Agenten parallel gestartet, ohne den Trace-Kontext sauber weiterzureichen, tauchen Spans isoliert statt eingebettet im Gesamt-Trace auf — der Zusammenhang zum auslösenden Schritt geht verloren.
- Tool-Bindung an ein SDK. Wer ausschließlich mit den proprietären Decorators eines einzelnen Anbieters instrumentiert, tauscht Beobachtbarkeit gegen Lock-in. OTel-basierte Instrumentierung hält diese Option offen.
- Tracing erst nachrüsten, wenn es brennt. Wird Observability erst nach dem ersten unerklärlichen Produktionsfehler eingebaut, fehlen genau die Traces, die den Fehler erklärt hätten. Tracing gehört an den Anfang eines Agenten-Projekts, nicht ans Ende.
FAQ
Was ist der Unterschied zwischen einem Trace und einem Span? Ein Trace ist die gesamte Aufzeichnung eines Agenten-Laufs von Anfang bis Ende. Ein Span ist ein einzelner Schritt darin — ein LLM-Aufruf, ein Tool-Call, eine Retrieval-Abfrage — mit eigenem Timing, Input/Output und einem Verweis auf seinen Eltern-Span. Viele Spans zusammen ergeben einen Trace.
Brauche ich Tracing auch für einen einzelnen, simplen Agenten? Bei einem Agenten mit nur einem oder zwei Schritten lässt sich ein Fehler oft noch per Auge im Rohprompt finden. Sobald mehrere Tool-Aufrufe, bedingte Verzweigungen oder Retries hinzukommen, wird die Fehlersuche ohne Tracing schnell zum Raten — der Umstiegspunkt kommt in der Praxis früher als gedacht.
Ist Langfuse oder LangSmith die bessere Wahl? Keins der beiden ist pauschal besser. LangSmith punktet bei tiefer LangChain/LangGraph-Integration und als ausgereifte kommerzielle Suite, Langfuse bei Open-Source-Charakter, Self-Hosting und Framework-Unabhängigkeit. Beide unterstützen mittlerweile OpenTelemetry-basierte Instrumentierung.
Ersetzt Tracing klassisches Logging? Nein. Tracing bildet die Struktur eines Laufs ab (welcher Schritt gehört zu welchem übergeordneten Schritt, wie lange hat er gedauert). Logs und Events liefern die Diagnose-Details innerhalb eines einzelnen Schritts. Beides zusammen ergibt vollständige Beobachtbarkeit.
Verursacht Tracing selbst spürbaren Overhead? Der reine Aufzeichnungs-Overhead pro Span ist meist gering. Spürbar wird es eher bei sehr hohem Trace-Volumen oder wenn komplette Prompt-/Antwort-Inhalte unkomprimiert mitgeloggt werden — hier lohnt sich Sampling oder selektives Logging von Payload-Inhalten.