Wzorce workflow agentów AI: 7 wzorców i kiedy każdy z nich naprawdę wygrywa (2026)

Wzorce workflow agentów AI: 7 wzorców i kiedy każdy z nich naprawdę wygrywa (2026)

Wzorce workflow agentów AI mają wreszcie twarde liczby: w styczniu 2026 roku Google Research przebadało 180 konfiguracji agentów i odkryło, że ta sama zmiana koordynacji podniosła parallelizowalne rozumowanie finansowe o 80,9%, a jednocześnie zgniotła planowanie sekwencyjne nawet o 70% na PlanCraft. Ta sama dźwignia, przeciwne wyniki. Zmienną, która decyduje, jest dekomponowalność zadania, a nie liczba agentów, a siedem wzorców poniżej oceniamy według opublikowanych danych, nie diagramów dostawców.

• Liczy się siedem wzorców: sekwencyjny, routing, parallelizacja, orchestrator-workers, refleksja, ReAct, plan-and-execute.
• Dekomponowalność zadania decyduje o zwycięzcy. Praca parallelizowalna zyskuje; praca sekwencyjna traci.
• Zacznij od jednego agenta. Drugiego dodaj dopiero, gdy pojedynczy agent utknie poniżej ~85% dokładności.

Wzorce workflow agentów AI w skrócie: co mówią dane

Siedem wzorców agentów AI to: sekwencyjny (prompt chaining), routing (handoff), parallelizacja (fan-out/fan-in), orchestrator-workers, refleksja (evaluator-optimizer), ReAct i plan-and-execute. Dokumentacje pięciu dostawców nazywają je inaczej, ale te siedem kształtów pokrywa każdą taksonomię, którą publikują obecnie Anthropic, OpenAI, Vercel, Microsoft i Google Cloud. Human-in-the-loop nie jest jednym z siedmiu: to warstwa sterowania, która owija dowolny z nich.

Kolumnę z pomiarami czytaj sceptycznie. Trzy wiersze niosą prawdziwe liczby; cztery mówią „brak publicznych pomiarów", co jest uczciwym stanem tej dziedziny w 2026 roku. Pięciu dostawców publikuje pięć różnych nazw na w gruncie rzeczy trzy lub cztery kształty pod spodem. Ostatnia kolumna istnieje po to, żebyś mógł odmapować dowolną z tych nazw na kształt, a reszta artykułu omawia je po jednej rodzinie naraz.

Dwie kolumny, których nikt w SERP nie omawia, to koszt tokenów i budżet opóźnień. Sekwencyjny i routing zużywają najmniej jednego i drugiego; orchestrator-workers najwięcej jednego i drugiego; parallelizacja zamienia wydatek tokenów na czas zegarowy. Wybieraj wzorzec według zasobu, który naprawdę ogranicza Twoje zadanie, a nie według diagramu, który wygląda imponująco.

Czym są wzorce workflow agentów AI (i jakie są 4 etapy workflow AI)?

Wzorce projektowe workflow agentów AI to wielorazowe kształty układania wywołań LLM, użycia narzędzi i logiki sterującej w system. Siedem, które powracają w każdej taksonomii dostawców, to: sekwencyjny, routing, parallelizacja, orchestrator-workers, refleksja, ReAct i plan-and-execute. Każdy inaczej wymienia koszt tokenów, opóźnienie i dokładność, więc właściwy wybór zależy od struktury zadania, a nie od frameworka, którego akurat używasz.

Typowy workflow agenta AI przechodzi cztery etapy w pętli:

1. Planowanie: model decyduje, co zrobić dalej, biorąc pod uwagę cel i dotychczasową historię.
2. Działanie: wywołuje narzędzie, co w 2026 roku zwykle oznacza serwer MCP lub function call. Model Context Protocol (MCP) standaryzuje tę warstwę narzędziową między modelami.
3. Obserwacja: wynik narzędzia wraca do kontekstu jako nowa wiadomość.
4. Refleksja / pętla: model ocenia, czy wynik jest wystarczająco dobry, po czym zapętla lub kończy.

Każdy wzorzec w tym artykule to inny sposób okablowania tych czterech etapów. Sekwencyjny ustala kolejność w kodzie. ReAct pozwala modelowi wybrać następny etap w każdej turze. Orchestrator-workers rozdziela pętlę między kilka modeli.

