Architektury agentów AI: przegląd

Dlaczego architektury agentów?

Agent LLM to coś więcej niż model z narzędziami: potrzebuje struktury, która określa, kiedy rozumuje, kiedy wywołuje narzędzie, kiedy tworzy plan, a kiedy sam się koryguje. Właśnie tę strukturę opisują architektury agentów: powtarzalne wzorce projektowe, które w ostatnich latach stały się wspólnym słownikiem branży.

Uderza, jak blisko siebie leżą ich początki: pięć kanonicznych wzorców ReAct, Reflexion, Plan-and-Execute, ReWOO i Tree-of-Thoughts powstało w krótkim oknie między październikiem 2022 a majem 2023 roku, głównie w środowisku Princeton, Google i Northeastern (Shunyu Yao jest współautorem trzech z pięciu publikacji). Od tego czasu branża albo uogólniła te wzorce do prymitywów frameworków (np. create_agent w LangChain, wcześniej create_react_agent w LangGraph, czy planning=True w CrewAI), albo połączyła je w hybrydowe wzorce następcze (LATS, LLMCompiler, Plan-and-Act).

Dla decydentów i tech leadów w Europie kluczowe pytanie rzadko brzmi „Który wzorzec jest najbardziej zaawansowany?”, lecz raczej „Który wzorzec rozwiąże to konkretne zadanie przy akceptowalnych kosztach, opóźnieniu i audytowalności?”. Ten przegląd daje do tego niezależną od dostawców mapę.

ReAct: splecione rozumowanie i działanie

ReAct (Yao i in., arXiv:2210.03629, październik 2022, ICLR 2023) to fundament niemal wszystkich dzisiejszych agentów korzystających z narzędzi. Idea: LLM na przemian generuje swobodnie formułowane tokeny „Thought” (rozumowanie) i tokeny „Action” (wywołania narzędzi), a następnie odczytuje „Observation” (wynik narzędzia). Pętla Thought → Action → Observation → Thought → … działa, dopóki model nie zwróci końcowego Finish[answer].

Rozwiązany problem: czysty Chain-of-Thought (CoT) halucynuje fakty, bo nie ma zakotwiczenia w rzeczywistości. Z kolei agenci typu action-only nie potrafią abstrakcyjnie rozumować o długoterminowych celach ani podnosić się po błędach. ReAct łączy jedno i drugie: rozumowanie steruje użyciem narzędzi, a obserwacje z narzędzi korygują rozumowanie. W oryginalnym badaniu dało to +34 punkty procentowe na ALFWorld (tekstowe zadania domowe) i +10 punktów procentowych na WebShop (nawigacja w e-commerce) w porównaniu z ówczesnymi baseline'ami opartymi na imitacji/RL, choć na modelach generacji GPT-3/PaLM. Wartości bezwzględne są dziś nieaktualne i należy je czytać wyłącznie jako efekty względne.

Mocne strony: niskie opóźnienie, niska złożoność implementacji, wysoka interpretowalność dzięki przejrzystemu śladowi rozumowania. W LangChain ReAct to jedna linijka kodu (create_agent, działa na LangGraph). Jego poprzednik create_react_agent jest od LangGraph v1 oznaczony jako przestarzały. CrewAI używa ReAct wewnętrznie w każdym agencie. n8n realizuje pętlę w natywnym węźle AI Agent za pomocą function callingu. Widok wykonania węzła rejestruje każde wywołanie narzędzia. Zespoły marketingowe bez własnych programistów dostają w ten sposób audytowalny log. Dawny typ agenta „ReAct Agent” n8n oznaczył jako przestarzały w wersji 1.82.0: nowe węzły AI Agent działają jako „Tools Agent”, a wraz z n8n 3.0 stara wersja węzła z opcją ReAct znika całkowicie.

