Czym jest granica transakcji agenta i kiedy można wycofać działanie narzędzia?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

What Is an Agent Transaction Boundary, and When Can a Tool Action Be Rolled Back? - Zima Store Online

Granica transakcji agenta definiuje skutki traktowane jako jedna zatwierdzona jednostka oraz odróżnia rzeczywiste wycofanie od kompensacji lub nieodwracalnego działania zewnętrznego.

Agent domowy może w ramach jednego planu zmienić nazwy plików, zaktualizować indeks, wysłać wiadomość, odblokować drzwi i zapisać rekord audytowy. Tylko niektóre operacje współdzielą transakcję bazy danych; pozostałe są zatwierdzane w niezależnych narzędziach lub w świecie fizycznym. Granica wskazuje, kiedy stan staje się trwały, co można dokładnie przywrócić oraz gdzie przepływ pracy przekracza punkt wymagający kompensacji lub wcześniejszej zgody.

Atomowe wycofanie istnieje tylko w ramach współdzielonego menedżera transakcji

W jednym transakcyjnym magazynie danych agent lub narzędzie może przygotować zmiany i zatwierdzić je razem, dzięki czemu awaria przed zatwierdzeniem sprawia, że żadna z nich nie będzie widoczna. Punkty zapisu mogą wycofać część pracy, zachowując nadrzędną transakcję.

Wzorzec sagi odróżnia sekwencję lokalnych transakcji od jednej globalnej transakcji atomowej. Gdy zewnętrzna usługa zatwierdzi operację, pierwotny mechanizm wycofywania bazy danych nie kontroluje już tego skutku. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Plan agenta nie jest więc transakcją tylko dlatego, że zawiera kilka kroków. Każde narzędzie musi udostępniać semantykę zatwierdzania, idempotencję oraz trwały identyfikator operacji, który orkiestrator może analizować. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Kompensacja tworzy nowy skutek, zamiast wymazywać historię

Usunięcie skopiowanego pliku, zwrot opłaty lub wysłanie sprostowania może zrównoważyć wcześniejsze działanie, ale pierwotne zdarzenie nadal miało miejsce, a obserwatorzy mogli już na nie zareagować. Kompensację należy projektować dla każdego narzędzia osobno, a ona sama również może się nie powieść.

Wytyczne Azure dotyczące sagi rozróżniają operacje podlegające kompensacji, kroki zwrotne i operacje niepodlegające kompensacji. Krok zwrotny wyznacza punkt, po którym przepływ pracy musi zmierzać do spójnego wyniku, zamiast udawać, że każdy wcześniejszy skutek można cofnąć.

W przypadku agenta odwracalne przenoszenie plików powinno poprzedzać wysyłanie wiadomości, sterowanie drzwiami, publikowanie lub wydawanie poleceń urządzeniom. Zgoda powinna zazwyczaj znajdować się bezpośrednio przed pierwszym nieodwracalnym lub widocznym zewnętrznie krokiem zwrotnym. Tę granicę należy mierzyć osobno w realistycznych warunkach działania.

Ponowienia wymagają idempotencji i wiarygodnego dziennika operacji

Po przekroczeniu limitu czasu orkiestrator może nie wiedzieć, czy narzędzie zakończyło działanie przed zatwierdzeniem, czy po nim. Ponowienie bez klucza idempotencji może zduplikować wiadomości, płatności, pliki lub automatyzacje; założenie powodzenia może pominąć wymaganą pracę. Praktyczne konsekwencje pojawiają się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Analiza Temporal dotycząca działań kompensacyjnych podkreśla konieczność jawnego określania działań kompensacyjnych dla wcześniej ukończonych kroków rozproszonych. Trwały stan przepływu pracy musi rejestrować próby, potwierdzenia, kompensacje i bieżący krok zwrotny. Ta zależność powinna pozostać wyraźna w finalnym interfejsie.

Granica awarii to skutek fizyczny lub zewnętrzny, który nie ma odwrotności, na przykład ujawnienie danych, wysłanie powiadomienia już odczytanego, usunięcie pliku bez wersjonowania lub uruchomienie sprzętu. Po przekroczeniu tej granicy żadne programowe wycofanie nie przywróci dokładnie stanu świata.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Klasyfikuj każdy krok narzędzia, zanim agent go wykona

Dla każdego działania zapisz zasób, menedżera transakcji, punkt przygotowania i zatwierdzenia, klucz idempotencji, obserwowalny skutek uboczny, operację odwrotną, warunki wstępne kompensacji, niejednoznaczność limitu czasu, regułę ponawiania, bramkę zatwierdzenia i zdarzenie audytowe. Wynik należy zatem sprawdzić względem pierwotnych dowodów.

Odtwarzaj decyzje za pomocą ścieżki audytu agenta. Wprowadzaj awarie przed żądaniem, po odebraniu żądania przez narzędzie, po zatwierdzeniu, przed potwierdzeniem, podczas kompensacji i po kroku zwrotnym; sprawdzaj zapobieganie duplikatom oraz końcową spójność. To rozróżnienie pozostaje widoczne podczas późniejszych testów domowych.

Zezwalaj na automatyczne wycofanie tylko tam, gdzie narzędzie je gwarantuje. Stosuj kompensację w przypadku odwracalnych skutków biznesowych, wymagaj zgody przed nieodwracalnymi krokami zwrotnymi i pokazuj niepewność zamiast twierdzić, że cały plan agenta został wycofany. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.