Fehlerbehandlung bei KI-Agenten: Wann fortsetzen, kompensieren oder stoppen?

Ein fehlgeschlagener Aufruf bedeutet nicht, dass die Aufgabe gescheitert ist

Ein Agent muss möglicherweise Informationen abrufen, einen Datensatz ändern und anschließend das Ergebnis mitteilen. Wenn mitten in diesem Ablauf die Antwort eines Tools ausbleibt, reicht es nicht, einfach zu entscheiden, ob der letzte Aufruf wiederholt werden soll. Vielleicht hat die Aktion das externe System gar nicht erreicht. Vielleicht wurde sie ausgeführt, aber lediglich die Bestätigung ging verloren. Oder die Änderung wurde nur teilweise übernommen. Für jeden dieser Fälle ist eine andere Entscheidung erforderlich.

In diesem Leitfaden bedeutet Wiederherstellung, das Ziel und den vom Agenten protokollierten Fortschritt mit dem überprüfbaren Zustand der Umgebung abzugleichen und anschließend eine sichere Fortsetzung oder einen ausdrücklichen Stopp zu wählen. Betrachtet wird die mehrstufige Aufgabe, nicht eine einzelne Anfrage. Das Wiederholen eines Aufrufs kann Teil der Wiederherstellung sein, definiert sie aber nicht.

Die zentrale Empfehlung ist einfach: Prüfen Sie zuerst, was außerhalb des Agenten geschehen ist, bevor Sie eine Aktion mit unbekanntem Ergebnis wiederholen. Lässt sich der Vorgang nicht zuverlässig verifizieren, darf die Unsicherheit nicht in eine zweite Änderung münden. Begrenzen Sie nachfolgende Aktionen und übergeben Sie den Fall an einen Menschen, wenn die möglichen Folgen eines Fehlers schwerer wiegen als eine Verzögerung.

Fehlerlandkarte: Erst einordnen, was tatsächlich bekannt ist

Ein expliziter Fehler beweist nicht immer, dass das externe System unverändert geblieben ist. Ebenso bedeutet ein Timeout lediglich, dass der Agent nicht rechtzeitig eine Antwort erhalten hat; für sich genommen sagt es nicht aus, ob der Vorgang abgeschlossen wurde. Ordnen Sie den Vorfall deshalb anhand der verfügbaren Belege ein und nicht anhand der Fehlerbezeichnung, die der Agent erhalten hat.

Unterscheiden Sie fünf Situationen. Bei einem bestätigten Fehlschlag lässt sich aus der Antwort schließen, dass die Aktion nicht ausgeführt wurde. Bei einem mehrdeutigen Ergebnis könnte die Anfrage angekommen sein, es fehlt jedoch eine verlässliche Bestätigung. Bei einer ungültigen Antwort liegt zwar eine Rückmeldung vor, ihr Format oder Inhalt reicht aber nicht aus, um sicher darauf aufzubauen. Bei einem unerwarteten externen Zustand meldet das System etwas, das nicht zu den Annahmen des Plans passt. Bei einer Unterbrechung zwischen Schritten wurde die Aufgabe nach einem oder mehreren bestätigten Effekten angehalten, bevor der Ablauf abgeschlossen war.

Diese Kategorien helfen dabei, die nächste Prüfung festzulegen; sie führen nicht automatisch zu einer bestimmten Reaktion. Ist der Fehlschlag bestätigt und kann der Vorgang gefahrlos wiederholt werden, kann ein neuer Versuch sinnvoll sein. Bei einem mehrdeutigen Ergebnis sollten Sie zunächst im betroffenen System nach Belegen suchen. Ist die Antwort ungültig oder widerspricht der beobachtete Zustand dem Plan, setzen Sie davon abhängige Aktionen aus, bis die Abweichung geklärt ist.

Vor dem Fortsetzen: Genügend Informationen für die Rekonstruktion sichern

