Kontroll-Schleifen: ReAct, Planung, Termination

Vier Fragen, die jede Schleife beantwortet — ob bewusst oder nicht

Eine Agenten-Schleife ist kein Framework-Detail, sondern eine Menge von vier Entscheidungen. Jede läuft mit, auch wenn niemand sie getroffen hat — dann eben als Voreinstellung der benutzten Bibliothek.

Kontroll-Schleife — Der wiederholte Wechsel aus Modellentscheidung, Ausführung und Rückführung des Ergebnisses, bis eine Abbruchbedingung greift. Ohne diese Bedingung ist es keine Schleife, sondern ein Leck.

• Welcher Schritt kommt als Nächstes? Datenabhängig entschieden oder vorab geplant — das ist die Wahl zwischen Reagieren und Planen.
• Wann ist Schluss? Eine Zielbedingung für den Normalfall, ein harter Deckel für den Rest. Zwei Bedingungen, nicht eine.
• Was fließt zurück? Werkzeugergebnisse und Fehler als Beobachtung — oder als Rauschen, das der Agent überliest.
• Was bleibt im Kontext? Jede Runde füllt ihn weiter. Ohne Verdrängungsregel entscheidet die Ankunftsreihenfolge, nicht die Relevanz.

ReAct: die Verschränkung ist der Wirkmechanismus

Das Muster, auf dem praktisch jede Agenten-Schleife aufsetzt, heißt ReAct und ist belegt. Yao et al. erzeugen Reasoning-Spuren und aufgabenspezifische Aktionen verschränkt: Das Nachdenken übernimmt Planung und Ausnahmebehandlung, die Aktionen holen Information aus externen Quellen.

Der Befund, der dabei am häufigsten übersehen wird, steckt im Vergleich: Der Gewinn entstand gegenüber Verfahren, die nur dachten oder nur handelten. Reines Nachdenken ohne Außenkontakt neigt zu Halluzination und Fehlerfortpflanzung; reines Handeln ohne Zwischenschritt verliert das Ziel. Auf ALFWorld und WebShop lag ReAct 34 beziehungsweise 10 Prozentpunkte über lernbasierten Verfahren — mit sehr wenigen Beispielen im Kontext.

Praktisch heißt das: Wer die Beobachtung aus der Schleife nimmt — etwa indem er Werkzeugergebnisse nur ins Protokoll schreibt statt in den nächsten Aufruf —, behält die Kosten des Musters und verliert seinen Wirkmechanismus.

Technisch hängt der Zyklus an einem einzigen Feld der Modellantwort. Solange stop_reason den Wert tool_use trägt, ist die Runde nicht die letzte: Der aufrufende Code führt aus und hängt das Ergebnis als tool_result an. Erst wenn das Modell mit end_turn antwortet, ist die Schleife aus Sicht des Modells fertig. Wer diese Bedingung im Code sucht, findet die Stelle, an der jede Grenze eingebaut werden muss.

Datenabhängigkeit versus Planungstiefe

Schritt für Schritt reagieren ist nicht immer das Richtige. Es gibt eine benennbare Klasse von Aufgaben, an denen reines Reagieren scheitert: solche mit wechselseitigen Bedingungen, bei denen ein früher Schritt eine spätere Anforderung unmöglich macht.

Reagieren (ReAct)

Der nächste Schritt hängt vom Ergebnis des vorherigen ab, aber die Schritte behindern sich nicht gegenseitig. Beispiel: erst Incidents abfragen, dann den Eigentümer des gefundenen Dienstes.

Planen, dann ausführen

Die Schritte konkurrieren um ein gemeinsames Budget oder eine Reihenfolge-Bedingung. Ein Plan macht die Abhängigkeiten vor der ersten Wirkung sichtbar.

Planen und neu planen

Der Regelfall bei Nebenwirkungen: Plan aufstellen, ausführen, bei Abweichung von der Annahme neu planen — statt einen veralteten Plan starr durchzuziehen.

Beide Fehlformen sind im Betrieb häufig. Die eine ist der Agent, der ohne Plan eine irreversible Buchung tätigt und danach feststellt, dass das Restbudget die zweite Buchung nicht mehr trägt. Die andere ist der Agent, der einen zehn Schritte langen Plan ausführt, obwohl Schritt zwei bereits gezeigt hat, dass die Annahme dahinter falsch war.

Beobachtung: der Rückkanal, der am häufigsten leckt

Die Beobachtung ist der Schritt, an dem die meisten Schleifen tatsächlich brechen — und zwar leise. Ein Werkzeug meldet einen Fehler, das Ergebnis geht unstrukturiert in den nächsten Aufruf, und der Agent arbeitet weiter, als hätte er Daten bekommen.

Termination: zwei Bedingungen, nicht eine

Eine Schleife braucht eine Zielbedingung für den Normalfall und einen harten Deckel für den Fall, dass das Ziel unerreichbar ist. Wer nur eine von beiden hat, hat entweder einen Agenten, der ewig weitersucht, oder einen, der bei jeder Aufgabe an derselben künstlichen Grenze abbricht.

