Hallo zusammen, hier ist Chris Wade, zurück auf agntlog.com. Es ist März 2026, und ehrlich gesagt, wenn ihr immer noch darüber nachdenkt, eure Agenten so zu überwachen wie vor fünf Jahren, lasst ihr Geld, Verstand und vielleicht sogar euren Job auf der Strecke. Die Welt hat sich weiterentwickelt, und das sollte eure Strategie auch. Heute möchte ich über etwas Spezifisches sprechen, etwas, das mich in letzter Zeit sehr beschäftigt hat (und mir das Leben gerettet hat): Beobachtbarkeit für Agentenzustände, nicht nur Metriken.
Ich weiß, “Beobachtbarkeit” ist ein Schlagwort, das wie ein Frisbee bei einem Tech-Picknick herumgeworfen wird. Aber hört mir zu. Für uns im Bereich der Agentenüberwachung ist es kein schickes Wort; es ist ein grundlegender Wandel in der Art und Weise, wie wir unsere Systeme verstehen. Wir betrachten nicht mehr nur die CPU-Auslastung oder den Speicherverbrauch. Wir versuchen, den *internen Zustand* unserer Agenten, ihren Weg durch einen Workflow und die subtilen Signale zu verstehen, die uns sagen, dass etwas schiefgehen könnte – oder es bereits ist.
Mein Weg in dieses Thema begann vor etwa anderthalb Jahren. Wir hatten einen neuen Kunden, einen riesigen Callcenter-Betrieb mit Tausenden von Agenten, die unsere benutzerdefinierte CRM-Integration nutzten. Der alte Überwachungsansatz scheiterte spektakulär. Wir hatten Dashboards, die rot leuchteten für „hohe CPU“ oder „wenig Speicherplatz“ auf den Arbeitsplatzrechnern der Agenten, aber das eigentliche Problem, das die Kundenbeschwerden und versäumten SLAs verursachte, war tiefergehender. Agenten blieben unendlich lange im Zustand „Nachbereitung nach dem Anruf“ hängen, oder ihre CTI (Computer Telephony Integration) registrierte ausgehende Anrufe nicht korrekt. Die traditionellen Metriken zeigten uns, dass die Maschinen in Ordnung waren, aber die *Agenten* (und damit das Geschäft) waren eindeutig nicht in Ordnung.
Da wurde mir klar, dass wir aufhören mussten, nur die Infrastruktur zu überwachen und anfangen mussten, das Verhalten und die Zustandsübergänge der Agenten zu beobachten. Es ist nicht genug, nur zu wissen, ob eine Agentenanwendung läuft; wir müssen wissen, *was* diese Anwendung denkt, was der Agent tut, und ob das mit der Realität übereinstimmt.
Das Problem bei der bloßen Überwachung von Metriken
Denkt an euer Auto. Wenn eure Motorleuchte angeht, ist das eine Metrik. Sie sagt euch, dass *etwas* nicht stimmt. Aber sie sagt euch nicht, *was*. Ist es ein loser Benzinkopf? Ein ausfallender Sauerstoffsensor? Ein katastrophaler Motorschaden? Ihr braucht mehr Kontext, mehr interne Sichtbarkeit, um das Problem wirklich zu verstehen.
Traditionelle Überwachung ist wie das Motorlicht. Es sagt euch, *ob* eine Ressource eingeschränkt ist oder *ob* ein Dienst ausgefallen ist. Aber für komplexe, zustandsbehaftete Agenten, insbesondere solche, die mit mehreren Systemen (CRM, Telefonie, Wissensdatenbank, benutzerdefinierte Skripte) interagieren, gibt euch eine einfache Metrik oft nicht das gesamte Bild. Ein Agent könnte „eingeloggt“ sein (laut eurer grundlegenden Präsenzüberwachung), aber effektiv eingefroren sein, unfähig, irgendwelche Aktionen auszuführen, aufgrund eines subtilen Deadlocks in der Zustandsmaschine ihrer Anwendung.
Dies haben wir eindrucksvoll mit unserem Callcenter-Kunden erlebt. Unsere grundlegende Überwachung zeigte, dass die Agenten im CRM angemeldet waren. Ihre Netzwerkverbindung war in Ordnung. Die CPU war normal. Dennoch wurden keine Anrufe bearbeitet. Bei näherer Untersuchung fanden wir heraus, dass eine bestimmte Abfolge von Aktionen (einen Anruf übertragen und dann sofort versuchen, auf die Zahlungshistorie eines Kunden zuzugreifen) dazu führte, dass der interne Zustand des CRM für diesen Agenten in einer „Warten auf Antwort des externen Dienstes“-Schleife festhing, selbst nachdem der externe Dienst geantwortet hatte. Die Anwendung stürzte nicht ab; sie war einfach aus der Sicht des Agenten in einem nicht reaktionsfähigen Zustand eingefroren. Keine Metrik hätte das erkannt.
Beobachtbarkeit für Agentenzustände: Was es bedeutet
Für mich bedeutet Beobachtbarkeit in diesem Kontext, die Anwendungen und Workflows der Agenten so auszustatten, dass sie detaillierte, strukturierte Daten über ihre internen Zustandsänderungen, Ereignisse und Kontexte ausgeben. Es geht darum, Folgendes zu fragen:
- Was macht der Agent *gerade* laut der Anwendung? (z. B. „Im Anruf“, „Nachbereitung“, „Verfügbar“, „Training“, „Pausiert“)
- Was war der *vorherige Zustand*?
- Welche *Ereignisse* haben die Zustandsänderung ausgelöst? (z. B. „Eingehender Anruf“, „Anruf beantwortet“, „Manuell Pause-Taste gedrückt“)
- Welcher *Kontext* ist mit diesem Zustand verbunden? (z. B. Anruf-ID, Kunden-ID, Grund für die Pause, Dauer im aktuellen Zustand)
Das ist nicht nur das Protokollieren von Fehlern; es ist das Protokollieren der *Reise* eines Agenten durch seinen Arbeitstag, Schritt für Schritt, mit reichlich Kontext.
Beispiel 1: Verfolgen von Agentenworkflow-Zuständen
Angenommen, ihr habt eine benutzerdefinierte Agenten-Desktopanwendung. Anstatt nur zu überwachen, ob der Prozess läuft, wollt ihr den internen Zustand kennen. Ihr könnt strukturierte Protokolle oder Traces ausgeben, wann immer sich ein wichtiger Zustand ändert.
// Innerhalb eurer Agenten-Desktopanwendung (Pseudo-Code)
enum AgentState {
LoggedIn,
Verfügbar,
ImAnruf,
Nachbereitung,
Pausiert,
Offline
}
currentAgentState = AgentState.Offline;
function transitionState(newState, eventDetails = {}) {
const timestamp = new Date().toISOString();
const agentId = getAgentId(); // Aus dem Anwendungskontext abrufen
const sessionId = getCurrentSessionId(); // Aus dem Anwendungskontext abrufen
// Protokolliere den Zustandsübergang mit reichhaltigem Kontext
console.log(JSON.stringify({
timestamp: timestamp,
agentId: agentId,
sessionId: sessionId,
oldState: currentAgentState.toString(),
newState: newState.toString(),
eventType: eventDetails.type || "STATE_CHANGE",
eventData: eventDetails.data || {}
}));
currentAgentState = newState;
}
// Beispielnutzung:
// Wenn ein Agent einen Anruf annimmt:
transitionState(AgentState.ImAnruf, { type: "ANRUF_ANTWORTEN", data: { callId: "12345", customerId: "98765" } });
// Wenn ein Agent in die Nachbereitung geht:
transitionState(AgentState.Nachbereitung, { type: "ANRUF_ENDE", data: { callId: "12345", dispositionTime: 30 } });
// Wenn ein Agent manuell pausiert:
transitionState(AgentState.Pausiert, { type: "MANUELLE_PAUSE", data: { reason: "Pause", duration: 15 } });
Das ist doch keine Raketenwissenschaft, oder? Aber die Kraft zeigt sich, wenn ihr diese Ereignisse zentral sammelt. Ihr könnt dann Dashboards erstellen, die die aktuellen Agentenzustände in Echtzeit anzeigen, Agenten identifizieren, die in unerwarteten Zuständen feststecken, und sogar Muster der Zustandsübergänge analysieren, um Engpässe im Workflow zu erkennen.
Beobachtbarkeit in euer Agenten-Tooling einbauen
Es geht nicht nur darum, ein paar Print-Anweisungen hinzuzufügen. Es erfordert einen überlegten Ansatz zur Instrumentierung. So haben wir es angepackt:
1. Definiert wichtige Agentenzustände und Übergänge
Bevor ihr irgendeinen Code schreibt, setzt euch mit euren Produktmanagern, Teamleitern und sogar einigen Agenten zusammen. Zeichnet die kritischen Zustände auf, in denen ein Agent sein kann, und die legitimen Möglichkeiten, wie sie zwischen ihnen wechseln. Das wird eure „Grundwahrheit“ dafür, wie ein gesunder Agentenworkflow aussieht. Dokumentiert dies ausdrücklich.
2. Instrumentiert alles Relevante
In euren Agentenanwendungen (Desktop, Web, Backend-Services, die Agenten unterstützen) solltet ihr strukturierte Protokolle oder Traces bei jeder signifikanten Zustandsänderung oder jedem Ereignis ausgeben. Konzentriert euch auf:
- Zustandsänderungen: Wenn sich der Status eines Agenten ändert (z. B. von „Verfügbar“ zu „Im Anruf“).
- Schlüsselaktionen: Wenn ein Agent eine kritische Aktion ausführt (z. B. „Anruf übertragen“, „Kundenakte aktualisieren“, „Formular einreichen“).
- Interaktionen mit externen Systemen: Wenn die Agentenanwendung mit einem CRM, Telefonsystem oder einer Datenbank interagiert. Protokolliert die Anfrage, die Antwort und eventuelle Fehler.
3. Nutzt strukturiertes Logging
JSON ist hier euer Freund. Protokolliert nicht einfach nur reinen Text. Strukturierte Protokolle erleichtern es extrem, eure Daten später zu parsen, zu filtern und zu analysieren. Fügt in jedem Protokolleintrag gängige Attribute hinzu (Zeitstempel, Agenten-ID, Sitzungs-ID, Anwendungs-Version) und spezifische Attribute für jeden Ereignistyp.
4. Zentralisieren und Analysieren
Sendet all diese Protokolle an ein zentrales Protokollierungssystem (Elasticsearch, Splunk, Loki, DataDog usw.). Dort geschieht die Magie. Jetzt könnt ihr:
- Echtzeit-Dashboards erstellen: Visualisiert den aktuellen Zustand aller Agenten, identifiziert Ausreißer (z. B. Agenten, die zu lange im „Nachbereitung“-Zustand hängen bleiben).
- Abfragen und Filtern: Findet schnell alle Ereignisse für einen bestimmten Agenten, Kunden oder Anruf-ID.
- Alarme bei Anomalien einrichten: Setzt Alarme für unerwartete Zustandsübergänge oder Dauer (z. B. „Alarm, wenn ein Agent länger als 30 Minuten im Zustand ‚Pausiert‘ ohne gültigen Grundcode ist“).
- Workflows nachverfolgen: Folgt der Reise eines Agenten durch einen komplexen Prozess, indem ihr verwandte Protokolleinträge verknüpft.
Beispiel 2: Erkennung von feststeckenden Agenten mit Protokollanalyse
Wenn ihr ein Protokollierungssystem wie Elasticsearch mit Kibana verwendet, könntet ihr eine Abfrage einrichten, um Agenten zu finden, die in einem unerwünschten Zustand feststecken. Stellt euch vor, ihr sucht nach Agenten, die in den Zustand „Nachbereitung“ eingetreten sind, aber seit mehr als 5 Minuten nicht mehr gewechselt haben.
// Elasticsearch-Abfrage (Kibana Discover oder Dev Tools)
{
"query": {
"bool": {
"must": [
{ "match": { "newState.keyword": "WrapUp" } },
{ "range": { "timestamp": { "lte": "now-5m" } } }
],
"must_not": [
{ "exists": { "field": "nextState" } } // Angenommen, ihr würdet ein „nextState“ oder „transitionedOut“-Ereignis protokollieren
]
}
},
"aggs": {
"stuck_agents": {
"terms": {
"field": "agentId.keyword",
"size": 100
}
}
}
}
Diese Abfrage würde euch eine Liste von Agenten-IDs geben, die den Zustand „Nachbereitung“ vor mehr als 5 Minuten erreicht haben und keinen anschließenden Zustandswechsel protokolliert haben. Dies ist eine sehr wirkungsvolle Möglichkeit, Probleme proaktiv zu erkennen und anzugehen, bevor sie eskalieren.
Meine Erkenntnisse und umsetzbare Schritte
Wenn Sie Agenten verwalten, egal ob sie menschlich oder automatisierte Bots sind, müssen Sie dringend über eine grundlegende Uptime-Überwachung hinausgehen. Hier sind meine Empfehlungen:
- Hören Sie auf, nur Ressourcen zu überwachen, und beginnen Sie, Zustände zu beobachten: Verlagern Sie Ihren Fokus von „Ist die CPU hoch?“ zu „Was macht die Agentenanwendung *gerade* und ist das korrekt?“
- Dokumentieren Sie Ihre Agenten-Workflows: Halten Sie jeden signifikanten Zustand, in dem sich ein Agent befinden kann, und die gültigen Übergänge fest. Dies ist Ihr Plan für die Observierbarkeit.
- Instrumentieren Sie Ihre Agentenanwendungen: Integrieren Sie strukturiertes Logging oder Tracing direkt in Ihre Agenten-Tools. Jede kritische Zustandsänderung oder Aktion sollte ein detailliertes Ereignis erzeugen. Verwenden Sie JSON.
- Centralisieren Sie Ihre Daten: Bringen Sie diese Ereignisse in ein System, in dem Sie sie abfragen, visualisieren und darauf reagieren können.
- Erstellen Sie proaktive Warnmeldungen: Warten Sie nicht darauf, dass Agenten sich beschweren. Richten Sie Warnungen für unerwartete Zustandsdauern oder ungültige Übergänge ein. Wenn ein Agent beispielsweise im Zustand „WrapUp“ im Durchschnitt länger als 180 Sekunden bleibt, alarmieren Sie. Wenn ein Agent versucht, einen Anruf im Zustand „Paused“ anzunehmen, alarmieren Sie.
- Schulen Sie Ihre Teams: Zeigen Sie Ihren Support-, Betriebs- und Produktteams, wie sie diese neuen Dashboards und Abfragen verwenden können. Je mehr Augen auf die Daten gerichtet sind, desto schneller werden Sie Probleme erkennen.
Dies ist kein einmaliges Projekt. Es ist ein fortlaufender Prozess, bei dem Sie Ihre Instrumentierung verfeinern, Ihre Dashboards verbessern und tiefere Fragen zur Erfahrung Ihrer Agenten stellen. Aber ich verspreche Ihnen, die Investition lohnt sich. Wir sind von reaktivem Feuerlöschen zu einer proaktiven Identifizierung und Lösung von agentenbezogenen Problemen innerhalb von Minuten übergegangen, manchmal sogar bevor der Agent selbst ein Problem bemerkte. Es hat die Einhaltung der SLA unserer Kunden verbessert, die Frustration der Agenten reduziert und ehrlich gesagt meinen Job viel weniger stressig gemacht. Und das ist im März 2026 für mich ein Gewinn.
Haben Sie Gedanken zur Observierbarkeit von Agenten? Hinterlassen Sie mir einen Kommentar unten!
Verwandte Artikel
- KI-agentenbasiertes, loggesteuertes Entwickeln
- Meine Debugging-Strategie: Von Chaos zu Ruhe
- KI-Agenten-Logging in der Produktion
🕒 Published: