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 senkt die Zahl der LLM-Calls 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 ist: Der Planner wird nicht nach jeder Aktion erneut konsultiert. Das erlaubt Modell-Tiering (großes Modell plant, günstiges führt aus) und spart bei Mehr-Tool-Aufgaben laut LangChain-Feldberichten in der Größenordnung 30-60 Prozent Tokens.
• 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 schlug 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.

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: entweder eine finale Response zurückgeben (terminieren) oder einen neuen, ggf. bearbeiteten Plan für die Restarbeit ausgeben.

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

• Weniger Planungs-Calls, schnellere Mehrschritt-Ausführung: Der Planner wird nicht nach jeder Aktion befragt.
• Kostenersparnis durch Modell-Tiering: Planner in GPT-4-Klasse, Executor in einem günstigeren Modell. Empirisch nennt der LangChain-Blog eine Token-Reduktion in der Größenordnung 30-60 Prozent gegenüber reinem ReAct bei Mehr-Tool-Aufgaben.
• Explizite, auditierbare Pläne: Ein starkes Argument für Enterprise- und Compliance-Anwendungen - 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: Jeder Replan ruft das große Modell erneut auf. In verrauschten Umgebungen wird der Replanner nahezu bei jedem Schritt aktiv und erodiert den Kostenvorteil.
• Modellwahl ist entscheidend: Kleinere Executor-Modelle (z. B. gpt-4o-mini) lösen laut LangChain-Tutorial "häufiges Replanning" aus.

ReAct vs. Plan-and-Execute im direkten Vergleich

Die Token-Werte sind als Größenordnung zu verstehen, synthetisiert aus Paper- und Feldberichten - keine direkten Messungen. Messen Sie auf Ihrer 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 also 12 teure Calls plus wachsendem 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. Der Replanner greift nur ein, wenn z. B. eine Quelle nicht erreichbar ist. Bei dieser Art zerlegbarer Batch-Aufgabe liegt die Token-Ersparnis im genannten Bereich von rund 30-60 Prozent - und der Plan ist 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 MS Agent Framework ist der SPAR-Zyklus (Sense → Plan → Act → Reflect) die produktisierte Variante. 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 - geeignet für Batch-Jobs (tägliche Reports, Content-Pipelines), nicht für hochfrequente Echtzeit-Agenten.

Wann einsetzen - und wann nicht

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

Verzichten Sie darauf, wenn die Umgebung stark stochastisch ist - wenn jede Beobachtung den Plan ungültig machen kann (etwa interaktive Web-Navigation), ist ReActs reaktive Schleife strikt besser. Für compliance-kritische DACH-Workflows (DSGVO, EU AI Act) bietet sich Plan-and-Execute mit Human-in-the-Loop an: auditierbarer Plan, deterministische Ausführung.

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. Der doppelte Gewinn - messbare Kostensenkung durch Modell-Tiering und ein vorab offenliegender, prüfbarer Plan - trifft genau die Anforderungen von Compliance und Budgetkontrolle im DACH-B2B-Umfeld. Der pragmatische Rat aus der Produktionserfahrung gilt aber auch hier: Starten Sie mit dem einfachsten Muster, das funktioniert (meist ReAct), und eskalieren Sie zu Plan-and-Execute erst, wenn gemessene Fehlermodi - Reasoning-Drift, Kosten, fehlender Überblick - es rechtfertigen. Wenn Sie evaluieren, welche Agent-Architektur zu Ihrem konkreten Use-Case passt, unterstützt Blck Alpaca bei Auswahl, Modell-Tiering und auditierbarer Umsetzung.