---
title: "Plan-and-Execute: gdy planowanie jest oddzielone od wykonania"
description: "Plan-and-Execute to architektura agentowa, w której Planner najpierw tworzy pełny, wieloetapowy plan, a Executor realizuje go krok po kroku. Replanner w razie potrzeby dostosowuje plan."
locale: "pl"
canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/architektury-agentow-ai-przeglad/plan-and-execute-gdy-planowanie-jest-oddzielone-od-wykonania"
category: "Agenci AI"
topic: "Architektury agentów AI: przegląd"
updated: "2026-10-28T13:36:23.061Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Plan-and-Execute: gdy planowanie jest oddzielone od wykonania

Plan-and-Execute to architektura agentowa, w której Planner najpierw tworzy pełny, wieloetapowy plan, a Executor realizuje go krok po kroku. Replanner w razie potrzeby dostosowuje plan. Oddzielenie planowania od wykonania pozwala wykonywać poszczególne kroki mniejszym modelem i daje lepszą kontrolę nad długimi zadaniami niż czysty ReAct.

## W skrócie

- Plan-and-Execute oddziela ciężkie zadanie rozumowania (planowanie) od taniego wykonania krok po kroku. Umożliwia to warstwowanie modeli: mocny model jako Planner, tani model jako Executor.
- W porównaniu z czystym ReAct ta architektura może obniżyć koszty, bo kroki z użyciem narzędzi wykonuje mniejszy model, a duży model tylko planuje i po każdym kroku sprawdza plan.
- Po każdym kroku Replanner decyduje: zakończyć albo dostosować resztę planu. Daje to odporność przy długich zadaniach, którą ReAct traci przez dryf rozumowania.
- Architekturę spopularyzował LangChain jako agentową adaptację promptingu Plan-and-Solve (Wang et al. 2023, arXiv:2305.04091), inspirowaną BabyAGI.
- Słabości: kruche plany marnują wywołania na beznadziejne kroki, brakuje prawdziwej równoległości (kroki wykonują się sekwencyjnie), a częste ponowne planowanie zjada przewagę kosztową.
- Stosuj, gdy zadania da się rozłożyć na więcej niż trzy niezależne kroki, poprawność planu można jasno sprawdzić, a opóźnienie nie jest bezpośrednio widoczne dla użytkownika. W silnie stochastycznych środowiskach lepszym wyborem jest ReAct.

Plan-and-Execute to [architektura agentowa](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/czym-sa-agenci-ai/elementy-agenta-ai-wyjasnienie-5-komponentow), w której **Planner** najpierw tworzy pełny, wieloetapowy plan, a **Executor** realizuje go krok po kroku. **Replanner** w razie potrzeby dostosowuje plan. Oddzielenie planowania od wykonania pozwala wykonywać poszczególne kroki mniejszym modelem i daje lepszą kontrolę nad długimi zadaniami niż czysty ReAct.

Najpierw szybkie odpowiedzi:

- **Co rozwiązuje:** rozumowaniu krok po kroku w ReAct brakuje globalnego obrazu: przy długich zadaniach [agent](https://blckalpaca.at/pl/slownik/agent) zapomina pierwotny cel. Plan-and-Execute wymusza trzymanie się celu dzięki jawnemu planowi przygotowanemu z góry.
- **Dlaczego może być taniej:** poszczególne kroki wykonuje mniejszy, tańszy model. Duży model tylko planuje i po każdym kroku sprawdza, czy plan nadal się trzyma (warstwowanie modeli).
- **Główny kompromis:** lepsza kontrola i audytowalne plany kontra kruchość planów i brak prawdziwej równoległości. W silnie stochastycznych środowiskach ReAct jest zdecydowanie lepszy.

## Pochodzenie: Plan-and-Solve, BabyAGI i adaptacja w LangChain

Precyzyjne umiejscowienie jest tu ważne, bo atrybucja często bywa uproszczona. Bazowy wzorzec promptingu pochodzi z pracy [*Plan-and-Solve Prompting*](https://blckalpaca.at/pl/slownik/chain-of-thought-prompting) (Wang et al., arXiv:2305.04091, ACL 2023). Praca zaproponowała dwuetapowy [prompt](https://blckalpaca.at/pl/slownik/prompt) zero-shot, w przybliżeniu „Najpierw opracujmy plan / Wykonajmy plan”, i przewyższyła nim Zero-Shot-CoT w rozumowaniu matematycznym.

**Nazwa agenta** „Plan-and-Execute” pochodzi jednak z [adaptacji w LangChain](https://python.langchain.com/docs/), a nie z oryginalnej pracy. Architekturę zainspirowało dodatkowo **BabyAGI** (Yohei Nakajima, 2023). Poprawne sformułowanie brzmi więc: spopularyzowana przez [LangChain](https://blckalpaca.at/pl/slownik/langchain) architektura agentowa Plan-and-Execute, oparta na promptingu Plan-and-Solve.

Blisko spokrewniony wzorzec Anthropic opisuje w [Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents) (grudzień 2024): w workflow Orchestrator-Workers centralny [LLM](https://blckalpaca.at/pl/slownik/llm) dynamicznie dzieli zadanie, deleguje części do LLM-ów workerów i łączy ich wyniki.

## Trzy komponenty

Wariant w LangGraph składa się z trzech węzłów:

1. **Planner:** jednorazowo generuje ponumerowany, wieloetapowy plan (`Plan: List[str]`).
2. **Executor:** zazwyczaj subagent ReAct, który realizuje kolejne kroki planu jeden po drugim.
3. **Replanner:** po każdym wykonaniu decyduje, czy zwrócić końcową `Response` (zakończenie), czy wygenerować nowy, w razie potrzeby zmieniony plan dla pozostałej pracy.

Przebieg:

`Input → Planner → [Plan: Schritt_1, Schritt_2, …] → Executor(Schritt_1) → Replanner → (Executor(Schritt_2) → Replanner → …) → Response`

Kluczowa innowacja: Plan-and-Execute **oddziela planowanie** (ciężkie zadanie rozumowania, przy którym opłaca się duży model) **od wykonania** ([korzystanie z narzędzi](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/czym-sa-agenci-ai/tool-calling-jak-agenci-ai-korzystaja-z-narzedzi) w każdym kroku, do którego wystarcza mniejszy, tańszy model).

## Zalety w porównaniu z czystym ReAct

- **Szybsze wykonanie wieloetapowe:** Executor sam realizuje krok planu wraz z jego wywołaniami narzędzi. Duży model wraca do gry dopiero potem, a nie po każdej pojedynczej akcji.
- **Oszczędność dzięki warstwowaniu modeli:** duży model klasy frontier planuje, a mały, tani model wykonuje kroki. LangChain opisuje tę [przewagę kosztową nad ReAct](https://www.langchain.com/blog/planning-agents) tylko jakościowo. Łączna liczba wywołań wcale nie musi przy tym spaść: w 2023 roku LangChain wprost wskazał [więcej wywołań LLM](https://www.langchain.com/blog/plan-and-execute-agents) jako cenę tego wzorca i przyznał, że wielu zalet nie sprawdzono w benchmarkach.
- **Jawne, audytowalne plany:** mocny argument w zastosowaniach korporacyjnych i compliance, bo plan jest dostępny do wglądu przed wykonaniem.
- **Globalny obraz:** cel nadrzędny pozostaje zachowany na długich trajektoriach, zamiast ginąć przez „dryf rozumowania” ReAct.

## Słabości i tryby awarii

Plan-and-Execute nie jest panaceum. Najważniejsze ograniczenia:

- **Kruchość planu:** jeśli plan przygotowany z góry jest błędny, Executor marnuje wywołania na beznadziejne kroki, dopóki Replanner tego nie zauważy. Sama praca o Plan-and-Solve dokumentuje błędy obliczeniowe, brakujące kroki i nieporozumienia semantyczne.
- **Brak prawdziwej równoległości:** plany są listami; Executor przetwarza je sekwencyjnie. Właśnie to rozwiązuje LLMCompiler (Kim et al., arXiv:2312.04511), który zamiast listy emituje DAG.
- **Koszty ponownego planowania:** jeśli Replanner musi często zmieniać plan, dochodzą kolejne kroki, a każdy dodatkowy krok kosztuje kolejny przebieg Executora i Replannera. W zaszumionych środowiskach dzieje się to niemal przy każdym kroku i zjada przewagę kosztową.
- **Wybór modelu jest kluczowy:** jeśli model Executora jest za słaby na dane kroki, więcej kroków kończy się niepowodzeniem, Replanner musi częściej zmieniać plan, a przewaga kosztowa maleje.

## ReAct vs. Plan-and-Execute: bezpośrednie porównanie

| Kryterium | ReAct | Plan-and-Execute |
| --- | --- | --- |
| Planowanie | Niejawne, krok po kroku (reaktywne) | Jawne, pełny plan z góry |
| Wywołania LLM | Jedno wywołanie na krok | Jedno wywołanie planujące, wykonanie małym modelem, wywołanie Replannera po każdym kroku |
| Zużycie tokenów | Rośnie z każdym krokiem, duży model przy każdej akcji | Zależy od częstotliwości ponownego planowania, wykonanie mniejszym modelem |
| Opóźnienie (N kroków z narzędziami) | N x sekwencyjnie | 1 wywołanie planujące + N wykonań + N wywołań Replannera, sekwencyjnie |
| Warstwowanie modeli | Trudne (jedna pętla, jeden model) | Naturalne (duży Planner, mały Executor) |
| Odporność przy długoterminowych celach | Słaba (dryf rozumowania) | Silna (cel pozostaje utrwalony w planie) |
| Odporność na stochastyczność | Silna (reaktywność) | Słaba (plan może się zdezaktualizować) |
| Audytowalność | Ślad wykonania dla każdego kroku | Jawny plan z góry, przyjazny dla compliance |
| Złożoność implementacji | Niska (jedna linijka w LangGraph) | Średnia |

Wiersz dotyczący tokenów opisuje tendencje, a nie wyniki pomiarów. Sprawdź to na własnym obciążeniu.

## Pseudokod: pętla Plan-and-Execute

W uproszczeniu, na wzór logiki schematu stanu w LangGraph:

\`\`\`

# State: input, plan (lista), past\_steps (wykonane), response

def planner(state):
    # duży model JEDEN RAZ tworzy kompletny plan
    state.plan = big\_model.plan(state.input)   # np. ["1. ...", "2. ...", "3. ..."]
    return state

def executor(state):
    krok = state.plan[0]                  # następny otwarty krok
    wynik = small\_model.run\_react(krok)   # tani subagent ReAct + narzędzia
    state.past\_steps.append((krok, wynik))
    return state

def replanner(state):
    # albo gotowe -> Response, albo nowy plan na resztę pracy
    if big\_model.is\_done(state):
        state.response = big\_model.final\_answer(state)
        return state, "END"
    state.plan = big\_model.replan(state.input, state.past\_steps)
    return state, "executor"

# Graf: planner -> executor -> replanner -> (executor | END)

\`\`\`

Kluczowa kwestia: `big_model` (drogi) działa tylko w `planner` i `replanner`, a `small_model` (tani) dźwiga właściwe obciążenie wykonawcze.

## Konkretny przykład: codzienny raport marketingowy

Agencja buduje agenta, który każdego ranka przygotowuje raport o konkurencji. Zadanie: „Zbadaj trzech najważniejszych konkurentów, zbierz ich nowe treści z ostatnich 24 godzin, podsumuj je i wyślij e-mailem”.

W [**czystym ReAct**](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/architektury-agentow-ai-przeglad/agent-react-wzorzec-thought-action-observation) agent po każdej pojedynczej akcji (wyszukiwanie, scraping, podsumowanie) ponownie wywoływałby pełny model, łącznie z całym dotychczasowym oknem kontekstu. Przy 12 krokach to 12 drogich wywołań plus rosnący prefiks.

W **Plan-and-Execute** Planner raz tworzy plan (1 drogie wywołanie):

\`\`\`
Plan:

1. Zidentyfikować konkurentów A, B, C
2. Dla każdego: zebrać scraperem nowe wpisy blogowe i posty w social mediach z ostatnich 24h
3. Krótko podsumować każdego konkurenta
4. Sformatować zbiorczy raport
5. Wysłać e-mailem do zespołu
\`\`\`

Kroki 2-5 realizuje potem tani Executor. Duży model po każdym kroku sprawdza tylko, czy plan nadal się trzyma, i planuje od nowa, gdy np. źródło jest niedostępne. Jeśli to pozostaje wyjątkiem, to zadanie wsadowe obniża koszty, bo właściwa praca spoczywa na tanim modelu. Jednocześnie agencja ma plan udokumentowany w przejrzysty sposób.

## Zastosowanie we frameworkach (stan na 2026 rok)

- **LangGraph:** natywnie, z oficjalnym tutorialem. Kanoniczny schemat stanu z `input`, `plan: List[str]`, `past_steps` i `response`; węzły `planner`, `agent` (Executor) i `replan`. Krawędź warunkowa `should_end` prowadzi z powrotem do Executora albo do `END`.
- **CrewAI:** bezpośrednie dopasowanie przez `Crew(planning=True)`. Aktywuje to `AgentPlanner`, który przed każdą iteracją crew tworzy plan krok po kroku i wstrzykuje go do opisu każdego zadania. Z `Process.hierarchical` oraz `manager_agent`/`manager_llm` dochodzi zarządzająca warstwa ponownego planowania.
- **AutoGen / Microsoft Agent Framework:** odwzorowanie przez group chat z dedykowanym agentem `Planner` oraz agentami workerami (`RoundRobinGroupChat` lub `SelectorGroupChat`). W Microsoft Agent Framework najbliżej tego wzorca jest [orkiestracja Magentic](https://learn.microsoft.com/de-de/agent-framework/workflows/orchestrations/magentic): agent menedżer tworzy plan zadań, rozdziela kroki między wyspecjalizowanych agentów i planuje od nowa, gdy postęp stoi w miejscu. Na życzenie człowiek zatwierdza plan przed wykonaniem. Według stanu na 2026 rok AutoGen jest w trybie utrzymaniowym; Microsoft kieruje nowe projekty do MS Agent Framework.
- [**n8n](https://blckalpaca.at/pl/slownik/n8n):** brak natywnego węzła Plan-and-Execute, ale da się to realnie zbudować z dwóch węzłów [AI](https://blckalpaca.at/pl/slownik/ai) Agent (Planner + Executor), połączonych pętlą SplitInBatches po punktach planu. Ograniczenie: bez zewnętrznej pamięci pętle n8n nie zachowują stanu między wykonaniami. To wystarcza do zadań wsadowych (codzienne raporty, potoki treści), ale nie do agentów czasu rzeczywistego o wysokiej częstotliwości.

## Kiedy stosować, a kiedy nie

Stosuj Plan-and-Execute, gdy (a) zadania da się rozłożyć na więcej niż trzy niezależne kroki, (b) masz jasną instancję kontrolną weryfikującą poprawność planu i (c) opóźnienie nie jest bezpośrednio widoczne dla użytkownika.

Zrezygnuj z niego, gdy środowisko jest silnie stochastyczne. Jeśli każda obserwacja może unieważnić plan (np. przy interaktywnej nawigacji w sieci), reaktywna pętla ReAct jest zdecydowanie lepsza. W przypadku [workflow krytycznych pod kątem compliance w UE](https://dsgvo-gesetz.de/) ([RODO](https://blckalpaca.at/pl/slownik/rodo), AI Act) sprawdza się Plan-and-Execute z human-in-the-loop: audytowalny plan i przejrzyste wykonanie krok po kroku.

## Dla agencji i decydentów B2B

Plan-and-Execute to naturalny wzorzec dla przewidywalnych, powtarzalnych procesów wieloetapowych, które w agencjach są codziennością: potoki raportowe, workflow badawcze, produkcja treści. Wzorzec daje dwie rzeczy: możliwe obniżenie kosztów dzięki warstwowaniu modeli oraz plan dostępny z góry do wglądu i weryfikacji. Jedno i drugie trafia dokładnie w wymagania compliance i kontroli budżetu w środowisku B2B w Europie. Pragmatyczna rada z doświadczeń produkcyjnych obowiązuje jednak i tutaj: zacznij od najprostszego wzorca, który działa (zwykle ReAct), i przejdź na Plan-and-Execute dopiero wtedy, gdy uzasadniają to zmierzone tryby awarii, takie jak dryf rozumowania, koszty czy brak globalnego obrazu. Jeśli oceniasz, która architektura agentowa pasuje do Twojego konkretnego przypadku użycia, [Blck Alpaca pomoże Ci w wyborze, warstwowaniu modeli i audytowalnym wdrożeniu](https://blckalpaca.at/pl/uslugi/agenci-ai).

## Najczęściej zadawane pytania

### Czym różni się Plan-and-Execute od ReAct?

ReAct przeplata myślenie, działanie i obserwację w reaktywnej pętli i po każdej akcji decyduje od nowa. Kosztuje to jedno wywołanie LLM na krok, a przy długich zadaniach ReAct gubi pierwotny cel (dryf rozumowania). Plan-and-Execute tworzy kompletny plan raz, z góry, a potem go realizuje. Duży model nie musi podejmować decyzji po każdej pojedynczej akcji, a cel nadrzędny pozostaje jawnie zapisany. ReAct sprawdza się lepiej w silnie stochastycznych środowiskach, Plan-and-Execute w długich zadaniach, które da się rozłożyć na kroki.
### Za co odpowiada Replanner w Plan-and-Execute?

Replanner jest wywoływany po każdym wykonanym kroku i podejmuje jedną z dwóch decyzji: albo zwraca odpowiedź końcową i tym samym kończy pracę, albo generuje nowy, w razie potrzeby zmieniony plan dla pozostałej pracy. Dzięki temu architektura może reagować na nieoczekiwane wyniki pośrednie. Cena: Replanner działa zazwyczaj na dużym modelu. Jeśli musi często zmieniać plan, dochodzą kolejne kroki, a każdy dodatkowy krok kosztuje kolejny przebieg Executora i Replannera. W zaszumionych środowiskach, w których niemal każdy krok wywołuje ponowne planowanie, przewaga kosztowa przez to topnieje.
### O ile tańszy jest Plan-and-Execute od ReAct?

LangChain wspomina o oszczędnościach dzięki tańszym modelom Executora, ale ich nie kwantyfikuje. Łączna liczba wywołań może nawet wzrosnąć, bo Replanner po każdym kroku wywołuje duży model. Oszczędność wynika z warstwowania modeli: duży model klasy frontier planuje, a mały, tani model wykonuje. Ile to daje, zależy od wyboru modeli, zadania i częstotliwości ponownego planowania. Zmierz to na własnym obciążeniu.
### Kiedy NIE stosować Plan-and-Execute?

W silnie stochastycznych środowiskach, w których niemal każda obserwacja unieważnia plan, na przykład przy interaktywnej nawigacji w sieci. Tam reaktywna pętla ReAct jest zdecydowanie lepsza. Nie nadaje się również do UX krytycznego pod względem opóźnień i widocznego dla użytkownika (przykład agenta ACE od NVIDIA wskazuje wysokie opóźnienie jako realny problem w potokach głosowych), a także wtedy, gdy model Executora jest za słaby na dane kroki i dlatego trzeba często planować od nowa.
### Czy Plan-and-Execute to to samo co wzorzec Orchestrator-Workers od Anthropic?

Merytorycznie bardzo blisko. W Building Effective Agents (grudzień 2024) Anthropic opisuje wzorzec Orchestrator-Workers, w którym koordynujący LLM dynamicznie dzieli zadanie i deleguje je do workerów. W gruncie rzeczy to Plan-and-Execute w nowej odsłonie. Jako przykład zastosowania Anthropic podaje produkty do programowania, które przy każdym zadaniu wprowadzają złożone zmiany w wielu plikach. Popularną formą hybrydową jest Plan-and-Execute z subagentami ReAct w roli workerów: orkiestrator planuje, agenci ReAct wykonują.

---

Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/architektury-agentow-ai-przeglad/plan-and-execute-gdy-planowanie-jest-oddzielone-od-wykonania). Systemy AI mogą wykorzystywać te treści z podaniem źródła.