--- title: "Jak zbudować fabrykę agentów: pętla etap po etapie" url: "https://demertis.com/pl/blog/jak-zbudowac-fabryke-agentow-etap-po-etapie" description: "Fabryka agentów to stary cykl wytwarzania zamknięty w pętlę. Każdy etap: po co jest, co się psuje bez niego i od którego zacząć budowę." --- # Jak zbudować fabrykę agentów: pętla etap po etapie 6 listopada 2026·7 min czytania·Redakcja Cyjanotypia zamkniętego owalnego przenośnika z ośmioma różnymi stanowiskami wokół, między innymi lejem, ramieniem robota, stołem testowym i bramką trzymaną dźwignią, oraz niewielką suwnicą nad jednym z boków Fabryka agentów nie jest szybszą wersją cyklu wytwarzania oprogramowania. To ten sam cykl, zamknięty w pętlę, w której każdy etap zostawia zapis, a ludzie przechodzą od wykonywania pracy do trzech punktów decyzji: zatwierdzają opis, potwierdzają weryfikację i zgadzają się na wydanie. Wszystko pomiędzy przygotowują agenci. Zespół, który przeniesie stary proces jeden do jednego, tylko z agentem zamiast programisty, dostanie więcej kodu, a nie lepszy produkt. To trzeci tekst z serii. [Pierwszy](https://demertis.com/pl/blog/fabryki-agentow-nie-zostana-w-dziale-it) mówił, że fabryki wyjdą poza IT, [drugi](https://demertis.com/pl/blog/czyja-jest-wiedza-fabryki-agentow) pytał, do kogo należy to, czego fabryka się uczy. Tu opisujemy samą pętlę, w kategoriach, których używamy w całym programie: działanie, naprawa, ewolucja, a wokół wszystkich trzech ludzka obwiednia. ## Stary cykl w jednym akapicie Klasyczny cykl wytwarzania (SDLC) to sztafeta ludzi. Analityk zbiera wymagania, architekt projektuje, programista pisze, drugi programista przegląda, tester testuje, administrator wdraża, ktoś patrzy na monitoring. Między każdą parą jest przekazanie: dokument, zgłoszenie, rozmowa na korytarzu. Wiedza o tym, dlaczego coś zbudowano tak, a nie inaczej, żyje głównie w głowach i odchodzi razem z nimi. Ten model działał, bo najrzadszym zasobem był czas programisty, a przekazania były ceną współpracy ludzi. W fabryce wykonanie staje się najtańszym zasobem, a uwaga człowieka najdroższym. To odwraca logikę całego cyklu. ## Pętla w ośmiu etapach ``` +-------------------------------------------------------------+ | | v | 1 WEJŚCIE --> 2 TRIAGE --> 3 OPIS --> 4 WYKONANIE --> 5 RECENZJA [CZŁOWIEK | zatwierdza] v 8 MONITORING <-- 7 WYDANIE <------------------------ 6 WERYFIKACJA [CZŁOWIEK [CZŁOWIEK akceptuje] potwierdza] ``` Nad pętlą pracuje koordynator: agent, który odbiera wyzwalacz (zgłoszenie, wiadomość na czacie, alert z monitoringu), ustala, na którym etapie jest praca, i uruchamia właściwego agenta z właściwym modelem i kontekstem. Tani model do sortowania. Mocniejszy do opisów. Do recenzji ten, który najlepiej wypadł na waszym zestawie testowym. Koordynator to też pierwsze miejsce, do którego musi sięgać wyłącznik. Jeśli da się go zatrzymać spoza pętli, da się zatrzymać fabrykę. Każdy etap poniżej ma trzy części: co się dzieje, dlaczego to ważne i co się psuje bez niego. ### 1\. Wejście: praca przychodzi w jedno miejsce **Co się dzieje.** Pomysł, zgłoszenie błędu, alert albo prośba trafia do jednej kolejki. **Dlaczego to ważne.** Fabryka z sześcioma wejściami nie wie, co ma na stole. Nie da się zmierzyć ani przepustowości, ani kosztu. **Co się psuje bez tego.** Połowa pracy agentów dzieje się poza pętlą, na laptopach, bez śladu i bez metryk. ### 2\. Triage: najtańsza oszczędność w pętli **Co się dzieje.** Agent czyta zgłoszenie, próbuje odtworzyć problem i odkłada je do jednego z trzech koszy: gotowe do wykonania (jasny, mały błąd), niejasne, potrzebny opis (funkcja, wymaganie z kilkoma interpretacjami), odstawione, potrzebny człowiek (brak danych, decyzja biznesowa). **Dlaczego to ważne.** W starym cyklu sortowanie, szacowanie i wstępne rozpoznanie zjadają godziny najbardziej doświadczonych ludzi. Tu dostają pracę już posortowaną, a dobrze opisane drobne błędy idą do wykonania bez dotknięcia człowieka. **Co się psuje bez tego.** Agent wykonawczy dostaje mgliste zadanie i produkuje dużo kodu, który rozwiązuje nie ten problem. ### 3\. Opis: tu decyduje się jakość pętli **Co się dzieje.** Dla niejasnej pracy agent przygotowuje dwa dokumenty. Opis produktowy mówi, co użytkownik zobaczy i zrobi od początku do końca. Opis techniczny mówi, jak zmiana wpasuje się w istniejącą architekturę. Człowiek czyta oba, poprawia i zatwierdza, zanim powstanie linia kodu. **Dlaczego to ważne.** To punkt kontroli o największej dźwigni w całej fabryce. Poprawienie zdania w opisie kosztuje minutę. Poprawienie tej samej decyzji w zmianie na tysiąc linii kosztuje dzień. W starym cyklu ludzie przeglądali gotowy kod. W fabryce przeglądają zamiar. **Co się psuje bez tego.** Recenzja zamienia się w archeologię: człowiek odtwarza z kodu, co agent chciał zrobić, i zwykle odkrywa, że nie to, czego chciał zespół. ### 4\. Wykonanie: najmniej ciekawy etap **Co się dzieje.** Agent bierze zgłoszenie po triage albo zatwierdzony opis i przygotowuje zmianę. **Dlaczego to ważne.** Mniej, niż się wydaje. Jeśli wejście, triage i opis działają, wykonanie jest najbardziej przewidywalną częścią pętli. Wszyscy chcą od niego zaczynać, bo tu widać efekt. To błąd. **Co się psuje, gdy zaczniecie tylko od tego.** Szybki agent pisze kod do zgłoszeń, których nikt nie posortował ani nie opisał, a ludzie spędzają dni na odrzucaniu zmian zamiast na ich zatwierdzaniu. ### 5\. Recenzja: etap, który się uczy **Co się dzieje.** Agent recenzent przegląda każdą zmianę, zanim zobaczy ją człowiek. Działa w piaskownicy z dostępem do kodu, więc zanim zaproponuje poprawkę, może ją uruchomić. Ma przed sobą opis produktowy i techniczny, więc ocenia zmianę względem zamiaru, nie tylko stylu. Drugi agent obserwuje uwagi, które ludzie zostawiają w swoich recenzjach, zbiera je i co jakiś czas proponuje zmianę instrukcji recenzenta. Ta propozycja to zwykła zmiana, którą człowiek przyjmuje albo odrzuca. **Dlaczego to ważne.** Konwencje zespołu nie muszą być spisane z góry w dokumencie, którego nikt nie czyta. Narastają w instrukcjach recenzenta, uwaga po uwadze, i zostają w firmie, gdy ludzie odchodzą. **Co się psuje bez tego.** Ludzie dostają surowe zmiany i co tydzień powtarzają te same pięć uwag. ### 6\. Weryfikacja: człowiek potwierdza, zamiast śledzić **Co się dzieje.** Agent dostaje maszynę, uruchamia aplikację i przechodzi ścieżkę użytkownika od początku do końca, tak jak zrobiłby to tester. Do zmiany dołącza zrzuty ekranu albo nagranie, a osobno sprawdza, czy wynik zgadza się z opisem, od którego wszystko się zaczęło. **Dlaczego to ważne.** Testy automatyczne sprawdzają to, co ktoś przewidział. Weryfikacja na żywo łapie to, czego nikt nie przewidział: przycisk zasłonięty komunikatem, formularz, który działa, ale na telefonie nie da się go wypełnić. Praca człowieka zmienia się z odtwarzania zmiany na obejrzenie krótkiego nagrania i powiedzenie „tak” albo „nie”. **Co się psuje bez tego.** Ostatni krok przed wydaniem znów zależy od tego, czy ktoś miał czas ręcznie przeklikać aplikację. ### 7\. Wydanie: decyzja, która zostaje przy człowieku **Co się dzieje.** Człowiek akceptuje zmianę i ją wydaje. **Dlaczego to ważne.** Wydanie to moment, w którym ryzyko przechodzi z zespołu na klientów. Ktoś musi się pod tym podpisać. To ta sama myśl, co w tekście [ostatni człowiek w pętli to podpis](https://demertis.com/pl/blog/ostatni-czlowiek-w-petli-to-podpis): podpis nie jest krokiem technicznym i nie znika przez automatyzację. ### 8\. Monitoring: pętla się zamyka **Co się dzieje.** Agent obserwuje działający produkt, wyłapuje awarie i nietypowe zachowania i zakłada zgłoszenie, które wraca na etap pierwszy. Cała pętla może przejść bez człowieka aż do akceptacji: monitoring wykrywa awarię, triage ją odtwarza, wykonanie przygotowuje poprawkę, recenzja i weryfikacja ją sprawdzają, a rano człowiek dostaje gotową zmianę z nagraniem. **Dlaczego to ważne.** Bez tego etapu fabryka jest linią montażową. Z nim produkt sam zgłasza, co trzeba poprawić. W naszym słowniku to pętla naprawy, a jak przy [samonaprawie w ogóle](https://demertis.com/pl/blog/samonaprawa-to-nie-funkcja-tylko-architektura), jest bezpieczna tylko wtedy, gdy każdą proponowaną poprawkę da się cofnąć. ## Druga pętla: fabryka, która ulepsza fabrykę Nad pętlą produktu działa druga, mniej widoczna. Agent obserwator ocenia każdy przebieg: ile kosztował, ile razy człowiek musiał coś poprawić, czy zmiana nie wróciła później jako błąd. Na tej podstawie proponuje zmiany w samej fabryce: inny model w triage, dokładniejszy szablon opisu, nową umiejętność dla recenzenta. To pętla ewolucji i to tu fabryki najczęściej się psują. Żeby była bezpieczna, definicja fabryki musi być kodem: wersjonowanym, z możliwością cofnięcia złej zmiany, sprawdzenia nowej wersji na części pracy i porównania wyników na stałym zestawie zadań testowych. Ten zestaw musi leżeć poza zasięgiem zapisu fabryki, z powodów opisanych w tekście [miara, której system nie zmieni](https://demertis.com/pl/blog/miara-ktorej-system-nie-zmieni). Zmiana w fabryce przechodzi tę samą drogę co zmiana w produkcie: propozycja, recenzja, akceptacja człowieka. Fabryka, która sama przepisuje swoje instrukcje bez zgody człowieka, po kilku miesiącach robi rzeczy, których nikt nie rozumie. Druga pętla to też druga praca dla zespołu. Inżynierowie nie tylko robią produkt przez fabrykę. Ulepszają fabrykę, opierając się na pomiarach, a nie na przeczuciu. ## Stary cykl a fabryka: co się naprawdę zmienia Wymiar Stary cykl wytwarzania Fabryka agentów Kształt sztafeta liniowych przekazań między ludźmi pętla: monitoring zasila nową pracę Gdzie patrzy człowiek na gotowy kod na opis przed kodem i na nagranie po weryfikacji Najrzadszy zasób czas programisty uwaga człowieka w punktach decyzji Wiedza zespołu w głowach i w nieaktualnej wiki w instrukcjach agentów, wersjonowana razem z kodem Testowanie testy pisane z góry plus ręczne przeklikanie testy plus weryfikacja na żywo względem opisu Doskonalenie procesu retrospektywa raz na sprint ocena każdego przebiegu, zmiany w fabryce proponowane i zatwierdzane Zapis decyzji rozproszony po zgłoszeniach i czatach każdy etap pisze do jednego rejestru Odpowiedzialność za wydanie człowiek nadal człowiek Ostatni wiersz jest najważniejszy. Wymagania, architektura, zatwierdzenie opisu i decyzja o wydaniu zostają przy ludziach. Zmienia się wszystko pomiędzy. ## Gdzie fabryka szkodzi **Automatyzacja pracy, która tylko wygląda na prostą.** „Podnieś wersję biblioteki” brzmi jak zadanie dla agenta, dopóki nowa wersja nie zmieni sposobu zaokrąglania w module faktur. Zacznijcie tam, gdzie błąd jest tani i od razu widoczny: drobne usterki interfejsu, oczywiste awarie, aktualizacje bez zmian w działaniu. **Pomijanie opisu, bo agent szybko pisze.** Szybkie pisanie bez zatwierdzonego opisu to najdroższy sposób, żeby odkryć, że każdy rozumiał zadanie inaczej. **Samodoskonalenie bez hamulca.** Zmiana w fabryce bez akceptacji człowieka to dryf, nie postęp. **Fabryka bez ludzi.** Zespół, któremu powie się, że fabryka go zastąpi, odejdzie, zanim fabryka zacznie działać. Ludzie, którzy lubią trudne problemy systemowe, zwykle najszybciej polubią budowanie fabryki, jeśli dostaną je jako większą odpowiedzialność, a nie jako wyrok. ## Po czym poznać, że fabryka działa Metryka próżności Metryka wyniku liczba linii kodu napisanych przez agentów ile razy człowiek dotknął jednej zmiany od zgłoszenia do wydania, z czasem coraz mniej liczba zużytych tokenów koszt jednej zamkniętej zmiany i jego trend z miesiąca na miesiąc liczba uruchomionych agentów odsetek zgłoszeń, które przeszły przez pętlę bez poprawek po akceptacji „agenci piszą większość naszego kodu” czas od zmiany do produkcji, częstotliwość wdrożeń, odsetek nieudanych wdrożeń i czas przywrócenia działania (cztery miary DORA) Ocena jakości przez drugi model może to uzupełnić, ale tylko uzupełnić. Jeśli rośnie liczba poprawek po wydaniu, żadna ocena modelu nie przykryje tego, że fabryka pracuje gorzej. ## W jakiej kolejności budować Każdy krok powinien zostawić działający system, tak żeby po każdym można było się zatrzymać i nadal mieć coś wartościowego. 1. **Triage.** Agent sortuje przychodzące zgłoszenia do trzech koszy i dla dobrze opisanych drobnych błędów przygotowuje pierwszą wersję zmiany. Ludzie przestają tracić godziny na etykietowanie i szacowanie. 2. **Opisy.** Dla niejasnej pracy agent przygotowuje opis produktowy i techniczny, a człowiek zatwierdza je przed wykonaniem. Złożona praca wchodzi do fabryki, zamiast utknąć w kolejce. 3. **Recenzja z pętlą uczenia.** Agent w piaskownicy przegląda każdą zmianę, a drugi zamienia uwagi ludzi w propozycje zmian instrukcji recenzenta. 4. **Weryfikacja na żywo.** Agent przechodzi ścieżkę użytkownika, nagrywa dowód i porównuje wynik z opisem. Ludzie potwierdzają, zamiast śledzić. 5. **Połączenie i pomiar.** Koordynator spina etapy, monitoring zasila wejście, obserwator ocenia przebiegi, a wyłącznik jest testowany spoza pętli. Dopiero teraz rusza druga pętla. Ta sama kolejność działa poza oprogramowaniem. Pętla „zapotrzebowanie, sortowanie, opis zakupu, przygotowanie, sprawdzenie zgodności z polityką, weryfikacja kwot i zgód, wydanie zamówienia, pomiar” to ta sama fabryka w zakupach. W naszym programie pętla działa na tym etapie wyłącznie na nieregulowanych zadaniach wewnętrznych i to jest kolejność, którą zalecamy: najpierw zadania wewnętrzne, nieregulowane, a dopiero potem szerszy zakres. W tym tygodniu weźcie ostatnie dwadzieścia zgłoszeń z waszego systemu zadań i ręcznie, w arkuszu, przypiszcie każde do jednego z trzech koszy triage. Jeśli ponad połowa trafi do kosza „niejasne”, pierwszym agentem w waszej fabryce nie powinien być ten, który pisze kod, tylko ten, który pisze opisy. Zostaje decyzja. Można dać zespołowi agenta, który szybciej pisze kod, i patrzeć, jak rośnie kolejka do recenzji. Można też zbudować pętlę, w której ludzie przestają pisać i sprawdzać wszystko, a zaczynają zatwierdzać to, co naprawdę wymaga ich osądu. - fabryki agentów - pętle sterowania - cykl wytwarzania - akceptacja ## Czytaj dalej - [Czyja jest wiedza, której uczy się fabryka agentów](https://demertis.com/pl/blog/czyja-jest-wiedza-fabryki-agentow) - [Fabryki agentów nie zostaną w dziale IT](https://demertis.com/pl/blog/fabryki-agentow-nie-zostana-w-dziale-it)