Skip to main content
Wenn Sie nachvollziehen wollen, warum ein Agent geantwortet hat, wie er geantwortet hat, wo die Latenz einer Anfrage herkommt oder was ein einzelner Run gekostet hat, finden Sie die Antwort in den Langfuse-Traces. Diese Seite zeigt, wie Sie die Traces lesen und filtern — Voraussetzung ist eine eingerichtete Anbindung, siehe Langfuse anbinden. Die eingebauten Ansichten zu Nutzung und Systemzustand (Analytik, Audit-Logs, System-Info) sind davon unabhängig und unter Observability beschrieben.

​
Was getraced wird

Bei Agents (Chat) erfasst Langfuse den kompletten Agent-Run: jeden Modell-Aufruf, jeden Tool-Aufruf und delegierte Sub-Agents — verschachtelt in der Reihenfolge, in der sie ausgeführt wurden. Auch die Apps, die das Modell direkt und ohne Agent aufrufen, werden getraced: Dokumenten-Analyse, Dokumenten-Vergleich, Dokumenten-Extraktion, Transkription, die Prompt-Verbesserung und Guardrail-Prüfungen von Widget-Konversationen.

​
Trace-Namen-Referenz

Der Trace-Name sagt Ihnen, welcher Teil des Produkts einen Trace erzeugt hat — er ist Ihr primärer Filter in der Trace-Liste (Tracing → Traces).

​
chat-turn lesen — das wichtigste Debug-Objekt

Wenn Sie Agent-Verhalten debuggen, beginnen Sie beim chat-turn. Ein chat-turn entspricht einer User-Nachricht plus allem, was das System getan hat, um sie zu beantworten. Öffnen Sie den Trace, zeigt die Timeline die gesamte Kette von oben nach unten:
Damit beantworten Sie die vier Fragen, die in der Praxis am häufigsten auftauchen:
  • Warum hat der Agent das gesagt? Der Input des letzten Modell-Aufrufs zeigt den exakten System-Prompt und Verlauf, mit dem das Modell gearbeitet hat.
  • Warum hat er das Tool nicht benutzt? Der Tool-Span fehlt dann schlicht — und der Modell-Aufruf davor zeigt, was das Modell stattdessen entschieden hat.
  • Warum war die Antwort langsam? Jeder Span hat seine eigene Dauer; der langsame sticht heraus.
  • Warum war der Run teuer? Token-Zahlen stehen an jedem Aufruf und sind auf dem Trace summiert.
Einzelne Modell-Aufrufe isoliert betrachtet reichen selten — die Kette innerhalb des chat-turn ist die Diagnose.

​
Sessions — zusammengehörige Traces

Sessions bündeln mehrere Traces, die zusammengehören. Statt Traces einzeln anzuklicken, öffnen Sie eine Session und sehen den gesamten Ablauf in Reihenfolge.
  • Chat: Die Session-ID ist die Conversation-ID. Jede Runde derselben Konversation landet in einer Session — Sie spielen die ganze Konversation nach, so wie sie stattgefunden hat.
  • Dokumenten-Analyse und -Vergleich: Die Session-ID ist die Job-ID. Diese Apps rufen das Modell einmal pro Frage und Seite auf — ein 50-Seiten-Job wäre sonst hunderte lose Traces in der Liste; als Session ist er ein einziges Objekt.
Die übrigen Operationen sind One-Shot und setzen keine Session — ihre Traces stehen für sich.

​
Tags und Attribution

Jeder Trace ist getaggt, damit Sie die Liste eingrenzen können: Tags, deren Wert nicht auflösbar ist, werden weggelassen statt als None geschrieben. Ein fehlender provider-Tag bei self-hosted-Modellen hinter einem Proxy-Alias ist deshalb erwartet — kein Fehler. Zusätzlich trägt jeder Trace drei Attributionsfelder:
  • User — wer den Run ausgelöst hat. Widget-Konversationen sind by design anonym und tragen keinen User.
  • Environment — trennt z. B. dev und prod im selben Langfuse-Projekt.
  • Release — die Localmind-Version, mit der Sie Verhalten über Versionen hinweg vergleichen.
Ist die Maskierung aktiv, sehen Sie Prompts und Completions als redigierte Platzhalter — Struktur, Token-Zahlen und Kosten bleiben vollständig erhalten.