KI-Agenten neu starten: Was lässt sich wiederholen?

Ein Agent speichert einen Beleg, beginnt den nächsten Teil der Aufgabe und verliert die Verbindung. Die ganze Aufgabe erneut zu starten, klingt hilfreich. Dabei kann auch der bereits erfolgreiche Schritt noch einmal ausgeführt werden.

Meine Regel lautet: Wiederhole die kleinste Einheit, deren Auswirkungen du nachvollziehen kannst. Manchmal ist das eine unvollständige Modellanfrage. Manchmal ist es eine Werkzeugoperation mit stabiler Kennung. Manchmal musst du zuerst prüfen, was tatsächlich passiert ist. Eine längere Wartezeit vor dem nächsten Versuch beantwortet diese Frage nicht.

Das wird praktisch relevant, weil Agentenplattformen mehr Verantwortung für die Ausführung übernehmen. Salesforce stellte am 11. September seine Enterprise-AI-Harness-Architektur vor, einschließlich gemeinsamer Kontrollen für Aktionen und Governance. Der am 2. September eingereichte READY-Preprint trennt Benchmarkleistung von der Eignung für einen bestimmten Einsatz. Daraus folgt keine allgemeine Erlaubnis, fehlgeschlagene Agenten neu zu starten. Die Wiederaufnahme braucht einen eigenen Vertrag und eigene Tests.

Warum kann ein Agent trotz HTTP 200 unvollständig bleiben?

Ein erfolgreicher HTTP-Status bedeutet, dass die Übertragung der Streaming-Antwort erfolgreich begonnen hat. Er garantiert kein vollständiges Anwendungsergebnis. Eine Verbindung kann nach dem ersten Ereignis schließen. Ebenso kann ein Stream ohne das Abschlussereignis enden, das die Ausführungslogik benötigt.

So entsteht ein leicht übersehener Fehler: Der Transport endet regulär, aber der Agent erhält kein vollständiges Ergebnis. Wer nur Netzwerkfehler abfängt, erkennt diesen Fall nicht. Das Ausbleiben einer Ausnahme ist ein schwächerer Beleg als ein tatsächlich eingetroffenes Abschlussereignis.

Definiere den Abschluss deshalb auf Protokollebene. Verfolge, ob das erforderliche erfolgreiche Endereignis angekommen ist. Endet der Stream vorher, melde eine unvollständige Generierung. Ein ausdrücklich erfolgloses Endereignis ist ein anderer Fall und muss seine Bedeutung behalten. Nicht jedes erfolglose Ende ist eine vorübergehende Verbindungsstörung, die einfach einen neuen Versuch rechtfertigt.

Solltest du die Modellanfrage oder den ganzen Agenten wiederholen?

Das sind unterschiedliche Operationen. Ein Agentendurchlauf kann mehrere Modellanfragen und bereits abgeschlossene Werkzeugaktionen enthalten. Ein Neustart mit der ursprünglichen Anweisung kann diese Aktionen erneut in die Ausführung bringen. Die aktuelle Modellanfrage lässt sich dagegen mit den bisherigen Werkzeugergebnissen als Eingabe wiederholen.

Diese engere Grenze funktioniert nur, wenn du weißt, wann dein Runner Werkzeuge aufruft. Bei den nativen Funktionswerkzeugen unseres Replays beginnt die Ausführung erst nach einer vollständigen Modellantwort. Während Argumente eintreffen, wird noch nichts ausgeführt. Ein unvollständiger Vorschlag ist damit etwas anderes als eine ausgeführte Operation. Ein anderer Runner oder ein vom vorgeschalteten Dienst ausgeführtes Werkzeug kann anders arbeiten.

Unser früherer Beitrag über Streaming für einen KI-Agenten behandelte eine konservative Wiederholungsregel für den gesamten Durchlauf. Hier geht es um die engere Frage: Lässt sich nur die unvollständige Generierung wiederholen, obwohl eine frühere Generierung schon nützliche Werkzeugaktionen ausgelöst hat?

Was hat der Wiederholungstest bei Norman gezeigt?

Wir haben Normans Assistant-Wrapper mit dem tatsächlichen Agent-Runner und synthetischen Werkzeugen geprüft. Die Testaufgabe speichert einen fiktiven Beleg und verknüpft ihn anschließend. Die Werkzeuge schreiben lediglich Markierungen in eine lokale Liste, keine Buchhaltungsdaten. Wir unterbrachen die Modellgenerierung sowohl vor diesen Aktionen als auch nachdem das Ergebnis des Speicherns bereits vorlag.

Der frühere Wrapper erkannte einen regulär beendeten Stream ohne Abschlussereignis nicht. Der aktuelle Wrapper wiederholt eine dafür geeignete unvollständige Generierung innerhalb eines begrenzten Budgets mit derselben Eingabe. Beim späteren Abbruch enthält diese Eingabe weiterhin das vorherige Werkzeugergebnis. Der Test erreicht seine abschließende Antwort mit der vorgesehenen Folge aus Speichern und Verknüpfen. Die frühere Markierung wird dabei nicht erneut geschrieben.

Zusätzlich führten wir einen synthetischen HTTP-200-Ereignisstrom durch den tatsächlichen HTTP/SSE-Decoder und Runner. Der fehlende Abschluss wurde erkannt; der nächste zulässige Versuch konnte fortfahren. Das ist relevant, weil ein künstlicher Iterator allein nicht zeigt, welche Ereignisse der Decoder an den Wrapper weitergibt.