• Zielbedingung — der Auftrag ist erfüllt, überprüfbar formuliert: das Ticket hat einen Status, die Datei existiert, der Betrag stimmt mit der Bestellung überein.
• Maximale Runden — die Zahl der Modellaufrufe pro Auftrag. Der wirksamste Deckel, weil daran auch die Kosten hängen.
• Maximale Werkzeugaufrufe je Werkzeug — begrenzt gezielt das eine Werkzeug, in dem sich ein Agent verrennt, ohne die ganze Schleife zu verkürzen.
• Token-Budget je Auftrag — greift dort, wo wenige Runden mit sehr großen Ergebnissen teuer werden.
• Zeitgrenze — die schwächste Grenze allein, weil sie nichts über den Zustand aussagt, aber die einzige, die auch hängende Aufrufe fängt.

Wichtig ist, was beim Abbruch passiert. Ein Agent, der am Deckel einfach verschwindet, hinterlässt einen halb ausgeführten Auftrag ohne Aussage. Ein Agent, der beim Deckel ein ausdrückliches „konnte nicht abschließen“ mit dem bisherigen Stand zurückgibt, hinterlässt einen bearbeitbaren Fall. Der Unterschied ist eine Zeile Code und entscheidet, ob der Betrieb den Fall findet.

Diese Grenzen gehören in die Konfiguration des Laufs, nicht in den Prompt — als benannte Felder, die im Protokoll auftauchen: eine Obergrenze für Runden, eine je Werkzeug, ein Token-Budget und eine Zeitgrenze. Wichtig ist, dass jede von ihnen beim Greifen einen unterscheidbaren Grund hinterlässt. Ein Lauf, der mit „Rundendeckel erreicht“ endet, verlangt eine andere Untersuchung als einer, der mit „Zeitgrenze überschritten“ endet, und beide eine andere als ein sauberes end_turn.

Fortschritt ist nicht Ressourcenverbrauch

Der Rundendeckel fängt das Feststecken — aber spät und teuer. Zwischen „läuft noch“ und „Deckel erreicht“ liegt ein Zustand, den ein Deckel nicht erkennt: Der Agent arbeitet, verbraucht Budget und kommt nicht voran.

No-Progress — Eine äquivalente Aktion führt zu einer äquivalenten Beobachtung, und der Zielzustand hat sich nicht verändert. Zwei Wiederholungen sind ein Verdacht, drei sind ein Befund.

Die Erkennung ist einfacher, als sie klingt: ein Hash aus Werkzeugname und normalisierten Argumenten, dazu ein Hash der Antwort. Wiederholt sich das Paar, ohne dass sich der Zielzustand ändert, greift eine Regel. Sinnvoll sind drei Ausgänge, gestaffelt statt gleichzeitig: Strategiewechsel erzwingen, an einen Menschen eskalieren, kontrolliert abbrechen.

Am Normalisieren hängt, ob die Erkennung greift. Ein Agent, der region: eu-west einmal als EU-West und einmal mit anhängendem Leerzeichen schickt, erzeugt drei verschiedene Hashes für dieselbe Suche — und läuft an einer wörtlichen Gleichheitsprüfung vorbei. Kleinschreibung, getrimmte Werte, sortierte Schlüssel und entfernte Zeitstempel sind hier kein Feinschliff, sondern die Voraussetzung dafür, dass die Wiederholung überhaupt als Wiederholung erscheint.

Die falschen Reaktionen sind leicht zu erkennen, weil sie alle am Symptom ansetzen. Den Deckel erhöhen gibt der Wiederholung mehr Raum. Die Temperatur erhöhen tauscht die Wiederholung gegen Zufall. Ein größeres Modell verschiebt die Wahrscheinlichkeit, ohne die Grenze einzuführen. Keine dieser Maßnahmen erkennt den Zustand — sie machen ihn nur seltener oder teurer.

Reflection ist Minderung — und nur mit externem Signal überhaupt Lernen

Selbstprüfung in der Schleife funktioniert messbar. Reflexion (Shinn et al.) lässt Agenten sprachlich über Rückmeldungen zur Aufgabe reflektieren und diesen Reflexionstext in einem episodischen Speicher halten, um in den folgenden Versuchen besser zu entscheiden — ohne jede Gewichtsanpassung. Auf HumanEval erreichte das 91 Prozent bei pass@1 gegenüber 80 Prozent des vorherigen Bestwerts.

Der Teil, den Zusammenfassungen gern weglassen, ist der wichtigste für den Betrieb: Die Rückmeldung, über die reflektiert wird, kommt aus einem Signal — skalar oder sprachlich, aus einer externen oder internen Quelle. Bei Code sind das Testergebnisse. Wo dieses Signal fehlt, bleibt vom Verfahren die Selbstkritik übrig, und die teilt die blinden Flecken des Modells.

Reflection mit externem Signal

Der Agent prüft gegen ein Urteil von außen: Tests laufen, ein Schema validiert, eine zweite Quelle bestätigt. Trägt eine Verbesserung.

Reflection ohne externes Signal

