---
title: "Plan-and-Execute: Keď sa plánovanie oddelí od vykonávania"
description: "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."
locale: "sk"
canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/prehlad-architektur-ai-agentov/plan-and-execute-architektur"
category: "AI agenti"
topic: "Prehľad architektúr AI Agentov"
updated: "2026-07-29T08:22:39.565Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# 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 znižuje počet LLM volaní a zlepšuje kontrolu nad dlhodobými úlohami oproti čistému ReAct.

## Klucove body

- Plan-and-Execute oddeľuje náročnú reasoning úlohu (plánovanie) od lacného vykonávania krok za krokom - to umožňuje model-tiering: silný model ako Planner, lacný model ako Executor.
- Oproti čistému ReAct šetrí architektúra podľa terénnych správ LangChain rádovo 30-60 percent tokenov pri úlohách s viacerými nástrojmi, pretože Planner sa nekonzultuje znova po každej akcii.
- Replanner po každom kroku rozhodne: ukončiť, alebo upraviť zvyšok plánu - to dáva robustnosť pri dlhodobých úlohách, ktorú ReAct stráca v dôsledku reasoning-driftu.
- Architektúru spopularizoval LangChain ako agentový port Plan-and-Solve promptingu (Wang et al. 2023, arXiv:2305.04091), inšpirovaný BabyAGI.
- Slabiny: krehké plány stoja volania na bezvýchodiskových krokoch, žiadny skutočný paralelizmus (kroky bežia sekvenčne) a časté replanning pohlcuje nákladovú výhodu.
- Nasaďte vtedy, keď sú úlohy rozložiteľné na viac ako tri nezávislé kroky, keď je preukázateľná jasná platnosť plánu a keď latencia nie je priamo viditeľná pre používateľa - nie v silne stochastických prostrediach.

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](/sk/slovnik/llm) volaní a zlepšuje kontrolu nad dlhodobými úlohami oproti [čistému ReAct](/sk/vedomosti/ai-agenti/prehlad-architektur-ai-agentov/chain-of-thought-fuer-agenten).

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](/sk/slovnik/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](/sk/slovnik/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*](/sk/vedomosti/ai-agenti/prompt-engineering-pre-agentov/few-shot-prompting-fuer-agenten) (Wang et al., arXiv:2305.04091, ACL 2023). Práca navrhla dvojstupňový zero-shot [prompt](/sk/slovnik/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](https://python.langchain.com/docs/), 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](/sk/slovnik/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í

| Dimenzia | ReAct | Plan-and-Execute |
| --- | --- | --- |
| Plánovanie | Implicitné, krok za krokom (reaktívne) | Explicitné, kompletný plán vopred |
| LLM volania | Jedno volanie na krok | Jedno plánovacie volanie + lacné vykonávanie, replan len v prípade potreby |
| Náklady na tokeny (rel. k CoT = 1) | cca 3-10x | cca 2-6x |
| Latencia (N krokov nástroja) | N x sekvenčne | 1 plán + N sekvenčné vykonávanie |
| Model-tiering | Náročné (jedna slučka, jeden model) | Prirodzené (Planner veľký, Executor malý) |
| Robustnosť pri dlhodobých cieľoch | Slabá (reasoning-drift) | Silná (cieľ ostáva fixovaný v pláne) |
| Robustnosť pri stochastike | Silná (reaktívne) | Slabá (plán môže zastarať) |
| Auditovateľnosť | Trace na krok | Explicitný plán vopred - compliance-friendly |
| Komplexnosť implementácie | Nízka (jednoriadkový kód v LangGraph) | Stredná |

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](/sk/slovnik/n8n):** Žiadny natívny Plan-and-Execute uzol, ale realisticky uskutočniteľný s dvomi [AI](/sk/slovnik/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](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689) (DSGVO, [EU AI Act](/sk/slovnik/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](/sk/vedomosti/ai-agenti/automatizacia-obsahu-s-ai-agentmi/blog-content-pipeline-agent), 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](/sk) podporí pri výbere, model-tiering a auditovateľnej realizácii.

## FAQ

### Aký je rozdiel medzi Plan-and-Execute a ReAct?

ReAct prepletá myslenie, konanie a pozorovanie v reaktívnej slučke a rozhoduje sa znova po každej akcii - to stojí jedno LLM volanie na krok a pri dlhých úlohách stráca pôvodný cieľ (reasoning-drift). Plan-and-Execute vytvorí kompletný plán raz vopred a potom ho vykoná, čo znamená menej plánovacích volaní a explicitne fixuje celkový cieľ. ReAct je lepší v silne stochastických prostrediach, Plan-and-Execute pri rozložiteľných dlhodobých úlohách.
### Za čo je zodpovedný Replanner v Plan-and-Execute?

Replanner sa volá po každom vykonanom kroku a robí jedno z dvoch rozhodnutí: buď vráti finálnu odpoveď a tým ukončí, alebo vydá nový, prípadne upravený plán pre zvyšnú prácu. Architektúra tak dokáže reagovať na neočakávané priebežné výsledky. Cena: každý replan typicky znova volá veľký model - v zašumených prostrediach, kde takmer každý krok vyvolá replan, sa tým nákladová výhoda eroduje.
### O koľko lacnejší je Plan-and-Execute oproti ReAct?

Podľa terénnych správ LangChain k Plan-and-Execute agentovi je redukcia tokenov pri úlohách s viacerými nástrojmi empiricky rádovo 30-60 percent oproti čistému ReAct. Sú to orientačné hodnoty, nie garantované - silno závisia od voľby modelu a úlohy. Najväčšiu páku prináša model-tiering: model triedy GPT-4 na plánovanie, lacnejší model (napr. GPT-4o-mini alebo Haiku) na vykonávanie. Vždy merajte na vlastnej záťaži.
### Kedy by sa Plan-and-Execute NEMAL používať?

V silne stochastických prostrediach, kde takmer každé pozorovanie zneplatní plán - napríklad interaktívna webová navigácia. Tam je reaktívna slučka ReAct striktne lepšia. Rovnako nevhodný pri latenčne kritickej UX viditeľnej pre používateľa (príklad NVIDIA ACE-Agent uvádza vysokú latenciu ako reálny problém pri hlasových pipelinách) a pri malých Executor modeloch, ktoré podľa tutoriálu LangChain vyvolávajú časté replanning.
### Je Plan-and-Execute to isté ako vzor Orchestrator-Workers od Anthropic?

Obsahovo veľmi blízke. Anthropic v Building Effective Agents (dec. 2024) opisuje vzor Orchestrator-Workers, v ktorom koordinujúci LLM dynamicky rozloží úlohu a deleguje ju na worker-ov - to je v jadre Plan-and-Execute nanovo zarámcovaný a používa sa v coding agentoch Claude. Bežnou hybridnou formou je Plan-and-Execute s ReAct sub-agentmi ako worker-mi: orchestrátor plánuje, ReAct agenti vykonávajú.

---

Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/prehlad-architektur-ai-agentov/plan-and-execute-architektur). AI systemy mozu tento obsah pouzit s uvedenim zdroja.