Dlaczego domowi agenci AI zapominają wykonane działania po ponownym uruchomieniu usługi?

Domowi agenci AI zapominają o wykonanych działaniach po ponownym uruchomieniu, gdy ich plan, wyniki narzędzi i znaczniki ukończenia istnieją wyłącznie w ulotnej pamięci procesu.

Agent może zaktualizować plik, utworzyć wydarzenie, ponownie uruchomić kontener lub zakończyć część partii, a mimo to utracić tę wiedzę, gdy jego usługa zostanie ponownie wdrożona lub ulegnie awarii. Zewnętrzny efekt działania może przetrwać, podczas gdy rozmowa z modelem, licznik pętli, oczekujący plan i obiekt wyniku narzędzia znikają. Po uruchomieniu agent może powtórzyć pracę lub uznać, że nic się nie wydarzyło. Trwałe odzyskiwanie wymaga zapisywania stanu wykonania na granicach łączących zamiar, wywołanie narzędzia, obserwowalny wynik i kolejny niewykonany krok.

Historia rozmowy nie jest trwałym stanem przepływu pracy

Transkrypcja czatu może zawierać żądanie użytkownika i opis działań agenta, ale nie musi rejestrować, które efekty uboczne zostały zatwierdzone, które rekordy pominięto ani od której gałęzi należy wznowić pracę.

Przewodnik Augment Code dotyczący trwałego stanu przepływu pracy oddziela długotrwałe wykonanie od pojedynczego procesu lub żądania synchronicznego.

Agent potrzebuje ustrukturyzowanego stanu, takiego jak identyfikator zadania, bieżący krok, ukończone operacje, skróty wyników narzędzi, oczekujące zatwierdzenia i liczba ponowień. Odtworzenie tego stanu z rozmowy w języku naturalnym po ponownym uruchomieniu jest niejednoznaczne.

Ukończone wywołania narzędzi wymagają trwałej granicy zatwierdzenia

Narzędzie może odnieść zewnętrzny sukces, zanim agent zapisze lokalny znacznik ukończenia. Ponowne uruchomienie w tej przerwie sprawia, że działanie jest rzeczywiste, ale agent o nim nie wie.

Zylos opisuje trwałe granice wykonania, które zachowują ukończoną pracę przed wznowieniem odzyskiwania.

Niezawodna granica zapisuje identyfikator operacji i wynik w trwałym magazynie albo korzysta z jednej usługi transakcyjnej, która może jednocześnie zatwierdzić efekt uboczny i rekord ukończenia.

Gdy atomowe zatwierdzenie jest niemożliwe, narzędzie musi udostępniać wyszukiwanie statusu, aby agent po ponownym uruchomieniu mógł uzgodnić niepewne wyniki.

Sam punkt kontrolny może nie wystarczyć do bezpiecznego odtworzenia wykonania

Zapisanie wiadomości modelu lub zserializowanego stanu grafu rejestruje to, co agent uważał w danym momencie. Nie gwarantuje jednak automatycznie, że zewnętrzne wywołania nie zostaną zduplikowane podczas odtwarzania.

Diagrid odróżnia punkty kontrolne aplikacji od środowisk wykonawczych, które zarządzają ponawianiem prób, historią zdarzeń i ukończeniem efektów ubocznych.

Projekt odzyskiwania musi określać, który kod jest deterministyczny, które wywołania narzędzi można odtwarzać, a które wyniki należy odczytywać z historii zamiast wykonywać ponownie.

W przeciwnym razie nawet poprawny punkt kontrolny może wznowić działanie, które wyśle zduplikowaną wiadomość, ponownie przeniesie plik lub wyda drugie polecenie urządzeniu.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

$799.00 - $2,499.00

Buy Now

Stabilne identyfikatory uruchomienia i kroków zapobiegają przypadkowemu rozpoczęciu nowego zadania

Po ponownym uruchomieniu nowo wygenerowany identyfikator rozmowy lub uruchomienia może sprawić, że ten sam cel użytkownika będzie wyglądał jak nowe zadanie. Agent nie ma wtedy klucza do odnalezienia poprzedniego stanu.

