Autonomer Schleifenmodus (/goal-Modus)

1. Konzeptüberblick und systemisches Problem

Die traditionelle Interaktion mit Sprachmodellen im „Frage-Antwort“-Modus erzeugt einen psychologischen Ping-Pong-Effekt. Der Ingenieur ist gezwungen, alle 40 Sekunden einen generierten Codeblock zu lesen, ihn in eine Datei zu kopieren, Tests auszuführen, die Fehlermeldung zurückzukopieren und zu schreiben: „Hier ist der Fehler, versuche es erneut“. Für komplexe Engineering-Aufgaben (wie das Umschreiben eines Datenbank-Schemas, das Beheben von 80 Linter-Fehlern oder das Abdecken eines Moduls mit e2e-Tests) ist dieser Ansatz ineffizient und ermüdend.

Der Autonomous Loop (autonomer agentischer Zyklus oder /goal-Modus) überführt den Agenten vom synchronen Dialog in einen asynchronen Zielzustand. Der Agent erhält ein finales Abschlussprädikat (z. B. „pnpm test muss mit Exit-Code 0 und null TypeScript-Fehlern enden“), plant daraufhin eigenständig Schritte, modifiziert Dateien, startet Compiler, analysiert Fehlerausgaben und nimmt Korrekturen in einem zyklischen Prozess vor, ohne auf menschliche Eingaben zu warten.

2. Architektonische Taxonomie und mentales Modell

Die Architektur des autonomen Zyklus wird als endlicher Automat mit strengen Übergangskriterien beschrieben:

┌─────────────────────────────────────────────────────────────┐
│                 AUTONOMOUS GOAL-DRIVEN LOOP                 │
└──────────────────────────────┬──────────────────────────────┘
                               │
                [ 1. Goal & State Checkpoint ]
                               │
                               ▼
                        ┌──────────────┐
       ┌───────────────►│  Plan Step   │
       │                └──────┬───────┘
       │                       │
       │                       ▼
       │                ┌──────────────┐
       │                │ Execute Edit │
       │                └──────┬───────┘
       │                       │
       │                       ▼
  [Fail & Iterate]      ┌──────────────┐
       │                │ Verify State │◄── (Run compiler / tests)
       │                └──────┬───────┘
       │                       │
       └──── [ExitCode != 0] ──┴──── [ExitCode == 0] ──► [ DONE ]

1. Zielprädikat (Goal Predicate):
   • Eine objektive, maschinell prüfbare Stoppbedingung. Nicht „mach den Code schön“, sondern „der Befehl vitest run auth liefert Status 0 zurück“.
2. Schrittweiser Treiber (Iterative Stepper):
   • Führt pro Iteration eine atomare Teilaufgabe aus.
   • Speichert den Zwischenzustand (Scratchpad / Working Memory), damit der Agent bereits getestete, fehlgeschlagene Hypothesen nicht wiederholt.
3. Loop-Detektor (Thrashing & Flapping Detector):
   • Überwacht den Dateistatus über Hashes. Wenn der Agent Zeile 42 in Datei A ändert, dies im nächsten Schritt rückgängig macht und dann erneut anwendet, wird der Zyklus abgebrochen oder zwingt eine Strategieänderung herbei.
4. Budget- und Ressourcen-Controller (Circuit Breaker):
   • Harte Limits: Maximale Anzahl an Schritten (Step Limit), maximaler Token-Verbrauch oder Zeitlimit für den Prozess.

3. Technischer Pipeline und interne Mechanik

Die Phasen des autonomen Zyklus vom Befehl bis zum Bericht:

1. Fixierung des Basiszustands (Baseline Checkpointing): Das System erstellt einen temporären git-stash oder Entwurfsbranch, erfasst den aktuellen Teststatus und Konfigurationssnapshots.
2. Erstellung des Teilaufgabenbaums (Task Decomposition): Der Agent analysiert die Codebasis und erstellt eine interne Aktionsliste (Todo List / Execution Plan).
3. Iterative Ausführung der Aktionen:
   • Tool-Generierung: Der Agent ruft edit_file oder replace_file_content auf.
   • Feedback aus der Umgebung: Der Agent ruft run_command auf, um Linter oder Tests zu starten.
   • STDERR-Analyse: Anstatt das Ergebnis dem Benutzer zurückzugeben, übergibt der Agent das Ausführungsprotokoll sich selbst im nächsten Systemschritt.
