Sagen Sie uns, wie wir helfen können

Vertrieb & Preise

Speak to a rep about your business needs

Vertrieb kontaktieren

Hilfe & Support

See our product support options

Support kontaktieren

Allgemeine Anfragen und Standorte

Kontakt

Beliebte Reiseziele

Wir verwenden KI-Tools, um unsere Inhalte in mehreren Sprachen bereitzustellen. Da diese Übersetzungen automatisiert sind, kann es zu Abweichungen zwischen der englischen und der übersetzten Version kommen. Die englische Version dieser Inhalte ist die offizielle Version. Kontaktieren Sie BMC, um mit einem Experten zu sprechen, der Ihre Fragen beantworten kann.

Beobachtbarkeit und Fehlerwiederherstellung für mehrstufige agentische KI-Workflows

Prognostizieren Sie das SLA-Risiko, bevor ein Vorfall eintritt. Modellüberwachung allein erkennt diese nachgelagerten Ausfälle nicht.

Entdecken Sie alle agentischen Fähigkeiten von Control-M

AI-Agenten-Workflow-Observabilität

Entdecken Sie die agentische Orchestrierung von Control-M

Wenn ein KI-Agent innerhalb eines Unternehmensprozesses eine Entscheidung trifft, landen die Konsequenzen woanders. Eine verwaltete Dateiübertragung wird ausgelöst, eine Datenpipeline startet, ein Batch-Job wird freigegeben oder ein System of Record wird aktualisiert. Die Arbeit verteilt sich auf die Systeme, die das Geschäft steuern, und dort wird eine schlechte Entscheidung zu einer verspäteten Zahlung, einer verpassten SLA oder einem nachgelagerten Ausfall, den niemand sieht, bis ein Kunde ihn sieht.

Die Werkzeuge, die zur Überwachung von KI-Modellen entwickelt wurden, zeigen gut, was das Modell macht, aber sie sind nicht darauf ausgelegt, zu sagen, was als Nächstes passiert. Control-M arbeitet auf der Ebene, auf der dieses "Nächste" passiert – wo Workflows ausgeführt werden, Abhängigkeiten aufgelöst werden und SLA-Verpflichtungen erfüllt oder verpasst werden. Diese Schicht hatte schon immer ihre eigenen Fehler, und agentische KI macht sie schwerer vorhersehbar und erschwert zu erholen.

Dieser Leitfaden behandelt diese Ausfälle und was nötig ist, um sie frühzeitig zu erkennen und sicher zu genesen.

Was Workflow-Observabilität bedeutet (und was sie nicht bedeutet)

Workflow-Observabilität ist Transparenz in die Ausführung eines mehrstufigen Geschäftsprozesses. Sie zeigt Ihnen den Zustand jedes Schrittes – laufend, wartend, abgeschlossen, fehlgeschlagen – und was diese Zustände für das Ergebnis bedeuten, das der Prozess liefern soll. Sie überwacht die Ausführungsschicht, nicht die Modellschicht.

Diese Unterscheidung ist bei agentischer KI wichtiger als in einer generativen KI-Welt, in der die Ausgabe des Modells größtenteils das Ende der Geschichte war. Jetzt beginnt diese Ausgabe mit der nachgelagerten Ausführung, und beide Schichten werden zu Live-Objekten, die nachverfolgt werden müssen. 

Die Modell-Observabilität beobachtet den Agenten: die Eingabeaufforderungen, die Tokennutzung, die Latenz eines Aufrufs, ob ein Output wie eine Halluzination aussieht.

Workflow-Observabilität beobachtet, was der Agent in Gang setzt: die Pipeline, die läuft, weil der Agent es für entschieden hat, die Übertragung, die abgeschlossen werden muss, bevor der nächste Schritt starten kann, die SLA, die davon abhängt, dass alles pünktlich abgeschlossen ist.

Ein Modellüberwachungstool kann Ihnen sagen, dass ein Agent ein bestimmtes Tool angerufen hat. Es kann Ihnen nicht sagen, dass der Auftrag, den der Anruf ausgelöst hat, jetzt vierzig Minuten hinterherhinkt und drei abhängige Dienste gefährdet sind. Das sind unterschiedliche Signale, die von unterschiedlichen Systemen verfolgt werden, und ein Unternehmen, das KI in der Produktion betreibt , benötigt beides.

Werkzeugverhalten

Modellbeobachtbarkeit

Workflow-Observabilität

Uhren

Der Agent

Was der Agent in Gang gesetzt hat

