Hallo zusammen, hier ist Chris Wade, zurück auf agntlog.com. Wir sind im März 2026, und ehrlich gesagt, wenn Sie immer noch darüber nachdenken, Ihre Agenten zu überwachen, wie wir es vor fünf Jahren getan haben, lassen Sie Geld, mentale Gesundheit und vielleicht sogar Ihren Job auf dem Tisch liegen. Die Welt hat sich weiterentwickelt, und Ihre Strategie sollte das auch. Heute möchte ich über etwas Spezifisches sprechen, etwas, das mich in letzter Zeit beschäftigt hat (und mir sehr geholfen hat): Observability für die Zustände von Agenten, nicht nur für Metriken.
Ich weiß, „Observability“ ist ein Modewort, das wie ein Frisbee bei einem Technologie-Picknick herumgeworfen wird. Aber hören Sie mir zu. Für uns im Bereich der Agentenüberwachung ist es nicht nur ein Modewort; es ist ein grundlegender Wandel in unserem Verständnis unserer Systeme. Wir betrachten nicht mehr nur die CPU-Nutzung oder den Speicherverbrauch. Wir versuchen, den *internen Zustand* unserer Agenten, ihren Verlauf durch einen Workflow und die subtilen Signale zu verstehen, die uns anzeigen, dass etwas schiefgehen könnte – oder es bereits tut.
Mein Weg dorthin begann vor etwa anderthalb Jahren. Wir hatten einen neuen Kunden, ein riesiges Callcenter mit Tausenden von Agenten, die unsere maßgeschneiderte CRM-Integration nutzten. Der alte Überwachungsansatz scheiterte spektakulär. Wir hatten Dashboards, die rot aufleuchteten für „hohe CPU-Nutzung“ oder „wenig Speicherplatz“ auf den Arbeitsplätzen der Agenten, aber das eigentliche Problem, das Kundenbeschwerden und verpasste SLAs verursachte, war tiefer. Die Agenten blieben unbestimmt im Zustand „Nach dem Anruf“ stecken oder ihre CTI (Computer-Telefon-Integration) registrierte ausgehende Anrufe nicht korrekt. Die traditionellen Metriken sagten uns, dass die Maschinen in Ordnung waren, aber die *Agenten* (und damit das Unternehmen) waren es offensichtlich nicht.
Da wurde mir klar, dass wir aufhören mussten, nur die Infrastruktur zu überwachen und anfangen mussten, das Verhalten der Agenten und die Zustandsübergänge zu beobachten. Es reicht nicht aus zu wissen, ob die Anwendung eines Agenten funktioniert; wir müssen wissen, *was* diese Anwendung denkt, dass der Agent tut, und ob das mit der Realität übereinstimmt.
Das Problem der Nur-Metriken-Überwachung
Denken Sie an Ihr Auto. Wenn die Motorleuchte angeht, ist das eine Metrik. Sie sagt Ihnen, dass *etwas* nicht stimmt. Aber sie sagt Ihnen nicht, *was*. Ist es ein falsch aufgesetzter Tankdeckel? Ein defekter Sauerstoffsensor? Ein katastrophaler Motorschaden? Sie benötigen mehr Kontext, mehr interne Sichtbarkeit, um das Problem wirklich zu verstehen.
Traditionelle Überwachung ist wie diese Motorleuchte. Sie sagt Ihnen, *ob* eine Ressource belastet ist oder *ob* ein Dienst offline ist. Aber für komplexe und zustandsbehaftete Agenten, insbesondere solche, die mit mehreren Systemen (CRM, Telefonie, Wissensdatenbank, maßgeschneiderte Skripte) interagieren, gibt Ihnen eine einfache Metrik oft nicht die Gesamtübersicht. Ein Agent kann „verbunden“ sein (laut Ihrer grundlegenden Anwesenheitsüberwachung), aber tatsächlich eingefroren, unfähig, Aktionen auszuführen, aufgrund eines subtilen Blockierungsproblems in der Zustandsmaschine seiner Anwendung.
Wir haben dies eindrucksvoll bei unserem Callcenter-Kunden gesehen. Unsere grundlegende Überwachung zeigte, dass die Agenten mit dem CRM verbunden waren. Ihre Netzwerkverbindung war in Ordnung. Die CPU war normal. Dennoch wurden die Anrufe nicht bearbeitet. Bei näherer Betrachtung entdeckten wir, dass eine spezifische Abfolge von Aktionen (einen Anruf übertragen und dann sofort versuchen, auf die Zahlungshistorie eines Kunden zuzugreifen) dazu führte, dass der interne Zustand des CRMs für diesen Agenten in einer Schleife von „Warten auf Antwort eines externen Dienstes“ stecken blieb, selbst nachdem der externe Dienst geantwortet hatte. Die Anwendung stürzte nicht ab; sie war einfach in einem nicht reaktionsfähigen Zustand aus der Sicht des Agenten eingefroren. Keine Metrik hätte dies erkennen können.
Observability für die Zustände von Agenten: Was das bedeutet
Für mich bedeutet Observability in diesem Kontext, Ihre Anwendungen und Agenten-Workflows mit der Fähigkeit auszustatten, detaillierte und strukturierte Daten über ihre internen Zustandsänderungen, Ereignisse und Kontexte auszugeben. Es geht darum zu fragen:
- Was macht der Agent *gerade* laut der Anwendung? (zum Beispiel „Im Anruf“, „In der Zusammenfassung“, „Verfügbar“, „Schulung“, „Pausiert“)
- Was war der *vorherige Zustand*?
- Welche *Ereignisse* haben den Zustandswechsel ausgelöst? (zum Beispiel „Eingehender Anruf“, „Anruf beantwortet“, „Manuell auf Pause gedrückt“)
- Welcher *Kontext* ist mit diesem Zustand verbunden? (zum Beispiel Anruf-ID, Kunden-ID, Grund für die Pause, Dauer im aktuellen Zustand)
Es geht nicht nur darum, Fehler zu protokollieren; es geht darum, den *Weg* eines Agenten durch seinen Arbeitstag Schritt für Schritt mit reichhaltigem Kontext festzuhalten.
Beispiel 1: Verfolgen der Zustände von Agenten-Workflows
Angenommen, Sie haben eine maßgeschneiderte Agenten-Desktopanwendung. Anstatt einfach zu überwachen, ob der Prozess funktioniert, möchten Sie seinen internen Zustand kennen. Sie können strukturierte Protokolle oder Traces ausgeben, jedes Mal wenn sich ein wichtiger Zustand ändert.
// In Ihrer Agenten-Desktopanwendung (Pseudo-Code)
enum AgentState {
LoggedIn,
Available,
OnCall,
WrapUp,
Paused,
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
// Protokollieren Sie 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;
}
// Beispielverwendung :
// Wenn ein Agent einen Anruf beantwortet :
transitionState(AgentState.OnCall, { type: "CALL_ANSWERED", data: { callId: "12345", customerId: "98765" } });
// Wenn ein Agent in die Zusammenfassung wechselt :
transitionState(AgentState.WrapUp, { type: "CALL_ENDED", data: { callId: "12345", dispositionTime: 30 } });
// Wenn ein Agent manuell pausiert :
transitionState(AgentState.Paused, { type: "MANUAL_PAUSE", data: { reason: "Break", duration: 15 } });
Das ist keine Raketenwissenschaft, oder? Aber die Kraft liegt in der zentralisierten Erfassung dieser Ereignisse. Sie können dann Dashboards erstellen, die die Zustände der Agenten in Echtzeit anzeigen, Agenten identifizieren, die in unerwarteten Zuständen feststecken, und sogar Muster von Zustandsübergängen analysieren, um Engpässe in den Workflows zu erkennen.
Integrating Observability into Your Agent Management Tool
Es geht nicht nur darum, ein paar Druckanweisungen hinzuzufügen. Es erfordert einen durchdachten Ansatz zur Instrumentierung. So haben wir es angegangen:
1. Definieren Sie die Schlüsselzustände und -übergänge der Agenten
Bevor Sie Code schreiben, setzen Sie sich mit Ihren Produktmanagern, Teamleitern und sogar einigen Agenten zusammen. Kartieren Sie die kritischen Zustände, in denen sich ein Agent befinden kann, und die legitimen Wege, wie er von einem Zustand in einen anderen wechseln kann. Das wird Ihre „Basiswahrheit“ darüber, wie ein gesunder Workflow für einen Agenten aussieht. Dokumentieren Sie dies ausdrücklich.
2. Instrumentieren Sie alles, was relevant ist
In Ihren Agentenanwendungen (Desktop, Web, Backend-Dienste, die die Agenten unterstützen) geben Sie strukturierte Protokolle oder Traces bei jeder signifikanten Zustandsänderung oder jedem Ereignis aus. Konzentrieren Sie sich auf:
- Zustandsänderungen: Wenn sich der Zustand eines Agenten ändert (zum Beispiel von „Verfügbar“ zu „Im Anruf“).
- Schlüsselaktionen: Wenn ein Agent eine kritische Aktion ausführt (zum Beispiel „Anruf übertragen“, „Kundendaten aktualisieren“, „Formular einreichen“).
- Interaktionen mit externen Systemen: Wenn die Anwendung des Agenten mit einem CRM, einem Telefonsystem oder einer Datenbank interagiert. Protokollieren Sie die Anfrage, die Antwort und alle Fehler.
3. Verwenden Sie strukturierte Protokolle
JSON ist hier Ihr Freund. Geben Sie nicht einfach nur Klartext aus. Strukturierte Protokolle erleichtern die Analyse, das Filtern und das Verständnis Ihrer Daten erheblich. Fügen Sie in jedem Protokolleintrag gemeinsame Attribute (Zeitstempel, Agenten-ID, Sitzungs-ID, Anwendungsversion) und spezifische Attribute für jeden Ereignistyp hinzu.
4. Zentralisieren und Analysieren
Leiten Sie all diese Protokolle an ein zentrales Protokollierungssystem (Elasticsearch, Splunk, Loki, DataDog usw.) weiter. Dort geschieht die Magie. Jetzt können Sie:
- Echtzeit-Dashboards erstellen: Visualisieren Sie den aktuellen Status aller Agenten, identifizieren Sie Ausreißer (zum Beispiel Agenten, die zu lange im „WrapUp“-Status feststecken).
- Abfragen und Filtern: Finden Sie schnell alle Ereignisse für einen bestimmten Agenten, Kunden oder Anruf-ID.
- Auf Anomalien hinweisen: Richten Sie Alarme für Statusübergänge oder unerwartete Dauern ein (zum Beispiel: „Alarmieren, wenn ein Agent länger als 30 Minuten im Status ‚Paused‘ ohne gültigen Grundcode ist“).
- Arbeitsabläufe verfolgen: Verfolgen Sie den Verlauf eines Agenten durch einen komplexen Prozess, indem Sie die zugehörigen Protokolle verknüpfen.
Beispiel 2: Blockierte Agenten mit Protokollanalyse erkennen
Mit einem Protokollierungssystem wie Elasticsearch mit Kibana könnten Sie eine Abfrage einrichten, um blockierte Agenten in einem unerwünschten Zustand zu finden. Stellen Sie sich vor, Sie suchen nach Agenten, die in den Status „WrapUp“ eingetreten sind, aber seit mehr als 5 Minuten nicht mehr herausgekommen sind.
// Elasticsearch-Abfrage (Kibana Discover oder Dev Tools)
{
"query": {
"bool": {
"must": [
{ "match": { "newState.keyword": "WrapUp" } },
{ "range": { "timestamp": { "lte": "now-5m" } } }
],
"must_not": [
{ "exists": { "field": "nextState" } } // Vorausgesetzt, Sie protokollieren ein Ereignis "nextState" oder "transitionedOut"
]
}
},
"aggs": {
"stuck_agents": {
"terms": {
"field": "agentId.keyword",
"size": 100
}
}
}
}
Diese Abfrage würde Ihnen eine Liste von Agenten-IDs geben, die vor mehr als 5 Minuten in den Status „WrapUp“ eingetreten sind und danach kein Statuswechselereignis protokolliert wurde. Dies ist ein sehr effektives Mittel, um Probleme proaktiv zu identifizieren und anzugehen, bevor sie sich verschlimmern.
Mein Feedback und umsetzbare Schritte
Wenn Sie Agenten verwalten, seien es Menschen oder automatisierte Bots, sollten Sie unbedingt über eine einfache Überwachung der Betriebszeit hinausgehen. Hier sind meine Empfehlungen:
- Hören Sie auf, nur Ressourcen zu überwachen, und beginnen Sie, die Zustände zu beobachten: Ändern Sie Ihren Fokus von „Ist die CPU hoch?“ zu „Was macht die Anwendung des Agenten gerade, und ist das korrekt?“
- Kartieren Sie Ihre Agenten-Workflows: Dokumentieren Sie jeden signifikanten Zustand, in dem sich ein Agent befinden kann, sowie die gültigen Übergänge. Dies ist Ihr Plan für die Beobachtbarkeit.
- Instrumentieren Sie Ihre Agenten-Anwendungen: Integrieren Sie strukturierte Protokollierung oder Tracing direkt in Ihre Agenten-Tools. Jeder kritische Statuswechsel oder jede Aktion sollte ein detailliertes Ereignis auslösen. Verwenden Sie JSON.
- Centralisieren Sie Ihre Daten: Senden Sie diese Ereignisse in ein System, in dem Sie abfragen, visualisieren und Alarme einrichten können.
- Richten Sie proaktive Alarme ein: Warten Sie nicht, bis die Agenten sich beschweren. Richten Sie Alarme für unerwartete Statusdauern oder ungültige Übergänge ein. Zum Beispiel, wenn ein Agent im Durchschnitt länger als 180 Sekunden im Status „WrapUp“ bleibt, alarmieren Sie. Wenn ein Agent versucht, einen Anruf anzunehmen, während er sich im Status „Paused“ befindet, alarmieren Sie.
- Schulen Sie Ihre Teams: Zeigen Sie Ihren Support-, Betriebs- und Produktteams, wie sie diese neuen Dashboards und Abfragen nutzen können. Je mehr Augen auf die Daten gerichtet sind, desto schneller erkennen Sie Probleme.
Dies ist kein einmaliges Projekt. Es ist ein kontinuierlicher Prozess, Ihre Instrumentierung zu verfeinern, Ihre Dashboards zu verbessern und tiefere Fragen zur Erfahrung Ihrer Agenten zu stellen. Aber ich verspreche Ihnen, die Investition lohnt sich. Wir sind von einem reaktiven Kampf zu einer proaktiven Identifizierung und Lösung von Problemen übergegangen, die Agenten innerhalb von Minuten betreffen, manchmal sogar bevor der Agent selbst ein Problem bemerkt. Dies hat die Einhaltung der SLA unserer Kunden verbessert, die Frustration der Agenten verringert und ehrlich gesagt meine Arbeit viel weniger stressig gemacht. Und das ist im März 2026 für mich ein Sieg.
Haben Sie Gedanken zur Beobachtbarkeit von Agenten? Lassen Sie es mich in den Kommentaren unten wissen!
Verwandte Artikel
- Entwicklung, die von den Protokollen von AI-Agenten gesteuert wird
- Meine Debugging-Strategie: Vom Chaos zur Ruhe
- Protokollierung von AI-Agenten in der Produktion
🕒 Published: