--- title: "Ponawia się model, nigdy przelew" url: "https://predictes.com/pl/blog/ponawia-sie-model-nigdy-przelew" description: "Procesy łączące modele ze zwykłymi systemami ponawiają kroki bez przerwy. Bez idempotencji i zapisu każdej zmiany stanu ponowienie staje się duplikatem." --- # Ponawia się model, nigdy przelew 8 sierpnia 2026·3 min czytania·predictes Proces czyta fakturę modelem, weryfikuje wynik, księguje i wysyła polecenie przelewu. Wywołanie modelu przekracza limit czasu, choć po stronie dostawcy w rzeczywistości się zakończyło. Orkiestrator ponawia, dostaje drugi odczyt — niekoniecznie identyczny z pierwszym — i jeśli nic nie pilnuje kroku księgowania, faktura zostaje zaksięgowana dwa razy. Nic w tym nie jest egzotyczne. Procesy łączące modele ze zwykłymi systemami ponawiają kroki znacznie częściej niż klasyczne integracje: wywołania modelu są wolne, dławione przy dużym ruchu i od czasu do czasu przekraczają limit czasu, a pętla agenta potrafi wywołać to samo narzędzie dwa razy, bo nie zobaczyła wyniku pierwszego wywołania. Ponowień nie da się uniknąć. Bezpieczne ponowienia to decyzja projektowa — i zwykle podejmowana za późno. ## Dwie właściwości, przez które ponowienia są groźne **Skutki uboczne.** Coś poza procesem się zmienia: zapis w księdze, mail, polecenie przelewu, status w portalu dostawcy. Dwukrotne wykonanie kroku oznacza dwukrotne zrobienie tej rzeczy. **Niedeterminizm.** Ponowne wywołanie modelu nie musi dać tej samej odpowiedzi. Ponowienie kroku z modelem nie jest powtórzeniem, tylko nową decyzją. Jeśli weryfikacja sprawdziła pierwszy odczyt, a księgowanie użyło drugiego, nikt nie sprawdził tego, co zostało zaksięgowane. Klasyczne integracje miały pierwszy problem i nauczyły się go rozwiązywać. Procesy mieszane mają oba, a drugi po cichu podkopuje zwykłe rozwiązanie pierwszego. ## Zasady, które to zabezpieczają **Zapiszcie propozycję i pracujcie na zapisie.** Wynik modelu zapisuje się raz, z identyfikatorem oraz wersją modelu i promptu, zanim cokolwiek na jego podstawie zadziała. Weryfikacja, księgowanie i ślad audytowy odwołują się do tego samego zapisanego artefaktu. Ponowienia późniejszych kroków z niego korzystają i nigdy nie pytają modelu jeszcze raz. Ponowne zapytanie to świadoma nowa wersja, a nie efekt uboczny przekroczonego czasu. **Klucz idempotencji przy każdej zmianie stanu.** Wyprowadzony z tożsamości biznesowej — dostawca i numer faktury, a nie identyfikator uruchomienia — żeby druga próba została rozpoznana jako ta sama operacja. System docelowy albo cienka warstwa przed nim odmawia drugiego zastosowania tego samego klucza i zwraca pierwszy wynik. Dostarczenia „dokładnie raz” między systemami, których nie kontrolujecie, nie da się kupić; w praktyce działa „co najmniej raz” plus deduplikacja. **Stanem zarządza proces, a nie agent.** To, gdzie jest sprawa, co zrobiono i co czeka, żyje w trwałym silniku przepływu albo w maszynie stanów, które przetrwają restart. Nie żyje w kontekście agenta ani w pamięci pętli. Agent jest krokiem, który proces wywołuje; to nie on trzyma proces. **Ponowienia według typu kroku.** Wywołanie modelu: ponowienie z rosnącym odstępem, ograniczoną liczbę razy, a potem wyjątek. Deterministyczna weryfikacja: bez ponowień, bo za drugim razem odpadnie dokładnie tak samo. Zapis zewnętrzny: ponowienie wyłącznie z kluczem idempotencji. **Odróżnijcie porażkę od niewiadomej.** Przekroczony czas przy poleceniu przelewu oznacza, że nie wiecie, co się stało. Następnym krokiem jest zapytanie o status, a nie ponowna wysyłka. 1. 01PrzyjęcieKlucz z tożsamości biznesowej, a nie z numeru uruchomienia. 2. 02Odczyt modelemWynik zapisany raz, z wersją modelu i promptu. 3. 03WeryfikacjaDeterministyczna, na zapisanej propozycji. Nie ma czego ponawiać. 4. 04Zmiana stanuKlucz idempotencji; powtórka zwraca pierwszy wynik. 5. 05Skutek zewnętrznyPrzy niejasnym wyniku najpierw zapytanie o status. 6. 06Ślad audytowyDopisywany przy każdym kroku, nigdy nadpisywany. Model to jedyny krok, którego ponowienie może dać inną odpowiedź. ## Zapis, którego potrzebuje proces mieszany Dla każdej sprawy, wyłącznie dopisywany: wejście albo odwołanie do niego, wersja modelu i promptu, zapisana propozycja, które kontrole się wykonały i z jakim wynikiem, co zostało zatwierdzone i pod jakim kluczem oraz każda decyzja człowieka razem z tym, kto ją podjął. Taki zapis odpowiada na pytanie, które prędzej czy później zada każdy audytor i każdy zirytowany dostawca — dlaczego to zostało zapłacone i na jakiej podstawie — trzy tygodnie po fakcie. Daje też korzyść inżynierską, którą zespoły zwykle odkrywają późno: gdy zmienia się reguła walidacji, można przepuścić nową weryfikację przez zapisane propozycje bez ponownego wywoływania modelu i zobaczyć dokładnie, które dawne sprawy by zatrzymała. ## Sprawdźcie to, psując Zabijcie proces w połowie kroku. Wymuście przekroczenie czasu przez model. Zwróćcie błąd po tym, jak zapis już się udał. Dostarczcie to samo wejście dwa razy w odstępie godziny. Jeśli którakolwiek z tych prób da zdublowany skutek albo sprawę, której nikt nie potrafi odnaleźć, proces nie jest gotowy — niezależnie od tego, jak dobry jest model. Te testy są tanie, mechaniczne i prawie nigdy nie ma ich w planie. Należą do tego samego zestawu co przypadki ewaluacyjne i razem z rejestrem decyzji, dzięki któremu każdą pojedynczą sprawę da się wyjaśnić, są tą częścią [inżynierii agentów AI](https://predictes.com/pl/services/ai-agents-engineering), której nikt nie pokazuje na prezentacji, a na której polegają wszyscy. - idempotencja - ponowienia - ślad audytowy - orkiestracja ## Czytaj dalej - [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem) - [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)