Strecken

Prompts, Token-Nutzung, Aufruflatenz, Ausgabequalität

Arbeitszustand, Abhängigkeiten, Zeitplan, SLA-Status

Kann ich dir sagen.

Ein Agent entschied sich, ein bestimmtes Werkzeug anzurufen

Der durch diesen Anruf ausgelöste Downstream-Job ist verspätet und bringt abhängige Dienste in Gefahr

Kann ich dir nicht sagen

Ob die Downstream-Umsetzung im Kurs ist

Ob die Ausgabe des Agenten eine Halluzination war

Workflow-Observabilität wird in einem agentischen Umfeld schwieriger, weil die Ausgabe eines Agenten weniger vorhersehbar ist als die eines geplanten Auftrags. Ein traditioneller Workflow führt dieselben Schritte in derselben Reihenfolge aus; wenn etwas kaputtgeht, dann an einem vertrauten Ort. Wenn ein Agent entscheiden kann, was als Nächstes zu tun ist, variiert die Form der Arbeit von Lauf zu Lauf, was bedeutet, dass die nachgelagerten Abhängigkeiten, das Timing und der Wiederherstellungspfad mehr Variationen aushalten müssen als ein fester Zeitplan, der je auferlegt wurde. Beobachtbarkeit auf der Workflow-Ebene ist die Art, wie ein Betriebsteam verhindert, dass diese Variation zu einem SLA-Verstoß wird, von dem es später erfährt.

Fehlermodi: Was auf der Workflow-Ebene schiefgeht

Die Fehler auf der Workflow-Ebene, die echten Schaden anrichten, sind diejenigen, bei denen der gemeldete Status und das tatsächliche Ergebnis nicht übereinstimmen. Wenn ein Job seinen Host nicht erreichen kann und Fehler ausgibt, stimmen Status und Ergebnis überein, und der Fehler wird behandelt. Die schwierigeren Fälle sind ruhiger: Der Prozess ist technisch in Ordnung; das Geschäftsergebnis nicht, und nichts im Status unterscheidet die beiden.

Vier dieser schwierigeren Fälle tauchen häufig auf.

  • Späte Ankunft: das Versagen, das fehlerbasierte Überwachung nicht erkennt
    Am häufigsten ist die verspätete Ankunft. Ein agentengesteuerter Schritt liefert seine Ausgabe später als erwartet, und jeder Schritt, der davon abhängt, erbt die Verzögerung. Eine Datenpipeline, die normalerweise vor Geschäftstagsbeginn abgeschlossen ist, läuft noch um 9 Uhr morgens. Eine Abstimmung, die vier Stunden Spielraum hatte, hat jetzt keine mehr. Es gab keinen Fehler, also wurde kein Alarm ausgelöst, aber die SLA ist bereits durchgebrannt; sie wurde nur noch nicht bemerkt. Verspätung ist der Ausfallmodus, den fehlerbasierte Überwachung einfach nicht erkennt, weil es kein Fehler ist.
  • Stiller Abhängigkeitsfehler: Wenn der Workflow abgeschlossen ist, das Ergebnis aber nicht mehr vertrauenswürdig ist
    Beim Silent Dependency Failure fehlschlägt ein Schritt auf eine Weise, die den Workflow nicht stoppt: Vielleicht gibt er einen Status zurück, den der nächste Schritt als gut genug behandelt, vielleicht scheitert er an einem Zweig, den nichts beobachtet. Der Prozess läuft auf einem Ergebnis weiter, auf das er sich nicht verlassen kann. Der Workflow wird abgeschlossen, aber der Abschluss ist eine Lüge. Wenn der Fehler auftaucht, hat sich das schlechte oder fehlende Ergebnis bereits in das nächste Ausführende ausgebreitet, und die Frage ist nicht mehr "Was ist gescheitert", sondern "Was haben wir auf dem Fehler aufgebaut?"
  • Teilweise Fertigstellung: wenn das Wiederholen nicht sicher ist
    Der     Teilabschluss ist der Fehlermodus, in dem "nochmal ausführen" nicht immer sicher ist. Ein Prozess kommt zur Hälfte und stoppt: Ein Host fällt aus, eine Zugangsdaten läuft ab, eine Verbindung bricht ab. Das lässt einige Schritte erledigt, andere nicht, und einige befinden sich in einem Zustand, bei dem niemand sicher ist. Ein erneutes Ausführen kann bereits erfolgreiche Arbeit wiederholen, eine Transaktion doppelposten oder eine Datei erneut senden. Sichere Wiederherstellung erfordert genau zu wissen, wo der Prozess gestoppt wurde und was ohne Schaden fortgesetzt werden kann.
  • Runaway Retry: Wenn ein lokaler Fehler zu einem systemweiten SLA-Risiko wird.
    Der unkontrollierte Neuangriff beginnt mit einem Schritt, der nicht abgeschlossen werden kann, und versucht es erneut – und versucht es immer wieder, weil nichts begrenzt, wie oft es geht. Die gleiche Arbeit wird immer wieder versucht und verbraucht die Ausführungskapazität, die andere Jobs benötigen. Das unmittelbare Symptom ist kein Fehler, sondern ein Streit. Kritische Pfad-Arbeit verlangsamt sich, weil ein feststeckender Prozess anderswo die Ressourcen verbraucht, auf die er angewiesen war. Der Fehler ist lokal, aber das SLA-Risiko ist systemweit.

Trotz all ihrer Unterschiede offenbaren diese vier Fehler denselben blinden Fleck: In jedem von ihnen reichen die durch fehlerbasierten Überwachungen sichtbaren Informationen nicht aus, um zu sagen, ob das Geschäftsergebnis sicher ist. Um solche Fehler auf der Workflow-Ebene zu erkennen, braucht es nicht nur Transparenz darüber, ob Schritte sauber ablaufen, sondern auch ihre Upstream- und Downstream-Abhängigkeiten sowie die Verpflichtungen, gegen die sie angesetzt sind. Bei drei dieser Fehler reicht es aus, die Ausführung richtig zu beobachten. Der vierte erfordert noch mehr: eine Erkennung, die nicht darauf wartet, dass ein Betreiber das abnormale Muster bemerkt.

Wie Transparenz in diese Misserfolge aussieht

Drei Arten von Sichtbarkeit auf Workflow-Ebene leisten den Großteil der Arbeit gegen diese Ausfälle, während zwei KI-Fähigkeiten noch weiter gehen.

Die Ansicht des Dienstes: Eine SLA-Verletzung zu sehen, bevor sie passiert

Die erste ist die Service-Ansicht – die Ebene über einzelnen Jobs, in der eine Reihe von Schritten als der Geschäftsdienst verstanden wird, zu dem sie sich summiert. Das Service Management von Control-M identifiziert kritische Flows und liefert prädiktive SLA-Risiko-Transparenz, indem es verfolgt, ob kritische Jobs auf dem richtigen Weg sind, wenn sie es müssen. Dies ist die Erhebung, in der die Verspätung lesbar wird: nicht "Job 47 ist lang", sondern "der Service, zu dem Job 47 gehört, wird sein Zeitfenster verpassen." Ein Betreiber, der den Service beobachtet, nicht nur den Job, kann einen SLA-Verstoß bevorstehen, solange noch Zeit ist, ihn zu verhindern.

Die Abhängigkeitssicht: nachzuverfolgen, was ein Scheitern mit sich bringt

Der zweite ist die Abhängigkeitsansicht – eine Karte, wie die Schritte in einem Prozess verbunden sind, welche welche speisen und wo ein bestimmter Job in der Kette liegt. Control-M stellt Workflows als visuell verbundene Jobs mit expliziten Abhängigkeiten dar, sodass ein Operator einen Workflow zusammen mit seinen Upstream- und Downstream-Beziehungen sehen kann, statt als eine flache Liste von Jobs. Das verwandelt einen stillen Abhängigkeitsfehler von einem Rätsel in einen Ort: Wenn ein Schritt ein Ergebnis zurückgibt, dem der nächste Schritt nicht vertrauen sollte, zeigt die Abhängigkeitsansicht alles, was stromabwärts davon liegt und nun auf Sand aufgebaut ist.

Die staatliche Sichtweise: genau wissen, wo ein Prozess steht

Der dritte ist die Zustandsansicht – die Fähigkeit, jederzeit genau zu sehen, wo ein Prozess ist: was abgeschlossen ist, was läuft, was wartet und worauf, was gescheitert ist. Die Viewpoints von Control-M machen Ausfälle, Wartezeiten und Engpässe auf einen Blick sichtbar und ermöglichen es einem Bediener, vom Symptom bis zum spezifischen Auftrag und dessen Protokollen zu bohren. Das ist es, was eine Erholung nach einem Teilabschluss erfordert: genau zu wissen, wo der Prozess gestoppt hat und welchen Zustand er hinterlassen hat.

Control-M-KI-Fähigkeiten für die Beobachtbarkeit von KI-Agenten

KI-Pilot zur Überwachung: vom Erkennen eines Scheiterns bis zum Verständnis

Darauf kommt eine neuere Schicht. Control-M's AI Pilot for Monitoring, verfügbar in Control-M SaaS, wendet KI auf dieselben Ausführungsdaten an, die ein Bediener manuell lesen würde. Gibt es einen Job, der als Nicht OK endete oder auf einen Host wartet, arbeitet seine Job-Statusanalyse anhand der Ausgabe, Logs, Definition und Hoststatus, um die wahrscheinliche Ursache zu erklären und eine Korrekturmaßnahme zu empfehlen. Seine Workflow-Analyse beschreibt hingegen die Struktur und den Zweck des Workflows, zu dem der Job gehört. AI Pilot sieht nichts, was der Bediener nicht sehen könnte; es liest dieselben Signale schneller aus und legt den wahrscheinlichen Grund sowie eine vorgeschlagene Lösung dem Bediener vor. Wo die Service-, Abhängigkeits- und Zustandsansichten einen Fehler lesbar machen, verkürzt diese Schicht die Distanz zwischen dem Sehen und dem Verstehen.

Execution Insights: Einen unkontrollierten Versuch erwischen, bevor er zur Krise wird

Der außer Kontrolle geratene Wiederholung erfordert etwas anderes: ein Muster zu erkennen, bevor es zur Krise wird, anstatt einen bereits sichtbaren Fehler zu diagnostizieren. Die Execution Insights von Control-M, verfügbar in Control-M SaaS, wendet Anomalieerkennung auf ein laufendes Fenster der aktuellen Jobhistorie an und markiert Jobs, die weit außerhalb ihres normalen Verhaltens liegen, zusammen mit späten Starts, Warteschlangenaufbau und Nebenzeitenspitzen, die die Press-Batch-Leistung belasten. Sie zeigt auf die spezifischen Jobs, die den Druck verursachen, nicht auf die, die nur darunter leiden, und zeigt das Muster früh genug, um den Schaden einzudämmen. Ein frühes Erfassen eines Retry-Sturms verhindert, dass ein lokaler Fehler eine Kette kritischer Jobs mit sich reißt.

Genesung: Was eine sichere Reaktion erfordert

Einen Fehler zu sehen ist die erste Hälfte des Problems. Die zweite ist, darauf zu reagieren, ohne die Situation zu verschlimmern – und hier unterscheidet sich die Erholung von einem agentengetriebenen Prozess am deutlichsten von einer normalen. Wenn die fehlgeschlagene Arbeit vorhersehbar war, ist die Lösung oft auch: den Auftrag erneut ausführen, die Pipeline fortsetzen, weitermachen. Wenn die Entscheidungen eines Agenten das Ergebnis bestimmten, können diese reflexartigen Korrekturen nicht als sicher angesehen werden.

Wenn-Aktionen: Kodierung der Wiederherstellung im Voraus

Manche Fehler erfordern nicht, dass man weiß, was der Agent getan hat; sie erfordern lediglich, den Status des Auftrags zu kennen. Für diese erlaubt Control-M's If-Actions die Antwort in der Workflow-Definition zu kodieren – also Regeln festzulegen, was zu tun ist, wenn bestimmte Bedingungen erfüllt sind – bevor etwas schiefgeht: den Job erneut ausführen, wenn er Not OK endet, bis zu einer definierten Anzahl von Versuchen; einen erneuten Versuch stoppen, sobald eine Fehleranzahl erreicht ist, und stattdessen eine Warnung auslösen; einen Job auf einen bekannten Zustand setzen, seine Ausgabe an ein anderes Ziel weitergeben oder die Ereignisse hinzufügen und entfernen, die das Nächste ausführen. Die Wiederherstellungslogik ist für jeden Durchlauf gleich, für jeden, der den Workflow überprüft, sichtbar und durch im Voraus gesetzte Limits begrenzt, anstatt unter Druck improvisiert zu werden. (Das Prinzip der Codierungsbeschränkung vor dem Arbeiten gilt fürmehr als nur die Genesung in Control-M.)

Jett: Rekonstruktion, was passiert ist, bevor ich entscheide, was zu tun ist.

