KI-Agenten-Observability bezeichnet die Praxis, das Verhalten LLM-basierter Agenten sichtbar und nachvollziehbar zu machen. Sie erfasst jeden Schritt eines Agentenlaufs, also Modellaufrufe, Tool-Aufrufe, Retrieval, Speicherzugriffe und Übergaben zwischen Agenten, als Traces, Metriken und Events, damit Teams Fehler analysieren, Kosten und Latenz steuern und die Qualität der Ergebnisse beurteilen können.
Was ist KI-Agenten-Observability?
KI-Agenten-Observability überträgt die Prinzipien der Observability auf Software-Agenten, die ein großes Sprachmodell nutzen, um zu planen und zu handeln. Anders als ein einzelner Chat-Aufruf arbeitet ein Agent in einer Schleife: Er liest ein Ziel, fragt das Modell nach dem nächsten Schritt, ruft Tools oder APIs auf, holt Dokumente, speichert Zwischenergebnisse und entscheidet, wann er fertig ist. Eine einzige Nutzeranfrage kann so Dutzende Modell- und Tool-Aufrufe auslösen, teils parallel, teils an andere Agenten delegiert.
Klassisches Application Monitoring sieht davon nur ein paar langsame HTTP-Anfragen an einen Modellanbieter. Agenten-Observability rekonstruiert dagegen den gesamten Lösungsweg: welcher Schritt gewählt wurde, mit welchen Eingaben, zu welchen Kosten und mit welchem Ergebnis. Sie erweitert LLM Observability von einzelnen Prompts auf mehrstufige, nicht deterministische Abläufe.
Warum Agenten schwer zu beobachten sind
- Nichtdeterminismus. Dieselbe Eingabe kann bei jedem Lauf zu einer anderen Schrittfolge führen. Allein aus Logs lässt sich ein Fehler daher selten reproduzieren.
- Stille Fehler. Ein Agent kann HTTP 200 und eine flüssige Antwort liefern, obwohl er das falsche Tool genutzt, unnötig Schleifen gedreht oder den abgerufenen Kontext ignoriert hat.
- Kosten und Latenz multiplizieren sich. Jeder zusätzliche Denkschritt kostet Modelllatenz und Token-Verbrauch; Endlosschleifen sind ein Betriebs- und ein Budgetrisiko.
- Externe Abhängigkeiten. Tools, Vektordatenbanken und MCP-Server haben eigene Fehlerbilder, Rate Limits und Timeouts.
- Sensible Inhalte. Prompts und Tool-Argumente können personenbezogene oder vertrauliche Daten enthalten, die nicht ungefiltert gespeichert werden dürfen.
Was Sie erfassen sollten: Traces, Metriken und Events
Das passende Datenmodell für einen Agentenlauf ist ein verteilter Trace. Der Root-Span steht für den Agentenaufruf, Child-Spans für jeden Modellaufruf, jede Tool-Ausführung, jedes Retrieval und jeden Sub-Agenten. Die OpenTelemetry GenAI Semantic Conventions (Status: Development) definieren dafür Operationsnamen wie invoke_agent, chat, execute_tool und retrieval sowie Attribute wie gen_ai.agent.name, gen_ai.request.model, gen_ai.tool.name und gen_ai.usage.input_tokens.
Ergänzend zu Traces sind folgende Metriken nützlich: Gesamtdauer pro Agent, Anzahl der Modell- und Tool-Aufrufe pro Lauf, Token-Verbrauch pro Schritt, Fehlerraten der Tools und der Anteil der Läufe, die in einem Fallback oder einer Übergabe an einen Menschen enden. Prompt- und Antwortinhalte sollten Sie nur per Opt-in und nach Maskierung erfassen, typischerweise als Span-Attribute oder Events mit kürzerer Aufbewahrung.
Multi-Agenten-Systeme fügen eine weitere Ebene hinzu. Delegiert ein Orchestrator Aufgaben an spezialisierte Agenten oder ruft ein Agent Tools auf, die ein Model Context Protocol-Server bereitstellt, sollte jede Übergabe den Trace-Kontext mitführen. Nur so erkennen Sie, welcher Agent welche Entscheidung getroffen hat, wo die Zeit verloren ging und welche Komponente fehlerhafte Daten geliefert hat. Wenn Sie Agentenversion, Version der Prompt-Vorlage und Modellversion am Root-Span festhalten, lassen sich Läufe vor und nach einer Änderung direkt vergleichen. Das ist die Grundlage, um Regressionen nach einem Modellwechsel oder einer geänderten Systemanweisung zuverlässig zu erkennen.
Beispiel: Analyse eines Agentenlaufs
Ein illustratives Beispiel: Ein Support-Agent braucht plötzlich deutlich länger pro Ticket. Der Trace eines langsamen Laufs zeigt folgende Struktur:
invoke_agent support-agent 38,2 s
chat gpt-model 2,1 s in 1.850 / out 120 Tokens
execute_tool search_orders 0,3 s status=error (timeout)
chat gpt-model 2,4 s
execute_tool search_orders 0,3 s status=error (timeout)
... 9 weitere Wiederholungen ...Nicht das Modell ist langsam, sondern ein Tool läuft in einen Timeout, und der Agent versucht es immer wieder, weil seine Anweisungen die Zahl der Versuche nicht begrenzen. Ohne Spans pro Schritt sähe das wie ein allgemeines Latenzproblem beim Modellanbieter aus. Die Lösung: ein Wiederholungslimit in der Agentenschleife und ein Alert auf die Fehlerrate der Tools.
Best Practices
- Instrumentieren Sie mit OpenTelemetry und den GenAI-Konventionen statt mit einem proprietären SDK, damit Traces zwischen Frameworks und Backends portabel bleiben.
- Propagieren Sie den Trace-Kontext durch Tools, Sub-Agenten und MCP-Server, damit ein Lauf einen einzigen Trace bildet.
- Setzen Sie harte Grenzen für Schritte, Tokens und Laufzeit pro Lauf und protokollieren Sie, wenn eine Grenze greift.
- Kombinieren Sie Laufzeit-Telemetrie mit LLM-Evaluierung: Traces zeigen, was passiert ist, Evals bewerten, ob das Ergebnis gut war.
- Maskieren Sie personenbezogene Daten vor der Speicherung und halten Sie vollständige Prompt-Inhalte optional und kurzlebig.
- Versehen Sie Läufe mit Agenten-, Prompt- und Modellversion, damit sich Regressionen einer Änderung zuordnen lassen.
Wie Obseria hilft
Obseria nimmt OpenTelemetry-Traces, -Metriken und -Events aus Agenten-Frameworks per OTLP entgegen und zeigt jeden Agentenlauf als Trace mit Modellaufrufen, Tool-Aufrufen und Token-Zahlen pro Schritt. Die Obseria Pipeline kann personenbezogene Daten in Prompts vor der Speicherung maskieren. Die Agenten-Telemetrie liegt direkt neben den Services und der Infrastruktur, die der Agent aufruft, sodass sich ein fehlerhaftes Tool mit seinem Backend korrelieren lässt. Mehr dazu unter AI Observability.
