Das Reflexion-Pattern: Agenten, die aus Fehlern lernen

Das Reflexion-Pattern ist eine Agent-Architektur, bei der ein LLM-Agent systematisch über seine eigenen vergangenen Versuche nachdenkt und sich dadurch verbessert. Statt einer einzigen Antwort durchläuft der Agent mehrere Versuche: Ein Actor erzeugt eine Lösung, ein Evaluator bewertet sie, und ein Self-Reflection-Modell schreibt aus Bewertung und Verlauf eine sprachliche Kritik. Diese Kritik landet in einem Gedächtnis-Puffer und steuert den nächsten Versuch. Bemerkenswert: Es werden keine Modellgewichte verändert. Die Verbesserung ist rein sprachlich.

Das Verfahren geht auf das Paper von Shinn, Cassano, Berman, Gopinath, Narasimhan und Yao zurück: Reflexion: Language Agents with Verbal Reinforcement Learning (arXiv:2303.11366, März 2023, NeurIPS 2023). Es war die erste breit zitierte Demonstration, dass die selbst verbalisierte Fehleranalyse eines LLM ein stärkeres Lernsignal für in-context-Verbesserung ist als ein einfacher numerischer Reward.

Das Wichtigste in drei Sätzen

• Was es ist: Eine Schleife aus Actor, Evaluator und Self-Reflection mit episodischem Speicher. Der Agent lernt aus Fehlern in-context über mehrere Versuche hinweg, ohne Fine-Tuning.
• Wann es lohnt: Bei iterativen Aufgaben mit klarem, automatisierbarem Prüfsignal, etwa Codegenerierung mit Unit-Tests. Hier steigert es die Erfolgsrate messbar.
• Wo die Grenze liegt: Hohe Kosten (Größenordnung 10- bis 30-fach eines CoT-Aufrufs), strikt sequenziell, und ohne verlässlichen Evaluator unbrauchbar. Es ist kein Ersatz für echtes Training.

Wie der Reflexion-Loop funktioniert

Das Muster besteht aus drei Komponenten, die in einer Schleife zusammenspielen:

1. Actor – erzeugt die Lösung beziehungsweise den Lösungsweg. Das ist typischerweise selbst ein ReAct- oder Chain-of-Thought-Agent.
2. Evaluator – bewertet den Versuch. Die Bewertung kann binär (bestanden/durchgefallen), skalar oder durch eine externe Test-Suite erfolgen.
3. Self-Reflection-Modell – wandelt die Bewertung plus den Verlauf in verbales Feedback um: einen Absatz natürlichsprachlicher Kritik. Dieser Text wird in einem episodischen Gedächtnis-Puffer abgelegt.

Beim nächsten Versuch wird der Reflexionstext dem Kontext des Actors vorangestellt. Die „Policy-Aktualisierung" ist also rein sprachlich, es ändern sich keine Gewichte. Der Speicher ist bewusst klein gehalten, typischerweise werden ein bis drei Reflexionen behalten.

Der Ablauf in Kurzform:

```
Versuch_k: Actor → Evaluator → Self-Reflect → [an Speicher anhängen]
Versuch_k+1: Actor sieht Speicher → erneuter Versuch
... bis Erfolg oder max. Versuche erreicht
```

Der konzeptionelle Vorsprung gegenüber klassischem Reinforcement Learning: Standard-RL braucht viele Stichproben und teures Fine-Tuning, um aus Feedback zu lernen. Reflexion lehrt in-context über wenige Versuche hinweg, das ist um Größenordnungen günstiger und schneller einzurichten.

Wann das Reflexion-Pattern die Erfolgsrate erhöht

Der Nutzen steht und fällt mit der Qualität des Evaluator-Signals. Das stärkste belegte Beispiel ist Codegenerierung, weil dort ein automatischer Oracle existiert: Unit-Tests.

Die ideale Konstellation für Reflexion ist damit klar umrissen: Die Aufgabe ist iterativ, ein Fehlversuch ist günstig wiederholbar, und es gibt ein automatisierbares Prüfsignal. Das trifft auf Code-Generierung und Bug-Fixing, auf Aufgaben mit verifizierbaren Zwischenergebnissen und auf textbasierte Such-/Handlungsumgebungen wie ALFWorld zu. In der Entscheidungsmatrix der zugrundeliegenden Recherche steht für Code-Generierungs- und Bug-Fix-Agenten ausdrücklich die Kombination „Reflexion + ReAct" mit dem Hinweis: braucht Unit-Tests als Oracle.

Die Grenzen: Kosten, Trugschlüsse und kein echtes Lernen

Reflexion ist kein Selbstläufer. Die wichtigsten Schwächen, alle aus dem Paper und der Praxis belegt:

• Der MBPP-Fall (Paper-Abschnitt 4.4): Bei MBPP unterbot Reflexion die GPT-4-Baseline, weil die selbst erzeugten Unit-Tests eine hohe Falsch-Positiv-Rate hatten. Der Agent erklärte den Versuch verfrüht für erfolgreich. Das ist die kanonische Warnung gegen die Annahme „Reflexion verbessert immer die Leistung".
• Konfabulierte Reflexionen: Diagnostiziert das Modell falsch, warum es gescheitert ist, erbt der nächste Versuch die falsche Korrektur. Die Selbstkritik kann den Agenten also auch in die Irre führen.
• Reward-Hacking: Der Agent kann lernen, den Evaluator auszutricksen, statt die eigentliche Aufgabe zu lösen.
• Vage Reflexionen ohne Oracle: Bei kreativem Schreiben oder offener Recherche fehlt ein klares Prüfsignal. Die Reflexionen verflachen dann zu allgemeinen Plattitüden.
• Kosten und Latenz: Pro Versuch grob das Zwei- bis Fünffache eines ReAct-Laufs, multipliziert mit K Versuchen. Die Versuche sind zwingend sequenziell, jeder braucht die vorige Reflexion. Echtzeit-Anwendungsfälle scheiden meist aus.

