Agent pisarz i agent krytyk: pętla w n8n, która kończy się na rubryce, a nie na zmęczeniu
Jeden agent pisze, drugi ocenia według rubryki i reguł domu, a pętla wraca do pisarza, dopóki tekst nie przejdzie progu. Najważniejsze w tym workflow nie są prompty, tylko trzy warunki stopu i to, że krytyk nie ma prawa podbijać oceny, żeby pętla się skończyła.
Autor
- Adrian HuniaWspółzałożyciel SEVENEDGE
- Opublikowano:
- Ostatnia weryfikacja:
- Wersja n8n:
- 2.8.4
W skrócie
Co robi
- Przyjmuje brief z czatu n8n albo z ręcznego uruchomienia
- Pisarz tworzy szkic według briefu i reguł domu
- Krytyk ocenia szkic według rubryki i wskazuje konkretne poprawki
- Zatwierdza tylko przy ocenie od progu i zerze punktów do poprawy
- Zapisuje historię ocen i powód zakończenia w Google Sheets
Czego nie robi
- Nie sprawdza faktów spoza briefu
- Nie gwarantuje, że ten sam model nie przeoczy własnych słabości
- Nie publikuje tekstu
- Nie zastępuje redakcji przy tekstach publicznych
Czego wymaga
- n8n z node'ami LangChain (sprawdzone na 2.8.4)
- Klucz API Anthropic
- Arkusz Google na rejestr przebiegów
Agent pisarz i agent krytyk: pętla w n8n, która kończy się na rubryce, a nie na zmęczeniu
Pomysł jest prosty: jeden model pisze, drugi czyta krytycznie, pierwszy poprawia. Kłopot w tym, że naiwna wersja kończy się na jeden z dwóch sposobów. Albo krytyk po drugiej rundzie zaczyna przytakiwać, bo „tekst się poprawił”, albo pętla kręci się bez końca na kosmetyce.
Ten workflow n8n jest zbudowany wokół warunków stopu. Prompty są drugorzędne.

Stan pętli w jednym obiekcie
Wszystko, co pętla przenosi między rundami, siedzi w jednym obiekcie: numer rundy, aktualny szkic, ostatnia krytyka i historia ocen. Węzeł na początku rundy niczego nie zmienia, tylko przepuszcza ten stan dalej. Dzięki temu krawędź wracająca do początku pętli jest łatwa do prześledzenia w edytorze.
Pisarz ma prawo się nie zgodzić
Pisarz musi odnieść się do każdego punktu krytyki. Jeśli świadomie się z którymś nie zgadza, wpisuje go do pola deliberate_deviations zamiast cicho go zignorować. Brakujące dane oznacza placeholderem w rodzaju [FIGURE NEEDED: przychód Q3] i wpisuje do needs_from_human, zamiast zmyślać liczbę.
Krytyk ocenia, nie przepisuje
Krytyk dostaje brief, reguły domu i rubrykę. Ma dzielić uwagi na must_fix (łamie brief albo reguły) i would_improve (preferencja). W prompcie jest wprost:
Do NOT inflate the score across rounds to let the loop finish.
Zatwierdzenie wymaga dwóch rzeczy naraz
const meets_bar = !isNaN(score) && score >= threshold && mustFix.length === 0;
Wysoka ocena z otwartym punktem must_fix nie jest zatwierdzeniem. Rubryka i lista blokujących uwag to dwa osobne sygnały, a decyduje surowszy.
Trzy wyjścia z pętli
| Powód | Kiedy |
|---|---|
APPROVED | ocena od progu (domyślnie 80) i zero punktów must_fix |
ROUND_LIMIT | wyczerpany limit rund (domyślnie 3) |
STALLED | ocena nie zmieniła się o więcej niż 2 punkty przez dwie rundy |
Limit rund gwarantuje zakończenie bez względu na to, co ustalą między sobą dwa modele. Rejestr w arkuszu zapisuje nie tylko wynik, ale też powód zakończenia, historię ocen i to, czego tekst wciąż potrzebuje od człowieka.
Konfiguracja
| Parametr | Domyślnie | Po co |
|---|---|---|
houseRules | m.in. zdania do 25 słów, strona czynna | reguły, których krytyk pilnuje |
rubric | progi 90/80/60/40 | jak przeliczać jakość na liczbę |
approvalScore | 80 | próg zatwierdzenia |
maxRounds | 3 | twardy limit rund |
Ograniczenia
Pisarz i krytyk to ten sam rodzaj modelu. Mają podobne ślepe plamki, więc krytyk może nie zauważyć błędu, który pisarz zrobił z tego samego powodu.
Każda runda to co najmniej dwa wywołania modelu, a przy szkicu przekazywanym w całości koszt rośnie z długością tekstu.
Jakość wyniku zależy od rubryki. Rubryka ogólnikowa daje ogólnikową krytykę.
Workflow nie sprawdza faktów. Pilnuje tylko, żeby tekst nie wprowadzał liczb spoza briefu.
Kiedy to nie ma sensu
Przy jednym krótkim tekście szybciej poprawić go samemu. Pętla ma sens przy powtarzalnych tekstach z jasnymi regułami: notatki wewnętrzne, opisy produktów, odpowiedzi według wzoru. O tym, jak wyznaczać granice między agentami, piszemy w tekście każdemu agentowi trzeba powiedzieć, czego nie robi. Gdy takie teksty mają powstawać w Twoich systemach, to robota dla automatyzacji procesów z AI.
Weź to do siebie
Jak to zacytować
Adrian Hunia (2026). Agent pisarz i agent krytyk: pętla w n8n, która kończy się na rubryce, a nie na zmęczeniu. SEVENEDGE. https://sevenedge.pl/pl/workflows/agent-pisarz-krytyk-rubryka (dostęp: 5 listopada 2026)
Źródła
- n8n docs — AI Agentdokumentacja n8n
- n8n docs — Structured Output Parserdokumentacja n8n
Kto za tym stoi
Adrian Hunia
Współzałożyciel SEVENEDGE
Współzałożyciel SEVENEDGE. Projektuje i wdraża systemy biznesowe dla małych firm — od zarządzania produkcją po rejestrację czasu pracy. Pracuje na Next.js, FastAPI i PostgreSQL. SEVENEDGE działa bez podwykonawców: kod piszą dwaj właściciele.
Powiązane dokumenty
Inne przepływy, które opisaliśmy tak samo dokładnie.
- Przegląd umowy według Twojego playbooka: klauzula po klauzuli, z bramką dla prawnikaUmowa wpada do folderu, Claude wyciąga z niej klauzule, agent ocenia każdą względem Twoich stanowisk negocjacyjnych, a werdykt liczy kod. Przy pisaniu tego tekstu znaleźliśmy w opublikowanej wersji błąd, który gubił dwie z trzech ocen. Opisujemy go razem z poprawką.
- Obsługa zgłoszeń z trzema agentami AI: triage, dokumentacja, odpowiedź i bramka człowiekaJeden agent klasyfikuje zgłoszenie, drugi szuka odpowiedzi we własnej dokumentacji, trzeci pisze odpowiedź. Sama wychodzi tylko odpowiedź, która przeszła trzy warunki naraz. Resztę widzi człowiek, a każde pytanie bez pokrycia w dokumentacji staje się zadaniem do dopisania.


