Signale, an denen Sie sehen, dass ein Agent teurer oder schlechter wird

Die Einheit ist der Fall, nicht der Aufruf

Ein einzelner Fall kann mehrere Läufe, Dutzende Modellaufrufe, eine Pause für eine Freigabe und einige Minuten Arbeitszeit einer Sachbearbeiterin umfassen. Tokenkosten pro Aufruf sagen für sich wenig aus. Kosten pro bearbeitetem Fall, einschließlich Prüfzeit und Nacharbeit, sind die Zahl, die die prozessverantwortliche Person mit den heutigen manuellen Kosten vergleichen kann.

Dafür braucht jeder Span und jede Logzeile eine Fallkennung. Die OpenTelemetry-Semantik-Konventionen für Agenten-Spans definieren Attribute wie gen_ai.conversation.id, gen_ai.agent.version und die Tokenzähler gen_ai.usage.input_tokens und gen_ai.usage.output_tokens. Die Konventionen haben noch den Status Development; legen Sie die umgesetzte Version fest und ergänzen Sie ein eigenes Attribut für die Fall-ID, wenn eine Konversation nicht eins zu eins einem Fall entspricht.

Ein Signalblatt für einen Prozessagenten

Dies ist eine Ausgangsliste für einen hypothetischen Rechnungsagenten. Jeder Punkt wird nach Fallart und Agentenversion aufgeschlüsselt.

Signale zum Ergebnis

• Anteil der Fälle, die ohne Person abgeschlossen wurden
• Anteil der eskalierten Fälle, nach Eskalationsgrund
• Fehlerquote in der menschlichen Stichprobenprüfung abgeschlossener Fälle
• Spätere Korrekturen, etwa Buchungen, die nachträglich storniert wurden

Signale zu Kosten

• Kosten pro bearbeitetem Fall, mit Modell-, Plattform- und Prüfkosten getrennt ausgewiesen
• Modellaufrufe, Tool-Aufrufe und Tokens pro Fall, als Perzentile

Signale zu Zustand und Drift

• Tool-Fehler nach Tool und Fehlertyp sowie die Zahl der Fälle mit unbekanntem Ergebnis eines Schreibvorgangs
• Zeit vom Eingang bis zum Abschluss und das Alter des ältesten Falls, der auf eine Person wartet
• Die Verteilung eingehender Fallarten im Vergleich zu der Verteilung, mit der der Agent getestet wurde

Schwellen vereinbaren, bevor Sie sie brauchen

Das SRE Workbook von Google empfiehlt, Service Level Indicators als Verhältnis guter Ereignisse zu allen Ereignissen auszudrücken, nur wenige davon zu wählen, möglichst nah am Nutzer zu messen und vorab schriftlich festzulegen, was passiert, wenn das Fehlerbudget aufgebraucht ist. Bei einem Prozessagenten ist der Nutzer der Prozess; messen Sie deshalb im führenden System statt im Agenten.

Ein hypothetisches Ziel: Mindestens 97 Prozent der stichprobenartig geprüften, automatisch abgeschlossenen Rechnungen sind über rollierende vier Wochen korrekt. Die Zahl ist eine Annahme zur Veranschaulichung; die prozessverantwortliche Person legt sie anhand der Fehlerquote des heutigen manuellen Prozesses fest. Die zugehörige Regel könnte lauten: Wird das Ziel verfehlt, geht die betroffene Fallart zurück in die Freigabe, bis die Ursache behoben ist.

Schleichende Kostensteigerung erkennen

Kosten pro Fall springen selten. Sie driften, wenn Dokumente länger werden, der Agent mehr Tool-Aufrufe durchläuft, Retries zunehmen oder mehr Fälle bei einer Person landen. Beobachten Sie Perzentile statt Durchschnittswerte; das Monitoring-Kapitel des SRE Workbook weist darauf hin, dass Mittelwerte langsame Anfragen verbergen, und dasselbe gilt für teure Fälle. Dasselbe Kapitel empfiehlt, beabsichtigte Änderungen wie Versionen und Konfiguration mitzuschreiben, damit sich Verschiebungen Rollouts zuordnen lassen. Für Agenten heißt das: Modell-, Prompt- und Tool-Versionen an jedem Fall.

Qualität braucht eine Stichprobe, nicht nur ein Dashboard

Telemetrie zum Laufzustand zeigt, dass ein Lauf endete, nicht, dass die Rechnung auf das richtige Konto gebucht wurde. Automatische Ergebnisprüfungen gegen das führende System schließen einen Teil dieser Lücke, und ihre Ergebnisse lassen sich als Metriken mit eigenen Alarmen ausgeben. Für Fallarten, die sie nicht abdecken, halten Sie eine kleine, regelmäßige menschliche Prüfung abgeschlossener Fälle am Laufen. Der Leitfaden von Anthropic zu Agenten-Evals beschreibt Monitoring in Produktion als nützlich, aber reaktiv, und empfiehlt, es mit automatisierten Evals und dem manuellen Lesen von Transkripten zu kombinieren, damit jede Ebene auffängt, was die anderen übersehen.

Was jemanden alarmieren sollte

Alarmieren Sie eine Person nur bei Zuständen, auf die sie reagieren kann: ein Tool, das für eine ganze Kategorie von Fällen ausfällt, jeder Fall mit unbekanntem Ergebnis eines Schreibvorgangs, eine Freigabewarteschlange, die älter ist als ihr Ziel, oder ein Ziel, das verfehlt zu werden droht. Schleichende Kostendrift gehört in eine wöchentliche Durchsicht, nicht in einen Alarm. Das SRE Workbook empfiehlt außerdem, Alarmregeln mit synthetischen Daten zu testen, da eine Regel, die nie auslöst, schlicht defekt sein kann. Ein praktischer erster Schritt: Markieren Sie im obigen Signalblatt, welche Zahlen Sie heute schon pro Fall erzeugen können, und beginnen Sie mit diesen.