Skrypt czy agent? Jak zaprojektować automatyzację analizy

Poniedziałek, 8:40. Raport sprzedaży ma być na spotkaniu o dziesiątej, więc ktoś pobiera eksport, poprawia daty, odświeża tabelę przestawną i dopisuje trzy zdania komentarza. Za tydzień to samo. W końcu pada propozycja: „Zbudujmy agenta, niech sam to ogarnia”.

Brzmi nowocześnie. Ja w takiej chwili pytam, co dokładnie kryje się pod słowem „to”. Pobranie pliku, policzenie przychodu, wyjaśnienie spadku i mail do dyrektora są czterema różnymi zadaniami. Każde potrzebuje innego narzędzia i innej kontroli. Wrzucone do jednego worka z napisem AI oszczędzają głównie czas na projektowanie. Ten czas wraca później, zwykle w piątek o 17:00.

Rozkładam taki raport na części i pokazuję, jak wybrać między skryptem, modelem i agentem. Na końcu dostajesz kartę automatyzacji, którą wypełnisz w kwadrans. Różnicę między modelem, czatem i agentem opisałem wcześniej, więc tutaj zajmuję się tym, co dzieje się przy kolejnym uruchomieniu, przy awarii i po zmianie danych. W kursie odpowiada temu „Projektowanie automatyzacji” z szóstego tygodnia.

Trzy poziomy tej samej automatyzacji

Najbardziej przydatne rozróżnienie znam z tekstu Anthropic Building effective agents. W workflow ścieżkę wyznacza kod: model i narzędzia przechodzą przez z góry zapisane kroki. W agencie model sam decyduje, jaki krok wykonać i po które narzędzie sięgnąć. Autorzy radzą zaczynać od najprostszego rozwiązania i dokładać złożoność dopiero wtedy, gdy wyraźnie poprawia wynik, bo elastyczność agenta kosztuje czas i pieniądze.

Na naszym raporcie wygląda to tak:

Zakres pracy	Rozwiązanie	Co odbierasz
Te same miary z tego samego eksportu	Skrypt z kontrolami	Tabelę zgodną z definicjami
Miary i krótki opis zmian	Skrypt plus jeden krok z modelem	Tabelę i sprawdzony komentarz
Szukanie przyczyny nietypowej zmiany	Agent w ograniczonym środowisku	Notatkę z ustaleniami i otwartymi pytaniami

Skrypt też ma warunki. „Jeśli brakuje pliku, zakończ z błędem” jest rozgałęzieniem, a mimo to nikt nie musi niczego zgadywać. Sama obecność wyjątków nie daje powodu, żeby oddawać sterowanie modelowi.

Trzy pytania, które wybierają narzędzie

Zanim ktoś otworzy edytor albo kreator agenta, zadaj trzy pytania.

Czy umiesz wypisać kroki? Pobierz eksport, sprawdź kolumny, policz przychód według zatwierdzonej definicji, zapisz tabelę. Jeśli tak, wystarczy skrypt w Pythonie albo zapytanie SQL uruchamiane z harmonogramu. Działa tak samo za tydzień i za rok, a gdy coś się zmieni, wiesz, którą linijkę poprawić.

Czy gdzieś trzeba pracować z tekstem? Odbiorca chce trzech zdań o tym, co się zmieniło. Tu model ma sens, ale w jednym, wąskim kroku. Dostaje gotowe agregaty i definicje, a liczby nadal pochodzą z obliczenia. Nie dostaje narzędzia do wysyłki, bo lista odbiorców siedzi w konfiguracji. Opis rynku ma prawo być błyskotliwy, ale przy okazji nie może zmieniać tego, kto dostaje dokument.

