Strzałki wybierają wynik, Enter go otwiera, Esc czyści pole.
Rozdział 22 · Procesy
Gdy coś się urwie: ponawianie bez dubli
Co się stało, gdy połączenie urwało się w połowie?
Agent dodaje termin do kalendarza. Połączenie pada, zanim wraca odpowiedź. Możliwości są co najmniej dwie: termin nie powstał albo powstał, a potwierdzenie nie dotarło. Ponowienie „na wszelki wypadek” może dać drugi wpis. Tak samo z wysłanym mailem, złożonym zamówieniem i zapisanym zgłoszeniem. W domu wygląda to tak: przypomnienie o przeglądzie auta pojawia się w kalendarzu dwa razy, a prośbę o fakturę dostaje ten sam sprzedawca dwa razy.
- JestNie ponawiaj
- Nie maPonów raz
- Nie da się ustalićZatrzymaj i zgłoś
Schemat decyzji po urwanym połączeniu. Najpierw sprawdź stan w miejscu docelowym, na przykład w kalendarzu albo w wysłanych. Jest wynik: nie ponawiaj. Nie ma wyniku: ponów raz. Nie da się ustalić: zatrzymaj się i zgłoś wynik niepotwierdzony.
Skąd się bierze bezpieczne ponawianie?
Informatycy mają na to pojęcie: idempotencja. Ponowienie tej samej operacji nie mnoży jej skutków. Wyobraź sobie numer sprawy wpisany na obu kopiach formularza. Urząd widzi, że to wciąż ta sama sprawa. Stripe opisuje to przez klucz operacji, który pozwala bezpiecznie ponawiać wybrane żądania (Stripe: idempotent requests). Nie każdy kalendarz, skrzynka i integracja działa w ten sposób, więc nie zakładaj tego z góry.
Formatu kluczy znać nie musisz. Potrzebujesz jednej zasady: gdy wynik działania jest niepewny, najpierw sprawdzamy stan, dopiero potem decydujemy o powtórzeniu. W kalendarzu agent odczytuje wydarzenie po identyfikatorze, jeśli go dostał. Gdy odpowiedź z identyfikatorem zginęła razem z połączeniem, szuka we właściwym kalendarzu wpisu z tą datą, godziną i uczestnikami. Podobny tytuł nie wystarcza, bo dwie różne sprawy mogą nazywać się tak samo.
Co ponawiać, a czego nie?
Odczyt i działanie ze skutkiem traktuj osobno. Ponowne pobranie listy wydarzeń nie utworzy drugiej listy, najwyżej zużyje limit. Ponowna wysyłka to nowa wiadomość. Gdy nie da się ustalić wyniku, agent ma napisać „wynik niepotwierdzony”, dodać, co wiadomo i co trzeba sprawdzić. Ty masz wiedzieć, czy sprawa wymaga Twojej uwagi.
Przy zadaniach z wieloma krokami agent powinien prowadzić krótki zapis postępu: co zrobiono, gdzie leży wynik, co zostało. Anthropic opisuje taki sposób pracy przy długich zadaniach programistycznych, gdzie kolejne sesje mają ograniczony kontekst (Anthropic: Effective harnesses for long-running agents). Zapis pomaga wznowić pracę. Nie dowodzi jednak, że kroki sprzed przerwy były poprawne, więc sprawdzasz je w miejscu docelowym.
Przed ponowną wysyłką maila agent zagląda do folderu wysłanych i szuka tej konkretnej wiadomości, nie podobnej. Jeśli nie ma do niego dostępu, zatrzymuje się i pyta Cię, zamiast wysyłać drugi raz. Serwer poczty może przyjąć wiadomość i wysłać ją chwilę później, więc pusty folder tuż po awarii agent sprawdza jeszcze raz po kilku minutach (Microsoft Graph: sendMail). Ponowienie zgłoszenia o awarii drukarki albo prośby do sprzedawcy wygląda w skrzynce na natręctwo, więc koszt pomyłki jest realny, choć niewielki.
Przykład techniczny: render w nocy. Komputer zasnął po 412 z 600 klatek. Wznowić da się render zapisywany jako osobne obrazy, po jednym na klatkę, i Blender zaleca taki zapis przy animacji, która liczy się dłużej niż kilka minut (Blender: Rendering Animations). Rozsądne wznowienie sprawdza, które pliki klatek istnieją i otwierają się, a potem liczy tylko brakujące. Start od zera marnuje noc. Start od klatki 413 bez sprawdzenia może zostawić uszkodzony ostatni plik.
Wznowienie renderu po przerwie
Render urwał się w nocy. Sprawdź, które pliki klatek istnieją i dają się otworzyć. Dokończ tylko brakujące i niczego nie nadpisuj.
Pełna wersja
Render animacji w folderze projektu urwał się w nocy, nie wiem, w którym miejscu. Jeśli nie widzisz folderu projektu albo plików klatek, napisz, co mam udostępnić, i na tym skończ. Najpierw sprawdź, czy render zapisuje osobny plik dla każdej klatki; jeśli to jeden plik wideo, zatrzymaj się i napisz mi to. Potem sprawdź, które pliki klatek istnieją i dają się otworzyć. Ostatni plik traktuj jako podejrzany i otwórz go osobno. Uszkodzone pliki przenieś do osobnego folderu, nic nie kasuj i nie nadpisuj poprawnych klatek. Policz brakujące i uszkodzone klatki, zaczynając od pierwszej z nich. Na końcu napisz mi, ile klatek jest poprawnych, ile policzono teraz i czy cały zakres jest kompletny. Jeśli czegoś nie da się potwierdzić, napisz to osobno. Nie ogłaszaj „gotowe”, dopóki każda klatka z zakresu ustawionego w projekcie nie ma pliku, który się otwiera.
Ta sama reguła obowiązuje po każdej przerwie, bo w tym czasie mogły zmienić się dane albo ktoś zrobił część pracy ręcznie. Agent zaczyna więc od odczytu tego, co jest teraz.
Zapisujemy to tylko w tej przeglądarce.