Jedno rozróżnienie ma znaczenie przed katalogiem. Workflow to z góry ustalone ścieżki kodu; agent oddaje sterowanie modelowi. Anthropic rysuje tę granicę tak w Building Effective Agents: „Workflow zapewniają przewidywalność i spójność dla dobrze zdefiniowanych zadań, natomiast agenci są lepszą opcją, gdy elastyczność i podejmowanie decyzji przez model są potrzebne na dużą skalę".

Jeśli trafiłeś tu, szukając klasycznych typów agentów w AI (prosty refleksyjny, oparty na modelu, oparty na celach, uczący się), ta taksonomia jest starsza niż LLM; to siedem wzorców powyżej decyduje o tym, czy Twój projekt w ogóle dowieziesz.

Wzorce deterministyczne: sekwencyjny, routing i parallelizacja

Trzy wzorce trzymają sterowanie w Twoim kodzie, a nie w modelu. Są najtańsze w uruchomieniu i najłatwiejsze do debugowania, a wskazówki zespołu Claude z marca 2026 są dosadne co do punktu startu: „Zacznij od najprostszego wzorca, który rozwiązuje Twój problem. Domyślnie wybieraj sekwencyjny".

Sekwencyjny (prompt chaining)

Jedno wywołanie zasila następne. Dzielisz trudne zadanie na uporządkowane kroki, a każdy krok dostaje wynik poprzedniego jako wejście. Wygraną jest czytelność: możesz obejrzeć każdy wynik pośredni i zbuforować każdy krok. Unikaj go, gdy podzadania są niezależne, bo płacisz opóźnieniem za kolejność, której nie potrzebujesz. Jeśli stan musi przetrwać między krokami lub między sesjami, to jest problem pamięci, a nie chainingu; podział opisujemy w naszym przewodniku po pamięci agenta AI. Jedynym opublikowanym potwierdzeniem jest domyślność: żadne badanie nie mierzy zysku z samego chainingu, bo to baseline, który każdy inny wzorzec musi dodatkowo pobić.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Routing (handoff)

Tani klasyfikator czyta wejście i wysyła je do wyspecjalizowanego promptu lub modelu. OpenAI ujmuje to w dokumentacji Agents SDK: „Agent triage kieruje rozmowę do specjalisty i ten specjalista staje się aktywnym agentem na resztę tury". Unikaj routingu, gdy klasyfikator jest mniej niezawodny niż uruchomienie jednej ogólnej ścieżki, bo każde błędne skierowanie to cicha błędna odpowiedź. Nazwany tryb awarii to utrata kontekstu przy przekazaniu: specjalista widzi tylko to, co prześle mu router. Przeniesienie pełnego śladu to decyzja z zakresu inżynierii kontekstu i błąd właśnie tutaj sprawia, że systemy z routingiem wydają się zapominalskie. Matematyka tokenów i tak przemawia za routingiem: klasyfikator działa na małym modelu (powyżej gpt-4o-mini), więc router dokłada kilkaset tanich tokenów na żądanie zamiast drugiego drogiego wywołania.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Parallelizacja (fan-out/fan-in)

Niezależne podzadania wykonują się jednocześnie, a krok scalający łączy wyniki. Anthropic dzieli to na sectioning (podział pracy) i voting (uruchomienie tego samego zadania kilka razy i porównanie). To jest właśnie kształt, który Google Research zmierzyło na +80,9% względem pojedynczego agenta na parallelizowalnym rozumowaniu finansowym w styczniu 2026, dokładnie dlatego, że zadanie dawało się czysto zdekomponować. Unikaj go w chwili, gdy krok n+1 zależy od wyniku kroku n; parallelizacja łańcucha zależności po prostu szybciej przestawia błędne odpowiedzi. Opóźnienie to druga połowa zysku: niezależne wywołania biegną współbieżnie, więc czas zegarowy spada z grubsza wraz z liczbą workerów, podczas gdy łączny wydatek tokenów zostaje stały.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct vs plan-and-execute: który wzorzec rozumowania wybrać?

ReAct przeplata rozumowanie z działaniem: model myśli, wywołuje narzędzie, obserwuje wynik i dopiero potem decyduje o następnym kroku. Plan-and-execute zapisuje pełny plan przed uruchomieniem jakiegokolwiek narzędzia, a potem wykonuje kroki po kolei. ReAct adaptuje się do niespodzianek w trakcie; plan-and-execute płaci z góry za jedno duże wywołanie planujące i ufa trasie.

