Observability für Agenten: sehen, was Ihre KI wirklich tut
Tracing, Metriken und Kostenkontrolle für autonome Agenten — die fünf Dinge, die man messen sollte, und wie OpenTelemetry zum De-facto-Standard für Agenten-Observability wurde.
Definition
Agenten-Observability ist die Praxis, das Verhalten eines autonomen Agenten aus seinen Ausgaben zu rekonstruieren — Traces, Logs und Metriken — sodass jeder Reasoning-Schritt, Tool-Aufruf und jede Entscheidung diagnostiziert, bepreist und auditiert werden kann. Sie erweitert Application-Observability auf mehrstufige, nicht-deterministische Systeme.
Man kann nicht verteidigen, debuggen oder bepreisen, was man nicht sieht. Bei einem einzelnen API-Aufruf war das leicht; bei einem Agenten, der plant, wiederholt und in dreißig Sekunden fünf Tools aufruft, nicht mehr. Observability macht aus einem Agenten statt einer Blackbox ein betreibbares System.
Warum sprengen Agenten klassisches Monitoring?
Klassisches Monitoring setzt Determinismus voraus: Dieselbe Anfrage tut dasselbe, und man beobachtet Latenz und Fehler. Agenten verletzen diese Annahme. Derselbe Prompt kann anders verzweigen, andere Tools aufrufen und bei einem schlechten Lauf das Zehnfache kosten. Durchschnitte verbergen die Fehler, auf die es ankommt.
Deshalb erfasst Agenten-Observability den Trace — den vollständigen Baum des Laufs: jeden Prompt, Modellaufruf, Tool-Aufruf und Sub-Agenten-Schritt, mit Timing, Tokens und Ergebnis. Dieser Trace ist die Einheit für Debugging, Bepreisung und Audit.
Die fünf Dinge, die zu messen lohnen
- Latenz pro Lauf82%
- Kosten / Tokens pro Aufgabe64%
- Task-Completion-Rate58%
- Tool-Auswahl-Genauigkeit31%
- Halluzinationsrate22%
Das Muster ist aufschlussreich: Teams messen das Leichte (Latenz) lange vor dem Schweren und Wichtigen (Halluzination, Tool-Auswahl). Die reifen schließen diese Lücke.
| Signal | Was es aussagt | Warum es zählt |
|---|---|---|
| Latenz pro Lauf | Wie schnell der Agent antwortet | UX und Timeout-Budget |
| Kosten / Tokens pro Aufgabe | Was jeder Lauf ausgibt | Fängt Schleifen und entlaufene Ketten |
| Task-Completion-Rate | Ob der Agent das Ziel erreicht | Das zentrale Qualitätssignal |
| Tool-Auswahl-Genauigkeit | Ob es das richtige Tool wählt | Falsches Tool heißt falsche oder unsichere Aktion |
| Halluzinationsrate | Wie oft die Ausgabe unbegründet ist | Vertrauen und Folgefehler |
OpenTelemetry wird zum Standard
Die wichtigste Verschiebung 2025 war die Konvergenz auf die GenAI-Konventionen von OpenTelemetry. Statt dass jede Plattform ihr eigenes Trace-Format erfindet, folgen Agenten-Spans nun einem gemeinsamen Schema. Das zählt aus zwei Gründen: Sie vermeiden Vendor-Lock-in, und Ihre Agenten-Traces liegen im selben Backend wie der Rest Ihres Stacks.
Dedizierte Plattformen liefern Mehrwert obendrauf — Session Replay, Time-Travel-Debugging, Agenten-Dashboards — bauen aber auf dem offenen Standard auf, nicht daneben.
Kosten sind ein Observability-Problem
Bei Agenten sind Kosten ein erstrangiges Signal. Ein schleifender Agent oder eine außer Kontrolle geratene Tool-Kette versagt nicht nur — sie verursacht Kosten. Erfassen Sie Tokens und Kosten pro Aufgabe, alarmieren Sie bei Anomalien und ergänzen Sie Loop-Detection, damit ein feststeckender Agent nicht stillschweigend Ihr Budget verbraucht. Das ist die FinOps-Seite von AgentOps — und oft das, was Observability finanziert.
Womit beginnen
- Tracing mit den OpenTelemetry-GenAI-Konventionen instrumentieren.
- Completion-Rate, Kosten pro Aufgabe und Latenz ab Tag eins erfassen.
- Bei Kosten- und Loop-Anomalien alarmieren.
- Halluzinations- und Tool-Auswahl-Metriken mit zunehmender Reife ergänzen.
Observability ist zugleich die Grundlage für Governance: Die Audit-Logs, die der EU AI Act erwartet, sind in der Praxis Ihre manipulationssicher gemachten Traces. Die hier verwendeten Begriffe stehen im Glossar.
Häufige Fragen
Wie unterscheidet sich Agenten-Observability von klassischem APM?
Klassisches Application Performance Monitoring setzt deterministische Dienste voraus: Dieselbe Anfrage folgt demselben Pfad, also beobachten Sie Latenz, Durchsatz und Fehlerraten, und das erzählt weitgehend die Geschichte. Agenten brechen diese Annahme. Derselbe Prompt kann bei jedem Lauf anders verzweigen, andere Tools aufrufen, schleifen, wiederholen und an einem schlechten Tag das Zehnfache eines guten kosten, sodass Durchschnitte genau die Fehler verbergen, auf die es ankommt. Agenten-Observability muss daher den Reasoning-Trace erfassen — den vollständigen Baum aus Prompts, Modellaufrufen, Tool-Aufrufen und Sub-Agenten-Schritten, jeweils mit Tokens, Timing und Ergebnis — nicht nur Metriken auf Anfrageebene. Sie muss zudem Kosten und Korrektheit als erstrangige Signale behandeln, denn ein Lauf kann technisch gelingen und dabei falsch oder absurd teuer sein. Der Denkwechsel führt von der Überwachung eines vorhersehbar arbeitenden Dienstes zur Rekonstruktion des Verhaltens eines Systems, das das nicht ist, damit Sie jeden einzelnen Lauf im Nachhinein debuggen, bepreisen und auditieren können.
Was sollte ich zuerst messen?
Beginnen Sie mit drei Signalen, die zusammen sagen, ob der Agent funktioniert, was er kostet und ob er schnell genug ist: Task-Completion-Rate, Kosten pro Aufgabe und Latenz. Die Completion-Rate ist Ihr zentrales Qualitätsmaß — welcher Anteil der Läufe das Ziel tatsächlich erreicht — und sie deckt eine Regression auf, bevor Nutzer sich beschweren. Kosten pro Aufgabe, als Tokens und Geld erfasst, fangen den agententypischen Fehlermodus, bei dem ein schleifender oder entlaufener Lauf nicht fehlschlägt, sondern still Kosten verursacht, und rechtfertigen die Instrumentierung damit von selbst. Latenz hält die Erfahrung nutzbar und meldet Timeouts. Diese drei sind günstig zu erfassen und signalstark, weshalb sie ab Tag eins dazugehören. Mit zunehmender Reife ergänzen Sie die schwereren, wertvolleren Metriken — Tool-Auswahl-Genauigkeit und Halluzinationsrate —, die die meisten Teams gerade deshalb spät instrumentieren, weil sie schwerer sind, obwohl sie die vertrauensschädigenden Fehler fangen. Messen Sie jetzt die leichten drei und schließen Sie dann bewusst die Lücke zu den schweren zwei.
Brauche ich ein spezielles Tool?
Nein, Sie können mit OpenTelemetry und seinen GenAI-Konventionen starten, die die meisten Plattformen inzwischen unterstützen, und das ist der richtige erste Schritt, denn er hält Ihre Agenten-Traces im selben Backend wie den Rest Ihres Stacks und vermeidet Vendor-Lock-in. Die Konvergenz 2025 auf ein gemeinsames Span-Schema bedeutet, dass Sie kein proprietäres Format mehr übernehmen müssen, um strukturierte Agenten-Traces zu erhalten. Dedizierte Observability-Plattformen liefern echten Mehrwert obendrauf — Session Replay, Time-Travel-Debugging durch einen Lauf und Dashboards rund um Agentenkonzepte wie Tool-Aufrufe und Sub-Agenten — und viele Teams führen mit dem Wachstum eine ein. Entscheidend ist, auf dem offenen Standard aufzubauen statt daneben, damit ein späterer Wechsel oder eine Ergänzung nicht bedeutet, alles neu zu instrumentieren. Kurz: erst der Standard für Portabilität, dann dediziertes Tooling für Tiefe, und nie ein proprietäres Format, das Ihre Traces dort einsperrt, wo nur ein Anbieter sie lesen kann.
Ist Observability dasselbe wie die Audit-Logs, die der AI Act erwartet?
Sie sind eng verwandt, aber nicht identisch, und die praktische Einsicht ist, dass Ihre Observability-Traces der Rohstoff sind, aus dem Ihre Compliance-Audit-Logs gemacht werden. Observability existiert, um den Agenten zu betreiben — Fehler debuggen, Kosten kontrollieren, Regressionen erkennen — und ist typischerweise auf Ingenieure optimiert, mit Sampling, Aufbewahrungslimits und veränderlichem Speicher. Die Audit-Logs, die Governance-Regime erwarten, auch der EU AI Act, haben strengere Anforderungen: Sie müssen jede folgenreiche Aktion einer Identität zuordnen, über definierte Zeiträume aufbewahrt und manipulationssicher sein, denn ein Log, das ein Beklagter still ändern könnte, ist als Beweis wertlos. Beide überschneiden sich also im Inhalt — beide halten fest, was der Agent tat — unterscheiden sich aber in den Garantien. Der effiziente Weg ist, Tracing einmal zu entwerfen und beides daraus abzuleiten: reiche Traces für den Betrieb behalten und die für Rechenschaft nötigen Entscheidungs- und Aktionsaufzeichnungen in signierte, anhängende, aufbewahrte Logs überführen. Behandeln Sie Governance-Logging als gehärtete Projektion Ihrer Observability-Daten, nicht als separates System, das Sie später anflanschen.