Der Agent bewertet seine Ausgabe selbst. Hebt oft die Form, selten die Korrektheit — und meldet Fehler nicht, die er auch beim ersten Versuch nicht gesehen hat.

Reflection als Freigabe

Selbstprüfung ersetzt die Verifikation vor einer Wirkung. Nicht tragfähig: Das Verfahren hat keine Korrektheitsgarantie und beansprucht sie nicht.

Die Schleife ist der Verbraucher des Kontexts

Jede Runde legt Werkzeugergebnisse in den Kontext, und der Kontext hat eine Obergrenze. Der Zusammenhang ist mechanisch: Die Rundenzahl ist der Treiber, nicht die Aufgabengröße.

Der Effekt ist benannt und begründet. Mit steigender Tokenzahl sinkt die Fähigkeit des Modells, Information aus dem Kontext zuverlässig abzurufen — Context Rot. Die Ursache liegt in der Architektur: Jedes Token kann auf jedes andere aufmerken, was bei n Tokens n² paarweise Beziehungen ergibt. Das Ziel ist deshalb nicht der volle, sondern der kleinste Satz aussagekräftiger Tokens, der das gewünschte Ergebnis wahrscheinlich macht.

Für die Schleife folgt daraus eine Betriebsregel: Ein Agent, der über 30 Schritte hinweg unschärfer wird und früh genannte Vorgaben vergisst, hat kein Modellproblem, sondern eine fehlende Verdrängungsstrategie. Welche — Verdichtung, ausgelagerte Notizen, gezielter Abruf — ist die Frage des nächsten Moduls. Hier zählt nur: Die Schleife selbst erzeugt das Problem, also gehört die Grenze in die Schleife.

Struktur statt Freiheit, wo der Ablauf bekannt ist

Wenn ein Agent Schritte vergisst, in falscher Reihenfolge ausführt oder welche erfindet, ist der Reflex, ihm bessere Anweisungen zu geben. Die wirksamere Maßnahme ist die umgekehrte: ihm Entscheidungen wegnehmen.

Die interessante Grenze liegt bei den verbleibenden zehn Prozent. Ein Gerüst, das auch sie festschreibt, bricht beim ersten Sonderfall — der Werkstudentin ohne Kostenstelle, dem externen Dienstleister ohne Postfach. Deshalb gehört zu jedem Gerüst ein benannter Ausgang: Fälle, die der feste Ablauf nicht abdeckt, laufen in eine Warteschlange für Menschen, statt das Modell auf einem Pfad improvisieren zu lassen, für den es keine Prüfung gibt.

Jede Schleifenkontrolle hat einen Preis

Alle Maßnahmen dieses Moduls sind richtig und alle kosten etwas. Wer den Preis nicht benennt, baut Kontrollen ein, die im ersten Zwischenfall als Hindernis wieder herausgenommen werden.

Harter Rundendeckel

Fängt jede Endlosschleife — bricht aber auch die legitimen langen Läufe ab. Der Deckel gehört an die beobachtete Verteilung, nicht an einen runden Wert.

No-Progress-Erkennung

Findet das Feststecken früh — kann aber legitime Wiederholung als Stillstand lesen, etwa bei bewusstem Warten auf ein noch nicht fertiges Ergebnis.

Planungsschritt

Macht wechselseitige Bedingungen vor der ersten Wirkung sichtbar — kostet eine Runde und kann selbst falsch sein.

Reflexionsrunde

Hebt die Qualität bei unvollständigen ersten Versuchen — verdoppelt im Zweifel Kosten und Latenz und garantiert nichts.

Deterministisches Gerüst

Macht den Ablauf zuverlässig und lokalisierbar — nimmt dem System die Fähigkeit, mit unvorhergesehenen Fällen umzugehen.

Die Reihenfolge, in der man sie einführt, ist nicht beliebig. Der harte Deckel kommt zuerst, weil er als einziger den unbegrenzten Schaden begrenzt. Alles Weitere ist Verbesserung innerhalb einer bereits geschlossenen Grenze.

Was der Check prüft

Die Übungen dieses Moduls prüfen die Eingriffe in eine laufende Schleife — an Symptomen, wie sie im Protokoll auftauchen.

• Die Runden eines ReAct-Zyklus in die Reihenfolge bringen, in der sie voneinander abhängen.
• Erkennen, wann eine Laufzeit-Datenabhängigkeit eine Schleife verlangt — und wann wechselseitige Bedingungen einen Plan verlangen.
• Werkzeugfehler so zurückführen, dass die Schleife sie lesen kann, statt sie zu überschreiben.
• Abbruchbedingungen in einer Konfiguration prüfen und die fehlende Grenze benennen.
• Stillstand von Ressourcenverbrauch unterscheiden und die passende Staffelung wählen.
• Reflexion einsetzen, ohne sie als Freigabe zu behandeln.
• Entscheiden, wann mehr Struktur die bessere Antwort auf Unzuverlässigkeit ist als mehr Freiheit.

Der gemeinsame Nenner: Eine Schleife wird nicht dadurch beherrschbar, dass das Modell besser wird, sondern dadurch, dass ihre Grenzen außerhalb des Modells liegen und im Protokoll sichtbar sind.