ReAct-Muster (Reasoning + Acting)

1. Überblick über das Konzept und das systemische Problem

Vor der Einführung des ReAct-Konzepts (veröffentlicht von Forschern der Princeton University und Google Research im Jahr 2022) herrschte in der Community eine Spaltung zwischen zwei Ansätzen zur Automatisierung von LLMs:

1. Chain-of-Thought (Nur Denken): Das Modell generiert lange Ketten von Überlegungen, hat aber keinen Zugriff auf die Außenwelt. Die Logik wirkt zwar überzeugend, basiert jedoch oft auf halluzinierten Fakten oder veralteten Daten.
2. Act-Only (Nur Handeln): Das Modell ruft APIs auf oder führt bash-Befehle aus, ohne vorherige Selbstreflexion. Dies führt zu chaotischen Wiederholungen, blindem Durchprobieren von Parametern und der Unfähigkeit, selbst einfache mehrstufige Aufgaben zu lösen.

Das ReAct-Pattern (Reasoning + Acting) vereinte diese beiden Stärken in einem iterativen Zyklus: Das Modell verbalisiert zunächst seine Gedanken und plant den nächsten Schritt, führt dann die gezielte Aktion aus, analysiert das tatsächliche Ergebnis der Umgebung (Observation) und trifft erst danach die nächste Entscheidung.

2. Architektonische Taxonomie und mentales Modell

Ein klassischer Schritt im ReAct-Zyklus besteht aus drei sequentiellen Zuständen:

• 1. Thought (Internes Schlussfolgern): Der Agent analysiert den aktuellen Zustand der Aufgabe, stellt eine Hypothese auf und formuliert eine konkrete Absicht: „Ich muss prüfen, ob der Redis-Dienst auf Port 6379 läuft, bevor ich Tests starte.“ Diese Phase reduziert die Wahrscheinlichkeit von Fehlern in Tool-Argumenten erheblich.
• 2. Action (Aufruf einer Aktion / eines Tools): Der Agent definiert eine spezifische Aktion mit strengen Parametern: Funktionsname und ein valides JSON-Objekt (z. B. execute_bash(command="systemctl status redis")).
• 3. Observation (Umgebungsbeobachtung): Die externe Runtime fängt die Aktion ab, führt sie auf dem Server oder in der Datenbank aus und gibt die rohe Textausgabe oder einen Fehlercode zurück in den Kontext des Agenten.
• 4. Finish / Final Answer (Abschlusszustand): Wenn der Agent in der letzten Observation erkennt, dass das Ziel erreicht ist, stoppt er den Zyklus und formuliert die endgültige Antwort für den Benutzer.

3. Technisches Pipeline-Design und interne Mechanik

Der Lebenszyklus eines ReAct-Agenten in einer Softwareumgebung:

1. Context & Scratchpad Injection (Prompt-Vorbereitung): In den System-Prompt werden Interaktionsregeln, Beschreibungen verfügbarer Tools und die Historie früherer Iterationen der aktuellen Sitzung (Scratchpad) eingebettet.
2. Inference with Tool Delimiter (Generierung von Schlussfolgerung und Absicht): Das LLM generiert Tokens für den Abschnitt Thought. Sobald das Modell zum Tool-Aufruf kommt, wird die Generierung vom Client angehalten und die Argumente des Aufrufs validiert.
3. Execution & Observation Feedback (Ausführung in der Umgebung): Der Orchestrator übergibt den Befehl an das entsprechende Subsystem (lokales Terminal, Datenbank oder Browser), liest die Ausgabe ein, begrenzt deren Länge zur Token-Einsparung und fügt die Nachricht Observation: ... dem Kontext hinzu.
4. Loop Progression & Termination Check (Prüfung des Abbruchs): Hat der Agent sein Ziel erreicht oder den Zähler max_iterations = 10 überschritten, wird der Zyklus unterbrochen. Andernfalls beginnt die nächste Iteration mit einem neuen Thought-Block.

4. Praktische Engineering-Szenarien im Produktionsbetrieb

01. Interaktive Diagnose und Reparatur der Server-Infrastruktur

• Thought: Der Dienst gibt einen 502-Fehler zurück. Ich prüfe zuerst die Nginx-Logs der letzten 5 Minuten.
• Action: read_logs(service="nginx", lines=20)
• Observation: connect() failed (111: Connection refused) while connecting to upstream 127.0.0.1:3000
• Thought: Der Upstream auf Port 3000 ist ausgefallen. Ich muss den Status des Node.js-Prozesses über PM2 überprüfen.
• Action: execute_cmd(command="pm2 status")
• Observation: app-server: errored (out of memory)
• Thought: Der Dienst ist aufgrund von Speichermangel abgestürzt. Ich starte ihn neu mit einem höheren Heap-Limit.

02. Iterative Suche in Dokumentation und API

Der Agent versucht, einen externen Stripe-Dienst aufzurufen. Im ersten Schritt erhält er einen invalid_api_key-Fehler. Durch den Thought-Block erinnert sich der Agent daran, dass für den Testmodus das Präfix sk_test_ erforderlich ist, holt die richtige Umgebungsvariable und erstellt erfolgreich eine Zahlungsabsicht im zweiten Versuch.

03. Schrittweises Debugging von Unit-Tests

Ein Code-Agent bemerkt einen Testfehler aufgrund einer Abweichung des erwarteten Werts. Er stellt eine Hypothese auf, nimmt eine minimale Änderung an einer Zeile vor, startet den Test neu, sieht ein grünes Ergebnis und meldet erst dann die erfolgreiche Ausführung der Aufgabe.

5. Fallstricke, häufige Fehler und Sicherheit

• Verharren in falschen Hypothesen (Self-Reinforcing Delusion): Wenn das Modell im ersten Schritt eine falsche Schlussfolgerung zieht, neigt es dazu, alle folgenden Observations zugunsten seines Fehlers zu interpretieren. Lösung: Erzwingende Hinzufügung eines Reflexions-Schritts (Reflection) nach drei aufeinanderfolgenden fehlgeschlagenen Aktionen.
• Kontextaufblähung durch rohe Beobachtungen: Der Befehl cat huge_file.json liefert 50.000 Tokens an „Müll“, was den System-Prompt verdrängt. Begrenzen Sie immer die Größe der zurückgegebenen Observation in der Runtime (z. B. maximal 2000 Zeichen).
• Aufruf nicht existierender Tools (Action Hallucination): Das Modell versucht, ein Tool aufzurufen, das nicht in der Liste enthalten ist. Lösung: Verwendung nativer API Tool Calling statt roher Textanalyse.