ReAct decyduje o następnym kroku po każdej obserwacji; plan-and-execute zobowiązuje się do całej trasy przed pierwszym wywołaniem narzędzia.

ReAct pochodzi od Yao i in. (arXiv 2210.03629, v1 październik 2022, v3 marzec 2023), którzy zaraportowali +34% absolutnego sukcesu na ALFWorld i +10% na WebShop względem baseline'ów z uczenia przez naśladownictwo i uczenia ze wzmocnieniem, używając zaledwie jednego lub dwóch przykładów in-context. To domyślna pętla większości agentów używających narzędzi i zarazem luka w trzecim wyniku SERP: licząca 7133 słów dokumentacja orkiestracji Microsoft Learn całkowicie pomija ReAct. Ten rytm obserwuj-decyduj sprawia, że ReAct radzi sobie z zadaniami otwartymi („przeglądaj, aż znajdziesz X") lepiej niż jakikolwiek plan z góry: plan musiałby zgadywać zawartość stron przed ich przeczytaniem.

Plan-and-execute pochodzi od Wang i in., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), które najpierw opracowuje plan dzielący zadanie na podzadania, a potem je wykonuje. Artykuł donosi o pokonaniu zero-shot chain-of-thought na wszystkich dziesięciu ewaluowanych zbiorach danych; nie cytujemy jednej wartości, bo abstrakt artykułu żadnej nie publikuje. Użyj go, gdy trasa jest przewidywalna, a przeplanowywanie po każdym kroku marnowałoby tokeny. Kosztem jest kruchość: jeśli krok trzeci zawiedzie, pętla plan-and-execute potrzebuje jawnego hooka przeplanowania, podczas gdy ReAct przeplanowuje z samej konstrukcji.

Wiersz ze zmierzonymi dowodami to uczciwy wskaźnik. ReAct ma artykuł z 2022 roku z liczbami na poziomie zadań; plan-and-execute ma przegląd dziesięciu zbiorów bez żadnej nagłówkowej wartości, co jest jednym z powodów, dla których cytuje się go częściej, niż benchmarkuje.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

Ten limit iteracji nie jest opcjonalny. Pętla ReAct bez wyjścia pali tokeny, aż skończy się Twój budżet; max_steps to najtańsza barierka w całym tym artykule. Plan-and-execute potrzebuje tej samej barierki poziom wyżej: limituj przeplanowania, nie tylko kroki, bo zawodziący plan będzie się regenerował w nieskończoność.

Wzorce jakości: refleksja, evaluator-optimizer i human-in-the-loop

Wzorce jakości wydają dodatkowe tokeny, żeby podnieść jakość wyjścia, i zwracają się tylko wtedy, gdy jakość jest mierzalna. Refleksja (Anthropic nazywa ją evaluator-optimizer) uruchamia generator i krytyka w pętli: jeden model szkicuje, drugi krytykuje, szkic się poprawia. Jeśli nie umiesz ocenić wyniku testem, rubryką ani modelem oceniającym, krytyk to tylko dodatkowe tokeny kłócące się same ze sobą. Zbudowanie takiego scorera to trudna część; nasz przewodnik po ewaluacji agentów w produkcji opisuje, czego wymaga używalna funkcja oceny. Tam, gdzie warunek wstępny jest spełniony, wzorzec jest tanią polisą: Anthropic opisuje evaluator-optimizer jako dwa wywołania LLM w pętli, jedno generujące i jedno krytykujące, co kupuje mierzalny wzrost jakości za kilka dodatkowych sekund opóźnienia.

Tryb awarii, którego nikt nie rysuje na diagramach, to uciekająca refleksja: krytyk i generator zapętlają się na zawsze albo, co gorsza, oscylują. Lekarstwem jest twardy limit iteracji plus przerwanie przy braku poprawy, zapisane w kodzie, a nie proszone w prompcie:

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Human-in-the-loop to warstwa sterowania, a nie ósmy wzorzec. Owija dowolny z siedmiu: człowiek zatwierdza, zanim wykona się nieodwracalny krok. Tylko 2 z 6 czołowych wyników SERP w ogóle go omawiają. Umieść bramkę przy nieodwracalnych akcjach, realnych wydatkach i wszystkim, co opuszcza Twój system jako komunikacja zewnętrzna. Wszystko inne powinno działać bez nadzoru albo nie działać wcale. Sama bramka powinna być prostym kodem, a nie kolejnym LLM: kolejka akceptacji, próg wydatków, allowlista domen. Postawienie modelu w roli decydenta o tym, czy człowiek powinien spojrzeć, mija się z celem.

