Deep Dive: Agentic AI Patterns – Planner/Executor, ReAct, Toolformer‑Style

KI-Agenten sind mehr als nur große Sprachmodelle mit API-Zugriff. Ihre Leistungsfähigkeit hängt maßgeblich von der zugrunde liegenden Architektur ab, die bestimmt, wie sie Aufgaben analysieren, planen und ausführen. In der Praxis haben sich drei zentrale Muster etabliert: die Trennung von Planung und Ausführung (Planner/Executor), die schrittweise Evaluierung (ReAct) und die integrierte Werkzeugnutzung (Toolformer-Ansatz).

Dieser Deep Dive beleuchtet die Funktionsweise dieser Patterns, ihre idealen Einsatzgebiete und wie sie sich strukturiert in Frameworks wie OpenClaw implementieren lassen.

Pattern 1: Planner/Executor – Trennung von Planung und Ausführung

Beim Planner/Executor-Pattern wird die kognitive Last aufgeteilt. Eine Komponente (der Planner) übernimmt die Aufgabenzergliederung und erstellt einen strategischen Aktionsplan. Eine zweite Komponente (der Executor) führt die einzelnen Schritte stur aus. Der Planner denkt voraus, der Executor handelt.

┌─────────────┐      ┌─────────────┐
│   Planner   │─────▶│   Executor  │
│  (LLM)      │      │  (Tools)    │
└─────────────┘      └─────────────┘
       │                      │
  „Zerlege die Aufgabe   „Führe Schritt 1 aus,
   in Teil-Schritte“      dann Schritt 2, …“

Vor- und Nachteile

Der größte Vorteil liegt in der klaren Trennung der Verantwortlichkeiten. Der Planner kann komplexe Abhängigkeiten berücksichtigen, ohne sich im Vorfeld um technische Tool-Details kümmern zu müssen. Einmal generierte Pläne lassen sich zudem zwischenspeichern, validieren und für ähnliche Aufgaben wiederverwenden, was das Debugging erheblich vereinfacht.

Nachteilig ist die starre Planung: Ändert sich die Umgebung während der Ausführung, wird der Plan oft ungültig. Zudem erzeugt der zweistufige Prozess bei sehr simplen Aufgaben einen unnötigen Overhead.

Praxisbeispiel

In agentischen Frameworks wie OpenClaw wird dieses Muster implizit genutzt, wenn ein Agent eine Checkliste abarbeitet. Der Agent evaluiert zuerst, welche Tools in welcher Reihenfolge benötigt werden, und ruft diese anschließend sequenziell auf.

# Beispiel-Konfiguration für einen Planner/Executor-Agenten
agent:
  name: "research_assistant"
  planner:
    model: "gpt-4o-mini"
    max_steps: 10
  executor:
    tools:
      - web_search
      - pdf_analyze
      - summarize

Pattern 2: ReAct – Reasoning und Acting im Wechsel

ReAct (Reasoning + Acting) ist ein interaktives Muster, das laut Dokumentationen von IBM und Google Cloud zu den Standardarchitekturen moderner KI-Systeme gehört. Der Agent arbeitet in einem kontinuierlichen Loop: Er denkt nach, handelt, beobachtet das Ergebnis und passt den nächsten Schritt an.

┌─────────────────────────────────────┐
│ 1. Denken: Was ist das Ziel?        │
│ 2. Handeln: Tool-Aufruf             │
│ 3. Beobachten: Resultat             │
│ 4. Wiederholen bis Ziel erreicht    │
└─────────────────────────────────────┘

Dieses Pattern ist primär für dynamische, unbekannte Umgebungen konzipiert – beispielsweise wenn ein Agent einen Browser steuert und nicht vorhersagen kann, welche UI-Elemente nach einem Klick erscheinen.

Vor- und Nachteile

ReAct ist extrem anpassungsfähig und robust. Schlägt ein Tool-Aufruf fehl, kann der Agent den Fehler analysieren und eine alternative Route wählen. Der Problemlösungsansatz ähnelt stark dem menschlichen Vorgehen.

Dem gegenüber steht der hohe Ressourcenverbrauch: Jeder Reasoning-Schritt kostet zusätzliche Tokens. Bei komplexen Aufgaben mit vielen Iterationen steigen dadurch Latenz und Kosten spürbar an.

Praxisbeispiel

In OpenClaw wird ReAct standardmäßig eingesetzt, wenn Agenten mit Tools interagieren. Jeder Aufruf wird von einem Reasoning-Schritt begleitet. Dies lässt sich über die Konfiguration explizit steuern:

openclaw agent --message "Finde die neuesten Nachrichten zu KI-Agenten" --thinking high