Czy następny krok zależy od tego, co odkryjesz? „Sprawdź, dlaczego sprzedaż w regionie spadła” jest dochodzeniem. Najpierw kompletność danych, potem wybór przekroju, potem może dodatkowe źródło. Dopiero tu agent zaczyna zarabiać na siebie. Daj mu zatwierdzony zestaw danych, limit pracy i jasny koniec: notatkę z ustaleniami, źródłami i pytaniami bez odpowiedzi. Uczciwe „brakuje danych, żeby to rozstrzygnąć” jest pełnoprawnym wynikiem.

Przy cyklicznych raportach na pierwsze pytanie zwykle odpowiadasz „tak”. Wtedy dostajesz skrypt i jest to dobra wiadomość.

Karta automatyzacji

Zanim wybierzesz narzędzie, wypełnij kartę. Mieści się na jednej stronie i odpowiada na pytania, które i tak padną, tylko później i w gorszym nastroju.

# Karta automatyzacji: tygodniowy raport sprzedaży

## Wynik

Co powstaje: tabela przychodu według regionów i 3 zdania komentarza
Odbiorca i użycie: dyrektor sprzedaży, poniedziałkowe spotkanie
Gotowe do: poniedziałek 9:30 (Europe/Warsaw)

## Wejście

Źródło: zatwierdzony eksport z systemu sprzedaży za zamknięty tydzień
Kompletność potwierdza: znacznik zamknięcia okresu w eksporcie
Definicje: przychód netto po zwrotach, data zamówienia (słownik KPI)

## Kroki

1. Skrypt: pobranie, kontrola kolumn i okresu, obliczenia
2. Model: komentarz z gotowych agregatów, obserwacje osobno od hipotez
3. Człowiek: akceptacja komentarza przed wysyłką

## Zatrzymanie

Brak eksportu albo zły okres: stop, alert do właściciela źródła
Pusty eksport: stop, chyba że jest potwierdzenie braku sprzedaży
Komentarz niezgodny z tabelą: wysyłka samej tabeli z adnotacją

## Ponowienia

Identyfikator przebiegu: rok i numer tygodnia
Przed ponowną wysyłką: sprawdź potwierdzenie doręczenia
Limit prób: 2, potem status "do sprawdzenia"

## Ludzie

Właściciel procesu: Zastępstwo:
Właściciel definicji KPI:
Kto reaguje na alert techniczny:

## Poza zakresem

Zmiana danych źródłowych, zmiana definicji, decyzje handlowe

Najwięcej daje sekcja „Zatrzymanie”. Najgroźniejsze są ciche awarie: proces kończy się na zielono, a w środku leży pusty plik albo dane z zeszłego tygodnia. Gdy z góry wiesz, co ma się stać przy pustym i niekompletnym eksporcie, znika sporo nerwowych telefonów w poniedziałek rano.

Harmonogram zaczyna się od gotowości danych

„Uruchom w poniedziałek o 6:00” zostawia sporo pytań. Czy dane będą już kompletne? Co, jeśli poprzedni przebieg jeszcze trwa? Do której godziny wynik ma sens? Oddziel godzinę startu od terminu gotowości i sprawdzaj kompletność przed obliczeniami.

Narzędzia do harmonogramów też mają swoje humory. Dokumentacja GitHub Actions uprzedza, że zaplanowane uruchomienie może się opóźnić przy dużym obciążeniu, a część zadań czekających w kolejce może przepaść. Zaplanowane workflow działają przy tym na domyślnej gałęzi repozytorium. Takie zdania czytam, zanim obiecam komukolwiek godzinę.

Proces nie podstawia po cichu zeszłotygodniowego pliku, gdy nowego brakuje. Jeśli chcesz mieć tryb awaryjny, raport pokazuje na samej górze, z jakiego okresu pochodzi.

Ponowienie wymaga osobnej reguły

Raport gotowy, wysyłka trwa, połączenie zrywa się w połowie. Wysłać jeszcze raz? AWS w tekście Timeouts, retries, and backoff with jitter przypomina, że przekroczenie czasu nie dowodzi, że operacja się nie wykonała. Bezpieczne ponawianie wymaga idempotencji, czyli takiej budowy operacji, żeby powtórzenie nie dawało drugiego skutku. Autorzy ostrzegają też, że ponowienia w czasie awarii potrafią ją pogłębić.

