Als wir erstmals einen AI-Agenten für einen Fertigungskunden im Einsatz hatten — die Aufgabe: die Zusammenstellung von Berichten aus mehreren Systemen automatisieren — haben wir naiv eine einfache Schleife mit einem LLM und einer Reihe von Tools gestartet. Es funktionierte… solange nichts anders lief als geplant. Sobald ein Tool eine unerwartete Ausgabe zurücklieferte, geriet der Agent in eine Schleife und generierte 40 Minuten lang Tokens, bis wir manuell eingreifen mussten. Das Problem war nicht das Modell. Das Problem war die Architektur — nicht auf reale Bedingungen ausgelegt.
Heute gibt es drei vorherrschende Muster für AI-Agenten-Architekturen: ReAct, Plan-and-Execute und Reflexion. Jedes hat seinen Platz, jedes hat Grenzen. Dieser Artikel ist ein Entscheidungsrahmen — wann welches Muster zu wählen ist, was man davon erwarten kann und wo es Probleme verursacht.
Warum die Wahl der Architektur entscheidet
Die Wahl der Architektur ist kein technisches Detail. Sie beeinflusst direkt vier Metriken, auf die es im Produktivbetrieb ankommt:
- Zuverlässigkeit — wie der Agent auf unerwartete Tool-Ausgaben oder Fehler reagiert
- Kosten — wie viele Tokens er pro Aufgabe verbraucht
- Latenz — wie schnell der Nutzer ein Ergebnis erhält
- Debugbarkeit — wie leicht zu finden ist, wo und warum der Agent versagt hat
Wichtiger Hinweis: ReAct, Plan-and-Execute und Reflexion sind akademische Muster aus den Jahren 2022–2023 (Yao et al. 2022 für ReAct). LangGraph, AutoGen, CrewAI und andere Frameworks *implementieren* diese Muster — sie haben sie aber nicht erfunden. Die Wahl des Frameworks ist eine sekundäre Entscheidung. Primär ist die Wahl des Musters.
ReAct: Reason-Act-Observe-Schleife
ReAct (Reasoning + Acting) ist das einfachste und am weitesten verbreitete Muster. Der Agent arbeitet in einer Schleife:
- 1.Reason — auf Basis des aktuellen Zustands und der Geschichte „denkt" das LLM (generiert Text, der das Reasoning beschreibt)
- 2.Act — wählt ein Tool aus und ruft es mit konkreten Parametern auf
- 3.Observe — empfängt die Tool-Ausgabe und fügt sie in den Kontext ein
- 4.Wiederholt, bis das Ziel erreicht oder eine finale Antwort gefunden ist
Die Stärke von ReAct ist Adaptabilität. Wenn sich während des Laufs etwas ändert — ein Tool liefert ein unerwartetes Ergebnis, eine API ändert ihr Format — sieht der Agent das in der Observe-Phase und kann den Kurs anpassen. Nicht nach einem vorgeschriebenen Plan, sondern reaktiv.
Wo ReAct gut funktioniert
- Aufgaben mit 2–4 Schritten und klarem Ziel (suche X, verarbeite Y, schreibe Z)
- Interaktive Tools, bei denen sich der Kontext in Echtzeit ändert
- Prototyping — ReAct ist am schnellsten zu implementieren
- Wenn Sie ein möglichst einfaches Audit-Log wollen (jeder Reason-Act-Observe-Schritt ist sichtbar)
Wo ReAct versagt
- Lange Aufgaben mit vielen Schritten — jeder neue Schritt fügt die gesamte Geschichte in den Kontext ein, die Kosten steigen quadratisch
- Parallele Aufgaben — ReAct ist sequenziell und kann nicht gleichzeitig mehrere Zweige ausführen
- Ohne `max_steps`-Limit ist es gefährlich — das ist keine Übertreibung. Ein Agent ohne gesetztes Schritt-Limit kann über Nacht in einer Schleife feststecken und Tausende unnötige API-Aufrufe erzeugen — und damit eine Rechnung in Tausenden von Euro. Wir sehen das in der Praxis; es ist kein hypothetisches Risiko.
Wichtige Korrektur eines verbreiteten Mythos: das Wort „Reason" in ReAct *bedeutet nicht*, dass der Agent tatsächlich korrekt denkt. Der Reason-Schritt ist ein Sprachoutput — das LLM generiert Text, der wie Reasoning aussieht. Er kann voller Fehler sein, ohne dass das Modell das irgendwie signalisiert. Nicht verifizierbares „Denken" ist eine der häufigsten Ursachen für stilles Versagen von ReAct-Agenten.
Kostenprofil ReAct
Eine typische ReAct-Aufgabe verbraucht 2.000–3.000 Tokens bei 3–4 Schritten. Ab 8+ Schritten kann der Verbrauch auf 10.000–20.000 Tokens pro Aufgabe steigen, da die gesamte Geschichte in jedem Kontextfenster wiederholt wird. Bei Produktionslast fällt das auf der Rechnung auf.
Plan-and-Execute: Erst der Plan, dann die Schritte
Plan-and-Execute (P&E) teilt den Agenten in zwei Phasen:
- 1.Planer — erhält das Ziel und generiert einen expliziten Schrittplan (z. B. „Schritt 1: Daten von API laden, Schritt 2: Format transformieren, Schritt 3: in Datenbank speichern, Schritt 4: Report versenden")
- 2.Executor — führt die Schritte gemäß Plan aus, einen nach dem anderen, ohne erneute Planung
Der entscheidende Vorteil: Planer und Executor müssen nicht dasselbe Modell sein. Das ist wirtschaftlich interessant — ein teures, leistungsstarkes Modell (z. B. der Klasse Claude Opus oder GPT) übernimmt die Planung, bei der Qualität entscheidend ist. Ein günstiges, schnelles Modell übernimmt die Ausführung, bei der Geschwindigkeit und Kosten zählen. Für lange Aufgaben mit N Schritten kann das günstiger sein als reines ReAct.
Wo P&E gut funktioniert
- Lange, strukturierte Aufgaben (5+ Schritte mit klarer Logik)
- Stapelverarbeitung — wenn Sie 1.000 Dokumente nach demselben Verfahren verarbeiten müssen
- Auditierbare Pipelines — der Plan ist ein explizites Dokument, der Kunde sieht es vor dem Start
- Robustheit gegenüber Prompt Injection — Forschungsergebnisse deuten darauf hin, dass P&E einen gewissen inhärenten Vorteil hat: Der Executor hat keinen Zugriff auf die Planungsanweisungen, ein Angreifer in den Daten kann ihn daher schwerer umleiten (es ist jedoch kein vollständiger Schutz)
Wo P&E versagt
Einfaches P&E hat einen fixen Plan. Wenn sich die Bedingungen während des Laufs ändern — eine API liefert ein anderes Format, Schritt 3 schlägt fehl — führt der Agent den alten Plan weiter aus oder steckt fest. Dynamic Replanning (Neuplanung nach einem Fehler) ist eine Erweiterung, keine Grundeigenschaft von P&E. Sie müssen es explizit implementieren.
Noch ein Mythos zur Korrektur: P&E ist *nicht immer präziser* als ReAct. Für dynamische Umgebungen, in denen sich die Bedingungen während des Laufs ändern, ist ReAct anpassungsfähiger. P&E ist besser dort, wo die Umgebung vorhersehbar ist und der Plan bis zum Ende gültig bleibt.
Kostenprofil P&E
Eine typische P&E-Aufgabe verbraucht 3.000–4.500 Tokens (einschließlich der Planungsphase). Auf den ersten Blick teurer als ReAct. Aber für Aufgaben mit 8+ Schritten ist der Gesamtverbrauch niedriger — der Executor arbeitet mit kürzerem Kontext als die ReAct-Schleife, die die gesamte Geschichte akkumuliert. Empfehlung: Für kurze Aufgaben (2–4 Schritte) ReAct wählen, für lange (6+ Schritte) P&E in Betracht ziehen.
Reflexion und Self-Critique
Reflexion (Reflexion, Shinn et al. 2023) ergänzt ReAct oder P&E um eine Selbstbewertungsebene:
- 1.Der Agent führt die Aufgabe aus (ReAct oder P&E)
- 2.Das Reflexionsmodul bewertet das Ergebnis — „wurde das Ziel erreicht? Wo traten Fehler auf?"
- 3.Auf Basis der Reflexion wird das Gedächtnis des Agenten aktualisiert oder der Schritt mit angepasstem Ansatz wiederholt
Beispiel aus Ergebnissen: Bei Aufgaben aus CodeContests stieg GPT-4 von ca. 19 % Erfolgsrate mit einfachem Prompt auf rund 44 % mit iterativem, testgetriebenem Ansatz (veröffentlichter Flow AlphaCodium). Das ist ein realer Anstieg — genau bei Aufgaben mit deterministischer Verifikation.
Wo Reflexion hilft
- Programmieraufgaben mit deterministischer Verifikation (Code besteht Tests oder nicht)
- Iterative Ausgaben — wenn die erste Version nie ausreicht und Sie automatische Verbesserungen wollen
- Komplexe Analysen, bei denen Sie einen zweiten Blick auf das Ergebnis benötigen
Grenzen der Reflexion
Kritische Grenze: Wenn dasselbe Modell sowohl die Ausgabe als auch die Kritik erzeugt, neigt Reflexion dazu, dieselben Fehler zu wiederholen. Das Modell sieht keine Lücken in seinem eigenen Reasoning. Replikationsstudien aus 2025 haben das bestätigt — Single-Agent-Reflexion in iterativen Zyklen konvergiert zur gleichen (falschen) Antwort. Die Lösung ist entweder ein anderes Modell für die Verifikation oder ein externer deterministischer Verifikator (Tests, Linter, Schema-Validierung).
Mehr dazu, wie Guardrails für AI-Agenten helfen, diese Fehler abzufangen, bevor sie den Nutzer erreichen.
Wann ein einzelner LLM-Aufruf ausreicht
Vor der Wahl einer Agenten-Architektur ist die Frage zu stellen: *Brauche ich wirklich einen Agenten?*
Unsere Einschätzung: 40–50 % der Use-Cases, bei denen Kunden mit einer Agenten-Anforderung kommen, lassen sich mit einem oder zwei LLM-Aufrufen ohne jede Schleife lösen. Beispiele:
- Klassifikation eines Dokuments (ein Aufruf, Structured Output)
- Extraktion von Feldern aus einer Rechnung (ein Aufruf + JSON-Modus)
- Generierung eines Reports aus vorbereiteten Daten (ein Aufruf, langer Prompt)
- Zusammenfassung mit Quellen (ein Aufruf + Agentic-RAG-Pipeline)
Die Regel: Wenn Sie Eingaben, Ausgaben und Transformation im Voraus exakt definieren können — brauchen Sie keinen Agenten. Ein Agent fügt Wert hinzu, wenn die Schritte nicht im Voraus bekannt sind oder die Umgebung dynamisch ist.
Verwandte Entscheidung: Chatbot vs. Copilot vs. Agent — wo genau die Grenzen zwischen diesen Begriffen liegen.
Entscheidungsrahmen
Statt einer Tabelle (die Trade-offs vereinfachen würde) bieten wir eine Fragenkette:
1. Wie viele Schritte hat die Aufgabe? - 1–3 Schritte → ein LLM-Aufruf oder einfaches ReAct - 4–7 Schritte, vorhersehbare Umgebung → Plan-and-Execute - 8+ Schritte mit paralleler Logik → P&E + DAG-Executor oder Multi-Agent
2. Ändert sich die Umgebung während des Laufs? - Nein (Stapelverarbeitung, deterministisches Verfahren) → P&E - Ja (interaktiv, Echtzeit-Daten, unvorhersehbare API) → ReAct
3. Benötigen Sie eine auditierbare Ausgabe? - Ja, der Kunde will den Plan vor dem Start sehen → P&E - Nein, das Ergebnis zählt → ReAct (kürzere Startzeit)
4. Wie hoch sind die Fehlerkosten? - Niedrig (internes Tool, leicht zu korrigieren) → ReAct mit max_steps-Limit - Hoch (Kunde, regulierter Bereich) → P&E + Reflexion + Human-in-the-Loop
5. Haben Sie ein dediziertes Team für die Wartung? - Nein → Möglichst einfaches Muster. ReAct mit klarem max_steps, Logging jedes Schritts. - Ja → Sie können sich P&E + Dynamic Replanning + Reflexion leisten.
Hybride Architekturen in der Praxis
Im Produktivbetrieb sehen wir fast nie reines ReAct oder reines P&E. Gängige Kombinationen:
- P&E + ReAct-Executor — der Planer generiert die Schritte, jeder Schritt wird von einem Mini-ReAct-Agenten mit Tool-Zugriff ausgeführt
- ReAct + Reflexion — nach Abschluss der ReAct-Schleife wird das Reflexionsmodul gestartet, das die Ausgabequalität bewertet
- P&E + Dynamic Replanning — bei einem Schrittfehler wird der gesamte Plan neu bewertet, nicht nur der betreffende Schritt
LangGraph ist heute de facto Standard für die Implementierung dieser hybriden Muster in Python. Alternativen wie AutoGen (Microsoft) oder CrewAI sind stark für die Multi-Agent-Koordination, aber LangGraph hat das größte Ökosystem und die höchste Produktionsstabilität.
Eine breitere Perspektive dazu, was ein Agent im Produktivbetrieb kostet — einschließlich Pro-Aufruf-Preisgestaltung und Optimierungsmöglichkeiten — finden Sie in einem separaten Artikel.
Debugbarkeit — die unterschätzte Dimension
Die Architektur beeinflusst auch, wie leicht sich Fehler finden lassen. Aus der Praxis:
ReAct: Jeder Reason-Act-Observe-Schritt ist im Trace-Log sichtbar. Wenn der Agent bei Schritt 7 versagt, sehen Sie genau, welche Observe-Eingabe er erhalten hat und welches Reason er generiert hat. Gut debugbar — wenn jeder Schritt korrekt geloggt ist.
P&E: Der Plan ist ein explizites Dokument — Sie sehen leicht, wo der Executor vom Plan abgewichen ist. Aber Fehler im Plan selbst (fehlerhafte Planungslogik) sind schwerer zu erkennen, da der Planer einmal läuft und seine Entscheidungen nicht inkrementell sind.
Reflexion: Am schwierigsten zu debuggen. Iterative Zyklen produzieren viele Logs, und wenn das Modell in jedem Zyklus denselben Fehler wiederholt, kann es schwer sein, die Grundursache zu bestimmen.
Mehr dazu, wie Sie Observability für AI-Agenten einrichten — Tracing, Logging und Alerts — im Produktivbetrieb.
Häufige Fragen
Was ist die ReAct-Architektur und woher stammt sie?
ReAct (Reasoning + Acting) ist ein Muster für AI-Agenten, das von Yao et al. im Jahr 2022 entwickelt wurde (akademische Publikation). Der Agent arbeitet in einer Reason–Act–Observe-Schleife: Das LLM denkt, wählt ein Tool, erhält das Ergebnis und wiederholt. LangGraph, LangChain und andere Frameworks implementieren dieses Muster, haben es aber nicht erfunden.
Wann Plan-and-Execute statt ReAct wählen?
Plan-and-Execute eignet sich für lange, strukturierte Aufgaben (6+ Schritte) mit vorhersehbarer Umgebung, bei denen Sie einen auditierbaren Plan vor dem Start wollen. ReAct ist besser für kurze, dynamische Aufgaben, bei denen sich die Bedingungen während des Laufs ändern. Für 1–3 Schritte überlegen Sie, ob Sie überhaupt einen Agenten benötigen.
Ist Plan-and-Execute immer präziser als ReAct?
Nein. P&E hat Vorteile bei strukturierten, vorhersehbaren Aufgaben. Für dynamische Umgebungen, in denen sich die Bedingungen während des Laufs ändern, versagt P&E — der Agent führt den veralteten Plan weiter aus. ReAct ist anpassungsfähiger, da es auf jeden Observe-Output reagiert.
Warum ist es gefährlich, einen ReAct-Agenten ohne max_steps-Limit zu starten?
Ohne gesetztes Schritt-Limit kann der Agent in eine Schleife geraten (z. B. ruft er wiederholt ein Tool auf, das einen Fehler zurückgibt, den der Agent nicht als terminalen Zustand wertet). Ein solcher unkontrollierter Agent kann über Nacht Tausende von Aufrufen erzeugen und eine Rechnung in Tausenden von Euro produzieren. Jeder Produktionsagent muss einen expliziten max_steps- oder max_iterations-Parameter gesetzt haben.
Kann ich ReAct und Reflexion kombinieren?
Ja, hybride Architekturen sind im Produktivbetrieb üblich. Typische Kombination: ReAct-Schleife für die Schrittausführung, Reflexionsmodul nach Abschluss zur Bewertung der Ausgabequalität. Wichtiger Hinweis: Reflexion funktioniert zuverlässig nur dann, wenn die Ausgabe von einem anderen Modell oder einem externen deterministischen Verifikator (Tests, Schema-Validierung) bewertet wird — nicht vom selben Modell, das den Output erzeugt hat.
*Wenn Sie den Einsatz eines AI-Agenten in Ihrem Unternehmen erwägen und unsicher sind, welche Architektur für Ihren Use-Case geeignet ist, bewerten wir die konkrete Situation gerne. Bei MP Industrial Solutions helfen wir Kunden, den Ansatz zu wählen, der ihren realen Anforderungen an Zuverlässigkeit, Kosten und Teamkapazitäten entspricht — nicht den, der in der Demo am beeindruckendsten wirkt.*