Słabe strony: przy niejednoznacznych opisach narzędzi model halucynuje argumenty wywołań. Występuje „reasoning drift”: gdy agent raz uczepi się błędnej myśli, interpretuje kolejne obserwacje pod jej kątem. Do tego kontekst się rozdyma, bo każdy krok ponownie ciągnie za sobą prompt systemowy i całą dotychczasową trajektorię (koszt O(N·T)). W praktyce górna granica wynosi zwykle 10–25 kroków, zanim zaczną dominować utrata kontekstu lub dryf.

Ważna lekcja z praktyki: nowoczesne modele frontier natywnie opanowały pętlę rozumowania i działania dzięki function callingowi. Według bloga n8n jawne promptowanie w stylu ReAct stało się w dużej mierze zbędne. Dziś decydujące są pamięć, limity iteracji i przejrzystość działania. Najczęstszy błąd produkcyjny przy słabszych modelach to niepoprawny JSON w argumentach narzędzi. Dlatego korzystaj ze strukturyzowanego wyjścia lub trybu function calling wszędzie tam, gdzie dostawca to obsługuje.

Reflexion: agenci, którzy sami się krytykują

Reflexion (Shinn i in., arXiv:2303.11366, NeurIPS 2023) otacza istniejącego agenta pętlą samokorekty. Współpracują tu trzy komponenty: Actor (zwykle agent ReAct lub CoT) generuje trajektorię; Evaluator ją ocenia (binarnie, skalarnie lub za pomocą zewnętrznego zestawu testów); model Self-Reflection zamienia ocenę wraz z trajektorią w werbalny feedback: akapit krytyki w języku naturalnym, zapisywany w pamięci epizodycznej. W kolejnej próbie ta refleksja trafia na początek kontekstu Actora. „Aktualizacja polityki” jest czysto językowa; żadne wagi nie są zmieniane.

Kluczowy wniosek z publikacji: samodzielnie zwerbalizowana przez LLM analiza błędów jest silniejszym sygnałem uczenia niż sama liczbowa nagroda, i to w pełni in-context, w ramach wielu prób. Na HumanEval (generowanie kodu w Pythonie) Reflexion osiągnął 91% pass@1 wobec około 80% dla baseline'u GPT-4 w czasie badania.

Uwaga jednak: na MBPP Reflexion wypadł gorzej niż baseline, bo samodzielnie wygenerowane testy jednostkowe miały wysoki odsetek wyników fałszywie pozytywnych, a agent przedwcześnie zgłaszał „sukces”. Reflexion nie jest więc uniwersalnym sposobem na poprawę wyników. Potrzebuje sygnału z ewaluatora o wysokiej jakości. W zadaniach bez jasnej wyroczni (kreatywne pisanie, otwarty research) refleksje degenerują się do mglistych frazesów, a „konfabulowane refleksje” (czyli błędnie zdiagnozowane przyczyny błędów) przenoszą złą poprawkę do kolejnej próby.

Koszty: na próbę mniej więcej 2–5 razy tyle co pojedynczy przebieg ReAct, pomnożone przez K prób, czyli przy typowym K=3 od 6 do 15 razy tyle co jeden przebieg ReAct. Próby muszą być wykonywane sekwencyjnie, co z reguły wyklucza zastosowania w czasie rzeczywistym.

Trzy praktyczne zasady: po pierwsze, zawsze ograniczaj liczbę iteracji (max_reasoning_attempts w CrewAI, revision_number ≤ N w LangGraph). Po drugie, tam gdzie to możliwe, dostarczaj zewnętrzny sygnał ground truth (testy jednostkowe, ewaluator RAG, dopasowanie regex), bo sama samoocena jest zawodna. Po trzecie, cache'uj refleksje: wiele zespołów zapisuje je w bazie wektorowej według typu zadania i w ten sposób buduje emergentną bibliotekę umiejętności. Uwaga co do nazewnictwa: w niektórych źródłach (blog LangChain) „Reflection” oznacza każdą pętlę samokrytyki, natomiast „Reflexion” konkretnie publikację Shinna i in. Dlatego warto rozróżniać Reflexion (Shinn i in.) oraz wzorzec Reflection w szerszym sensie.

