Plan-and-Execute: Wenn Planung von Ausführung getrennt wird

Plan-and-Execute ist eine Agent-Architektur, bei der ein Planner zuerst einen vollständigen mehrstufigen Plan erstellt und ein Executor diesen Schritt für Schritt abarbeitet. Ein Replanner passt den Plan bei Bedarf an. Die Trennung von Planung und Ausführung erlaubt es, die einzelnen Schritte mit einem kleineren Modell auszuführen, und verbessert die Kontrolle über Langzeit-Aufgaben gegenüber reinem ReAct.

Die schnellen Antworten vorab:

• Was es löst: ReActs Schritt-für-Schritt-Reasoning fehlt der globale Überblick: Auf langen Aufgaben vergisst der Agent das ursprüngliche Ziel. Plan-and-Execute erzwingt das Ziel durch einen expliziten Plan im Voraus.
• Warum es günstiger sein kann: Ein kleineres, günstigeres Modell führt die einzelnen Schritte aus. Das große Modell plant nur und prüft nach jedem Schritt, ob der Plan noch trägt (Modell-Tiering).
• Der zentrale Trade-off: Bessere Kontrolle und auditierbare Pläne stehen gegen Plan-Brüchigkeit und fehlende echte Parallelität. In stark stochastischen Umgebungen ist ReAct strikt überlegen.

Herkunft: Plan-and-Solve, BabyAGI und der LangChain-Port

Eine präzise Einordnung ist hier wichtig, weil die Attribution oft verkürzt wird. Das zugrunde liegende Prompting-Muster stammt aus Plan-and-Solve Prompting (Wang et al., arXiv:2305.04091, ACL 2023). Das Paper schlug den zweistufigen Zero-Shot-Prompt vor, sinngemäß "Lass uns zuerst einen Plan entwerfen / Lass uns den Plan ausführen", und übertraf damit Zero-Shot-CoT bei mathematischem Reasoning.

Der Agent-Name "Plan-and-Execute" stammt jedoch vom LangChain-Port, nicht aus dem Originalpaper. Die Architektur wurde zusätzlich durch BabyAGI (Yohei Nakajima, 2023) inspiriert. Korrekt formuliert ist es also: die von LangChain popularisierte Plan-and-Execute-Agent-Architektur, basierend auf Plan-and-Solve-Prompting.

Ein eng verwandtes Muster beschreibt Anthropic in Building Effective Agents (Dezember 2024): Im Orchestrator-Workers-Workflow zerlegt ein zentrales LLM eine Aufgabe dynamisch, delegiert die Teile an Worker-LLMs und führt deren Ergebnisse zusammen.

Die drei Komponenten

Die LangGraph-Variante besteht aus drei Knoten:

1. Planner: generiert einmalig einen nummerierten, mehrstufigen Plan (Plan: List[str]).
2. Executor: typischerweise ein ReAct-Sub-Agent, der einen Planschritt nach dem anderen abarbeitet.
3. Replanner: entscheidet nach jeder Ausführung, ob er eine finale Response zurückgibt (terminiert) oder einen neuen, ggf. bearbeiteten Plan für die Restarbeit ausgibt.

Der Ablauf:

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

Die zentrale Innovation: Plan-and-Execute entkoppelt die Planung (eine schwere Reasoning-Aufgabe, für die sich ein großes Modell lohnt) von der Ausführung (per-Schritt-Tool-Nutzung, für die ein kleineres, günstigeres Modell genügt).

Vorteile gegenüber reinem ReAct