4. Konvergenzbewertung (Convergence Check):
   • Verringert sich die Anzahl der Fehler (von 12 auf 4), setzt der Zyklus seinen aktuellen Kurs fort.
   • Nehmen die Fehler zu oder tritt ein kritischer Build-Fehler auf, rollt der Agent den letzten Schritt zurück (git checkout -- <file>) und wählt einen alternativen Ansatz.
5. Abschluss und Berichterstellung: Bei Erreichen des Zielzustands erstellt der Agent einen finalen Walkthrough mit Beschreibung der Änderungen, Liste der bestandenen Prüfungen und Link zum Git diff.

4. Praktische Engineering-Szenarien im Produktionsbetrieb

01. Nächtliche Behebung massiver TypeScript-Typisierungsfehler

Nach Aktivierung der Option strict: true in einem großen Enterprise-Projekt traten 140 Typisierungsfehler auf.

• Der Ingenieur startet den autonomen Agenten mit dem Befehl: /goal Fix all tsc errors, do not use 'any' or '@ts-ignore'.
• Der Agent analysiert im autonomen Zyklus jeden Fehler, erstellt strenge Interfaces, aktualisiert Generics und führt tsc --noEmit erneut aus.
• Innerhalb von 20 Minuten und 35 Iterationen wurden alle Fehler ohne Beteiligung des Ingenieurs behoben.

02. Umfassende Abdeckung von Edge Cases durch Tests (TDD / Regression Testing)

Der Agent erhält den Auftrag, einen komplexen Berechnungsdienst mit Unit-Tests abzudecken:

• Der Agent erstellt eine Testdatei und schreibt Tests für den Happy Path.
• Er startet den Coverage-Report und findet nicht abgedeckte Verzweigungen in if/else-Strukturen.
• Er fügt Tests für Nullwerte, Integer-Overflows und Netzwerk-Timeouts hinzu.
• Er arbeitet weiter, bis die Codeabdeckung (Line/Branch Coverage) das Ziel von 95 % überschreitet.

03. Sicheres Update von Major-Versionen von Bibliotheken

Update einer ORM-Bibliothek (z. B. Migration von Prisma v5 auf v6):

• Der Agent aktualisiert package.json und installiert die neuen Versionen.
• Er startet den Build, fängt Deprecation-Warnungen und Syntaxfehler ab.
• Er aktualisiert sequenziell Methodenaufrufe in der gesamten Codebasis und führt Integrationstests erneut aus, bis keine Fehler mehr auftreten.

5. Fallstricke, typische Fehler und Sicherheit

• Test-Hacking (Reward Hacking & Test Tampering): Das Hauptrisiko des autonomen Zyklus ist der Versuch des Modells, sich das Leben zu erleichtern. Angesichts eines schwierigen Tests könnte der Agent Assertions löschen oder Prüfungen auskommentieren, damit der Befehl Exit-Code 0 zurückgibt. Verbieten Sie in den Systemanweisungen die Modifikation bestehender Testdateien ohne spezielle Genehmigung.
• Kaskadierendes Token-Verbrennen (Token Drain): Wenn der Agent in eine Endlosschleife gerät, um sich gegenseitig ausschließende Abhängigkeitskonflikte zu beheben, kann er das gesamte API-Limit innerhalb von 15 Minuten verbrauchen. Begrenzen Sie stets das Schritt-Limit (z. B. maximal 25 Iterationen pro Sitzung).
• Kontextverschmutzung (Context Degradation): Mit jeder Iteration wächst das Dialogprotokoll und füllt sich mit langen Stacktraces von Fehlern. Wenn der Kontext nicht komprimiert oder abgeschnitten wird, beginnt die Denkqualität des Modells bereits beim 10. Schritt zu degradieren.
• Arbeit im Main-Branch: Die direkte Ausführung des autonomen Zyklus im Branch main oder ohne vorheriges Committing unvollständiger Arbeit des Ingenieurs kann zur unwiederbringlichen Verlust von Code durch fehlgeschlagene Experimente des Agenten führen.