Plan-and-Execute Pattern
Wissen
ReAct ist mächtig, aber teuer: Jeder Denkschritt verbraucht Tokens auf einem leistungsstarken (und teuren) Modell. Das Plan-and-Execute Pattern löst dieses Problem elegant: Ein teures Modell plant, ein günstiges führt aus.
Die Architektur
- Planner (z.B. Claude Opus, GPT-5.6) -- Erstellt einmalig einen detaillierten Ausführungsplan
- Executor (z.B. Claude Haiku 4.5, GPT-5 mini) -- Führt die einzelnen Schritte des Plans aus
- Evaluator (optional, wieder das teure Modell) -- Prüft am Ende das Gesamtergebnis
Warum 90% Kostenersparnis möglich sind
Rechnen wir ein konkretes Beispiel durch:
| Aspekt | Reines ReAct (Opus) | Plan-and-Execute |
|---|---|---|
| Planungsphase | 5 Denkschritte x Opus | 1 Planungsschritt x Opus |
| Ausführung | 10 Tool-Calls x Opus | 10 Tool-Calls x Haiku |
| Evaluation | -- | 1 Prüfschritt x Opus |
| Opus-Tokens | ~15.000 | ~3.000 |
| Haiku-Tokens | 0 | ~8.000 |
| Kosten (geschätzt) | ~$0.075 | ~$0.023 |
Der Trick: Die Ausführung einzelner Schritte braucht kein geniales Reasoning. "Ruf diese API mit diesen Parametern auf" kann ein kleines, günstiges Modell genauso gut. Das teure Modell wird nur für die strategische Planung und die finale Qualitätskontrolle eingesetzt.
iPreisvergleich (Stand 2026)
Claude Opus: ~$5/1M Input-Tokens. Claude Haiku: ~$1/1M Input-Tokens. Das ist ein Faktor 5. Selbst wenn der Planner etwas mehr Tokens braucht, ist die Ersparnis enorm -- vor allem bei den Output-Token-Kosten ($25 vs. $5/1M).
Verstehen
So funktioniert der Plan
Phase 1: Planung (teures Modell)
Der Planner bekommt die Aufgabe und die Liste verfügbarer Tools. Er erstellt einen strukturierten Plan:
{
"plan": [
{
"step": 1,
"action": "search_knowledge_base",
"params": { "query": "Rückgaberichtlinie Premium-Kunden" },
"reason": "Erst die aktuelle Policy laden"
},
{
"step": 2,
"action": "get_customer_info",
"params": { "email": "kunde@beispiel.de" },
"reason": "Kundenstatus prüfen (Premium oder Standard)"
},
{
"step": 3,
"action": "check_order_status",
"params": { "order_id": "ORD-2025-4832" },
"depends_on": [1, 2],
"reason": "Bestellung prüfen mit Kontext aus Schritt 1 und 2"
},
{
"step": 4,
"action": "compose_response",
"params": { "template": "return_approval" },
"depends_on": [3],
"reason": "Antwort formulieren basierend auf allen gesammelten Infos"
}
]
}
Phase 2: Ausführung (günstiges Modell)
Der Executor arbeitet den Plan Schritt für Schritt ab. Er braucht kein eigenes Reasoning -- er folgt einfach den Anweisungen und führt die Tool-Calls aus.
Phase 3: Evaluation (teures Modell, optional)
Am Ende prüft der Evaluator: Wurde die Aufgabe korrekt gelöst? Sind die Ergebnisse konsistent? Falls nicht, kann er den Plan anpassen und eine neue Runde starten.
Wann Plan-and-Execute vs. ReAct?
| Kriterium | ReAct | Plan-and-Execute |
|---|---|---|
| Aufgabenkomplexität | Mittel | Hoch |
| Vorhersagbarkeit der Schritte | Niedrig (Schritte hängen von Ergebnissen ab) | Hoch (Schritte sind im Voraus planbar) |
| Kosten | Höher (alles auf teurem Modell) | Niedriger (Ausführung auf günstigem Modell) |
| Flexibilität | Hoch (kann jederzeit den Kurs ändern) | Mittel (Plan muss bei Überraschungen angepasst werden) |
| Latenz | Mittel | Niedriger (Schritte können parallelisiert werden) |
Nutze ReAct, wenn die nächsten Schritte stark von den Ergebnissen abhängen und du Flexibilität brauchst.
Nutze Plan-and-Execute, wenn die Aufgabenstruktur vorhersagbar ist und du Kosten optimieren willst.
*Hybrid-Ansatz
In der Praxis kombinieren viele Systeme beide Patterns: Plan-and-Execute für die Gesamtstruktur, aber innerhalb einzelner Schritte kann der Executor eine Mini-ReAct-Schleife nutzen, wenn unerwartete Ergebnisse auftreten.
Anwenden
Ein Agent soll jeden Morgen 200 Nachrichtenartikel zusammenfassen und kategorisieren. Das Format ist immer gleich. Welches Pattern ist hier am sinnvollsten?
Reflektieren
Plan-and-Execute trennt Denken vom Handeln -- ein Planner-Modell erstellt den Plan, ein günstiges Executor-Modell arbeitet ihn ab. Bei vorhersagbaren, wiederkehrenden Aufgaben spart dieses Pattern bis zu 90% der Kosten gegenüber ReAct. Die Kunst liegt darin, zu erkennen, wann die Schritte vorhersagbar genug sind.