Warum vergessen KI-Agenten zu Hause nach einem Neustart des Dienstes abgeschlossene Aktionen?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Lokale KI-Agenten vergessen abgeschlossene Aktionen nach einem Neustart, wenn ihr Plan, Tool-Ergebnisse und Abschlussmarkierungen ausschließlich im flüchtigen Prozessspeicher vorhanden sind.

Ein Agent kann eine Datei aktualisieren, ein Ereignis erstellen, einen Container neu starten oder einen Teil eines Stapelverarbeitungsvorgangs abschließen und dieses Wissen dennoch verlieren, wenn sein Dienst neu bereitgestellt wird oder abstürzt. Der externe Seiteneffekt kann bestehen bleiben, während die Modellkonversation, der Schleifenzähler, der ausstehende Plan und das Tool-Ergebnisobjekt verschwinden. Nach dem Start wiederholt der Agent möglicherweise die Arbeit oder geht davon aus, dass nichts geschehen ist. Eine dauerhafte Wiederherstellung erfordert, dass der Ausführungsstatus an den Grenzen gespeichert wird, die Absicht, Tool-Aufruf, beobachtbares Ergebnis und den nächsten noch nicht abgeschlossenen Schritt miteinander verbinden.

Der Gesprächsverlauf ist kein dauerhafter Workflow-Status

Ein Chatverlauf kann die Anfrage des Benutzers und die Erläuterungen des Agenten enthalten, aber möglicherweise nicht festhalten, welche Seiteneffekte übernommen wurden, welche Datensätze übersprungen wurden oder an welchem Zweig die Ausführung fortgesetzt werden sollte.

Der Leitfaden von Augment Code zu dauerhaftem Workflow-Status trennt lang laufende Ausführungen von einem einzelnen Prozess oder einer synchronen Anfrage.

Der Agent benötigt strukturierten Status wie Aufgaben-ID, aktuellen Schritt, abgeschlossene Vorgänge, Hashes der Tool-Ergebnisse, ausstehende Genehmigungen und Wiederholungszähler. Diesen Status nach einem Neustart aus einem natürlichsprachlichen Chat neu zu erzeugen, ist mehrdeutig.

Abgeschlossene Tool-Aufrufe benötigen eine dauerhafte Commit-Grenze

Ein Tool kann extern erfolgreich sein, bevor der Agent seine lokale Abschlussmarkierung schreibt. Ein Neustart in diesem Zeitfenster hinterlässt eine tatsächlich ausgeführte Aktion, von der der Agent nichts weiß.

Zylos beschreibt dauerhafte Ausführungsgrenzen, die abgeschlossene Arbeit bewahren, bevor die Wiederherstellung fortgesetzt wird.

Eine zuverlässige Grenze speichert die Vorgangs-ID und das Ergebnis in einem dauerhaften Speicher oder verwendet einen Transaktionsdienst, der den Seiteneffekt und den Abschlussdatensatz gemeinsam übernehmen kann.

Wenn ein atomarer Commit nicht möglich ist, muss das Tool eine Statusabfrage bereitstellen, damit der neu gestartete Agent unklare Ergebnisse abgleichen kann.

Ein Snapshot allein reicht möglicherweise nicht aus, um eine sichere Ausführung wiederherzustellen

Das Speichern von Modellnachrichten oder eines serialisierten Graphstatus hält fest, was der Agent in einem bestimmten Moment glaubte. Es garantiert jedoch nicht automatisch, dass externe Aufrufe bei der Wiedergabe nicht doppelt ausgeführt werden.

Diagrid unterscheidet Anwendungs-Checkpoints von Laufzeitsystemen, die Wiederholungen, Ereignisverlauf und den Abschluss von Seiteneffekten verwalten.

Das Wiederherstellungskonzept muss festlegen, welcher Code deterministisch ist, welche Tool-Aufrufe wiedergegeben werden können und welche Ergebnisse aus dem Verlauf gelesen werden, statt erneut ausgeführt zu werden.

Andernfalls kann ein korrekter Checkpoint dennoch zu einer doppelten Nachricht, einem wiederholten Verschieben einer Datei oder einem zweiten Gerätebefehl führen.

Stabile Lauf- und Schritt-Identitäten verhindern, dass versehentlich eine neue Aufgabe gestartet wird

