AI Operations · 10 Min.
AI-Agent Observability: Was du messen musst, bevor ein Agent echte Arbeit uebernimmt
Ein Agent ohne Observability ist eine Black Box mit Firmenzugang. Wer Autonomie will, muss Verhalten messbar machen.
SYSTEMS Grafik zu AI Agent Observability Evals: Trace -> Metric -> Decision. Fokus: Welche Metriken Unternehmen brauchen, um KI-Agenten produktiv zu betreiben.
Kurzfassung
Agenten muessen auf Prozessverhalten gemessen werden, nicht nur auf Antwortqualitaet. Relevante Metriken sind Tool-Wahl, Fehlerklasse, Kosten, Abbruchgrund und Freigabequote. Observability ist die Grundlage fuer mehr Autonomie.
Strategischer Lesepfad
Baue das Thema im passenden Cluster weiter aus und verknuepfe es mit den naechsten Architekturentscheidungen.
Warum klassische Logs nicht reichen Bei normaler Software ist oft klar, welcher Codepfad gelaufen ist. Bei Agenten ist das schwieriger: Ein Modell entscheidet, welcher Kontext wichtig ist, welches Tool passt und wann das Ergebnis gut genug ist.
Ein Log mit "Request erfolgreich" sagt deshalb wenig. Entscheidend ist, wie der Agent zu seinem Ergebnis kam.
Stand Mai 2026: Trace-first statt Output-first OpenAI empfiehlt fuer Agenten-Evals, Verhalten zuerst ueber Traces zu verstehen und dann Datasets, Grader und Eval Runs aufzubauen. Trace-Grading bewertet nicht nur die finale Antwort, sondern den ganzen Lauf: Entscheidungen, Tool Calls, Handoffs, Guardrails und Zwischenschritte.
Das ist der Unterschied zwischen "der Agent antwortet gut" und "der Agent arbeitet korrekt".
Ein Unternehmen sollte Agenten deshalb nicht nur mit Stichproben lesen. Es braucht Release-Gates, die Agentenlaeufe strukturiert bewerten.
Google trennt bei Agenten-Evaluation ebenfalls zwischen finaler Antwort und Trajectory Evaluation. Genau das ist der Punkt: Ein Agent kann am Ende zufaellig richtig liegen und trotzdem unterwegs falsche Tools, falsche Daten oder riskante Zwischenschritte genutzt haben.
Die fuenf wichtigsten Signale Ein produktiver Agent sollte mindestens diese Signale liefern:
Diese Signale machen aus Bauchgefuehl ein Betriebsmodell.
OpenAI Agents SDK Tracing erfasst unter anderem Agent Runs, LLM-Generierungen, Function Tool Calls, Guardrails, Handoffs und eigene Events. Wichtig ist die Datenschutzentscheidung: Traces koennen sensible Inputs und Outputs enthalten; fuer Zero-Data-Retention-Setups sind Tracing-Funktionen je nach Policy eingeschraenkt.
Trace: Welche Schritte wurden ausgefuehrt? Tool-Wahl: Warum wurde welches Tool genutzt? Kosten: Wie viele Tokens und externe Calls wurden verbraucht? Qualitaet: Hat der Lauf ein Eval bestanden? Freigabe: Musste ein Mensch korrigieren oder stoppen? Metriken pro Run Ein Agentenlauf sollte eine Run-ID haben, an der alles haengt:
Erst diese Verbindung zeigt, ob ein Agent produktiv besser wird oder nur mehr Aktivitaet erzeugt.
Auf Plattformebene kommen weitere Betriebsmetriken dazu: Request-Volumen, Token-Durchsatz, First-Token-Latenz, Fehlerquoten und Rate-Limits. Diese Zahlen wirken trocken, entscheiden aber darueber, ob ein Agent nur in einer Demo fluessig ist oder im echten Tagesgeschaeft stabil bleibt.
Ziel des Laufs Modell und Version Kontextquellen Tool Calls und Ergebnisse Guardrail-Entscheidungen Kosten und Latenz Eval-Score menschliche Korrektur finaler Business-Status Fehlerklassen statt Einzelfaelle Viele Teams debuggen Agenten fallweise. Besser ist eine Fehler-Taxonomie: falscher Kontext, falsches Tool, fehlende Berechtigung, unklare Aufgabe, Halluzination, Formatfehler, Kostenlimit, Sicherheitsblock.
Wenn Fehler gruppiert werden, erkennt man Muster. Dann verbessert man nicht den einen Prompt, sondern die richtige Schicht.
Evals als Regressionstest Evals sind nicht nur ein Launch-Check. Sie sind Regressionstests fuer Agenten. Wenn ein Tool, ein Modell oder ein Prompt geaendert wird, muss sichtbar sein, ob Kernfaelle weiterhin funktionieren.
Gute Eval-Saetze enthalten Normalfaelle, Grenzfaelle und Angriffsfaelle. Genau dort zeigt sich, ob ein Agent robust genug fuer mehr Rechte ist.
Eval-Typen fuer produktive Agenten Ein professionelles Eval-Set trennt mehrere Fragen:
Trace-Grading ist besonders stark fuer Tool Correctness und Policy Compliance. Output-Evals reichen dafuer nicht.
Trajectory-Metriken sind dafuer die harte Kante: Stimmen Reihenfolge, Tool-Auswahl, Zwischenschritte und Abbruchgrund? Ein Eval, das nur den finalen Text bewertet, sieht diese Fehler nicht. Ein Eval, das die Spur bewertet, kann Autonomie wirklich begrenzen oder erweitern.
Task Success: Wurde das Ziel erreicht? Tool Correctness: War das richtige Tool mit den richtigen Parametern im Einsatz? Policy Compliance: Wurden Freigaben, Rollen und Datenregeln beachtet? Cost Discipline: War der Lauf wirtschaftlich? Robustness: Funktioniert der Agent bei fehlenden, widerspruechlichen oder manipulierten Daten? Regression: Bleiben alte Kernfaelle nach Updates stabil? Observability ist auch Security Wenn ein Agent auf CRM, E-Mail, Dateien, Browser oder MCP -Tools zugreift, ist Observability eine Sicherheitskontrolle. Sie zeigt, ob der Agent unerwartete Tool-Ketten bildet, Daten in falsche Systeme sendet oder Freigaben umgeht.
Google Vertex AI Agent Engine rahmt Produktion ebenfalls als Runtime plus Sessions, Memory, Tracing, Logging, Monitoring und Security. Das bestaetigt: Agentenbetrieb ist kein einzelnes Dashboard, sondern ein Betriebsstack.
NIST beschreibt AI-Risikomanagement als kontinuierlichen Kern aus Govern, Map, Measure und Manage. Fuer Agenten ist das praktisch: Zustaendigkeit klaeren, Einsatzkontext abbilden, Verhalten messen und Risiken steuern. Observability ist also nicht nur DevOps, sondern Governance.
Der SYSTEMS-Blick Wir geben Agenten nicht sofort maximale Autonomie. Wir bauen Messbarkeit, lassen den Agenten kontrolliert laufen und erweitern Rechte erst, wenn Daten zeigen, dass er stabil arbeitet.
Das ist langsamer als eine Demo. Aber es ist der Weg, auf dem Agenten echte Arbeit uebernehmen koennen.
