KI-Agenten im Betrieb überwachen: was loggen, worauf alarmieren
Ein klassischer Dienst ist gesund, wenn er schnell antwortet und nichts wirft. Ein Agent kann beides tun und völlig falsch liegen — jede Anfrage in zwei Sekunden beantwortet, jede davon mit einer im März zurückgezogenen Richtlinie.
Agenten-Monitoring ist deshalb eine eigene Disziplin. Sie ruht auf zwei Dingen: einem Trace je Lauf, detailliert genug zur Rekonstruktion, und wenigen Verhaltensmetriken, deren Bewegung etwas bedeutet. Der Rest ist Dekoration.
Was ein brauchbarer Trace enthält#
- Eine Lauf-ID an jeder Logzeile, jedem Modellaufruf und jedem ausgehenden Request.
- Den exakten Kontext je Schritt oder einen Hash plus die zusammengesetzten Teile.
- Jeden Werkzeugaufruf mit Argumenten, Ergebnis, Dauer und Ausgang.
- Modellname und -version je Aufruf plus Tokenzahlen.
- Den Abbruchgrund: fertig, Schrittgrenze, Ausgabengrenze, menschliches Tor, Fehler.
- Die finale Ausgabe und ob ein Mensch sie später korrigierte oder rückgängig machte.
Sechs Metriken, die sich wirklich bewegen#
| Metrik | Worauf achten | Bedeutet meist |
|---|---|---|
| Erfolgsquote | Anhaltender Rückgang | Modellwechsel, Datendrift, API-Änderung |
| Schritte pro Lauf | Schleichender Anstieg | Werkzeugfehler werden wiederholt; Retrieval schlechter |
| Werkzeugfehlerquote | Spitze bei einem Werkzeug | Upstream kaputt — kein Agentenproblem |
| Interventionsquote | Anstieg | Vertrauen sinkt oder neue Anfragekategorie |
| Quote unbelegter Aussagen | Jeder Anstieg | Retrieval scheitert still |
| Kosten pro Aufgabe | Anstieg bei gleichem Volumen | Kontextaufblähung oder mehr Retries |
Auf Verhalten alarmieren, nicht nur auf Fehler#
Ein Agent scheitert selten laut. Er degradiert: etwas mehr Schritte, etwas mehr Retries, etwas mehr Eskalationen — und eines Morgens antwortet er aus veralteten Dokumenten. Alarmieren Sie auf Änderungsraten über ein rollierendes Fenster statt auf absolute Schwellen. Und hängen Sie an jeden Alarm den Trace eines repräsentativen Laufs; ein Alarm, den niemand schnell untersuchen kann, wird stummgeschaltet.
Täglich echte Läufe lesen#
Kein Dashboard ersetzt Lesen. Wählen Sie täglich eine Handvoll Läufe — ein paar Erfolge, jede Eskalation, jeden Lauf am Limit — und lesen Sie sie ganz. Jedes ernste Problem, das wir in einem Produktionsagenten fanden, war im Trace sichtbar, bevor es in einer Metrik auftauchte. Rotieren Sie, wer liest; wer den Prompt schrieb, bemerkt am wenigsten, was er falsch macht.
Nehmen Sie Überraschendes noch am selben Tag ins Eval-Set auf. Diese Gewohnheit macht aus Monitoring Verbesserung statt Beobachtung.
Loggen, ohne zu sammeln, was Sie nicht dürfen#
Traces enthalten konstruktionsbedingt Kundendaten. Maskieren Sie Identifikatoren beim Loggen statt in einem späteren Job, setzen Sie für volle Kontexte eine kürzere Aufbewahrung als für Metriken und behandeln Sie Werkzeugargumente — wo sich personenbezogene Daten sammeln — mit denselben Zugriffsrechten wie das darunterliegende System.
Häufige Fragen
Wie lange volle Traces behalten?
Lang genug zum Debuggen und für Audits — üblich sind 30 bis 90 Tage für volle Kontexte, während Metriken und Ergebniszusammenfassungen deutlich länger bleiben. Legen Sie es bewusst fest; darin steht, was Ihre Nutzer geschrieben haben.
Welcher Alarm ist am wertvollsten?
Ein Anstieg bei Eskalationen oder menschlichen Korrekturen. Das früheste ehrliche Signal für Drift, und es braucht kein Labeling — Ihre Nutzer und Operatoren bewerten den Agenten kostenlos.
Brauche ich ein spezielles Observability-Tool?
Anfangs nicht. Eine abfragbare Trace-Tabelle deckt das meiste ab. Spezialwerkzeuge helfen bei Lauf-Vergleich, Evaluationsintegration und Prompt-Versionierung an einem Ort — sinnvoll, wenn Traces lesen für mehrere Leute Tagesgeschäft ist.
agenten monitoringllm observabilityagenten tracingki metriken produktionagenten drift