W raporcie oznacza to trzy proste rzeczy: identyfikator każdego przebiegu, osobny zapis „przygotowano” i „doręczono” oraz limit prób. Gdy nie da się ustalić, czy mail wyszedł, status „do sprawdzenia” jest lepszy niż dyrektor z trzema identycznymi raportami w skrzynce.

Alert, który ktoś obsłuży

Google SRE w rozdziale o monitorowaniu systemów odróżnia obserwację wnętrza systemu od sprawdzania tego, co widzi użytkownik, i podkreśla, że alert wzywający człowieka ma prowadzić do działania. Przy raporcie potrzebujesz obu widoków. Technicznego: kiedy start, który etap, jaki błąd. Biznesowego: czy zaakceptowany raport za właściwy okres leży tam, gdzie odbiorca go szuka.

Każdy alert ma adresata i czynność. Awaria pobrania idzie do właściciela źródła, zmiana definicji do właściciela KPI, odrzucony komentarz do recenzenta. Wiadomość „AI nie działa” na wspólnym kanale tylko przerzuca problem na osobę, która musi zgadnąć, gdzie praca utknęła.

Właściciel zostaje po wdrożeniu

NIST AI RMF w funkcji Govern mówi o jasnym przypisaniu ról i odpowiedzialności oraz o regularnych przeglądach ryzyka. Przekładam to na przyziemne pytanie: kto może zatrzymać publikację raportu i kto go zastępuje na urlopie? Osoba, która naprawia pobieranie pliku, wcale nie musi mieć prawa do zmiany zasad liczenia przychodu. Dlatego karta ma na te role osobne pola.

Przegląd wpisz w kalendarz po każdej zmianie źródła, instrukcji dla modelu albo samego modelu u dostawcy. Porównaj nowy wynik z kilkoma zaakceptowanymi raportami z przeszłości i zapisz, jak wrócić do poprzedniej wersji.

Pilotaż w cieniu

Nowej automatyzacji nie wpuszczaj od razu na poniedziałkowe spotkanie. Przez pierwsze cztery cykle niech działa w cieniu, obok dotychczasowego procesu. Raport ręczny trafia do dyrektora jak zwykle, a automatyczny ląduje w osobnym folderze. Po każdym cyklu porównujesz trzy rzeczy: czy liczby się zgadzają, czy komentarz mówi to samo co analityk i czy proces zatrzymał się tam, gdzie powinien.

Najwięcej uczy cykl, w którym coś się popsuło. Spóźniony eksport, zmieniona nazwa kolumny, święto w środku tygodnia. Jeśli automatyzacja w takim tygodniu zatrzymała się z czytelnym komunikatem, karta zadziałała. Jeśli wyprodukowała ładny raport z błędnymi danymi, wracasz do sekcji „Zatrzymanie” i dopisujesz brakujący przypadek.

Pilotaż kończysz decyzją zapisaną w karcie: przechodzimy na automat, zostajemy przy ręcznym procesie albo zmieniamy zakres. Każda z tych odpowiedzi jest w porządku, o ile wynika z porównania, a nie z tego, ile czasu zespół już w projekt włożył.

Policz koszt zaakceptowanego raportu

W pilotażu notuj czas przygotowania, sprawdzania i poprawek, koszt usług i każdy powód interwencji. Licz koszt raportu, który odbiorca przyjął, razem z próbami odrzuconymi. Jeśli model pisze komentarz w sekundę, a człowiek poprawia go przez kwadrans, ten kwadrans należy do rachunku.

Zacznij od jednego raportu i jednej karty. Jeśli po jej wypełnieniu wyjdzie Ci skrypt z harmonogramem, przyjmij to z ulgą. Nudny proces, który rozumie cały zespół, ma w sobie sporo uroku.