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.

Najpierw szybkie odpowiedzi:

• Co rozwiązuje: rozumowaniu krok po kroku w ReAct brakuje globalnego obrazu: przy długich zadaniach 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 (Wang et al., arXiv:2305.04091, ACL 2023). Praca zaproponowała dwuetapowy 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, a nie z oryginalnej pracy. Architekturę zainspirowało dodatkowo BabyAGI (Yohei Nakajima, 2023). Poprawne sformułowanie brzmi więc: spopularyzowana przez LangChain architektura agentowa Plan-and-Execute, oparta na promptingu Plan-and-Solve.

Blisko spokrewniony wzorzec Anthropic opisuje w Building Effective Agents (grudzień 2024): w workflow Orchestrator-Workers centralny 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 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 tylko jakościowo. Łączna liczba wywołań wcale nie musi przy tym spaść: w 2023 roku LangChain wprost wskazał więcej wywołań LLM 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

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 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: 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: brak natywnego węzła Plan-and-Execute, ale da się to realnie zbudować z dwóch węzłów 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 (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.