Inference.sh wyjaśnia, jak trwała tożsamość uruchomienia pozwala agentowi wznowić pracę od ostatniego ukończonego punktu kontrolnego.

Trwały identyfikator przepływu pracy należy przechowywać poza kontenerem i powiązać go z użytkownikiem, zadaniem, zakresem danych oraz uprawnieniami. Wykrywanie usług i równoważenie obciążenia nie mogą tworzyć nowego logicznego uruchomienia tylko dlatego, że żądanie obsługuje inny proces roboczy.

Ukończone kroki należy wykorzystywać ponownie, zamiast ponownie je analizować

Ponowne uruchamianie wcześniejszych wywołań modelu może doprowadzić do utworzenia innego planu, innych argumentów narzędzi lub odmiennej interpretacji tego, które działania są ukończone.

Artykuł Pydantic dotyczący środowiska wykonawczego stwierdza, że ukończone punkty kontrolne pozostają ukończone, a odzyskiwanie ponownie uruchamia wyłącznie granicę, na której wystąpiła awaria.

Zmniejsza to koszt tokenów i zapobiega wymyślaniu przez ponownie uruchomionego agenta drugiej ścieżki działania w już zmodyfikowanych systemach domowych.

Przechowywane wyniki powinny zawierać wystarczające dowody, aby potwierdzić, że wynik narzędzia nadal odpowiada bieżącemu stanowi docelowemu.

Idempotencja i uzgadnianie chronią odzyskiwanie przed zduplikowanymi efektami

Trwały stan nadal może być o jeden krok opóźniony względem systemu zewnętrznego. Identyfikatory operacji, klucze idempotencji, kontrole stanu i działania kompensacyjne pomagają radzić sobie z tą niepewnością.

Przewodnik Restate dotyczący odpornych pętli agentów zachowuje stan iteracji po ponownym uruchomieniu i umożliwia kontrolowaną kontynuację.

Artykuł ZimaSpace o automatyzacji bezpiecznej przy powtarzaniu pokazuje, dlaczego osiągnięcie zamierzonego stanu końcowego jest bezpieczniejsze niż bezmyślne odtwarzanie poleceń addytywnych.

Gdy działania nie można uczynić idempotentnym, ponownie uruchomiony agent powinien uzgodnić bieżący stan lub zatrzymać się w celu weryfikacji, zamiast zakładać, że brak lokalnego rekordu oznacza niepowodzenie.

Testy ponownego uruchamiania muszą obejmować każde okno awarii

Zatrzymaj usługę przed wywołaniem narzędzia, w trakcie wywołania, po wystąpieniu zewnętrznego efektu, po zapisaniu lokalnego punktu kontrolnego i podczas oczekiwania na zatwierdzenie. Każde ponowne uruchomienie powinno prowadzić do jednego przewidywalnego wznowienia.

DBOS opisuje wykonywanie odporne na awarie w przepływach pracy obejmujących interfejsy API i interakcje z człowiekiem.

Sprawdź, czy ukończone działania są wykorzystywane ponownie, niepewne działania uzgadniane, oczekujące działania pozostają oczekujące, a żadne uprawnienia nie są po cichu generowane ponownie.

Agent pamięta ukończoną pracę tylko wtedy, gdy postęp jest przechowywany jako trwały dowód operacyjny — a nie wyłącznie jako tekst, który przypadkowo znajdował się w pamięci starego procesu.

FAQ

Czy zapisanie transkrypcji czatu wystarczy?

Nie. Transkrypcja może pomijać identyfikatory operacji, zatwierdzone efekty uboczne, stan ponawiania prób, zatwierdzenia oraz dokładną granicę, od której należy wznowić wykonanie.

Czy agent powinien po ponownym uruchomieniu odtwarzać każde wywołanie narzędzia?

Nie. Ukończone wywołania należy ponownie wykorzystywać z trwałej historii, a niepewne wywołania wymagają idempotencji lub uzgodnienia przed ponowieniem próby.

Czy punkt kontrolny w bazie danych może zapobiec każdemu zduplikowanemu działaniu?

Nie. Musi być skoordynowany z zewnętrznym efektem ubocznym. Awaria między wystąpieniem efektu a zapisaniem punktu kontrolnego nadal prowadzi do niepewnego wyniku.