Plan-and-Execute: Keď sa plánovanie oddelí od vykonávania

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 umožňuje vykonávať jednotlivé kroky menším modelom a zlepšuje kontrolu nad dlhodobými úlohami oproti čistému ReActu.

Rýchle odpovede vopred:

• Čo to rieši: Uvažovaniu ReActu krok za krokom chýba globálny prehľad: pri dlhých úlohách agent zabudne pôvodný cieľ. Plan-and-Execute ukotví cieľ v explicitnom pláne vopred.
• Prečo to môže byť lacnejšie: Jednotlivé kroky vykonáva menší, lacnejší model. Veľký model len plánuje a po každom kroku kontroluje, či plán ešte platí (model-tiering).
• Hlavný kompromis: Za lepšiu kontrolu a auditovateľné plány platíš krehkosťou plánu a chýbajúcim skutočným paralelizmom. V silne stochastických prostrediach je ReAct jednoznačne lepší.

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

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 uvažovaní.

Názov agenta "Plan-and-Execute" však pochádza z portu do LangChain, nie z pôvodnej práce. Architektúru navyše inšpirovalo BabyAGI (Yohei Nakajima, 2023). Správne formulované je to teda takto: agentová architektúra Plan-and-Execute, ktorú spopularizoval LangChain a ktorá stavia na Plan-and-Solve promptingu.

Úzko príbuzný vzor opisuje Anthropic v Building Effective Agents (december 2024): vo workflow orchestrator-workers centrálny LLM dynamicky rozloží úlohu, deleguje jej časti na worker LLM a spojí ich výsledky.

Tri komponenty

Variant v LangGraph pozostáva z troch uzlov:

1. Planner: jednorazovo vygeneruje očíslovaný viackrokový plán (Plan: List[str]).
2. Executor: typicky ReAct subagent, ktorý vykonáva jeden krok plánu za druhým.
3. Replanner: po každom vykonaní rozhodne, či vráti finálnu Response (ukončí beh), alebo vydá nový, prípadne upravený plán pre zvyšnú prácu.

Priebeh:

Input → Planner → [Plán: Krok_1, Krok_2, …] → Executor(Krok_1) → Replanner → (Executor(Krok_2) → Replanner → …) → Response

Hlavná inovácia: Plan-and-Execute oddeľuje plánovanie (náročnú úlohu uvažovania, pre ktorú sa oplatí veľký model) od vykonávania (používanie nástrojov v jednotlivých krokoch, na ktoré stačí menší, lacnejší model).

Výhody oproti čistému ReActu

• Rýchlejšie viackrokové vykonávanie: Executor vybaví krok plánu vrátane jeho volaní nástrojov sám. Veľký model prichádza na rad až potom, nie po každej jednotlivej akcii.
• Úspora nákladov vďaka model-tieringu: Veľký frontier model plánuje, malý a lacný model vykonáva kroky. LangChain opisuje túto nákladovú výhodu oproti ReActu len kvalitatívne. Celkový počet volaní pritom nemusí klesnúť: v roku 2023 LangChain výslovne uviedol viac LLM volaní ako cenu tohto vzoru a o mnohých výhodách napísal, že neboli overené benchmarkom.
• Explicitné, auditovateľné plány: Silný argument pre podnikové aplikácie a aplikácie s požiadavkami na compliance, pretože plán je otvorene k dispozícii ešte pred vykonaním.
• Globálny prehľad: Celkový cieľ ostáva zachovaný počas dlhých trajektórií a nestratí sa v dôsledku "reasoning-driftu" ReActu.

Slabiny a typické zlyhania

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