Plan-and-Execute: najpierw plan, potem realizacja

Wzorzec Plan-and-Execute oddziela planowanie od wykonania. Planner jednorazowo tworzy ponumerowany plan wieloetapowy, Executor (często subagent ReAct) realizuje go krok po kroku, a Replanner po każdym wykonaniu decyduje, czy zakończyć pracę, czy wydać skorygowany plan pozostałych kroków. Koncepcyjnie wzorzec opiera się na promptowaniu „Plan-and-Solve” (Wang i in., arXiv:2305.04091, ACL 2023) i na BabyAGI. Nazwę i popularność zawdzięcza implementacji w LangChain.

Kluczowa dźwignia: planowanie to trudne zadanie rozumowania (duży model), a wykonanie to używanie narzędzi krok po kroku (mniejszy, tańszy model). Takie stopniowanie modeli może obniżyć koszty, bo liczne kroki wykonania działają na mniejszym modelu. LangChain opisuje te oszczędności jedynie jakościowo, a pierwotny wpis LangChain przyznaje, że wzorzec wymaga więcej wywołań modelu niż agent ReAct. Do tego jawnie rozpisane plany są audytowalne, co jest mocnym argumentem w kontekstach enterprise i compliance.

Słabe strony: kruchość planu. Jeśli wstępny plan jest błędny, Executor marnuje wywołania na skazane na porażkę kroki, dopóki Replanner tego nie zauważy. Wykonanie pozostaje sekwencyjne (brak prawdziwej równoległości). Do tego każde ponowne planowanie znów wywołuje duży model; w silnie stochastycznych środowiskach plan jest odświeżany niemal na każdym kroku, co zjada przewagę kosztową. Praktyczna reguła: stosuj, gdy zadania rozpadają się na więcej niż trzy niezależne kroki, istnieje jasna wyrocznia do walidacji planu, a opóźnienie nie jest bezpośrednio odczuwalne dla użytkownika. Nie stosuj, gdy środowisko jest wysoce stochastyczne. Wtedy reaktywna pętla ReAct jest zdecydowanie lepsza. Wzorzec „Orchestrator-Workers” firmy Anthropic to w gruncie rzeczy to samo w nowej oprawie.

ReWOO: rozumowanie bez ciągłej obserwacji

