Plan-and-Execute je agentová architektúra, v ktorej Planner najprv vytvorí kompletný viackrokový plán a Executor ho krok za krokom vykonáva. Replanner plán podľa potreby upravuje. Oddelenie plánovania a vykonávania znižuje počet LLM volaní a zlepšuje kontrolu nad dlhodobými úlohami oproti čistému ReAct.

Rýchle odpovede vopred:

• Čo to rieši: ReAct reasoning krok za krokom postráda globálny prehľad - pri dlhých úlohách agent zabudne pôvodný cieľ. Plan-and-Execute vynucuje cieľ prostredníctvom explicitného plánu vopred.
• Prečo je to lacnejšie: Planner sa nekonzultuje znova po každej akcii. To umožňuje model-tiering (veľký model plánuje, lacný vykonáva) a šetrí pri úlohách s viacerými nástrojmi podľa terénnych správ LangChain rádovo 30-60 percent tokenov.
• Centrálny trade-off: Lepšia kontrola a auditovateľné plány stoja proti krehkosti plánu a chýbajúcemu skutočnému paralelizmu - v silne stochastických prostrediach je ReAct striktne lepší.

Pôvod: Plan-and-Solve, BabyAGI a LangChain port

Presné zaradenie je tu dôležité, pretože atribúcia sa často skracuje. Základný prompting vzor pochádza z Plan-and-Solve Prompting (Wang et al., arXiv:2305.04091, ACL 2023). Práca navrhla dvojstupňový zero-shot prompt - významovo "Najprv navrhnime plán / Vykonajme plán" - a tým prekonala zero-shot CoT pri matematickom reasoningu.

Názov agenta "Plan-and-Execute" však pochádza z LangChain portu, nie z pôvodnej práce. Architektúra bola navyše inšpirovaná BabyAGI (Yohei Nakajima, 2023). Korektne formulované to teda je: Plan-and-Execute agentová architektúra spopularizovaná LangChain, založená na Plan-and-Solve promptingu.

Tri komponenty

Variant LangGraph pozostáva z troch uzlov:

1. Planner - jednorazovo generuje očíslovaný, viackrokový plán (Plan: List[str]).
2. Executor - typicky ReAct sub-agent, ktorý vykonáva jeden krok plánu po druhom.
3. Replanner - po každom vykonaní rozhodne: buď vrátiť finálnu Response (ukončiť), alebo vydať nový, prípadne upravený plán pre zvyšnú prácu.

Priebeh:

Input → Planner → [Plan: Krok_1, Krok_2, …] → Executor(Krok_1) → Replanner → (Executor(Krok_2) → Replanner → …) → Response

Centrálna inovácia: Plan-and-Execute oddeľuje plánovanie (náročnú reasoning úlohu, pre ktorú sa oplatí veľký model) od vykonávania (používanie nástrojov na úrovni krokov, pre ktoré stačí menší, lacnejší model).

Výhody oproti čistému ReAct

• Menej plánovacích volaní, rýchlejšie viackrokové vykonávanie: Planner sa nedopytuje po každej akcii.
• Úspora nákladov vďaka model-tiering: Planner v triede GPT-4, Executor v lacnejšom modeli. Empiricky uvádza blog LangChain redukciu tokenov rádovo 30-60 percent oproti čistému ReAct pri úlohách s viacerými nástrojmi.
• Explicitné, auditovateľné plány: Silný argument pre enterprise a compliance aplikácie - plán je otvorene k dispozícii pred vykonaním.
• Globálny prehľad: Celkový cieľ ostáva zachovaný počas dlhých trajektórií, namiesto toho, aby sa stratil v dôsledku "reasoning-driftu" ReActu.

Slabiny a chybové režimy

Plan-and-Execute nie je všeliek. Podstatné hranice:

• Krehkosť plánu: Ak je predbežný plán chybný, Executor plytvá volaniami na bezvýchodiskových krokoch, kým si to Replanner nevšimne. Práca Plan-and-Solve sama dokumentuje výpočtové chyby, chýbajúce kroky a sémantické nedorozumenia.
• Žiadny skutočný paralelizmus: Plány sú zoznamy; Executor ich spracúva sekvenčne. Práve to adresuje LLMCompiler (Kim et al., arXiv:2312.04511) tým, že emituje DAG namiesto zoznamu.
• Náklady na replan: Každý replan znova volá veľký model. V zašumených prostrediach sa Replanner aktivuje takmer pri každom kroku a eroduje nákladovú výhodu.
• Voľba modelu je rozhodujúca: Menšie Executor modely (napr. gpt-4o-mini) vyvolávajú podľa tutoriálu LangChain "časté replanning".

ReAct vs. Plan-and-Execute v priamom porovnaní

Hodnoty tokenov treba chápať ako rádové, syntetizované zo správ z prác a terénu - nie sú to priame merania. Merajte na vlastnej záťaži.

Pseudokód: Plan-and-Execute slučka

Zjednodušene, orientované na logiku LangGraph state-schémy:

