Agent-Architekturen im Überblick

Warum Agent-Architekturen?

Ein LLM-Agent ist mehr als ein Modell mit Tools: Er braucht eine Struktur, die festlegt, wann er nachdenkt, wann er ein Tool aufruft, wann er einen Plan macht und wann er sich selbst korrigiert. Genau diese Struktur beschreiben Agent-Architekturen – wiederkehrende Design-Patterns, die in den letzten Jahren zum gemeinsamen Vokabular der Branche geworden sind.

Bemerkenswert ist, wie eng der Ursprung zusammenliegt: Die fünf kanonischen Muster ReAct, Reflexion, Plan-and-Execute, ReWOO und Tree-of-Thoughts entstanden in einem knappen Zeitfenster zwischen Oktober 2022 und Mai 2023, überwiegend aus dem Umfeld von Princeton, Google und Northeastern (Shunyu Yao ist Mitautor an drei der fünf Paper). Seither hat die Branche diese Muster entweder zu Framework-Primitiven verallgemeinert (etwa LangGraphs create_react_agent oder CrewAIs planning=True) oder zu Nachfolgemustern hybridisiert (LATS, LLMCompiler, Plan-and-Act).

Für Entscheider und Tech-Leads im DACH-Raum ist die Kernfrage selten „Welches Muster ist das fortschrittlichste?\", sondern „Welches Muster löst diese konkrete Aufgabe zu vertretbaren Kosten, Latenz und Auditierbarkeit?\". Dieser Überblick gibt dafür eine herstellerneutrale Landkarte.

ReAct – Reasoning und Acting verzahnt

ReAct (Yao et al., arXiv:2210.03629, Oktober 2022, ICLR 2023) ist das Fundament fast aller heutigen Tool-nutzenden Agenten. Die Idee: Das LLM erzeugt abwechselnd frei formulierte „Thought\"-Token (Reasoning) und „Action\"-Token (Tool-Aufrufe) und liest die „Observation\" – das Tool-Ergebnis – zurück. Die Schleife Thought → Action → Observation → Thought → … läuft, bis das Modell ein abschließendes Finish[answer] ausgibt.

Das gelöste Problem: Reines Chain-of-Thought (CoT) halluziniert Fakten, weil es keine Erdung in der Realität hat. Reine Action-Only-Agenten wiederum können nicht abstrakt über langfristige Ziele nachdenken oder sich von Fehlern erholen. ReAct vereint beides – Reasoning steuert den Tool-Einsatz, und Tool-Beobachtungen korrigieren das Reasoning. In der Originalstudie brachte das auf ALFWorld (textbasierte Haushaltsaufgaben) +34 Prozentpunkte und auf WebShop (E-Commerce-Navigation) +10 Prozentpunkte gegenüber damaligen Imitation-/RL-Baselines – allerdings gegen Modelle der GPT-3-/PaLM-Generation; die absoluten Zahlen sind heute überholt und nur als relative Effekte zu lesen.

Stärken: niedrige Latenz, geringe Implementierungskomplexität, hohe Interpretierbarkeit durch den nachvollziehbaren Reasoning-Trace. In LangGraph ist ReAct ein Einzeiler (create_react_agent); CrewAI nutzt es intern in jedem Agent; n8n bietet mit „ReAct AI Agent\" und dem moderneren „Tools Agent\" zwei native Knoten, deren Ausführungsansicht jeden Thought/Action-Schritt protokolliert – ein echter Vorteil für nicht-entwickelnde Marketing-Teams, die einen auditierbaren Log brauchen.

Schwächen: Bei mehrdeutigen Tool-Beschreibungen halluziniert das Modell Tool-Argumente. Es gibt „Reasoning Drift\" – einmal auf einen falschen Gedanken festgelegt, interpretiert der Agent nachfolgende Beobachtungen passend dazu. Und der Kontext bläht sich auf, weil jeder Schritt den System-Prompt und die komplette bisherige Trajektorie erneut mitschleppt (Kosten O(N·T)). In der Praxis liegt die Obergrenze typischerweise bei 10–25 Schritten, bevor Kontextverlust oder Drift dominieren.

Ein wichtiges Praxis-Learning: Moderne Frontier-Modelle beherrschen die Reasoning-Action-Schleife nativ über Function-Calling. Explizites ReAct-Prompting ist laut n8n-Blog weitgehend unnötig geworden – entscheidend sind heute Memory, Iterations-Obergrenzen und Nachvollziehbarkeit. Der häufigste Produktionsfehler bei schwächeren Modellen ist fehlerhaftes JSON in Tool-Argumenten; nutzen Sie strukturierte Ausgabe bzw. Function-Calling-Modus, wo immer der Anbieter es unterstützt.

Reflexion – Agenten, die sich selbst kritisieren

Reflexion (Shinn et al., arXiv:2303.11366, NeurIPS 2023) legt einen Selbstkorrektur-Loop um einen bestehenden Agenten. Drei Komponenten greifen ineinander: ein Actor (meist ein ReAct- oder CoT-Agent) erzeugt eine Trajektorie; ein Evaluator bewertet sie (binär, skalar oder über eine externe Testsuite); ein Self-Reflection-Modell wandelt Bewertung plus Trajektorie in verbales Feedback um – einen Absatz natürlichsprachiger Kritik, der in einem episodischen Speicher abgelegt wird. Im nächsten Versuch wird diese Reflexion dem Actor vorangestellt. Der „Policy-Update\" ist rein sprachlich; es werden keine Gewichte verändert.

Die zentrale Erkenntnis des Papers: Die selbst verbalisierte Fehleranalyse eines LLM ist ein stärkeres Lernsignal als ein bloßer numerischer Reward – und das vollständig in-context über mehrere Versuche hinweg. Auf HumanEval (Python-Codegenerierung) erreichte Reflexion 91 % pass@1 gegenüber rund 80 % der GPT-4-Baseline zum Zeitpunkt der Studie.

Aber – und das ist als Glaubwürdigkeits- und Warnsignal für DACH-B2B-Leser wichtig: Auf MBPP unterperformte Reflexion die Baseline, weil die selbst generierten Unit-Tests eine hohe False-Positive-Rate hatten und der Agent vorzeitig „Erfolg\" meldete. Reflexion ist also kein Universal-Verbesserer. Es braucht ein hochwertiges Evaluator-Signal. Für Aufgaben ohne klares Orakel (kreatives Schreiben, offene Recherche) verkommen Reflexionen zu vagen Plattitüden, und „konfabulierte Reflexionen\" – also falsch diagnostizierte Fehlerursachen – vererben die falsche Korrektur in den nächsten Versuch.

Kosten: Pro Versuch grob das 2- bis 5-fache eines einzelnen ReAct-Laufs, multipliziert mit K Versuchen; bei typisch K=3 also das 5- bis 15-fache. Versuche sind zwingend sequenziell, was Echtzeit-Anwendungsfälle in der Regel ausschließt.

Drei Praxisregeln aus der Recherche: Erstens immer die Iterationen deckeln (max_reasoning_attempts in CrewAI, revision_number ≤ N in LangGraph). Zweitens wo möglich ein externes Ground-Truth-Signal liefern (Unit-Tests, RAG-Evaluator, Regex-Match) – Selbstbewertung allein ist unzuverlässig. Drittens Reflexionen cachen: Viele Teams persistieren sie in einem Vektorspeicher nach Aufgabentyp und bauen so eine emergente Skill-Bibliothek auf. Ein Hinweis zur Benennung: In manchen Quellen (LangChain-Blog) meint „Reflection\" jeden Selbstkritik-Loop, „Reflexion\" dagegen speziell das Paper von Shinn et al. – im Deutschen lohnt sich die Unterscheidung Reflexion (Shinn et al.) versus Reflection-Muster im weiteren Sinn.

Plan-and-Execute – erst der Plan, dann die Umsetzung

Das Plan-and-Execute-Muster entkoppelt Planung von Ausführung. Ein Planner erstellt einmalig einen nummerierten Mehrschritt-Plan, ein Executor (häufig ein ReAct-Sub-Agent) arbeitet ihn Schritt für Schritt ab, und ein Replanner entscheidet nach jeder Ausführung, ob terminiert oder ein angepasster Restplan ausgegeben wird. Konzeptionell basiert es auf „Plan-and-Solve\"-Prompting (Wang et al., arXiv:2305.04091, ACL 2023) und BabyAGI; der Agentenname stammt aus der LangChain-Portierung. Korrekt formuliert: die von LangChain popularisierte Plan-and-Execute-Architektur auf Basis von Plan-and-Solve-Prompting.

Der entscheidende Hebel: Planung ist eine schwere Reasoning-Aufgabe (großes Modell), Ausführung ist per-Schritt-Tool-Nutzung (kleineres, günstigeres Modell). Diese Modell-Staffelung spart laut LangChain-Blog empirisch 30–60 % Tokens gegenüber reinem ReAct bei Mehr-Tool-Aufgaben. Die explizit ausformulierten Pläne sind zudem auditierbar – ein starkes Argument für Enterprise- und Compliance-Kontexte.