ReWOO (Xu i in., arXiv:2305.18323, maj 2023) to zoptymalizowana kosztowo odpowiedź na apetyt ReAct na tokeny. Trzy moduły: Planner w jednym jedynym wywołaniu LLM generuje cały łańcuch kroków planu i wywołań narzędzi, przy czym składnia zmiennych (#E1, #E2, …) pozwala odwoływać się do wyników, których jeszcze nie ma. Worker uruchamia narzędzia w zadanej kolejności i zastępuje placeholdery rzeczywistymi wynikami. Na koniec Solver w ostatnim wywołaniu LLM odczytuje zadanie wraz ze wszystkimi dowodami i formułuje odpowiedź.

Efekt: N wywołań LLM zastępują dokładnie dwa (Planner + Solver), niezależnie od liczby kroków z narzędziami. Na HotpotQA publikacja podaje 5-krotnie wyższą efektywność tokenową przy +4% dokładności względem ReAct oraz spójną redukcję tokenów w sześciu benchmarkach NLP. ReWOO jest też odporny na awarie narzędzi: plan jest już ustalony, a Solver czysto rozpoznaje brakujące dowody.

Ograniczenia: brak adaptacji w trakcie wykonania. Jeśli dowód 3 przeczy planowi, ReWOO nie może przeplanować w tym samym przebiegu. Bez kontekstu środowiska Planner słabo radzi sobie z nieznanymi ekosystemami narzędzi (potrzebny few-shot prompting lub fine-tuning). Do tego narzędzia działają sekwencyjnie. Prawdziwą równoległość zapewnia dopiero następca, LLMCompiler (Kim i in., arXiv:2312.04511), dzięki grafowi DAG.

Dla agencji marketingowych ReWOO jest często najlepszym wzorcem w n8n: mocną stroną n8n są deterministyczne, deklaratywne workflowy, podstawianie zmiennych jest natywne, a zadania typu „zbadaj X → wzbogać → sformatuj → wyślij” stają się dzięki temu łatwe do debugowania, tanie i odporne na błędy. Raporty z praktyki mówią o redukcji kosztów tokenów o około 65% przy wzroście dokładności o 4–5%. Antywzorzec: nie stosuj ReWOO do zadań, w których wyniki narzędzi często unieważniają plan (np. interaktywna nawigacja w sieci); tam lepsze są Plan-and-Execute lub ReAct.

Tree-of-Thoughts: przeszukiwanie zamiast linii prostej

Tree-of-Thoughts (Yao i in., arXiv:2305.10601, NeurIPS 2023) zrywa ze ściśle liniową, biegnącą od lewej do prawej logiką CoT. Zamiast jednego łańcucha myśli rozpina się drzewo: każdy węzeł to „Thought” (częściowe rozwiązanie), w każdym miejscu model generuje k kandydatów, State-Evaluator ich ocenia (np. głosowaniem pewne/może/niemożliwe), a algorytm przeszukiwania (BFS lub DFS z backtrackingiem) przeczesuje drzewo. Publikacja wprost przedstawia to jako przeszukiwanie typu „System 2”, nawiązując do formalizmów rozwiązywania problemów Newella & Simona.

Wyniki w zadaniach opartych na przeszukiwaniu są drastyczne: Game of 24 rozwiązane w 74% (wobec 4% dla CoT i 7,3% dla IO), Mini-Crosswords na poziomie słów w 60% (wobec 16% dla CoT), kreatywne pisanie z lepszą spójnością. Cena jest jednak ogromna: z grubsza 10–100 razy więcej tokenów niż pojedyncze wywołanie CoT, a przy szerokich i głębokich drzewach przeszukiwania jeszcze więcej. Poniższa tabela rzędów wielkości liczy z szerokością b=5 i głębokością d=3, co daje 50–150×. Ponadto skuteczność mocno zależy od jakości generatora (GPT-3.5+ToT osiągnął w Game of 24 tylko 19% zamiast 74%).

Najważniejsza lekcja z praktyki dotycząca ToT: w 2026 roku do rozumowania ogólnego jest on w dużej mierze przestarzały, bo nowoczesne modele rozumujące (np. GPT-5 z reasoningiem, Claude z Extended Thinking, Gemini 3 z Thinking) wykonują przeszukiwanie wewnętrznie. ToT pozostaje istotny jako koncepcyjna podstawa drzewiastego przeszukiwania przez agentów (jest bazą LATS) oraz w trzech niszach: regulowanych branżach podlegających audytowi, łamigłówkach i optymalizacji z weryfikowalnymi nagrodami oraz wdrożeniach małych modeli z tanimi proposerami. W narzędziach takich jak n8n ToT praktycznie się nie skaluje z powodu eksplozji kombinatorycznej. Czystym przybliżeniem jest „Best-of-N sampling”: kilka równoległych przebiegów, z których krytyk wybiera najlepszy (ToT o głębokości 1).

Routing i wzorce hierarchiczne

Poza pięcioma wzorcami rozumowania Anthropic wymienia w „Building Effective Agents” (grudzień 2024) dwa kolejne wzorce strukturalne, które w praktyce często stanowią ramę. Routing klasyfikuje dane wejściowe i kieruje je do wyspecjalizowanej ścieżki, np. krok klasyfikatora, który rozdziela zgłoszenia do supportu według typu między różne prompty lub modele. Architektury hierarchiczne zagnieżdżają orkiestratora z subagentami: koordynujący LLM dynamicznie rozkłada zadanie i deleguje je do podrzędnych agentów. Plan-and-Execute z subagentami ReAct to właśnie ta odmiana (Orchestrator-Workers według Anthropic).

W kwestii ostrożności wobec hierarchii najczęściej cytowaną lekcję dostarcza Cognition (Devin): wpis „Don't Build Multi-Agents” (czerwiec 2025) ostrzegał, że równolegli agenci niejawnie podejmują sprzeczne decyzje i dają kruche wyniki. Zaktualizowane stanowisko „Multi-Agents: What's Actually Working” (kwiecień 2026) uznaje podejście multi-agent za sensowne w setupach równoległych przy odczycie, jednowątkowych przy zapisie. W przełożeniu na klientów agencji: postaw na jednego silnego agenta z narzędziami. Równoległych subagentów używaj wyłącznie do zbierania informacji, nigdy do zapisów ani zmian stanu.

Porównanie: kiedy który wzorzec

Poniższą tabelę rzędów wielkości traktuj jako przybliżony punkt odniesienia (syntetyczne szacunki na podstawie danych z publikacji i raportów z praktyki, nie bezpośrednie pomiary). Zmierz to samodzielnie na własnym obciążeniu:

Myśl przewodnia dla praktyki

Niezależnie od wzorca najważniejsza lekcja z produkcyjnych wpisów blogowych z lat 2024–2026 (Anthropic, Cognition, LangChain) jest zaskakująco trzeźwa: zacznij od najprostszego wzorca, który działa (zwykle ReAct), i przechodź do planowania, Reflexion lub przeszukiwania dopiero wtedy, gdy wymagają tego zmierzone tryby błędów. Anthropic ujmuje to tak: „Najbardziej udane implementacje korzystały z prostych, komponowalnych wzorców zamiast złożonych frameworków”.

Wzorce następcze powstałe od jesieni 2023 roku to w gruncie rzeczy rekombinacje pierwotnej piątki: LATS (Zhou i in., październik 2023) = ToT + Reflexion + MCTS, dostępny w LangGraph jako implementacja referencyjna; LLMCompiler (Kim i in., grudzień 2023) = ReWOO + równoległy DAG, według publikacji do 3,7× szybszy niż ReAct; Plan-and-Act (Erdogan i in., marzec 2025) = Plan-and-Execute dla długich horyzontów. Także frameworki zbiegają się we wspólnym prymitywie złożonym z grafu stanów i tool callingu: Microsoft skonsolidował AutoGen i Semantic Kernel w Microsoft Agent Framework (AutoGen jest oficjalnie w trybie utrzymania), a LangChain zastąpił create_react_agent przez langchain.agents.create_agent z middleware. Dla decydentów z regionu DACH, którzy oceniają stos technologiczny Microsoftu, to właśnie jest istotne rozwidlenie dróg.

Na koniec trzy niepodlegające negocjacjom zasady praktyczne: po pierwsze, każdy agent potrzebuje twardych limitów (recursion_limit, max_iterations), w przeciwnym razie pętle windują koszty. Po drugie, narzędzia do obserwowalności (LangSmith, Langfuse, Arize Phoenix) są de facto obowiązkowe. Po trzecie, na potrzeby compliance trzeba utrwalać pełne ślady Thought/Action/Observation z usuwaniem danych osobowych (PII). Ma to kluczowe znaczenie zwłaszcza w systemach podlegających RODO i unijnemu AI Act.

Uwaga: informacje dotyczące compliance w tym tekście mają charakter wyłącznie informacyjny i nie stanowią porady prawnej. Podane wyniki benchmarków pochodzą w większości z oryginalnych publikacji z lat 2022–2023 (era GPT-3.5/GPT-4) i należy je rozumieć jako względne wielkości efektu, a nie wartości bezwzględne dla dzisiejszych modeli frontier.