Der Agent formuliert dann vor jedem Tool-Aufruf einen kurzen „Gedanken“ im Kontextfenster und handelt erst, wenn die Strategie plausibel ist.

Pattern 3: Toolformer-Ansatz – Integrierte Werkzeugnutzung

Der Toolformer-Ansatz basiert auf Forschungen von Meta. Dabei lernt ein Modell, wann und wie es externe Tools (wie Taschenrechner, Suchmaschinen oder Kalender) nutzt, ohne dass ein expliziter Reasoning-Loop wie bei ReAct nötig ist. Die Tool-Nutzung wird direkt in die Token-Generierung integriert.

Das Modell wird auf Texten trainiert oder per Prompting so instruiert, dass Tool-Aufrufe als spezielle Token-Sequenzen eingefügt werden (z. B. [CALC] 2+2 [/CALC]). Es generiert diese Aufrufe fließend im Text und baut die asynchron abgerufenen Ergebnisse nahtlos in die weitere Antwort ein.

Vor- und Nachteile

Die nahtlose Integration sorgt dafür, dass sich Tool-Aufrufe wie ein natürlicher Sprachfluss anfühlen. Da der extra Reasoning-Overhead entfällt, ist dieser Ansatz sehr effizient.

Allerdings erfordert echtes Toolformer-Verhalten oft ein spezialisiertes Fine-Tuning des Modells. Zudem ist die Tool-Syntax starr: Abweichungen von der gelernten Formatierung führen schnell zu Parsing-Fehlern.

Praxisbeispiel

OpenClaw unterstützt Toolformer-ähnliche Abläufe durch präzise Skill-Dateien. Der Agent lernt die Syntax durch Pattern-Matching im System-Prompt.

# Beispiel-Skill-Definition (Auszug)
tools:
  - name: "calculator"
    description: "Berechnet mathematische Ausdrücke. Syntax: `calc(expression)`."
    pattern: "calc\\((.*?)\\)"

Erkennt das System calc(2+2) im generierten Text, wird die Ausführung pausiert, die Berechnung durchgeführt und das Ergebnis (4) direkt in den Kontext eingefügt.

Welches Pattern für welche Aufgabe?

Muster	Geeignet für	Nicht geeignet für
Planner/Executor	Aufgaben mit klaren, vorhersehbaren Schritten (z. B. ETL-Prozesse, Report-Generierung).	Dynamische Umgebungen, in denen sich Bedingungen während der Ausführung ändern.
ReAct	Exploration, Fehlerbehebung, Umgebungen mit Feedback-Loop (z. B. Browser-Automation).	Hochfrequente, repetitive Tasks (zu hoher Token-Overhead).
Toolformer-Ansatz	Domänen mit festen Tool-Sets und vorhersehbaren Aufrufen (z. B. simple Datenabfragen, Kalender-Management).	Aufgaben, die kreative Abweichungen oder spontan hinzugefügte Tools erfordern.

Implementierung in der Praxis

Moderne Frameworks sind flexibel genug, um diese Patterns je nach Anforderung abzubilden. Die Wahl der Architektur sollte sich immer nach der Komplexität der Aufgabe richten:

1. Für Planner/Executor: Definiere einen separaten Planner-Agenten, der ausschließlich strukturierte Pläne (z. B. als JSON) ausgibt. Ein nachgelagerter Executor-Agent oder ein deterministisches Skript arbeitet diese Liste ab.
2. Für ReAct: Gib dem Agenten Werkzeuge, die klares Feedback liefern (z. B. Terminal-Output oder Screenshots). Zwinge das Modell per System-Prompt, vor jedem Tool-Aufruf eine kurze Reflexion zu generieren.
3. Für den Toolformer-Ansatz: Setze auf striktes Pattern-Matching. Beschreibe die Tool-Syntax in den Skill-Dateien so präzise, dass das Modell sie als natürlichen Teil seines Vokabulars adaptiert.

Fazit: Patterns als Baukasten

Agentic AI Patterns schließen sich nicht gegenseitig aus. In produktiven Systemen werden sie häufig kombiniert: Ein Planner generiert einen groben Ablaufplan, der Executor arbeitet kritische Schritte im ReAct-Style ab, und für simple Berechnungen kommen Toolformer-ähnliche Spezialskills zum Einsatz.

Patterns sind keine Magie, sondern bewährte Blaupausen. Sie helfen dabei, komplexe Agenten-Logik strukturiert, wartbar und kosteneffizient zu implementieren. Der beste Ansatz ist meist iterativ: Beginne mit einfachen ReAct-Abläufen und wechsle zu einem mehrstufigen Planner/Executor-Setup, sobald die Anforderungen an Zuverlässigkeit und Skalierbarkeit wachsen.