Ein Checkpoint oder Wiederherstellungspunkt ist hilfreich, wenn sich daraus rekonstruieren lässt, was der Agent vorhatte und was er über jeden Schritt weiß. Es ist nicht nötig, sämtliche Überlegungen oder alle verfügbaren Daten zu speichern. Bewahren Sie stattdessen die mindestens erforderlichen operativen Informationen auf: Aufgabenkennung, Ziel, relevante Einschränkungen, Reihenfolge der Schritte, angefordertes Tool und angeforderter Vorgang, zur Identifizierung des Vorgangs erforderliche Parameter, erhaltenes Ergebnis, Bestätigungsstatus und letzte Beobachtung der Umgebung.

Protokollieren Sie jeden Schritt mit einem klaren Status, zum Beispiel: ausstehend, angefordert, bestätigt, mit Belegen fehlgeschlagen oder Ergebnis unbekannt. Vermeiden Sie es, diese Zustände in einer einzigen Notiz wie „Aktion abgeschlossen“ zusammenzufassen. Dabei könnte der Unterschied zwischen Absicht und Bestätigung verloren gehen. Bietet das externe System eine Möglichkeit, das geänderte Objekt abzufragen, speichern Sie den erforderlichen Suchschlüssel und notieren Sie, wann es zuletzt geprüft wurde.

Der Checkpoint beweist nicht, dass die Außenwelt unverändert geblieben ist. Er ist eine Momentaufnahme dessen, was der Prozess gespeichert hat. Zwischen Unterbrechung und Fortsetzung können eine andere Person oder ein anderes System den Datensatz verändert haben. Prüfen Sie beim Wiederherstellen erneut alle Bedingungen, die vor weiteren Änderungen relevant sind. Die Microsoft-Dokumentation zu Workflow-Checkpoints behandelt das Speichern und Wiederherstellen von Checkpoints. Für eine konkrete Implementierung muss das Team prüfen, welcher Zustand tatsächlich erhalten bleibt und wie er wiederhergestellt wird.

Das Design sollte außerdem die Grenzen der Aufgabe festhalten: welches Ergebnis als Erfolg gilt, welche Vorgänge nicht wiederholt werden dürfen und welche Bedingungen eine Eskalation erfordern. Ohne solche Grenzen kann ein Agent zwar die technischen Schritte rekonstruieren und trotzdem in eine Richtung weiterarbeiten, die nicht mehr sicher ist.

Entscheidungsbaum: fortsetzen, prüfen, neu planen, kompensieren oder stoppen

Die Entscheidung lässt sich als kurzer Ablauf formulieren. Ermitteln Sie zuerst den letzten bestätigten Schritt und den ersten unsicheren Schritt. Fragen Sie anschließend, ob sich der externe Zustand zuverlässig abfragen lässt. Falls ja, führen Sie diese Abfrage vor jeder weiteren Aktion durch. Falls nicht, bewerten Sie die möglichen Folgen einer Wiederholung und prüfen Sie, ob es einen sicheren Weg gibt, die Mehrdeutigkeit aufzulösen. Gibt es auch diesen nicht, halten Sie an und holen Sie menschliche Unterstützung ein.

Fortsetzen bedeutet, von einem bekannten Punkt aus weiterzuarbeiten, ohne bereits bestätigte Schritte erneut auszuführen. Das ist angemessen, wenn der gespeicherte Zustand ausreicht, die relevanten Bedingungen weiterhin gelten und die ausstehenden Schritte sicher sind. Prüfen bedeutet, die Umgebung abzufragen, um herauszufinden, was geschehen ist – nicht, denselben Befehl erneut zu senden. Neu planen bedeutet, den Plan zu ändern, weil der aktuelle Zustand seine Annahmen nicht mehr erfüllt. Kompensieren heißt, eine andere Aktion auszuführen, um einen früheren Effekt auszugleichen. Stoppen bedeutet, keine weiteren Änderungen vorzunehmen, bis eine Entscheidung oder ausreichende Belege vorliegen.

Der AWS-Leitfaden zu Checkpoints für agentische Systeme warnt davor, dass eine Fortsetzung ohne Idempotenzgarantien Effekte duplizieren oder Daten beschädigen kann. Daraus folgt eine praktische Unterscheidung: Ein gespeicherter Ausführungszustand hilft, den Ablauf zu rekonstruieren, macht die Wiederholung eines Vorgangs aber nicht automatisch sicher.