Czy multi-agent jest wart 15× więcej tokenów? Co naprawdę mówią benchmarki

Orchestrator-workers to siódmy wzorzec: agent wiodący dekomponuje zadanie, deleguje części agentom wykonawczym i scala to, co zwrócą. „Multi-agent" to ten wzorzec doprowadzony do skrajności, a nie osobny kształt, więc pytanie brzmi tak naprawdę, kiedy orkiestrator zarabia na swój narzut.

Kiedy użyć multi-agent zamiast pojedynczego agenta? Tylko wtedy, gdy pojedynczy agent utknie poniżej około 85% dokładności na zadaniu. Ta reguła kciuka krążyła na r/AI_Agents (2026-04-23) razem z badaniem Google Research i pasuje do zmierzonych danych: powyżej tego progu dodatkowi agenci dokładają koszt i amplifikację błędów, nie dokładając dokładności.

Oto każda opublikowana liczba, którą udało nam się zweryfikować, zestawione obok siebie:

Jedno zastrzeżenie, zanim klikniesz dalej: każda liczba Google Research powyżej pochodzi z wpisu na blogu z 2026-01-28, a artykuł za nim (arXiv 2512.08296) został od tego czasu zrewidowany, więc jego bieżąca wersja raportuje 260 konfiguracji i R² = 0,373 zamiast blogowych 180 i 0,513. Kierunek pozostaje ten sam w obu przypadkach; dokładne wartości zależą od tego, którą wersję czytasz.

Dwa z tych wierszy są rutynowo źle cytowane, więc oto arytmetyka. Wartość 15× od Anthropic jest mierzona względem interakcji czatowej, a wartość dla pojedynczego agenta to 4×. Czyli multi-agent kosztuje z grubsza 15 / 4 = 3,75× tokenów pojedynczego agenta, a nie 15×. A amplifikacja błędów 17,2× dla agentów niezależnych wobec 4,4× dla scentralizowanych w danych Google Research oznacza, że orkiestrator ogranicza amplifikację błędów z grubsza 17,2 / 4,4 = 3,9× względem puszczenia agentów bez nadzoru.

Czytając relację Anthropic obok liczb Google Research, nasza interpretacja jest taka, że to dekomponowalność, a nie liczba agentów, jest decydującą zmienną. Zadanie badawcze Anthropic dzieliło się czysto na równoległe podszukania, więc więcej agentów pomogło. Zadania planowania sekwencyjnego w Google nie dzieliły się, więc więcej agentów wchodziło sobie w drogę.

To zgadza się z tym, co mówią praktycy, gdy systemy trafiają do produkcji. Na r/AI_Agents wątek zatytułowany „Multi agent systems are a total nightmare in production" (2026-04-23, 56 punktów, 68 komentarzy) założył autor, który dowiózł ponad 20 systemów klienckich: „Te, które naprawdę działają… są niemal żenująco proste" oraz „za każdym razem, gdy jeden agent mówi do drugiego, tracisz kontekst. To jak ta zabawa w głuchy telefon". Najlepszy komentarz destyluje całą sekcję: „spróbuj rozwiązać problem pojedynczym agentem. Jeśli ten agent ma >85% dokładności, system multi-agent nie doda żadnej wartości".

Zanim dodasz agenta, wypróbuj tanie poprawki, które zmierzyło Anthropic: jeden ulepszony opis narzędzia dał 40% spadek czasu realizacji zadania, a równoległe wywoływanie narzędzi skróciło czas badania nawet o 90%. Obie biją drugiego agenta pod względem kosztu. Jeśli jednak przejdziesz na multi-agent w prawdziwym narzędziu, subagenci Claude Code to orchestrator-workers, które możesz obejrzeć linia po linii.

Ten sam wzorzec, pięć nazw: tablica Rosetta dla frameworków

Te same cztery kształty pojawiają się pod różnymi nazwami w dokumentacji każdego dostawcy, a nazewnictwo nie przenosi się między frameworkami. „Magentic" i „group chat" Microsoftu nie znaczą nic w OpenAI SDK, dopóki ich nie przetłumaczysz, a ten podatek od tłumaczenia to realny koszt, który ta tabela usuwa.