Nach einem Neustart kann eine neu erzeugte Konversation oder Lauf-ID dasselbe Benutzerziel wie eine neue Aufgabe erscheinen lassen. Der Agent hat dann keinen Schlüssel, mit dem er seinen alten Status finden kann.

Inference.sh erklärt, wie eine dauerhafte Lauf-Identität einem Agenten ermöglicht, am zuletzt abgeschlossenen Checkpoint fortzusetzen.

Speichere die Workflow-ID außerhalb des Containers und verknüpfe sie mit Benutzer, Aufgabe, Datenumfang und Autorisierung. Diensterkennung und Load-Balancing dürfen nicht allein deshalb einen neuen logischen Lauf erzeugen, weil ein anderer Worker die Anfrage erhält.

Abgeschlossene Schritte sollten wiederverwendet statt erneut durchdacht werden

Die erneute Ausführung früherer Modellaufrufe kann zu einem anderen Plan, anderen Tool-Argumenten oder einer anderen Interpretation des bereits abgeschlossenen Arbeitsumfangs führen.

Der Runtime-Artikel von Pydantic erklärt, dass abgeschlossene Checkpoints abgeschlossen bleiben, während die Wiederherstellung nur die fehlgeschlagene Grenze erneut ausführt.

Das senkt die Token-Kosten und verhindert, dass ein neu gestarteter Agent einen zweiten Weg durch bereits veränderte Systeme im Haushalt erfindet.

Gespeicherte Ergebnisse sollten genügend Belege enthalten, um zu prüfen, dass die Tool-Ausgabe weiterhin dem aktuellen Zielzustand entspricht.

Idempotenz und Abgleich schützen die Wiederherstellung vor doppelten Effekten

Ein dauerhafter Status kann dennoch einen Schritt hinter dem externen System zurückliegen. Vorgangs-IDs, Idempotenzschlüssel, Zustandsprüfungen und kompensierende Aktionen gehen mit dieser Unsicherheit um.

Restates Leitfaden zu robusten Agentenschleifen bewahrt den Iterationsstatus über Neustarts hinweg und unterstützt eine kontrollierte Fortsetzung.

Der Artikel von ZimaSpace über sicher wiederholbare Automatisierung zeigt, warum ein angestrebter Endzustand sicherer ist als das blinde erneute Abspielen additiver Befehle.

Wenn eine Aktion nicht idempotent gemacht werden kann, sollte der neu gestartete Agent den aktuellen Zustand abgleichen oder die Ausführung zur Prüfung anhalten, statt anzunehmen, dass ein fehlender lokaler Datensatz einen Fehlschlag bedeutet.

Neustarttests müssen jedes Fehlerfenster abdecken

Beende den Dienst vor einem Tool-Aufruf, während des Aufrufs, nach dem externen Effekt, nach dem lokalen Checkpoint und während des Wartens auf eine Genehmigung. Jeder Neustart sollte zu einer vorhersehbaren Fortsetzung führen.

DBOS beschreibt eine absturzsichere Ausführung für Workflows, die APIs und menschliche Interaktion umfassen.

Prüfe, ob abgeschlossene Aktionen wiederverwendet, unklare Aktionen abgeglichen, ausstehende Aktionen ausstehend belassen und keine Autorisierungen stillschweigend neu erzeugt werden.

Der Agent erinnert sich nur dann an abgeschlossene Arbeit, wenn der Fortschritt als dauerhafter operativer Nachweis gespeichert wird – nicht lediglich als Text, den der alte Prozess zufällig im Speicher hielt.

FAQ

Reicht es aus, den Chatverlauf zu speichern?

Nein. Im Verlauf können Vorgangs-IDs, übernommene Seiteneffekte, Wiederholungsstatus, Genehmigungen und die genaue Grenze fehlen, ab der die Ausführung fortgesetzt werden sollte.

Sollte der Agent nach einem Neustart jeden Tool-Aufruf wiedergeben?

Nein. Abgeschlossene Aufrufe sollten aus dem dauerhaften Verlauf wiederverwendet werden, während unklare Aufrufe vor jedem Wiederholungsversuch Idempotenz oder einen Abgleich erfordern.

Kann ein Datenbank-Checkpoint jede doppelte Aktion verhindern?

Nein. Er muss mit dem externen Seiteneffekt koordiniert werden. Ein Absturz zwischen dem Effekt und dem Checkpoint führt weiterhin zu einem unklaren Ergebnis.

Tech- & KI-Zentrum

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.