Teilweise eingetretene Effekte: Rückgängigmachen führt nicht immer zum Ausgangszustand

Bei einer zusammengesetzten Aufgabe können einige Schritte abgeschlossen sein, bevor der nächste fehlschlägt. Aktualisiert der Agent einen Datensatz und kann anschließend keine Benachrichtigung versenden, könnte eine Wiederholung des gesamten Ablaufs die Änderung erneut anwenden, doppelte Datensätze erzeugen oder Nachrichten mehrfach versenden. Die Wiederherstellung muss von den bestätigten Effekten ausgehen und für jeden einzelnen entscheiden, wie weiter vorzugehen ist.

Ist ein Vorgang umkehrbar, legen Sie im Voraus fest, was „rückgängig machen“ bedeutet und wie sich überprüfen lässt, ob die Rücknahme wirksam war. Gehen Sie nicht davon aus, dass dadurch jede Spur gelöscht wird oder das System exakt zum früheren Zustand zurückkehrt. In manchen Abläufen ist eine kompensierende Aktion die passende Reaktion: Beispielsweise wird ein Datensatz mit einem neuen Vorgang korrigiert, statt den historischen Vorgang zu löschen. Auch diese Kompensation kann scheitern und braucht daher eine eigene Bestätigung und klare Grenzen.

Das von AWS für mehrstufige Abläufe beschriebene Saga-Muster unterscheidet zwischen einer Vorwärtswiederherstellung – fortsetzen oder erneut versuchen – und einer Rückwärtswiederherstellung durch kompensierende Transaktionen. Es ist eine hilfreiche Referenz für die Strukturierung verteilter Prozesse. Daraus folgt jedoch nicht, dass sich jeder Effekt eines Agenten kompensieren lässt oder eine Kompensation sicher ist. Die Entscheidung hängt von den Regeln des Systems und den Folgen der Aktion ab.

Lässt sich eine Aktion nicht zuverlässig rückgängig machen, sollte der Agent sie als Risikogrenze behandeln. Er kann den Effekt protokollieren, weitere Schritte verhindern, die ihn verschlimmern würden, und eine Prüfung anfordern. Eine für diesen Fall nicht definierte Kompensation sollte er nicht improvisieren.

Grenzen und Eskalation: Wann der Agent anhalten sollte

Eine Wiederherstellungsrichtlinie braucht ausdrückliche Stoppbedingungen. Zu den praktischen Warnsignalen gehören: Der Zustand, der klären würde, ob eine Aktion ausgeführt wurde, lässt sich nicht abfragen; beobachtete Änderungen widersprechen dem Plan; ungültige Antworten treten wiederholt auf; Versuche häufen sich, ohne dass ein bestätigter Fortschritt erzielt wird; Auswirkungen oder Umfang überschreiten die Autorisierung; oder für einen unerwünschten Effekt gibt es keine zuverlässige Kompensation. Dies sind vorgeschlagene Gestaltungskriterien und keine automatischen Sicherheitsgarantien.

Legen Sie auch fest, wer den Fall übernimmt, welche Informationen benötigt werden und welche Aktionen diese Person genehmigen darf. Eine hilfreiche Eskalation sollte das Aufgabenziel, bestätigte Schritte, den unsicheren Punkt, bereits durchgeführte Prüfungen, beobachtete externe Effekte und die vom Agenten bevorzugte Option enthalten. Stellen Sie eine nicht ermittelte Ursache nicht als Tatsache dar.

Anhalten muss nicht bedeuten, die Aufgabe stillschweigend aufzugeben. Der Agent kann den Checkpoint sichern, die Aufgabe als blockiert markieren und klar mitteilen, was noch geprüft werden muss. Bietet die Benutzeroberfläche eine Fortsetzung an, sollte dabei erneut geprüft werden, ob die relevanten Bedingungen noch gelten – nicht angenommen werden, dass die Umgebung unverändert ist.