Pięciu dostawców, pięć słowników, trzy lub cztery realne kształty. Praktyczny koszt wychodzi przy zmianie frameworka: zespół przechodzący z Microsoft Agent Framework na OpenAI SDK musi najpierw odmapować „magentic" na agents-as-tools, a „group chat" na graf handoffów, zanim przeniesie się choćby linia kodu. Taksonomia Google Cloud z jedenastoma nazwami jest najdłuższa, lista Anthropic z siedmioma jest najczęściej cytowana, a trzy nazwy z bloga Claude to te, które wdrożysz jako pierwsze. Czytaj kształt, potem czytaj SDK. Nagłówki kolumn to sama dokumentacja: Anthropic, blog Claude, OpenAI Agents SDK, Vercel AI SDK, Microsoft Learn i Google Cloud. Gdy zobaczysz kształty, wybór frameworka staje się osobną decyzją; nasz przegląd najlepszych frameworków agentów AI w 2026 i porównanie LangGraph vs CrewAI vs OpenAI Agents SDK pokrywają ten temat.

Kiedy w ogóle NIE używać workflow agentów?

Często nie powinieneś. Najwyżej oceniana drabina decyzyjna na r/AI_Agents (2026-03-09) ujmuje to wprost: „Jeśli działają instrukcje if…then, użyj ich. Potem, jeśli działa tradycyjny workflow, użyj go. W przeciwnym razie użyj agentowej AI". Dwa z trzech czołowych wyników SERP to dokumentacja chmurowa, która strukturalnie nie może Ci powiedzieć, żebyś budował mniej. My możemy. Dane w tym artykule wskazują ten sam kierunek: dwa największe zmierzone wzrosty (+80,9% i +90,2%) wzięły się z zadań, które dawały się czysto zdekomponować, a największa zmierzona strata (−70%) wzięła się z siłowego użycia agentów na zadaniu, które się nie dawało.

Tryby awarii mają nazwy i każdy ma teraz przypisaną liczbę:

• Utrata kontekstu przy przekazaniach: każda wiadomość agent-do-agenta gubi stan (skarga „głuchy telefon" na r/AI_Agents, 2026-04-23).
• Amplifikacja błędów: 17,2× dla agentów niezależnych wobec 4,4× scentralizowanych (Google Research, 2026-01-28).
• Uciekające pętle refleksji: limituj iteracje i przerywaj przy braku poprawy, jak w kodzie powyżej.
• Degradacja zadań sekwencyjnych: 39–70% gorzej, gdy parallelizujesz pracę, która nie daje się zdekomponować (Google Research, 2026-01-28).
• Rozdęcie kosztów: z grubsza 15× tokenów czatu dla systemu multi-agent (Anthropic, 2025-06-13).

Każdy z tych trybów awarii ma limit, który zapiszesz w dziesięciu liniach kodu, a limit jest zawsze tańszy niż agent, którego miałeś właśnie dodać.

Walden Yan z Cognition przedstawił ten sam argument od strony budującego w Don't Build Multi-Agents (2025-06-12): „Dzielcie się kontekstem i pełnymi śladami agentów, nie tylko pojedynczymi wiadomościami" oraz „Akcje niosą ukryte decyzje, a sprzeczne decyzje niosą złe wyniki". Porównanie z r/AI_Agents to to, do którego ciągle wracamy: „multi-agent zaczyna wyglądać bardzo jak mikrousługi. Potężne, gdy granice są prawdziwe, bolesne, gdy są wymyślone".

Jak Techsy podchodzi do wyboru wzorca

Drabina poniżej to nasza interpretacja ustaleń Google Research i Anthropic oraz wątków praktyków, a nie nasz własny pomiar. Przechodzimy ją od góry do dołu i zatrzymujemy się przy pierwszym pasującym wierszu:

Z danych w tym artykule wynikają trzy rzeczy. Zaczynaj sekwencyjnie, bo Anthropic tak mówi i nic w SERP temu nie przeczy. Parallelizuj tylko to, co daje się zdekomponować, bo ta sama zmiana koordynacji zmierzona na +80,9% została też zmierzona na −70%. I traktuj drugiego agenta jak ostatnią deskę ratunku, bo rachunek za tokeny jest realny, a amplifikacja błędów zmierzona. Wspólny mianownik jest taki, że dodawanie agentów to ruch skalowania, a nie jakości: benchmarki nagradzają go tylko tam, gdzie praca się dzieli, a wątki praktyków potwierdzają to wszędzie indziej. Jeśli chcesz drugą opinię o architekturze, zanim ją zbudujesz, umów się na bezpłatną konsultację.

Najczęściej zadawane pytania

Jakie jest 7 wzorców agentów AI?

Siedem to: sekwencyjny (prompt chaining), routing (handoff), parallelizacja (fan-out/fan-in), orchestrator-workers, refleksja (evaluator-optimizer), ReAct i plan-and-execute. Powracają pod różnymi nazwami w każdej taksonomii dostawców, od Anthropic po Google Cloud. Human-in-the-loop jest omawiany razem z nimi, ale to warstwa sterowania owijająca dowolny z siedmiu, a nie ósmy wzorzec.

Jakie są 4 etapy workflow agenta AI?

Planowanie, działanie, obserwacja, refleksja. Model planuje następny krok, działa przez wywołanie narzędzia, obserwuje wynik narzędzia wchodzący do kontekstu, po czym ocenia, czy cel został osiągnięty, i zapętla lub kończy. Każdy wzorzec w tym artykule to inny sposób połączenia tych czterech etapów.

Jaka jest różnica między workflow AI a agentem AI?

Workflow podąża z góry ustalonymi ścieżkami kodu; agent pozwala modelowi kierować własnym przepływem sterowania. Reguła Anthropic: workflow dla przewidywalności przy dobrze zdefiniowanych zadaniach, agenci dla elastyczności, gdy decyzje sterowane modelem są potrzebne na dużą skalę. Większość systemów produkcyjnych to workflow z kilkoma agentowymi krokami w środku.

ReAct vs plan-and-execute: co wybrać?

Użyj ReAct, gdy następny krok zależy od tego, co zwróciło ostatnie narzędzie, a trasa może się zmienić w trakcie. Użyj plan-and-execute, gdy trasę można z góry przewidzieć, a przeplanowywanie po każdym kroku marnowałoby tokeny. ReAct zmierzono na +34% na ALFWorld (Yao i in., 2022); plan-and-execute pokonało zero-shot CoT na dziesięciu zbiorach danych (Wang i in., 2023).

Czy potrzebuję frameworka takiego jak LangGraph, żeby używać tych wzorców?

Nie. Każdy blok kodu w tym artykule to zwykłe wywołanie SDK, a wzorce są starsze niż frameworki, które je nazywają. Framework zarabia na siebie przy trwałości stanu, ponowieniach i śledzeniu wykonania, nie przy samym wzorcu. Jeśli wybierasz, nasze porównanie frameworków omawia te kompromisy.

Jak zatrzymać pętlę refleksji, żeby nie działała w nieskończoność?

Dwie barierki, obie w kodzie: twardy limit iteracji (używamy 4 rund) i przerwanie przy braku poprawy, które zatrzymuje pętlę w chwili, gdy przeróbka krytyka nie zdobywa lepszego wyniku niż bieżący szkic. Nie ufaj promptowi, że zakończy pętlę; model nie ma pojęcia, ile co kosztuje.

Kiedy pojedynczy agent wystarczy?

Gdy przekracza z grubsza 85% dokładności na zadaniu. Ta heurystyka, krążąca na r/AI_Agents (2026-04-23) razem z badaniem Google Research, pasuje do benchmarków: powyżej tego progu dodatkowi agenci dokładają koszt i amplifikację błędów, nie dokładając dokładności. Zmierz baseline pojedynczego agenta, zanim zaprojektujesz cokolwiek większego.

Gdzie znajdę przykłady wzorców workflow agentów AI z kodem?

Pięć bloków Pythona powyżej pokrywa wzorzec sekwencyjny, routing, parallelizację, ReAct i refleksję, wszystkie jako zwykłe wywołania SDK, które możesz skopiować wprost. Po przykłady w dialekcie dostawców: Vercel AI SDK dostarcza działający TypeScript dla każdego wzorca, a dokumentacja OpenAI Agents SDK pokrywa handoffy i agents-as-tools. Linki do obu znajdują się na liście źródeł poniżej.

Źródła

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); artykuł: arXiv 2512.08296
• Yao i in., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang i in., Plan-and-Solve Prompting (ACL 2023)
• Claude od Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (zaktualizowano 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Walden Yan), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)