Schwächen: Plan-Sprödigkeit – ist der Vorab-Plan falsch, verschwendet der Executor Aufrufe auf zum Scheitern verurteilte Schritte, bis der Replanner es bemerkt. Die Ausführung bleibt sequenziell (keine echte Parallelität). Und jeder Replan ruft das große Modell erneut auf; in stark stochastischen Umgebungen wird fast bei jedem Schritt neu geplant, was den Kostenvorteil aufzehrt. Faustregel: einsetzen, wenn Aufgaben in mehr als drei unabhängige Schritte zerfallen, ein klares Orakel für die Plan-Validität existiert und die Latenz nicht direkt nutzerseitig spürbar ist. Nicht einsetzen, wenn die Umgebung hochgradig stochastisch ist – dann ist ReActs reaktive Schleife strikt besser. Anthropics „Orchestrator-Workers\"-Muster ist im Kern dasselbe, neu gerahmt.

ReWOO – Reasoning ohne ständige Beobachtung

ReWOO (Xu et al., arXiv:2305.18323, Mai 2023) ist die kostenoptimierte Antwort auf ReActs Token-Hunger. Drei Module: Ein Planner erzeugt in einem einzigen LLM-Aufruf die komplette Kette aus Plan-Schritten und Tool-Aufrufen, wobei eine Variablen-Syntax (#E1, #E2, …) erlaubt, auf noch nicht vorliegende Ergebnisse zu verweisen. Ein Worker führt die Tools in der vorgegebenen Reihenfolge aus und ersetzt die Platzhalter durch echte Ergebnisse. Ein Solver liest schließlich in einem letzten LLM-Aufruf Aufgabe plus alle Evidenzen und formuliert die Antwort.

Der Effekt: N LLM-Aufrufe werden durch genau zwei ersetzt (Planner + Solver), unabhängig von der Zahl der Tool-Schritte. Auf HotpotQA berichtet das Paper 5-fache Token-Effizienz bei +4 % Genauigkeit gegenüber ReAct, über sechs NLP-Benchmarks hinweg konsistente Token-Reduktion. ReWOO ist zudem robust bei Tool-Ausfällen – der Plan steht bereits fest, und der Solver erkennt fehlende Evidenzen sauber.

Grenzen: keine Anpassung mitten in der Ausführung – widerspricht Evidenz 3 dem Plan, kann ReWOO im selben Durchlauf nicht neu planen. Ohne Umgebungskontext tut sich der Planner bei unbekannten Tool-Ökosystemen schwer (Few-Shot-Prompting oder Fine-Tuning nötig). Und Tools laufen sequenziell; echte Parallelität liefert erst der Nachfolger LLMCompiler (Kim et al., arXiv:2312.04511) über einen DAG.

Für DACH-Marketingagenturen ist ReWOO oft das beste Muster in n8n: Die Stärke von n8n sind deterministische, deklarative Workflows, Variablen-Substitution ist nativ, und Aufgaben wie „recherchiere X → reichere an → formatiere → versende\" sind damit debugbar, günstig und fehlertolerant. Praxisberichte nennen rund 65 % Token-Kostenreduktion bei 4–5 % Genauigkeitsgewinn. Anti-Pattern: ReWOO nicht für Aufgaben einsetzen, bei denen Tool-Ergebnisse den Plan häufig invalidieren (z. B. interaktive Web-Navigation) – dort sind Plan-and-Execute oder ReAct besser.

Tree-of-Thoughts – Suche statt Linie

Tree-of-Thoughts (Yao et al., arXiv:2305.10601, NeurIPS 2023) bricht mit der streng links-nach-rechts verlaufenden Logik von CoT. Statt einer einzigen Gedankenkette wird ein Baum aufgespannt: Jeder Knoten ist ein „Thought\" (eine Teillösung), an jeder Stelle generiert das Modell k Kandidaten, ein State-Evaluator bewertet sie (etwa per sicher/vielleicht/unmöglich-Abstimmung), und ein Suchalgorithmus (BFS oder DFS mit Backtracking) durchforstet den Baum. Das Paper rahmt das explizit als „System-2\"-Suche in Anlehnung an die Problemlöse-Formalismen von Newell & Simon.

Die Ergebnisse sind auf such-lastigen Aufgaben drastisch: Game of 24 zu 74 % gelöst (gegenüber 4 % CoT, 7,3 % IO), Mini-Crosswords auf Wortebene 60 % (vs. 16 % CoT), kreatives Schreiben mit besserer Kohärenz. Der Preis ist allerdings enorm – das 10- bis 100-fache an Tokens gegenüber einem einzelnen CoT-Aufruf, und die Wirksamkeit hängt stark von der Generator-Qualität ab (GPT-3.5+ToT erreichte bei Game of 24 nur 19 % statt 74 %).

Das wichtigste Feld-Learning zu ToT: Für allgemeines Reasoning ist es 2026 weitgehend obsolet, weil moderne Reasoning-Modelle (o-Serie, Claude mit Extended Thinking, Gemini-2.x-Thinking) die Suche modellintern internalisieren. ToT bleibt relevant als konzeptionelles Fundament für baumstrukturierte Agenten-Suche (es ist die Basis von LATS) sowie für drei Nischen: auditpflichtige regulierte Branchen, Puzzles/Optimierung mit verifizierbaren Rewards und Small-Model-Deployments mit günstigen Proposern. In Tools wie n8n ist ToT durch die kombinatorische Explosion praktisch nicht skalierbar; die saubere Annäherung ist „Best-of-N-Sampling\" – mehrere parallele Läufe, aus denen ein Kritiker den besten wählt (ToT mit Tiefe 1).

Routing und hierarchische Muster

Über die fünf Reasoning-Muster hinaus nennt Anthropic in „Building Effective Agents\" (Dezember 2024) zwei weitere strukturgebende Patterns, die in der Praxis oft den Rahmen bilden. Routing klassifiziert eine Eingabe und leitet sie an einen spezialisierten Pfad – etwa ein Klassifikator-Schritt, der Support-Anfragen nach Typ an unterschiedliche Prompts oder Modelle verteilt. Hierarchische Architekturen verschachteln einen Orchestrator mit Sub-Agenten: Ein koordinierendes LLM zerlegt die Aufgabe dynamisch und delegiert an untergeordnete Agenten – Plan-and-Execute mit ReAct-Sub-Agenten ist genau diese Spielart (Anthropics Orchestrator-Workers).

Zur Vorsicht bei der Hierarchie liefert Cognition (Devin) das meistzitierte Learning: „Don't Build Multi-Agents\" (Juni 2025) warnte, dass parallele Agenten implizit widersprüchliche Entscheidungen treffen und fragile Ergebnisse liefern. Die aktualisierte Position „Multi-Agents: What's Actually Working\" (April 2026) hält Multi-Agent für tragfähig bei lesend-parallelen, schreibend-einsträngigen Setups. Übersetzt für Agenturkunden: Setzen Sie auf einen starken Agenten mit Tools; parallele Sub-Agenten nur zur Informationsbeschaffung, niemals für Schreib- oder Zustandsänderungen.

Vergleich – wann welches Muster

Die folgende Größenordnungs-Tabelle ist als grober Richtwert zu lesen (synthetisierte Schätzungen aus Paper-Angaben und Feld-Berichten, keine Direktmessungen) – messen Sie auf Ihrer eigenen Last nach:

Der rote Faden für die Praxis

Über alle Muster hinweg ist das wichtigste Feld-Learning aus produktiven Blogposts von 2024–2026 (Anthropic, Cognition, LangChain) erstaunlich nüchtern: Starten Sie mit dem einfachsten Muster, das funktioniert – meist ReAct – und eskalieren Sie erst zu Planning, Reflexion oder Suche, wenn gemessene Fehlermodi es verlangen. Anthropic formuliert es so: „Die erfolgreichsten Implementierungen nutzten einfache, komponierbare Patterns statt komplexer Frameworks.\"

Die 2025/2026er-Generation an Mustern ist im Kern Rekombination der ursprünglichen fünf: LATS = ToT + Reflexion + MCTS (nativ in LangGraph), LLMCompiler = ReWOO + paralleler DAG (~3,6× Speedup), Plan-and-Act = Plan-and-Execute für lange Horizonte. Auch die Frameworks konvergieren auf ein gemeinsames Primitiv aus State-Graph plus Tool-Calling – Microsoft hat AutoGen und Semantic Kernel im Microsoft Agent Framework konsolidiert (AutoGen ist offiziell im Wartungsmodus), LangChain führt create_react_agent in langchain.agents.create_agent mit Middleware über. Für DACH-Entscheider, die den Microsoft-Stack evaluieren, ist das die relevante Weichenstellung.

Drei nicht verhandelbare Praxisregeln zum Schluss: Erstens braucht jeder Agent harte Obergrenzen (recursion_limit, max_iterations), sonst eskalieren Loops in Kosten. Zweitens sind Observability-Tools (LangSmith, Langfuse, Arize Phoenix) de facto Pflicht. Drittens müssen für die Compliance vollständige Thought/Action/Observation-Traces mit PII-Scrubbing persistiert werden – das ist gerade für DSGVO und EU-AI-Act-relevante Systeme zentral.

Hinweis: Compliance-Aussagen in diesem Text sind informativ und stellen keine Rechtsberatung dar. Die genannten Benchmark-Zahlen stammen überwiegend aus den Original-Papern der Jahre 2022–2023 (GPT-3.5-/GPT-4-Ära) und sind als relative Effektgrößen zu verstehen, nicht als absolute Werte für heutige Frontier-Modelle.