```

State: input, plan (zoznam), past_steps (hotové), response

def planner(state):
# veľký model vytvorí RAZ kompletný plán
state.plan = big_model.plan(state.input) # napr. ["1. ...", "2. ...", "3. ..."]
return state

def executor(state):
krok = state.plan[0] # ďalší otvorený krok
vysledok = small_model.run_react(krok) # lacný ReAct sub-agent + nástroje
state.past_steps.append((krok, vysledok))
return state

def replanner(state):
# buď hotovo -> Response, alebo vydať nový zvyšný plán
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)

```

Rozhodujúci bod: big_model (drahý) beží len v planner a replanner, small_model (lacný) nesie vlastnú záťaž vykonávania.

Konkrétny príklad: denný marketingový report

Agentúra stavia agenta, ktorý každé ráno vytvorí konkurenčný report. Úloha: "Preskúmaj tri najdôležitejších konkurentov, zozbieraj ich nový obsah za posledných 24 hodín, zhrň a pošli e-mailom."

Pri čistom ReAct by agent po každej jednotlivej akcii (vyhľadávanie, scrape, zhrnutie) znova volal plný model, vrátane celého doterajšieho kontextového okna - pri 12 krokoch teda 12 drahých volaní plus rastúci prefix.

Pri Plan-and-Execute vytvorí Planner plán raz (1 drahé volanie):

```
Plan:

1. Identifikovať konkurentov A, B, C
2. Pre každého: scrapnúť nový blog/social obsah za posledných 24h
3. Krátko zhrnúť za každého konkurenta
4. Naformátovať celkový report
5. Poslať e-mailom tímu
   ```

Kroky 2-5 potom bežia cez lacný Executor. Replanner zasiahne len vtedy, ak je napr. zdroj nedostupný. Pri tomto druhu rozložiteľnej batch úlohy je úspora tokenov v uvedenom rozsahu okolo 30-60 percent - a plán je pre agentúru zdokumentovaný a sledovateľný.

Použitie vo frameworkoch (stav 2026)

• LangGraph: Natívne s oficiálnym tutoriálom. Kanonická state-schéma s input, plan: List[str], past_steps a response; uzly planner, agent (Executor) a replan. Podmienená hrana should_end vedie späť k Executoru alebo na END.
• CrewAI: Priamy fit cez Crew(planning=True). To aktivuje AgentPlanner, ktorý pred každou iteráciou crew vytvorí plán krok za krokom a vloží ho do každého popisu úlohy. S Process.hierarchical plus manager_agent/manager_llm pribudne manažujúca replanning vrstva.
• AutoGen / Microsoft Agent Framework: Mapovanie cez Group Chat s dedikovaným Planner agentom plus worker agentmi (RoundRobinGroupChat alebo SelectorGroupChat). V MS Agent Framework je SPAR cyklus (Sense → Plan → Act → Reflect) produktizovaným variantom. AutoGen je k stavu 2026 v režime údržby; Microsoft odkazuje nové projekty na MS Agent Framework.
• n8n: Žiadny natívny Plan-and-Execute uzol, ale realisticky uskutočniteľný s dvomi AI-Agent uzlami (Planner + Executor), prepojenými cez SplitInBatches slučku nad bodmi plánu. Obmedzenie: slučky n8n nie sú bez externého úložiska stavové naprieč behmi - vhodné pre batch joby (denné reporty, content pipeliny), nie pre vysokofrekvenčné real-time agenty.

Kedy nasadiť - a kedy nie

Nasaďte Plan-and-Execute vtedy, keď (a) sú úlohy rozložiteľné na viac ako tri nezávislé kroky, (b) máte jasnú kontrolnú inštanciu pre platnosť plánu a (c) latencia nie je priamo viditeľná pre používateľa.

Vynechajte ho vtedy, keď je prostredie silne stochastické - keď každé pozorovanie môže zneplatniť plán (napríklad interaktívna webová navigácia), reaktívna slučka ReAct je striktne lepšia. Pre compliance-kritické DACH workflow (DSGVO, EU AI Act) sa ponúka Plan-and-Execute s Human-in-the-Loop: auditovateľný plán, deterministické vykonávanie.

Pre agentúry a B2B rozhodovateľov

Plan-and-Execute je prirodzený vzor pre plánovateľné, opakujúce sa viackrokové procesy, aké sú v agentúrach každodenné: reportovacie pipeliny, rešeršné workflow, produkcia obsahu. Dvojitý zisk - merateľné zníženie nákladov vďaka model-tiering a vopred otvorene dostupný, overiteľný plán - presne trafí požiadavky compliance a kontroly rozpočtu v prostredí DACH B2B. Pragmatická rada z produkčnej skúsenosti však platí aj tu: začnite s najjednoduchším vzorom, ktorý funguje (väčšinou ReAct), a eskalujte na Plan-and-Execute až vtedy, keď to ospravedlnia namerané chybové režimy - reasoning-drift, náklady, chýbajúci prehľad. Ak vyhodnocujete, ktorá agentová architektúra sa hodí k vášmu konkrétnemu use-case, Blck Alpaca podporí pri výbere, model-tiering a auditovateľnej realizácii.