Wir bekamen einen Anruf von einem Kunden aus der Logistik: Ein Agent, der Transportbuchungen automatisieren sollte, wählte wiederholt den teureren Spediteur statt des günstigeren. Der Preisunterschied war sichtbar — die Ursache nicht. Die Logs zeigten Eingaben und Ausgaben. Sie zeigten nicht, warum der Agent in einem bestimmten Schritt ein Tool mit genau den Parametern aufrief, die er aufrief. Es dauerte vier Stunden, bis wir die Entscheidungssequenz aus rohen Logs rekonstruiert hatten. Das Problem ließ sich in fünfzehn Minuten beheben — aber nur, wenn man wusste, wo man suchen musste.
Das ist ein Problem, das sich bei den meisten ersten Produktionsdeployments von Agenten wiederholt. Teams wissen, wie man einen Agenten baut und startet — aber nicht, wie man ihn debuggt. Observability — die Fähigkeit, den internen Zustand eines Systems aus seinen externen Ausgaben zu verstehen — ist für Agenten kein Luxus. Sie ist die Voraussetzung dafür, dass Sie das System warten und verbessern können.
Eval vs. Observability: zwei verschiedene Dinge
Bevor wir zu Tools und Ansätzen kommen, ist es wichtig, zwei Dinge zu unterscheiden, die häufig verwechselt werden.
Eval (Evaluierung) beantwortet die Frage: *Ist die Qualität der Ausgabe des Agenten ausreichend?* Sie wird offline oder auf historischen Daten gemessen — zum Beispiel: Hatte der Agent in 87 % der Fälle recht? Hat er das richtige Format generiert? Hat er die Fragen korrekt beantwortet?
Observability beantwortet die Frage: *Was genau ist während eines bestimmten Laufs passiert?* Sie wird zur Laufzeit gemessen — während der Agent läuft oder nachdem ein Lauf abgeschlossen ist — und erfasst die Abfolge von Entscheidungen, Tool-Aufrufen, Zwischenzuständen und Fehlern.
Eval ist retrospektive Statistik. Observability ist ein chirurgisches Instrument für einen konkreten Vorfall. Beide werden gebraucht — sie ersetzen einander nicht.
Die meisten Teams starten mit Eval und ignorieren Observability. In der Praxis funktioniert das bis zum ersten Produktionsvorfall. Danach kehren sich die Prioritäten um.
Was Sie erfassen müssen
Ein Agent ist keine einzelne Funktion. Er ist ein Netz von Schritten — jeder Schritt hat eine Eingabe, eine Ausgabe, einen LLM-Prompt, eine Entscheidung und gegebenenfalls einen Fehler. Für jeden Lauf des Agenten müssen Sie folgendes sehen können:
- Trace: der vollständige Aufrufbaum vom Eingabe-Prompt bis zur finalen Antwort, einschließlich aller Teilbäume
- Spans: die einzelnen Schritte innerhalb eines Trace — jeder LLM-Call, jeder Tool-Aufruf, jeder Retrieval-Schritt
- State diff: was sich im internen Zustand des Agenten zwischen den Schritten geändert hat (besonders wichtig bei
LangGraph) - Tool calls: die genauen Parameter jedes Tool-Aufrufs und die genaue Ausgabe, die das Tool zurückgegeben hat
- LLM-Prompts: welcher Prompt tatsächlich an das Modell gesendet wurde (nicht die Vorlage — der finale Text nach der Interpolation)
- Tokens und Latenz: Token-Anzahl pro Span, Zeit pro Span — zur Identifikation von Engpässen
- Fehler und Retries: wo der Agent versagt hat, wie oft er es wiederholt hat und mit welchem Ergebnis
Jedes dieser Elemente ist unverzichtbar. Wenn Sie nur die Ausgabe des letzten Schritts erfassen, haben Sie ein Anwendungslog — keine Observability für Agenten.
Warum klassisches Logging nicht ausreicht
Wenn Entwickler zum ersten Mal von „Observability" hören, lautet die häufigste Antwort: „Aber wir loggen doch." Sie loggen — nur nicht auf die richtige Art für Agenten.
Ein klassisches Log ist sequenziell. Eintrag für Eintrag, Timestamp, Meldung. Für eine einfache API reicht das. Für einen Agenten, bei dem eine einzelne Nutzereingabe Dutzende LLM-Aufrufe, Tool-Aufrufe und Retrieval-Schritte auslöst — in einem Baum, nicht in einer Sequenz — ist ein flaches Log unbrauchbar. Es fehlt Kontext, Hierarchie und der Zustand zu einem bestimmten Zeitpunkt.
Ein weiteres Problem: Agenten-Frameworks wie LangGraph internalisieren viele Entscheidungen. Welcher Node ausgewählt wurde, warum eine bestimmte Edge aktiviert wurde, wie der Zustand am Checkpoint war — das ist aus einem gewöhnlichen stdout-Log nicht erkennbar. Sie brauchen eine direkte Integration mit dem Framework, keinen Wrapper darum herum.
Das dritte Problem sind Sampling und Kosten. Ein Produktionsagent kann täglich Tausende von Läufen ausführen. Alles in strukturierte Traces zu loggen ist storage-intensiv. Sie brauchen eine Sampling-Strategie — zum Beispiel: 100 % der Fehler und langen Läufe erfassen, 10–20 % der erfolgreichen Läufe zufällig samplen.
Trace: die Grundlage der Agenten-Observability
Ein Trace ist der Root-Container eines einzelnen Agentenlaufs. Er entspricht einer Aufgabe — zum Beispiel einer Nutzeranfrage oder einem geplanten Vorgang. Innerhalb eines Trace befinden sich Spans — jeder Span ist ein Schritt mit Metadaten.
Die Hierarchie sieht folgendermaßen aus:
- Trace: „Buche Transport für Auftrag #4821"
- - Span: LLM-Call — Anfrage verstehen
- - Span: Tool-Call —
search_carriers(origin, destination, date) - - Span: Tool-Call —
get_price(carrier_id=12) - - Span: Tool-Call —
get_price(carrier_id=17) - - Span: LLM-Call — Entscheidung und Begründung
- - Span: Tool-Call —
book_shipment(carrier_id, price, ...)
Jeder Span enthält: Startzeit und Endzeit, Eingabe, Ausgabe, einen etwaigen Fehler und die Parent-ID. Daraus lässt sich der gesamte Entscheidungsverlauf ohne Rätselraten rekonstruieren.
In LangGraph bildet sich dieser Baum natürlich auf Graphen ab — jeder Node im Graph entspricht einem Span. Tools wie LangSmith erfassen den State diff bei jedem Graph-Edge-Übergang und liefern damit einen detaillierten Blick auf die Zustandsentwicklung.
ReAct-Tracing: Reason-Act-Observe in den Logs
Wenn ein Agent die ReAct-Architektur verwendet — die Reason-Act-Observe-Schleife — sollte die Observability jeden dieser Schritte explizit erfassen.
Reason-Schritt: was der Agent „dachte" — die Chain-of-Thought-Ausgabe des Modells vor dem Tool-Aufruf. Das ist der wertvollste Schritt für das Debugging. Wenn der Agent das falsche Tool aufruft, ist die Antwort fast immer im Reason-Schritt sichtbar — das Modell hat aus einem Grund „falsch entschieden", der im Text steht.
Act-Schritt: der genaue Tool-Aufruf mit den Parametern. Nicht die Vorlage — die tatsächlichen Werte nach der Interpolation. Fehler beim Tool Calling — falsch formatierte Parameter, falscher Typ — sind hier erkennbar.
Observe-Schritt: was das Tool zurückgegeben hat. Wichtig: die rohe Ausgabe des Tools, bevor das Modell sie verarbeitet. Wenn ein Tool ein unerwartetes Format oder eine Fehlermeldung zurückliefert, sehen Sie das hier.
Ohne explizites Logging dieser drei Schritte pro Iteration haben Sie nur die finale Ausgabe. Und die finale Ausgabe sagt Ihnen nicht, warum der Agent nach der dritten Iteration seine Entscheidung geändert hat.
Metriken, die Sie überwachen sollten
Neben dem Trace pro Lauf brauchen Sie aggregierte Metriken für das Monitoring:
- Latenz p50/p95/p99 — nicht nur die Gesamtlatenz eines Laufs, sondern die Latenz pro Node. Wo verbringt der Agent seine Zeit?
- Token-Verbrauch pro Lauf — Trend, Ausreißer (Läufe mit 10× mehr Tokens = Fehlermuster)
- Tool-Fehlerrate — Anteil der Läufe, bei denen mindestens ein Tool-Aufruf fehlgeschlagen ist
- Retry-Rate — wie viel Prozent der Läufe einen Retry erforderten. Eine Retry-Rate von 12 % und mehr signalisiert in der Regel ein Problem bei der Schema-Validierung oder im Prompt
- Abandonment-Rate — Läufe, bei denen der Agent das Ziel nicht erreicht und eine Fallback-Antwort zurückgegeben hat
- Human Escalation Rate — bei HITL (human-in-the-loop)-Systemen: der Anteil der Läufe, die an einen Menschen eskaliert wurden
Jede dieser Metriken hat symptomatischen Charakter. Eine hohe Retry-Rate weist auf instabiles Tool Calling hin. Eine hohe p99-Latenz bei niedriger p50-Latenz deutet auf Ausreißer-Szenarien hin — wahrscheinlich lange Kontexte oder Retry-Schleifen. Eine hohe Abandonment-Rate zeigt Randfälle an, die der Agent nicht verarbeiten kann.
Tools: LangSmith, Langfuse, Arize Phoenix
Für den Produktionseinsatz gibt es heute drei Hauptplattformen:
`LangSmith` — die tiefste Integration mit LangGraph und LangChain. Erfasst automatisch Traces, State diffs, Tokens und Latenz. Hat ein Playground für den Replay von Läufen — Sie können einen konkreten Trace nehmen und ihn erneut mit einem modifizierten Prompt ausführen. Cloud-hosted, Preisgestaltung nach Trace-Volumen. Wenn Ihr Stack LangGraph ist, ist LangSmith die natürliche Wahl.
`Langfuse` — framework-agnostisch, self-hostable (Postgres + ClickHouse). SDK für Python, TypeScript, REST. Funktioniert auch, wenn Sie nicht über LangGraph schreiben — Sie rufen das SDK direkt bei jedem LLM-Call und Tool-Call auf. Geeignet für Teams, die volle Kontrolle über ihre Daten wollen (regulierte Branchen, On-Prem-Anforderungen). Self-Hosting erhöht den Ops-Aufwand — ein ClickHouse-Cluster muss betrieben werden.
`Arize Phoenix` — OpenTelemetry-basiert. Erfasst Traces über das standardmäßige OTel-Protokoll, was die Integration in einen bestehenden Monitoring-Stack ermöglicht (Prometheus, Grafana, Jaeger). Zusätzlich: 50+ Eval-Metriken direkt in der Plattform — Faithfulness, Hallucination Detection, Relevance. Für Teams, bei denen Agenten-Observability Teil einer umfassenderen APM-Lösung sein soll.
Die Wahl: Wenn Sie LangGraph in der Cloud betreiben — LangSmith. Wenn Sie Self-Hosting brauchen oder einen heterogenen Stack haben — Langfuse. Wenn Sie Observability und Eval in einem wollen und OTel-Infrastruktur haben — Arize Phoenix.
Für kleinere Projekte in einer frühen Phase: Self-hosted Langfuse auf einem einfachen Docker Compose reicht aus und spart Kosten.
Replay und Debugging eines konkreten Vorfalls
Observability hat den größten Nutzen bei einem konkreten Vorfall. Das Vorgehen, das in der Praxis funktioniert:
- 1.Trace identifizieren — nach Trace-ID oder Filter (zum Beispiel: alle Läufe mit einer Tool-Fehlerrate > 0 in den letzten 24 Stunden)
- 2.State diff öffnen — ansehen, wie sich der Zustand des Agenten Schritt für Schritt verändert hat. Wo trat eine unerwartete Änderung auf?
- 3.Reason-Text in jedem LLM-Call lesen — nach der Logik suchen, die auf die Frage antwortet „warum hat der Agent diese Entscheidung getroffen"
- 4.Tool-Ausgaben prüfen — könnte das Problem in dem liegen, was das Tool zurückgegeben hat, und nicht darin, was der Agent mit der Ausgabe gemacht hat?
- 5.Replay starten mit modifiziertem Prompt oder Parametern — Hypothese verifizieren ohne Zugriff auf eine reale Umgebung
Dieses Vorgehen reduziert die MTTR (Mean Time to Resolution) von Stunden auf Minuten. Aus der Erfahrung: Die meisten Agenten-Bugs liegen nicht im LLM-Reasoning — sie liegen im Tool Calling, in einem unerwarteten Ausgabeformat des Tools oder im State Management. Observability ermöglicht diese Unterscheidung in Sekunden.
Alerts und proaktives Monitoring
Reaktives Debugging ist nur eine Ebene. Ein Produktionssystem braucht auch proaktive Alerts.
Grundlegende Alerting-Regeln:
- Tool-Fehlerrate > 5 % im Stunden-Fenster → Alert, wahrscheinliche Änderung im Downstream-System oder im Tool-Schema
- Durchschnittliche Lauflatenz > 2× Baseline → Alert, Ausreißer-Szenario oder Upstream-Verlangsamung
- Abandonment-Rate > 10 % pro Tag → Alert, neue Randfälle in der Produktion
- Token-Kosten pro Tag > X EUR — Cost-Alert, unverzichtbar bei Agenten, bei denen Looping ohne Limit Aufrufe generieren kann. Ein Agent ohne Cost-Alert kann über Nacht Tausende von Aufrufen erzeugen und eine Rechnung im vierstelligen Bereich — ein Risiko, das wir in der Praxis immer wieder sehen
Alerts sollten auf einen Trace verweisen, nicht nur auf eine Zahl. Wenn ich einen Alert „Tool-Fehlerrate 8 %" erhalte, möchte ich direkt einen Link zu dem Trace, bei dem das aufgetreten ist — nicht eine Zahl ohne Kontext.
Observability und die Kosten eines Agenten
Observability selbst erzeugt Kosten — Storage für Traces, Compute für Analytics. Bei Produktionssystemen mit hohem Volumen ist es wichtig, eine Sampling-Strategie zu definieren.
Empfohlenes Vorgehen:
- 100 % Sampling für fehlerhafte Läufe (Tool-Fehler, Abandonment, Timeout)
- 100 % Sampling für Läufe mit ungewöhnlicher Latenz (p99-Ausreißer)
- 10–20 % Sampling für erfolgreiche Läufe im Normbereich
- 100 % Sampling beim Deployment einer neuen Agenten-Version (erste 24–48 Stunden)
Das reduziert die Storage-Kosten um das 5- bis 10-Fache, ohne die vollständige Sichtbarkeit für die Diagnose zu verlieren. Plattformen wie Langfuse unterstützen die Konfiguration der Sampling-Rate nativ.
Der Zusammenhang mit den Kosten von Agenten in der Produktion: Observability ermöglicht es Ihnen, ineffiziente Läufe zu identifizieren — zum Beispiel Läufe, bei denen der Agent wiederholt dasselbe Tool aufruft, weil die Antwort unklar ist. Das ist typischerweise ein Problem der Tool-Calling-Zuverlässigkeit, das Observability aufdeckt, bevor es die Kosten spürbar erhöht.
Die Sicherheitsdimension des Tracings
Traces enthalten sensible Daten — Prompts, Tool-Ausgaben, den internen Zustand des Agenten. In regulierten Branchen (Finanzen, Gesundheitswesen, Recht) erfordert das:
- Verschlüsselung von Traces at rest und in transit
- Zugriffskontrolle — wer darf Trace-Einträge lesen?
- Aufbewahrungsrichtlinie — wie lange werden Traces gespeichert?
- PII-Scrubbing — personenbezogene Daten in Prompts oder Tool-Ausgaben dürfen nicht im Klartext gespeichert werden
Self-hosted Langfuse gibt Ihnen volle Kontrolle über all diese Aspekte. Cloud-Plattformen müssen anhand Ihrer DSGVO/Data-Residency-Anforderungen bewertet werden — insbesondere wenn Traces Unternehmens- oder Kundendaten enthalten.
Für On-Prem-LLM-Deployments ist Self-hosted Observability fast immer eine Anforderung, keine Wahl.
Häufige Fragen
Muss ich Observability vor dem ersten Deployment eines Agenten haben?
Nicht unbedingt vor dem ersten Testdeployment — aber ja, vor dem Deployment in die Produktion mit echten Nutzern oder echten Daten. Ohne Observability haben Sie keine Möglichkeit, zu identifizieren, wo der Agent versagt und warum. Der erste Produktionsvorfall, der ein Debugging ohne Tracing erfordert, überzeugt das Team in der Regel schneller als jedes Argument.
Was ist der Unterschied zwischen Tracing und standardmäßigem Logging?
Ein klassisches Log ist eine flache Abfolge von Einträgen. Tracing erfasst einen hierarchischen Baum — ein Trace enthält Spans, Spans enthalten Child-Spans. Für einen Agenten, bei dem eine Eingabe Dutzende von Aufrufen in einem Baum auslöst, ist die hierarchische Struktur unverzichtbar. Außerdem erfasst Tracing den State diff zwischen den Schritten, was ein flaches Log nicht leistet.
Funktioniert Observability auch für Agenten, die nicht auf LangGraph basieren?
Ja. Langfuse und Arize Phoenix sind framework-agnostisch — es genügt, das SDK bei jedem LLM-Call und Tool-Call aufzurufen. Wenn Sie einen eigenen Agenten ohne Framework schreiben, können Sie OpenTelemetry-Spans manuell hinzufügen. LangSmith hat die tiefste Integration mit LangGraph, aber es gibt auch Integrationen für andere Frameworks.
Was kostet das?
Langfuse self-hosted ist kostenlos (nur Infrastruktur-Ops-Kosten — ein einfaches Docker Compose mit Postgres + ClickHouse). LangSmith und Arize Phoenix haben einen Free Tier für niedrige Volumen, kostenpflichtige Pläne beginnen bei etwa einigen Dutzend Euro pro Monat. Der Hauptkostenblock ist nicht die Plattform — es ist der Storage für Traces, vor allem bei hohem Lauf-Volumen.
Soll ich vollständige LLM-Prompts loggen?
Ja — mit einer Einschränkung: Wenn die Prompts personenbezogene oder unternehmenssensible Daten enthalten, müssen Sie PII-Scrubbing vor dem Speichern sicherstellen. Nur Metadaten zu loggen (Token-Anzahl, Latenz, Tool-Name) ohne Promptinhalt ist kostengünstiger, schränkt aber die Debuggbarkeit erheblich ein. Wir empfehlen, vollständige Prompts mit einer Aufbewahrungsrichtlinie und Zugriffskontrolle zu loggen.
Fazit
*Observability von KI-Agenten ist keine Frage der Tools — es ist eine Frage der Verantwortungskultur für das, was das System in der Produktion tut. Wenn ein Agent versagt, muss die Antwort auf „warum" innerhalb von Minuten vorliegen, nicht erst nach Stunden. Bei MP Industrial Solutions helfen wir Teams dabei, Observability als Teil der Agenten-Architektur aufzusetzen — nicht als nachträgliche Schicht. Wenn Sie ein Agenten-Deployment planen oder gerade einen Vorfall in einem bestehenden System debuggen, schauen wir uns Ihren konkreten Fall gerne an.*