Das ist ein Regressionstest mit Norman-Code, kein Zuverlässigkeitsbenchmark des Produktivbetriebs. Es gab keine echten Modellaufrufe und keine Abfrage von Kundendatenbanken. Das Ergebnis ist eine geprüfte Grenze und keine Kennzahl für eine Werbeseite.

Welche Ereignisse müssen einen automatischen Neustart verhindern?

Ein leerer Stream ist nicht dasselbe wie eine halb angezeigte Antwort. Wenn die Antwort von vorn beginnt, können Textduplikate entstehen, nachgelagerte Systeme durcheinanderkommen oder Aussagen bereits sichtbarem Inhalt widersprechen. Auch der Abschluss selbst schließt das Wiederholungsfenster: Ein anschließender Transportfehler erlaubt keine neue Generierung einer fertigen Antwort.

Eine weitere Grenze bilden Aktionen, die innerhalb eines vorgeschalteten Dienstes ausgeführt werden. Deren Auswirkungen sind für die Anwendung möglicherweise weniger sichtbar als die eigener Werkzeuge. Der geprüfte Wrapper behandelt deshalb gehostete Werkzeugaktivität und unbekannte Ereignistypen konservativ, statt sie als harmlos anzunehmen.

Auch ein Abbruch muss ein Abbruch bleiben. Wenn du eine Aufgabe stoppst, erteilst du dem Wiederholungsmechanismus keinen Auftrag zum Weiterarbeiten. Die lokalen Tests prüfen sowohl Abbruchsignale als auch ein Zeitlimit, das die Wartephase vor einem erneuten Versuch unterbricht. Das Wiederholungsbudget gehört in das ursprüngliche Zeitbudget. Es darf der Aufgabe nicht unbemerkt eine neue Laufzeit geben.

Ist der Agent damit nach einem Absturz wiederaufnehmbar?

Nein. Ein früheres Werkzeugergebnis im laufenden Prozess zu behalten, belegt keine Wiederaufnahme nach einem Worker-Absturz. Dafür braucht es dauerhaft gespeicherten Fortschritt und eine Verbindung zu bereits ausgeführten Operationen. Unser Beitrag zum Agent Harness erklärt den größeren Ausführungskontext. Dieser Test untersucht nur einen Ausschnitt davon.

Die Agent-Dokumentation von Apache Airflow macht eine hilfreiche Unterscheidung: Gespeicherte Ergebnisse können wiederverwendet werden. Ändert ein Werkzeug aber externen Zustand, bevor sein Ergebnis gespeichert wird, kann ein erneuter Versuch diese Änderung wiederholen.

Bei solchen Operationen beschreibt „kein gespeichertes Ergebnis“ deinen Datenbestand. Es beweist nicht, dass nichts passiert ist. Nutze eine Operationskennung, eine Deduplizierungsfunktion des Zielsystems oder eine maßgebliche Ergebnisprüfung, soweit verfügbar. Lässt sich das Ergebnis nicht feststellen, muss die Unsicherheit erhalten bleiben. Eine lokale Streaming-Korrektur garantiert keine einmalige Ausführung über externe Systeme hinweg.

Was gehört in einen Bericht über Wiederholungsversuche?

„Wiederholung erfolgreich“ lässt die wichtigste Entscheidung offen. Halte fest, welche Einheit wiederholt wurde, weshalb das zulässig war, welche früheren Ergebnisse erhalten blieben und wie der resultierende Zustand geprüft wurde. Unterscheide einen erfolgreichen Abschluss von einem gestoppten Versuch oder einem ungeklärten externen Ergebnis.

Das folgende Schema illustriert einen Bericht. Es ist weder Normans API noch eine ausführbare Konfiguration:

{
  "retry_scope": "current_generation",
  "completion_event": "missing",
  "earlier_tool_results": "retained",
  "restart_boundary": "still_open",
  "verification": "synthetic_effect_sequence_checked"
}

Zum Bericht gehören außerdem die Grenzen der Prüfung. Lief der tatsächliche Decoder, der tatsächliche Runner, eine Persistenzschicht oder nur ein simuliertes Werkzeug? Waren Netzwerkverbindungen gesperrt? Welche Revision wurde getestet? Die Überlegung aus unserem Beitrag über Belege für Agentengedächtnis gilt auch hier: Ein aufgezeichnetes Ereignis stützt eine bestimmte Aussage und nicht jede wünschenswerte Schlussfolgerung über das System.

Wie testest du Wiederholungen von KI-Agenten ohne blinde Flecken?

Platziere Fehler direkt an der Grenze, die du schützen möchtest. Beende den Stream vor dem Abschluss, unterbrich eine spätere Generierung nach einem früheren Werkzeugergebnis und prüfe die genaue Folge synthetischer Auswirkungen. Teste anschließend die Ablehnungsfälle: sichtbaren Text, fertige Ergebnisse, vorgeschaltete Werkzeugaktivität, ausdrücklich erfolglose Endereignisse und Abbruchsignale.

Behalte einen Fehlerfall, der das Wiederholungsbudget überlebt. Sonst belohnt die Testsuite womöglich einen Mechanismus, der endlos weiterprobiert und nie seinen Stillstand meldet. Vergleiche mit der früheren Implementierung, damit der Regressionstest die Änderung tatsächlich nachweist.

Benenne schließlich, was ungetestet bleibt. Unser Replay deckt weder Worker-Verlust noch unklare externe Schreibvorgänge oder jede Clientdarstellung ab. Dafür braucht es andere Testfälle. Ich würde eine Wiederherstellungsregel mit klarer Grenze ausliefern, statt jeden unterbrochenen Agenten als wiederaufnehmbar zu beschreiben. Die Grenze zeigt dem nächsten Entwickler, wo zusätzliche Belege fehlen.