Ein langlaufender Agent kann stoppen, nachdem das Modell eine Entscheidung getroffen hat, nachdem eine Tool-Anfrage gesendet wurde oder nachdem ein externer Dienst die Anfrage akzeptiert hat. Das sind verschiedene Wiederherstellungssituationen. Das Wiederholen des Gesprächs von Anfang an erklärt nicht, welche aufgetreten ist.
Ich entwerfe wiederherstellbare Arbeiten rund um den dauerhaften Anwendungszustand. Das Gespräch kann helfen, die Absicht zu erklären, aber die Wiederherstellung benötigt explizite Aufzeichnungen über den Job, die abgeschlossenen Schritte und die Effekte, deren Ergebnisse noch ungewiss sind.
Geben Sie dem Job eine Identität über die Sitzung hinaus
Ein Job sollte einen stabilen Identifikator haben, der Worker-Neustarts und Browser-Trennungen übersteht. Dieser Identifikator verbindet das angeforderte Ziel, den Kontobereich, die Eingaben, den Fortschritt und die Ausgabe. Eine neue Sitzung kann dann den bestehenden Job inspizieren, anstatt versehentlich nicht verwandte Arbeiten zu erstellen.
Ich würde die Versionen der Eingaben speichern, die eine entscheidende Entscheidung beeinflusst haben. Wenn sich die Quelldaten ändern, während der Job pausiert ist, könnte eine Wiederaufnahme eine neue Entscheidung erfordern. Ein gespeicherter Plan ist nützlicher Kontext; er ist kein Beweis dafür, dass die ursprünglichen Annahmen weiterhin gültig sind.
Dies ist ein wiederkehrendes architektonisches Anliegen in der operational systems work I undertake through Wizutech. Geschäftsprozesse können länger dauern als eine einzelne Anfrage, und die Wiederherstellung sollte ihre Identität bewahren.
Checkpoint bedeutungsvolle Grenzen
Ein Checkpoint ist am nützlichsten, wenn er einen Zustand erfasst, den die Anwendung wiederherstellen kann. Zum Beispiel könnte ein Forschungsprojekt zwischen gesammelten Quellen, überprüften Ergebnissen und vorgeschlagenen Veröffentlichungen unterscheiden. Diese Zustände beschreiben den Fortschritt des Geschäfts und nicht eine Position innerhalb des generierten Textes.
Der dauerhafte Datensatz sollte akzeptierte Ausgaben und ungelöste Fragen enthalten. Ich würde vermeiden, die Wiederherstellung von der Rekonstruktion der privaten Modellbegründung abhängig zu machen. Die Anwendung benötigt die Entscheidung, relevante Beweise und den Ausführungszustand, nicht ein Protokoll jedes zwischenzeitlichen Gedankens.
Jede Wiederaufnahme benötigt auch kompatiblen Code und Daten. Wenn eine neue Version die Struktur des gespeicherten Zustands ändert, sollte der Worker diese Version ausdrücklich migrieren oder ablehnen, anstatt alte Felder unter neuen Annahmen zu interpretieren.
Den Abstand um externe Effekte behandeln
Der schwierige Fall ist ein Werkzeugaufruf, dessen remote Effekt erfolgreich war, bevor der lokale Arbeiter den Erfolg aufgezeichnet hat. Blindes Wiederholen kann den Effekt wiederholen. Den Schritt als abgeschlossen zu markieren, bevor der Aufruf erfolgt, führt zum gegenteiligen Fehler: Der Job kann Erfolg für eine Operation beanspruchen, die nie stattgefunden hat.
Wo verfügbar, verwende ich einen stabilen Betriebsschlüssel und eine Möglichkeit, das entfernte Ergebnis abzurufen. Andernfalls sollte der Job einen unsicheren Zustand bewahren und einen Versöhnungsweg einschlagen. Allein durch Persistenz kann kein Exactly-Once-Garantie über einen nicht verwandten externen Dienst geschaffen werden.
Das Design verbindet sich direkt mit der Trennung vorgeschlagener Aktionen von akzeptierten Effekten. Die Absicht eines Modells und das bestätigte Ergebnis eines Werkzeugs gehören in unterschiedliche Bereiche.
Verhindern Sie, dass zwei Mitarbeiter denselben Schritt wieder aufnehmen.
Ein Neustart kann mit einem langsamen ursprünglichen Worker überlappen. Ein Leasing- oder Eigentumsdatensatz hilft, die Ausführung zu koordinieren, benötigt jedoch eine Möglichkeit, Arbeiten von einem abgelaufenen Eigentümer abzulehnen. Ich würde die aktuelle Ausführungsversion an der Schreibgrenze überprüfen und nicht davon ausgehen, dass eine frühere Leasingprüfung für immer gültig bleibt.
Für externe Operationen benötigt die lokale Koordination weiterhin den Duplikatschutz oder das Abgleichverhalten des Ziels. Ein Datenbankschloss kann eine bereits anderswo akzeptierte Anfrage nicht rückgängig machen.
Machen Sie die Wiederherstellung sichtbar
Der Betreiber sollte in der Lage sein zu erkennen, ob ein Job läuft, auf eine Abhängigkeit wartet, einen ungewissen Effekt abgleicht oder bereit ist, fortzufahren. „Wiederholen“ ist zu vage, wenn das System tatsächlich darauf wartet, dass eine Person die ursprüngliche Anfrage klärt.
Ich würde jeden Unterbrechungspunkt neben den Stopbedingungen des Jobs überprüfen. Ein dauerhafter Zustand ist wertvoll, wenn er dem nächsten Arbeiter ermöglicht, einen bekannten Prozess fortzusetzen. Er sollte die Menge an Schlussfolgerungen reduzieren, die nach einem Fehler erforderlich sind, insbesondere bei Aktionen, die andere Systeme betreffen.
Aktualisiert am 30. September 2026.