• Krehkosť plánu: Ak je vopred vytvorený plán chybný, Executor plytvá volaniami na kroky, ktoré nevedú k cieľu, kým si to Replanner nevšimne. Samotná práca Plan-and-Solve 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 rieši LLMCompiler (Kim et al., arXiv:2312.04511), ktorý namiesto zoznamu emituje DAG.
• Náklady na preplánovanie: Ak musí Replanner často preplánovať, pribúdajú kroky a každý ďalší krok stojí ďalšie kolo Executora a Replannera. V zašumených prostrediach sa to deje takmer pri každom kroku a nákladová výhoda sa tým stráca.
• Voľba modelu je rozhodujúca: Ak je model Executora na kroky príliš slabý, zlyhá viac krokov, Replanner musí častejšie preplánovať a nákladová výhoda sa zmenšuje.

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

Riadok o tokenoch opisuje tendencie, nie namerané hodnoty. Zmeraj si to na vlastnej záťaži.

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

Zjednodušene, podľa logiky state-schémy v LangGraph:

```

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 subagent + 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 samotnú záťaž vykonávania.

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

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

S čistým ReActom 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 je to 12 drahých volaní plus rastúci prefix.

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

```
Plán:

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

Kroky 2-5 potom bežia cez lacný Executor. Veľký model po každom kroku len kontroluje, či plán ešte platí, a preplánuje, ak je napr. nejaký zdroj nedostupný. Ak to zostane výnimkou, táto dávková úloha ušetrí náklady, pretože samotná práca pripadá na lacný model. Zároveň je plán pre agentúru zrozumiteľne zdokumentovaný.

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: Vzor sa dá priamo realizovať 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žérska vrstva pre preplánovanie.
• AutoGen / Microsoft Agent Framework: Realizácia cez Group Chat s vyhradeným agentom Planner plus worker agentmi (RoundRobinGroupChat alebo SelectorGroupChat). V Microsoft Agent Framework má k vzoru najbližšie orchestrácia Magentic: manažérsky agent vytvorí plán úloh, rozdelí kroky špecializovaným agentom a preplánuje, keď sa postup zasekne. Ak chceš, plán pred vykonaním schváli človek. AutoGen je v roku 2026 v režime údržby; Microsoft odkazuje nové projekty na MS Agent Framework.
• n8n: Žiadny natívny uzol Plan-and-Execute, ale realisticky sa dá zostaviť z dvoch uzlov AI Agent (Planner + Executor), prepojených slučkou SplitInBatches nad bodmi plánu. Obmedzenie: slučky v n8n nie sú bez externého úložiska stavové naprieč behmi. To stačí na dávkové úlohy (denné reporty, pipeliny na tvorbu obsahu), nie na vysokofrekvenčných agentov pracujúcich v reálnom čase.

Kedy nasadiť a kedy nie

Nasaď Plan-and-Execute vtedy, keď (a) sa úlohy dajú rozložiť na viac ako tri nezávislé kroky, (b) vieš jasne overiť, či je plán platný, a (c) latencia nie je priamo viditeľná pre používateľa.

Vynechaj ho, keď je prostredie silne stochastické. Ak môže každé pozorovanie zneplatniť plán (napríklad pri interaktívnej webovej navigácii), reaktívna slučka ReActu je jednoznačne lepšia. Pre workflow v EÚ, ktoré sú kritické z hľadiska compliance (GDPR, EU AI Act), sa ponúka Plan-and-Execute s Human-in-the-Loop: auditovateľný plán, sledovateľné vykonávanie krok za krokom.

Pre agentúry a vedenie B2B firiem

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. Vzor ponúka dve veci: možné zníženie nákladov vďaka model-tieringu a plán, ktorý je otvorene k dispozícii a overiteľný už vopred. Oboje presne zodpovedá požiadavkám compliance a kontroly rozpočtu v prostredí DACH B2B. Pragmatická rada z produkčnej praxe však platí aj tu: začni s najjednoduchším vzorom, ktorý funguje (väčšinou ReAct), a na Plan-and-Execute prejdi až vtedy, keď to opodstatnia namerané typy zlyhaní ako reasoning-drift, náklady alebo chýbajúci prehľad. Ak vyhodnocuješ, ktorá agentová architektúra sa hodí na tvoj konkrétny prípad použitia, Blck Alpaca pomôže s výberom, model-tieringom a auditovateľnou realizáciou.