• Schnellere Mehrschritt-Ausführung: Der Executor erledigt einen Planschritt samt seiner Tool-Aufrufe allein. Das große Modell kommt erst danach wieder zum Zug, nicht nach jeder einzelnen Aktion.
• Kostenersparnis durch Modell-Tiering: Ein großes Frontier-Modell plant, ein kleines, günstiges Modell führt die Schritte aus. LangChain beschreibt diesen Kostenvorteil gegenüber ReAct nur qualitativ. Die Gesamtzahl der Calls sinkt dabei nicht zwingend: 2023 nannte LangChain mehr LLM-Calls ausdrücklich als Preis des Musters und bezeichnete viele der Vorteile als nicht gebenchmarkt.
• Explizite, auditierbare Pläne: Ein starkes Argument für Enterprise- und Compliance-Anwendungen, denn der Plan liegt vor der Ausführung offen.
• Globaler Überblick: Das Gesamtziel bleibt über lange Trajektorien erhalten, statt durch ReActs "Reasoning-Drift" verloren zu gehen.

Schwächen und Fehlermodi

Plan-and-Execute ist kein Allheilmittel. Die wesentlichen Grenzen:

• Plan-Brüchigkeit: Ist der Vorab-Plan falsch, verschwendet der Executor Calls auf aussichtslose Schritte, bis der Replanner es bemerkt. Das Plan-and-Solve-Paper dokumentiert selbst Rechenfehler, fehlende Schritte und semantische Missverständnisse.
• Keine echte Parallelität: Pläne sind Listen; der Executor arbeitet sie sequenziell ab. Genau das adressiert LLMCompiler (Kim et al., arXiv:2312.04511), indem es einen DAG statt einer Liste emittiert.
• Replan-Kosten: Muss der Replanner oft umplanen, kommen Schritte hinzu, und jeder zusätzliche Schritt kostet einen weiteren Durchlauf von Executor und Replanner. In verrauschten Umgebungen passiert das nahezu bei jedem Schritt und erodiert den Kostenvorteil.
• Modellwahl ist entscheidend: Ist das Executor-Modell für die Schritte zu schwach, scheitern mehr Schritte, der Replanner muss öfter umplanen, und der Kostenvorteil schrumpft.

ReAct vs. Plan-and-Execute im direkten Vergleich

Die Token-Zeile beschreibt Tendenzen, keine Messwerte. Miss auf deiner eigenen Last nach.

Pseudocode: der Plan-and-Execute-Loop

Vereinfacht, an der LangGraph-State-Schema-Logik orientiert:

```

State: input, plan (Liste), past_steps (erledigt), response

def planner(state):
# ein großes Modell erstellt EINMAL den kompletten Plan
state.plan = big_model.plan(state.input) # z. B. ["1. ...", "2. ...", "3. ..."]
return state

def executor(state):
schritt = state.plan[0] # nächster offener Schritt
ergebnis = small_model.run_react(schritt) # günstiger ReAct-Sub-Agent + Tools
state.past_steps.append((schritt, ergebnis))
return state

def replanner(state):
# entweder fertig -> Response, oder neuen Restplan ausgeben
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"

Graph: planner -> executor -> replanner -> (executor | END)

```

Der entscheidende Punkt: big_model (teuer) läuft nur in planner und replanner, small_model (günstig) trägt die eigentliche Ausführungslast.

Konkretes Beispiel: täglicher Marketing-Report

Eine Agentur baut einen Agenten, der jeden Morgen einen Wettbewerbs-Report erstellt. Aufgabe: "Recherchiere die drei wichtigsten Konkurrenten, sammle deren neue Inhalte der letzten 24 Stunden, fasse zusammen und sende per E-Mail."

Mit reinem ReAct würde der Agent nach jeder einzelnen Aktion (Suche, Scrape, Zusammenfassung) das volle Modell erneut aufrufen, inklusive des kompletten bisherigen Kontextfensters. Bei 12 Schritten sind das 12 teure Calls plus ein wachsender Prefix.

Mit Plan-and-Execute erstellt der Planner einmal den Plan (1 teurer Call):

```
Plan:

1. Konkurrenten A, B, C identifizieren
2. Für jeden: neue Blog-/Social-Inhalte der letzten 24h scrapen
3. Pro Konkurrent kurz zusammenfassen
4. Gesamt-Report formatieren
5. Per E-Mail an das Team senden
   ```