Der grundlegende konzeptionelle Punkt für Entscheider: Reflexion ist kein echtes Lernen. Es ändern sich keine Gewichte, das „Gelernte" lebt im Kontextfenster der aktuellen Episode. Dauerhaftes Wissen entsteht erst, wenn man Reflexionen extern persistiert.

Kosten im Vergleich

Die folgenden Werte sind Richtwerte (Größenordnungen), synthetisiert aus den Paper-Angaben und Feldberichten. Sie ersetzen keine Messung auf der eigenen Last.

Reflexion liegt also bewusst im oberen Kostenbereich. Wer es ohne harte Iterationsgrenze einsetzt, riskiert, dass die Schleife die Kosten in die Höhe treibt.

Praxisbeispiel: Selbstkorrigierender Code-Agent

Ein konkretes Szenario aus dem belegten Anwendungsfeld. Eine Agentur soll einen Agenten bauen, der zu einer Funktionsbeschreibung lauffähigen Python-Code liefert. Der Pseudocode des Reflexion-Loops:

```text
versuch = 0
reflexionen = []
solange versuch < MAX_VERSUCHE (z. B. 3):
code = Actor.generiere(aufgabe, kontext=reflexionen) # Actor
ergebnis = Evaluator.fuehre_unit_tests_aus(code) # Evaluator = Test-Oracle
wenn ergebnis.alle_bestanden:
gib code zurueck # Abbruch bei Erfolg
kritik = SelfReflect.analysiere(code, ergebnis.fehler) # verbale Kritik
reflexionen.append(kritik) # Speicher auf 1–3 Eintraege begrenzen
versuch += 1
```

In der Logik des HumanEval-Ergebnisses: Ein erster Entwurf scheitert an zwei von zehn Tests. Die Self-Reflection notiert sinngemäß „Randfall leere Liste nicht behandelt, Off-by-one in der Schleife". Der zweite Versuch liest diese Notiz, korrigiert beides und besteht alle Tests. Genau dieses Muster trägt die HumanEval-Verbesserung von rund 80% auf 91% pass@1.

Zwei nicht verhandelbare Produktionslektionen aus der Recherche:

• Iterationen immer deckeln. In CrewAI über max_reasoning_attempts, in LangGraph über eine Bedingung revision_number ≤ N. Sonst kann die Schleife eskalieren.
• Externes Ground-Truth-Signal nutzen, wo möglich – Unit-Tests, RAG-Evaluator, Regex-Match. Reine Selbstbewertung ist unzuverlässig; der MBPP-Fall ist die Mahnung.

Wer wiederkehrende Aufgabentypen hat, kann Reflexionen zudem in einem Vektorspeicher ablegen, keyed nach Aufgabentyp. So entsteht eine emergente Skill-Bibliothek, die über einzelne Episoden hinaus wirkt, der Brückenschlag zu Skill-Library-Ansätzen wie Agent Workflow Memory (arXiv:2409.07429).

Einordnung im Framework-Ökosystem (Stand 2026)

• LangGraph: offizielles Tutorial mit drei Varianten – Basic Reflection (Generator-Reflektor-Paar), Reflexion (Draft-Responder → Tool-Ausführung → Revisor-Schleife mit explizitem Reflexionsspeicher) und LATS (Reflexion plus Baumsuche). Ein starkes Produktionsmuster ist dabei strukturierter Output, der answer, reflection (was fehlt, was überflüssig ist) und Folge-search_queries zusammenfasst.
• CrewAI: zweistufig. Auf Agent-Ebene über Agent(reasoning=True, max_reasoning_attempts=N), auf Crew-Ebene über einen dedizierten Critic Agent im Hierarchical Process.
• AutoGen: dokumentiert als „Reflection"-Design-Pattern mit Coder- und Reviewer-Agent, die bis zur Konvergenz oder bis max_iterations iterieren. Hinweis: AutoGen ist offiziell im Wartungsmodus, Microsoft verweist neue Projekte auf das Microsoft Agent Framework mit dem SPAR-Zyklus (Sense, Plan, Act, Reflect).
• n8n: kein nativer Reflexion-Knoten. Umsetzbar als Workflow-Schleife – Generator-Agent → Kritiker-Agent → IF-Knoten auf das Urteil → zurück zum Generator oder Ende. Geeignet für Batch- und Back-Office-Aufgaben, nicht für latenzarmen Chat.

Für Agenturen und B2B

Für DACH-Marketing-Agenturen ist Reflexion das richtige Werkzeug für eng umrissene, prüfbare Batch-Aufgaben mit Qualitätsanspruch: automatisierte Code- oder Konfigurations-Generierung, Datenanreicherung mit klaren Validierungsregeln, strukturierte Inhalte mit hartem Schema. Die Faustregel: Nur einsetzen, wenn Sie ein automatisierbares Prüfsignal definieren können und Latenz nicht im Kundengespräch sichtbar wird. Für Echtzeit-Chatbots ist ein reaktives ReAct-Muster die bessere Wahl. Wir bei Blck Alpaca bauen genau diese Architektur-Entscheidung in den Kostenrahmen ein: erst messen, welche Fehlermodi auftreten, dann gezielt von einfachem ReAct auf Reflexion eskalieren, mit harter Iterationsgrenze und externem Oracle. So bleibt der Agent zuverlässig und das Token-Budget kalkulierbar.