Wiederherstellung mit kontrollierten Unterbrechungen testen

Es reicht nicht, nur den Erfolgsfall zu testen oder zu prüfen, ob sich ein Prozess aus einem Checkpoint wiederherstellen lässt. Simulieren Sie Unterbrechungen an unterschiedlichen Stellen: vor dem Senden eines Vorgangs, nach dem Senden, aber vor Erhalt einer Antwort, nach der Bestätigung eines Effekts und vor dem nächsten Schritt sowie nach der Beobachtung einer unerwarteten Änderung. Beziehen Sie verspätete, ungültige oder doppelte Antworten ein, sofern sie in der zu bewertenden Umgebung auftreten können.

Legen Sie für jedes Szenario im Voraus das erwartete Verhalten fest: Was muss erhalten bleiben? Welche Abfrage ist erforderlich? Wann ist eine Fortsetzung sicher? Welche Bedingung macht eine Eskalation notwendig? Vergleichen Sie anschließend das tatsächliche Ergebnis mit diesen Kriterien. Die Auswertung sollte sowohl übermäßige Eigeninitiative – etwa eine doppelte Aktion – als auch übertriebene Vorsicht erfassen, beispielsweise eine angehaltene Aufgabe, die sicher hätte fortgesetzt werden können.

Als Kennzahlen kommen der Anteil erfolgreich abgeschlossener Aufgaben, doppelte Effekte, inkonsistente Zustände, blockierte Aufgaben, die Zeit bis zur Klärung einer Mehrdeutigkeit und der Anteil angemessener Eskalationen infrage. Interpretieren Sie die Kennzahlen zusammen mit der Schwere des jeweiligen Falls: Eine niedrige Quote doppelter Aktionen beweist nicht, dass ein unumkehrbarer Vorgang sicher ist.

Nutzen Sie die Ergebnisse, um Checkpoints, Prüfungen, Wiederholungsgrenzen und Stoppbedingungen anzupassen. Unterscheiden Sie Fehler des Agenten, des Tools und des externen Systems, sofern die Belege dies zulassen. Ist eine solche Zuordnung nicht möglich, halten Sie die Ursache als ungeklärt fest, statt eine Zuschreibung zu erzwingen.

Was dieser Leitfaden nicht abdeckt

Dieser Leitfaden behandelt die Wiederherstellung einer Agentenaufgabe, die mehrere Schritte umfasst und externe Systeme verändern kann. Er ersetzt weder das Design von API-Wiederholungsversuchen noch Idempotenzgarantien für eine konkrete Anfrage oder die Wiederherstellung der Infrastruktur. Diese Themen bleiben wichtig: Ein Aufgabenprotokoll kann auf ihnen aufbauen, ihre Garantien aber nicht voraussetzen, wenn sie nicht dokumentiert sind.

Idempotenz ist hier eine Eigenschaft, die für den jeweiligen Vorgang geprüft werden muss, bevor eine Wiederholung als sicher gelten kann. Es reicht nicht, die gesamte Aufgabe als idempotent zu bezeichnen. Ebenso kann ein Checkpoint Workflow-Informationen sichern und wiederherstellen, bestätigt aber nicht von selbst, dass das externe System eine Änderung übernommen hat. Die Arbeit über eine fehlertolerante Multiagentenarchitektur ist ein thematischer Vorläufer mit einem anderen Schwerpunkt: Sie untersucht die Steuerung eines mobilen Roboters und ist keine unmittelbare Anleitung für Agenten, die mit Unternehmensdiensten verbunden sind.

Stellen Sie sich als abschließende praktische Leitlinie nacheinander folgende Fragen: Was ist bestätigt? Was lässt sich außerhalb des Agenten prüfen? Welche Effekte sind bereits eingetreten? Welche Schritte sind weiterhin gültig? Gibt es eine sichere Kompensation? Welche Bedingung zwingt zum Anhalten? Ist eine wesentliche Antwort unbekannt und könnte weiteres Handeln die Folgen verschlimmern, sichern Sie den Zustand, stoppen Sie und eskalieren Sie.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.