Die Schritte 2-5 laufen dann über einen günstigen Executor. Das große Modell prüft nach jedem Schritt nur, ob der Plan noch trägt, und plant neu, wenn z. B. eine Quelle nicht erreichbar ist. Bleibt das die Ausnahme, spart diese Batch-Aufgabe Kosten, weil die eigentliche Arbeit beim günstigen Modell liegt. Zugleich ist der Plan für die Agentur nachvollziehbar dokumentiert.

Einsatz in Frameworks (Stand 2026)

• LangGraph: Nativ mit offiziellem Tutorial. Kanonisches State-Schema mit input, plan: List[str], past_steps und response; Knoten planner, agent (Executor) und replan. Eine bedingte Kante should_end führt zurück zum Executor oder zu END.
• CrewAI: Direkter Fit über Crew(planning=True). Das aktiviert einen AgentPlanner, der vor jeder Crew-Iteration einen Schritt-für-Schritt-Plan erstellt und in jede Task-Beschreibung injiziert. Mit Process.hierarchical plus manager_agent/manager_llm kommt eine managende Replanning-Ebene hinzu.
• AutoGen / Microsoft Agent Framework: Abbildung über Group Chat mit dediziertem Planner-Agent plus Worker-Agenten (RoundRobinGroupChat oder SelectorGroupChat). Im Microsoft Agent Framework kommt die Magentic-Orchestrierung dem Muster am nächsten: Ein Manager-Agent erstellt einen Aufgabenplan, verteilt Schritte an spezialisierte Agenten und plant neu, wenn der Fortschritt stockt. Auf Wunsch gibt ein Mensch den Plan vor der Ausführung frei. AutoGen befindet sich Stand 2026 im Maintenance-Modus; Microsoft verweist Neuprojekte auf das MS Agent Framework.
• n8n: Kein nativer Plan-and-Execute-Knoten, aber realistisch mit zwei AI-Agent-Knoten (Planner + Executor), verbunden über eine SplitInBatches-Schleife über die Planpunkte. Einschränkung: n8n-Schleifen sind ohne externen Speicher nicht zustandsbehaftet über Ausführungen hinweg. Das reicht für Batch-Jobs (tägliche Reports, Content-Pipelines), nicht für hochfrequente Echtzeit-Agenten.

Wann einsetzen und wann nicht

Setze Plan-and-Execute ein, wenn (a) Aufgaben in mehr als drei unabhängige Schritte zerlegbar sind, (b) du eine klare Prüfinstanz für die Plan-Validität hast und (c) Latenz nicht direkt nutzersichtbar ist.

Verzichte darauf, wenn die Umgebung stark stochastisch ist. Kann jede Beobachtung den Plan ungültig machen (etwa bei interaktiver Web-Navigation), ist ReActs reaktive Schleife strikt besser. Für compliance-kritische Workflows in der EU (DSGVO, EU AI Act) bietet sich Plan-and-Execute mit Human-in-the-Loop an: auditierbarer Plan, nachvollziehbare Ausführung Schritt für Schritt.

Für Agenturen und B2B-Entscheider

Plan-and-Execute ist das natürliche Muster für planbare, wiederkehrende Mehrschritt-Prozesse, wie sie in Agenturen alltäglich sind: Reporting-Pipelines, Recherche-Workflows, Content-Produktion. Das Muster bietet zweierlei: eine mögliche Kostensenkung durch Modell-Tiering und einen vorab offenliegenden, prüfbaren Plan. Beides trifft genau die Anforderungen von Compliance und Budgetkontrolle im DACH-B2B-Umfeld. Der pragmatische Rat aus der Produktionserfahrung gilt aber auch hier: Starte mit dem einfachsten Muster, das funktioniert (meist ReAct), und wechsle erst zu Plan-and-Execute, wenn gemessene Fehlermodi wie Reasoning-Drift, Kosten oder fehlender Überblick es rechtfertigen. Wenn du evaluierst, welche Agent-Architektur zu deinem konkreten Use-Case passt, unterstützt Blck Alpaca bei Auswahl, Modell-Tiering und auditierbarer Umsetzung.