Für Ausfälle, bei denen man vor der Antwort verstehen muss, was passiert ist, ermöglicht Jett (Control-M's KI-Berater, verfügbar in Control-M SaaS) dem Bediener dieses Bild in klarer Sprache. Anstatt Logs und Statusbildschirme zu durchsuchen, kann er fragen, welche Aufträge ausgeführt wurden, was fehlgeschlagen ist, welchen Zustand sie hinterlassen haben und welche Maßnahmen ergriffen wurden, und die Antwort in Text, Tabellen oder Diagrammen erhalten. Dieser Kontext ist der Unterschied zwischen einer Wiederherstellungsentscheidung, die der Bediener mit Zuversicht treffen kann, und einer unter Druck mit teilweisen Transparenz.

KI-Pilot zur Überwachung: Ursache und empfohlene Maßnahmen, schnell.

Wenn ein Auftrag mit einem Fehlerstatus endet oder auf einen Host gestoppt ist, geht AI Pilot for Monitoring weiter als das gesamte Workflow-Gesamtbild von Jett. Ausgehend von der Ausgabe, den Protokollen, der Definition und dem Status des Wirts identifiziert es die wahrscheinliche Ursache und empfiehlt eine Korrekturmaßnahme, sodass der Bediener eine schnelle und fundierte Entscheidung treffen kann.

MCP-Server: gesteuert durch KI-Agenten

Der MCP Server, verfügbar in Control-M SaaS, bringt diese Funktion direkt zu KI-Agenten. Ein KI-Agent kann den Jobstatus abfragen, Logs abrufen und Behebungsaktionen ausführen: einen Job erneut ausführen, halten, freigeben, auf OK setzen. Ein Mensch muss nicht bei jedem Schritt im Loop sein. Der MCP Server kann eine Bestätigung verlangen, bevor eine Aktion ausgeführt wird, und dieselben rollenbasierten Zugriffskontrollen gelten, die alle anderen Aktionen in Control-M steuern.

In der Praxis kann derselbe Arbeitsablauf auf If-Actions angewiesen sein, um bekannte Fehler automatisch zu bearbeiten, während Jett und AI Pilot einen Operator für die Fehler vorbereitet, die menschliches Urteil erfordern. MCP Server fügt einen dritten Pfad hinzu: einen KI-Agenten, der direkt innerhalb desselben regulierten Rahmens wie alles andere handeln kann.

Prüfung, Rechenschaftspflicht und die Dokumentation, die den Lauf überdauert

Wenn ein Prozess abgeschlossen ist, hören die Fragen nicht auf. Wochen später fragt jemand, warum eine Figur falsch aussah, ob eine Kontrolle befolgt wurde, wer den defekten Schritt geändert hat oder was genau in der Nacht eines SLA abgelaufen ist. Die Beantwortung einer dieser Fragen hängt von der Spur ab, die der Prozess hinterlässt. (Für einen detaillierten Einblick, wie Control-M dokumentiert und beweist, was in KI-Workflows lief, siehe Audit-Ready Execution Lineage.)

Agentengesteuerte Arbeit erhöht die Einsätze auf diesem Datensatz. Wenn eine Person jeden Schritt initiierte, war der Verantwortlichkeit ein Name zugeordnet – man konnte fragen, wer es getan hat und warum. Wenn ein Agent zur Laufzeit entscheidet, was er ausführen soll, auf einem Weg, der von Ausführung zu Ausführung variiert, gibt es niemanden, den man fragen kann, der sich an die Details erinnert. Das Konto muss direkt aus dem System stammen.

Control-M verwaltet dieses Konto. Es erfasst nicht nur Ergebnisse, sondern auch Aktionen – die Aktionen des Benutzers gegen Jobs und Änderungen an Job-Definitionen – sodass die Frage "Wer das geändert hat?" eine Antwort hat, die nicht vom Speicher abhängt (und Jett kann sie in klarer Sprache darstellen).

Sein Archive Service speichert Workflow-Ausführungsdaten für die Audit-Abfrage und ermöglicht es Teams, einen aktuellen Lauf mit historischen zu vergleichen. Und da Control-M Mainframe-, Cloud- und Hybrid-Ausführung an einem Ort abdeckt, hinterlässt ein Prozess, der einen Mainframe-Batchjob, eine Cloud-Datenpipeline und eine Dateiübertragung berührt, einen nachverfolgbaren Datensatz statt drei teilweiser, verteilt auf drei Werkzeuge. 

Ein vollständiger, lesbarer Nachweis ist der Ort, an dem Beobachtbarkeit zur Rechenschaftspflicht wird.

KI-Agenten-Workflow-Observabilität FAQs