Was macht Loop-Design + Review?
Prämisse. Ein LLM ist ein Feed-Forward-System: Prompt rein → Tokens raus, ohne eingebaute "Steuerung in Richtung Ziel" über mehrere Durchläufe hinweg. Damit es sich wie ein zielorientiertes System verhält, muss man eine Rückkopplungsschleife darum herum bauen. Diese Fähigkeit hilft dir, diesen Loop korrekt zu schreiben und zu überprüfen, damit er nicht durchdreht.
Wann verwenden / nicht
Verwende es, wenn:
- Du eine sich wiederholende Aufgabe an einen Agenten übergeben möchtest, der sie immer wieder ausführt (schreiben→testen, testen→korrigieren, korrigieren→verifizieren…).
- Du bereits einen Loop hast und befürchtest, dass er spinnt, betrügt oder eine falsche Antwort bis zum Ende durchführt.
Nicht verwenden für:
- Eine einmalige Aufgabe → mach es einfach; baue keinen Loop darum herum.
- Einen reinen Timer / Poll → verwende
/loop; kein Design nötig. - Wie man die Loop-Architektur verdrahtet (Pipelines → DAGs, Langzeit-Wiederherstellung) → das ist die Mechanismus-Ebene; siehe
autonomous-loops/continuous-agent-loop. Diese Fähigkeit behandelt nur "Ist das Ziel richtig und wird es durchdrehen" – sie erklärt den Mechanismus nicht erneut.
Rote-Linie-Prämisse: zwei Ebenen der Rückkopplung
| Ebene | Wer besitzt sie | Was sie tut |
|---|---|---|
| Ausführung (niedrig) | Maschine / Agent | Misst "wie weit vom buchstäblichen Ziel entfernt" und arbeitet es auf null herunter. Die Maschine ist hier stark. |
| Urteil (hoch) | Mensch | Entscheidet: "Ist dieses Ziel selbst richtig, sollte es geändert werden, sollte es gestoppt werden." Die Maschine kann nicht aus ihrer eigenen Schleife heraustreten, um das Ziel zu hinterfragen. |
Ein Thermostat kann zurückmelden "wie weit von 26°C entfernt", aber wenn du Fieber hast und 28°C möchtest, kann es nicht beurteilen, ob 26 das richtige Ziel ist – es arbeitet einfach auf 26 hin. "Was heute eingestellt werden soll" ist immer die Entscheidung des Menschen. Das Urteil / die Freigabe / den letzten Schalter der Maschine zu überlassen = die hochrangige Rückkopplung entfernen = sie sprintet schnell und hart auf ein Ziel zu, das niemand hinterfragt hat → falsche Ausgabe.
Aktion 1 – Einen Loop schreiben (5 Schritte)
Schritt 0 · Erst subtrahieren: Sollte man ihn überhaupt bauen? (4-Bedingungen-Gatter, jeder Fehler = Veto)
① Die Aufgabe wiederholt sich wöchentlich oder häufiger ② Die Verifikation kann automatisiert werden ③ Das Token-Budget kann es verkraften ④ Der Agent hat Werkzeuge, die tatsächlich laufen und das Ergebnis sehen
Fehlt eine Bedingung → keinen Loop bauen; von Hand oder anders erledigen.
Was die meisten Menschen nicht aufhält, ist "kann ich einen Loop schreiben", sondern "verdient mein Repository einen?" Ein Repository, das einen Loop verdient, hat eine Abgleichsbasislinie (Goldstandard / Upstream-Gesamtsumme) + Tests + einen Lint-Guard. Ein Repository, das keinen Loop verdient, wird seine Fehler durch einen nur noch vergrößern.
Schritt 1 · Ein maschinenentscheidbares Ziel definieren (der schwierige Teil – der Loop lebt oder stirbt hier)
Der gesamte Loop basiert auf dem Komparator, der fragt: "Ist es fertig?" Der Komparator kann nur funktionieren, wenn deine Beendigungsbedingung von einer Maschine mit Ja/Nein beurteilt werden kann.
- Schlecht: Vage ("mach es gut", "schreib es schärfer") → der Komparator kann nicht urteilen → entweder besteht er nie (bleibt in Wiederholungen stecken) oder er rät (besteht / blockt zufällig).
- Gut: Entscheidbar ("alle 96 Komponententests grün UND eine Änderungsliste wird erstellt", "Modul-02-Felder ausgefüllt, pytest bestanden, Geschäftslogik unverändert") → ein Check klärt es; der Loop konvergiert sauber.
Fünf-Punkte-Zielrahmenwerk:
- Das Kriterium für "Fertig" ist maschinenüberprüfbar.
- Grenzbedingungen sind zusammen mit dem "Fertig"-Kriterium definiert ("was es NICHT tun darf") – Anti-Goodhart; fehlende Grenzen = eine Lizenz zum Betrügen.
- Hat einen Fehlerausweichplan – Wiederholungslimit N + Eskalation an einen Menschen bei Überschreitung.
- Das Ziel ist geschichtet.
- Bevorzuge Abgleich (Reconciliation) gegenüber Behauptung (Assertion) für das "Fertig"-Kriterium – verankere es an einer externen Tatsache (Goldstandard / Upstream-Gesamtsumme / finanzieller Abgleich / Plattform-Backoffice-Zahlen) vor deinen eigenen Behauptungen. "Alle Tests bestanden" kann manipuliert werden (Behauptungen lockern, Mocks fälschen, Ausnahmen schlucken); "Abweichung vs. Referenz < 0,01" kann es nicht.
Selbstcheck: Lies das Ziel jemandem vor, der die Domäne nicht kennt – kann diese Person einen Befehl ausführen und sagen, ob es fertig ist? Wenn nicht, ist es nicht entscheidbar genug. Geh zurück.
Schritt 2 · Den Loop-Typ wählen
| Deine Aufgabe | Loop-Typ (kybernetisch) | Wie er anhält |
|---|---|---|
| Hat einen klaren "Fertig"-Test (schreiben bis fertig / einen Batch Bilder verarbeitet) | Servo (/goal-artiger geschlossener Loop) | stoppt bei Erreichen des Ziels |
| Kein Endpunkt, muss einen Zustand aufrechterhalten (Bestandswarnmeldung / geplanter Gesundheitscheck) | Regler (/loop-artiger Thermostat) | stoppt nie; reagiert nur auf Änderung (Totband unterdrückt Rauschen) |
| Periodische Abtastung, Stopp bei einer Bedingung (auf einen PR warten, bis CI grün ist) | Regler mit Ausstieg | stoppt, wenn die Ausstiegsbedingung gilt |
| Muss "sicherstellen, dass etwas pünktlich passiert" | Obiges mit /schedule umschließen | Cron löst es aus |
Faustregel: Klarer "Fertig"-Test → Servo; muss aufrechterhalten, kein Endpunkt → Regler; muss "pünktlich passieren" → Regler in Zeitplan einwickeln.
Schritt 3 · Ein Skelett wählen
Wartungstyp (etwas Bestehendes pflegen) → dokumentengetriebene Abwicklung. Der Loop ist nicht "eine feste Prüfung auf einem Timer", sondern "lies ein Dokument auf einem Timer und bearbeite nur, wenn das Dokument geändert wurde". Das Dokument ist die Aufgabenwarteschlange + Zustandsmaschine + menschliche Schnittstelle. Drei Disziplinen: ① die Problemspalte ist nur vom Menschen beschreibbar, die Ergebnisspalte ist nur vom Loop beschreibbar, der Zustand schreitet nur in eine Richtung voran und rollt niemals zurück; ② der Exit-Code ist endgültig (wenn das Skript exit 1 sagt, gewinnt das Skript); ③ der Zustand schreitet nur bis "wartet auf Verifikation" voran – die Zelle "Fertig" wird nur von einem Menschen umgeschaltet. Der Loop ist der Arbeiter, nicht der Abnahmeoffizier.
Neuentwicklungstyp (von Grund auf neu bauen) → Planen / Bauen / Beurteilen, drei Rollen.
| Rolle | Tut | Schlüssel |
|---|---|---|
| Planen | Das Ziel in eine Spezifikation + entscheidbare Abnahmebedingungen zerlegen | Abnahme muss per Skript beurteilbar sein |
| Bauen | Nach der Spezifikation schreiben | darf die Abnahmebedingungen nicht ändern |
| Beurteilen | Die Abnahme unabhängig durchführen; bestanden → Stopp, fehlgeschlagen → mit Fehlergrund an Bauen zurückgeben | unabhängig + deterministisch |
Drei eiserne Regeln (alles setzt auf den Beurteiler): ① der Beurteiler muss unabhängig sein – nicht derselbe Agent wie Bauen (die eigene Hausaufgabe zu benoten macht immer besser); ② deterministische Regeln – pytest / Abgleichsdifferenz / Typprüfung / Diff, niemals "sieht richtig aus"; ③ Bauen darf die Abnahmebedingungen nicht ändern, um zu bestehen. Drei fehlgeschlagene Wiederholungen → an einen Menschen eskalieren.
Schritt 4 · Dämpfung hinzufügen (gegen Oszillation / Durchdrehen)
Wiederholungslimit, harter Stopp, der Mensch schaltet den letzten Schalter um = Dämpfung. Negative Rückkopplung ohne Dämpfung oszilliert (der Ralph-Wiggum-Loop: auf der Stelle drehen, Tokens verbrennen).
Schritt 5 · In drei Stufen einführen (nicht von Tag eins an vollautomatisch)
① Einmal von Hand ausführen (zwingt dich, genau zu sagen, "wie der Beurteiler entscheidet") → ② zu einer Fähigkeit / Claude Code-Unteragenten verhärten (ein Haupt-Claude loopt und verteilt Planen/Bauen/Beurteilen) → ③ für die vollständige Automatisierung an einen Cron hängen.
Aktion 2 – Einen Loop überprüfen (Checkliste = fünf Fehlermodi)
Führe den Loop an jeder Zeile vorbei. Trifft irgendeine zu = dieser Loop wird danebengehen; schicke ihn zurück. Diese fünf sind negative Erfahrungen (Stolperfallen) – wertvoller als positive Regeln.
| # | Fehlermodus (wie er bricht) | Überprüfungsfrage (Treffer = rot) | Antikörper |
|---|---|---|---|
| 1 | Ziel ist eine korrekte Platitüde → spinnt, verbrennt Geld | Kann die Beendigungsbedingung von einer Maschine mit Ja/Nein beurteilt werden? Oder ist es "gut verwalten / gut machen"? | Ersetze durch eine entscheidbare Ergebnisbedingung (Aktion 1·Schritt 1) |
| 2 | "Verifikation" formuliert als "prüfen, ob es okay aussieht" → Agent sagt selbstbewusst 'passt' und stoppt | Ist der Beurteiler der Angeklagte selbst? Beruht die Verifikation auf "sieht richtig aus" oder deterministischen Regeln? | Abgleichen + Exit-Code-Regeln + unabhängiger Beurteiler |
| 3 | (am schlimmsten) Nur auf "alle Tests bestanden" gepolt → Agent löscht die Tests | Gibt es eine Grenze ("was es NICHT tun darf")? Oder nur ein "Fertig"-Kriterium? | "Fertig"-Kriterium + Grenze gemeinsam (der Goodhart-Antikörper) |
| 4 | Vertraut darauf, dass der Agent während des Laufs nachfragt → er wird es nicht tun; er führt die falsche Antwort bis zum Ende aus | Gibt es irgendeine "erst zur Laufzeit klären"-Stelle? | Jede Klärung vorab erledigen; einmal vor dem Start festlegen |
| 5 | Aufgeblähte CLAUDE.md + veralteter Speicher → je schneller er loopt, desto mehr Fehler macht er | Sind die Dokumente / der Speicher, von denen er abhängt, aktuell? Wer pflegt sie? | Geschichteter Speicher + regelmäßiger Lint |
Plus drei rote Linien (Verstoß gegen eine = nicht erlaubt, automatisch zu laufen):
- Behalte das Urteil beim Menschen. Abnahme / die Zelle "Fertig" wird von einem Menschen umgeschaltet; der Loop ist nicht der Abnahmeoffizier.
- Verantwortung geht nicht über. Alles, dessen Scheitern du dir nicht leisten kannst (den falschen PR zusammenführen / das Falsche veröffentlichen / Geld falsch zuweisen) → übergebe die Autorität nicht automatisch.
- Kontraintuitive Warnung. Je mehr ein Loop "sich selbst verbessert / seine eigenen Regeln umschreibt", desto strengere menschliche Überprüfung benötigt er (um zu sehen, wohin er die Regeln umgeschrieben hat) – nicht lockerere. Die Maschine ist zu schnell, um nachträglich einzugreifen, also muss das menschliche Urteil vor der Aktion (ein hartes Tor) sitzen, nicht als nachträglicher Patch.
Ausgearbeitetes Beispiel – Überprüfung eines "nächtlichen Grün-Halters"-Loops
Du möchtest einen Loop, der jede Nacht läuft und alle fehlschlagenden Tests korrigiert.
- Naives Ziel: "alle Tests zum Bestehen bringen." → Schritt-1-Selbstcheck schlägt fehl: das ist der Köder für Fehlermodus #3.
- Entscheidbares Ziel (korrigiert): "alle Tests grün UND keine Testdatei gelöscht oder abgeschwächt UND Abdeckung nicht gesenkt UND eine Änderungsliste erstellt." Grenzen jetzt zusammen mit dem "Fertig"-Kriterium definiert.
- Typ: Servo mit einem Wiederholungslimit von 3 (Schritt 2 + Schritt 4).
- Skelett: Planen/Bauen/Beurteilen – der Beurteiler ist CI, der unabhängig läuft, niemals der korrigierende Agent (Schritt 3).
Wende nun die Überprüfungs-Checkliste an, und sie fängt ein, was die naive Version übersehen hätte:
- #3 getroffen → das naive "alle Tests bestanden" lässt den Agenten einen fehlschlagenden Test löschen, um zu "gewinnen". Behoben durch die Grenze "keine Testdatei gelöscht/abgeschwächt".
- #2 getroffen → wenn der korrigierende Agent auch seine eigene Korrektur beurteilen würde, würde er sich selbst bestehen lassen. Behoben durch "Beurteiler = unabhängiges CI, deterministisch".
- #4 getroffen → wenn eine Korrektur mehrdeutig ist, wird der Agent um 2 Uhr morgens nicht anhalten und nachfragen; er wird eine Vermutung festschreiben. Behoben durch Vorab-Klärung: mehrdeutige Korrekturen bleiben dem Menschen überlassen, werden nicht geraten.
- Rote Linie → der Loop öffnet einen PR, führt aber nicht automatisch zusammen; der Mensch schaltet den letzten Schalter um (Verantwortung geht nicht über).
Der naive Loop und der überprüfte Loop unterscheiden sich um vier Zeilen Einschränkung – und das ist der Unterschied zwischen "weckt dich mit einer gelöschten Test-Suite" und "weckt dich mit einem sauberen PR".
Einzeiler zum Schluss
Der schwierige Teil beim Schreiben eines Loops ist nicht "kann ich einen Loop schreiben", sondern ein Ziel zu definieren, das eine Maschine abgleichen kann – entscheidbar, begrenzt, auf Abgleich basierend. Der Regler muss deterministisch und extern sein; behalte Urteil und Maßstab beim Menschen; das System neigt zur Entropie, also pflege es. Ein Loop belohnt nur jemanden, der bereits gründlich nachgedacht hat. Verlasse dich darauf, dass er für dich denkt, und er wird fröhlich falsch denken – mit dir – im großen Stil.
Abstammung: Wieners Zwei-Ebenen-Rückkopplung (The Human Use of Human Beings, 1950) für die Urteils-/Ausführungsteilung und roten Linien; das Planen/Bauen/Beurteilen-Muster von Anatolis Loops explained und Addys Loop Engineering. Mechanismus-Ebene (wie man die Loop-Architektur verdrahtet): siehe
autonomous-loops/continuous-agent-loop. Diese Fähigkeit implementiert den Mechanismus nicht neu; sie behandelt nur die Zieldefinition und die Verhinderung von Durchdrehen.