autonome Schleifen

Fertigkeit Autonome Schleifen

Kompatibilitätshinweis (v1.8.0): autonomous-loops wird für eine Version beibehalten. Der kanonische Fertigkeitsname ist jetzt continuous-agent-loop. Neue Anleitungen für Schleifen sollten dort verfasst werden, während diese Fertigkeit verfügbar bleibt, um bestehende Workflows nicht zu unterbrechen.

Muster, Architekturen und Referenzimplementierungen für das autonome Ausführen von Claude Code in Schleifen. Deckt alles ab, von einfachen claude -p-Pipelines bis hin zu vollständigen RFC-gesteuerten Multi-Agenten-DAG-Orchestrierungen.

Wann verwenden

• Einrichten von autonomen Entwicklungsworkflows, die ohne menschliches Eingreifen laufen
• Auswahl der richtigen Schleifenarchitektur für Ihr Problem (einfach vs. komplex)
• Erstellen von CI/CD-ähnlichen kontinuierlichen Entwicklungspipelines
• Ausführen von parallelen Agenten mit Merge-Koordination
• Implementieren von Kontextpersistenz über Schleifeniterationen hinweg
• Hinzufügen von Qualitätstoren und Bereinigungsläufen zu autonomen Workflows

Spektrum der Schleifenmuster

Vom einfachsten bis zum anspruchsvollsten:

Muster	Komplexität	Am besten geeignet für
Sequenzielle Pipeline	Niedrig	Tägliche Entwicklungsschritte, skriptgesteuerte Workflows
NanoClaw REPL	Niedrig	Interaktive persistente Sitzungen
Unendliche Agentenschleife	Mittel	Parallele Inhaltsgenerierung, spezifikationsgesteuerte Arbeit
Kontinuierliche Claude-PR-Schleife	Mittel	Mehrtägige iterative Projekte mit CI-Gates
Entschlampfungsmuster	Add-on	Qualitätsbereinigung nach jedem Implementierungsschritt
Ralphinho / RFC-gesteuerter DAG	Hoch	Große Funktionen, parallele Arbeit mit Merge-Queue

---

1. Sequenzielle Pipeline (claude -p)

Die einfachste Schleife. Unterteilen Sie die tägliche Entwicklung in eine Abfolge von nicht-interaktiven claude -p-Aufrufen. Jeder Aufruf ist ein fokussierter Schritt mit einer klaren Aufforderung.

Kern-Einsicht

Wenn Sie keine solche Schleife entwickeln können, bedeutet das, dass Sie nicht einmal das LLM dazu bringen können, Ihren Code im interaktiven Modus zu reparieren.

Das claude -p-Flag führt Claude Code nicht-interaktiv mit einer Aufforderung aus und beendet sich, wenn die Aufgabe erledigt ist. Verketten Sie Aufrufe, um eine Pipeline zu erstellen:

#!/bin/bash
# daily-dev.sh – Sequenzielle Pipeline für einen Feature-Branch

set -e

# Schritt 1: Funktion implementieren
claude -p "Lesen Sie die Spezifikation in docs/auth-spec.md. Implementieren Sie OAuth2-Login in src/auth/. Schreiben Sie zuerst Tests (TDD). Erstellen Sie KEINE neuen Dokumentationsdateien."

# Schritt 2: Entschlampfen (Bereinigungslauf)
claude -p "Überprüfen Sie alle Dateien, die durch den vorherigen Commit geändert wurden. Entfernen Sie unnötige Typtests, übermäßig defensive Prüfungen oder Tests von Sprachfunktionen (z.B. Testen, ob TypeScript-Generics funktionieren). Behalten Sie echte Geschäftslogiktests. Führen Sie die Testsuite nach der Bereinigung aus."

# Schritt 3: Überprüfen
claude -p "Führen Sie den vollständigen Build-, Lint-, Typprüfungs- und Testsuite-Durchlauf aus. Beheben Sie alle Fehler. Fügen Sie keine neuen Funktionen hinzu."

# Schritt 4: Commit
claude -p "Erstellen Sie einen konventionellen Commit für alle gestagten Änderungen. Verwenden Sie 'feat: add OAuth2 login flow' als Nachricht."

Wichtige Designprinzipien

1. Jeder Schritt ist isoliert – Ein frischer Kontextfenster pro claude -p-Aufruf bedeutet keine Kontextüberlappung zwischen den Schritten.
2. Die Reihenfolge ist wichtig – Schritte werden nacheinander ausgeführt. Jeder baut auf dem Dateisystemzustand des vorherigen auf.
3. Negative Anweisungen sind gefährlich – Sagen Sie nicht „teste keine Typsysteme“. Fügen Sie stattdessen einen separaten Bereinigungsschritt hinzu (siehe Entschlampfungsmuster).
4. Exit-Codes propagieren – set -e bricht die Pipeline bei Fehlern ab.

Varianten

Mit Modell-Routing:

# Recherche mit Opus (tiefgehendes Denken)
claude -p --model opus "Analysieren Sie die Codebasis-Architektur und schreiben Sie einen Plan zum Hinzufügen von Caching..."

# Implementierung mit Sonnet (schnell, leistungsfähig)
claude -p "Implementieren Sie die Caching-Schicht gemäß dem Plan in docs/caching-plan.md..."

# Überprüfung mit Opus (gründlich)
claude -p --model opus "Überprüfen Sie alle Änderungen auf Sicherheitsprobleme, Race Conditions und Randfälle..."

Mit Umgebungskontext:

# Kontext über Dateien übergeben, nicht über die Aufforderungslänge
echo "Schwerpunkte: Auth-Modul, API-Ratenbegrenzung" > .claude-context.md
claude -p "Lesen Sie .claude-context.md für Prioritäten. Arbeiten Sie sie der Reihe nach ab."
rm .claude-context.md

Mit --allowedTools-Einschränkungen:

# Nur-Lese-Analyse-Durchlauf
claude -p --allowedTools "Read,Grep,Glob" "Auditieren Sie diese Codebasis auf Sicherheitslücken..."

# Nur-Schreib-Implementierungs-Durchlauf
claude -p --allowedTools "Read,Write,Edit,Bash" "Implementieren Sie die Korrekturen aus security-audit.md..."

---

2. NanoClaw REPL

ECCs integrierte persistente Schleife. Ein sitzungsbewusstes REPL, das claude -p synchron mit vollständigem Gesprächsverlauf aufruft.

# Standardsitzung starten
node scripts/claw.js

# Benannte Sitzung mit Fertigkeitskontext
CLAW_SESSION=my-project CLAW_SKILLS=tdd-workflow,security-review node scripts/claw.js

Wie es funktioniert

1. Lädt den Gesprächsverlauf aus ~/.claude/claw/{session}.md
2. Jede Benutzernachricht wird an claude -p mit dem vollständigen Verlauf als Kontext gesendet
3. Antworten werden an die Sitzungsdatei angehängt (Markdown-als-Datenbank)
4. Sitzungen bleiben über Neustarts hinweg erhalten

Wann NanoClaw vs. Sequenzielle Pipeline

Anwendungsfall	NanoClaw	Sequenzielle Pipeline
Interaktive Erkundung	Ja	Nein
Skriptgesteuerte Automatisierung	Nein	Ja
Sitzungspersistenz	Integriert	Manuell
Kontextakkumulation	Wächst pro Runde	Neu pro Schritt
CI/CD-Integration	Schlecht	Exzellent

Vollständige Details finden Sie in der Dokumentation des /claw-Befehls.

---

3. Unendliche Agentenschleife

Ein Zwei-Aufforderungssystem, das parallele Unteragenten für spezifikationsgesteuerte Generierung orchestriert. Entwickelt von disler (Quelle: @disler).

Architektur: Zwei-Aufforderungssystem

AUFFORDERUNG 1 (Orchestrator)          AUFFORDERUNG 2 (Unteragenten)
┌─────────────────────┐              ┌──────────────────────┐
│ Spezifikationsdatei  │              │ Vollständigen Kontext  │
│ analysieren          │              │ erhalten               │
│ Ausgabeverzeichnis   │  setzt ein   │ Zugewiesene Nummer     │
│ scannen              │────────────  │ lesen                   │
│ Iteration planen     │  N Agenten  │ Spezifikation genau    │
│ Kreative Richtungen  │              │ befolgen               │
│ zuweisen             │              │ Einzigartige Ausgabe   │
│ Wellen verwalten     │              │ generieren             │
│                      │              │ Im Ausgabeverzeichnis  │
│                      │              │ speichern              │
└─────────────────────┘              └──────────────────────┘

Das Muster

1. Spezifikationsanalyse – Der Orchestrator liest eine Spezifikationsdatei (Markdown), die definiert, was generiert werden soll
2. Verzeichnis-Erkundung – Scannt vorhandene Ausgaben, um die höchste Iterationsnummer zu finden
3. Parallele Bereitstellung – Startet N Unteragenten, jeder mit:
   • Der vollständigen Spezifikation
   • Einer eindeutigen kreativen Richtung
   • Einer bestimmten Iterationsnummer (keine Konflikte)
   • Einem Snapshot vorhandener Iterationen (zur Sicherstellung der Einzigartigkeit)
4. Wellenverwaltung – Im unendlichen Modus werden Wellen von 3-5 Agenten bereitgestellt, bis der Kontext erschöpft ist

Implementierung über Claude Code-Befehle

Erstellen Sie .claude/commands/infinite.md:

Parsen Sie die folgenden Argumente aus $ARGUMENTS:
1. spec_file – Pfad zur Spezifikations-Markdown-Datei
2. output_dir – Verzeichnis, in dem Iterationen gespeichert werden
3. count – Ganzzahl 1-N oder "infinite"

PHASE 1: Lesen und tiefgreifendes Verständnis der Spezifikation.
PHASE 2: Liste output_dir, finden Sie die höchste Iterationsnummer. Starten Sie bei N+1.
PHASE 3: Planen Sie kreative Richtungen – jeder Agent erhält ein ANDERES Thema/Ansatz.
PHASE 4: Setzen Sie Unteragenten parallel ein (Task-Tool). Jeder erhält:
  - Vollständigen Spezifikationstext
  - Aktuellen Verzeichnis-Snapshot
  - Ihre zugewiesene Iterationsnummer
  - Ihre eindeutige kreative Richtung
PHASE 5 (unendlicher Modus): Schleife in Wellen von 3-5, bis der Kontext niedrig ist.

Aufruf:

/project:infinite specs/component-spec.md src/ 5
/project:infinite specs/component-spec.md src/ infinite

Batching-Strategie

Anzahl	Strategie
1-5	Alle Agenten gleichzeitig
6-20	Batches von 5
unendlich	Wellen von 3-5, progressive Raffinesse

Kern-Einsicht: Einzigartigkeit durch Zuweisung

Verlassen Sie sich nicht darauf, dass Agenten sich selbst unterscheiden. Der Orchestrator weist jedem Agenten eine spezifische kreative Richtung und Iterationsnummer zu. Dies verhindert doppelte Konzepte über parallele Agenten hinweg.

---

4. Kontinuierliche Claude-PR-Schleife

Ein produktionsreifes Shell-Skript, das Claude Code in einer kontinuierlichen Schleife ausführt, PRs erstellt, auf CI wartet und automatisch zusammenführt. Erstellt von AnandChowdhary (Quelle: @AnandChowdhary).

Kernschleife

┌─────────────────────────────────────────────────────┐
│  KONTINUIERLICHE CLAUDE-ITERATION                    │
│                                                     │
│  1. Branch erstellen (continuous-claude/iteration-N) │
│  2. claude -p mit erweiterter Aufforderung ausführen  │
│  3. (Optional) Reviewer-Durchlauf – separater claude -p│
│  4. Änderungen committen (Claude generiert Nachricht) │
│  5. Pushen + PR erstellen (gh pr create)              │
│  6. Auf CI-Checks warten (poll gh pr checks)          │
│  7. CI-Fehler? → Auto-Fix-Durchlauf (claude -p)       │
│  8. PR zusammenführen (squash/merge/rebase)           │
│  9. Zurück zu main → wiederholen                      │
│                                                     │
│  Begrenzung durch: --max-runs N | --max-cost $X      │
│            --max-duration 2h | Abschlusssignal       │
└─────────────────────────────────────────────────────┘

Installation

Warnung: Installieren Sie continuous-claude von seinem Repository, nachdem Sie den Code überprüft haben. Leiten Sie keine externen Skripte direkt an bash weiter.

Verwendung

# Einfach: 10 Iterationen
continuous-claude --prompt "Füge Unit-Tests für alle ungetesteten Funktionen hinzu" --max-runs 10

# Kostenbegrenzt
continuous-claude --prompt "Behebe alle Linter-Fehler" --max-cost 5.00

# Zeitbegrenzt
continuous-claude --prompt "Verbessere die Testabdeckung" --max-duration 8h

# Mit Code-Review-Durchlauf
continuous-claude \
  --prompt "Füge Authentifizierungsfunktion hinzu" \
  --max-runs 10 \
  --review-prompt "Führe npm test && npm run lint aus, behebe alle Fehler"

# Parallel über Worktrees
continuous-claude --prompt "Füge Tests hinzu" --max-runs 5 --worktree tests-worker &
continuous-claude --prompt "Refaktoriere Code" --max-runs 5 --worktree refactor-worker &
wait

Kontext über Iterationen hinweg: SHARED_TASK_NOTES.md

Die entscheidende Neuerung: Eine SHARED_TASK_NOTES.md-Datei bleibt über Iterationen hinweg bestehen:

## Fortschritt
- [x] Tests für Auth-Modul hinzugefügt (Iteration 1)
- [x] Randfall bei Token-Aktualisierung behoben (Iteration 2)
- [ ] Noch erforderlich: Ratenbegrenzungstests, Fehlergrenztests

## Nächste Schritte
- Als nächstes auf das Ratenbegrenzungsmodul konzentrieren
- Das Mock-Setup in tests/helpers.ts kann wiederverwendet werden

Claude liest diese Datei zu Beginn der Iteration und aktualisiert sie am Ende. Dies überbrückt die Kontextlücke zwischen unabhängigen claude -p-Aufrufen.

CI-Fehlerbehebung

Wenn PR-Checks fehlschlagen, führt Continuous Claude automatisch Folgendes durch:

1. Abrufen der fehlgeschlagenen Run-ID über gh run list
2. Starten eines neuen claude -p mit CI-Fix-Kontext
3. Claude untersucht Logs über gh run view, behebt Code, commitet, pusht
4. Erneutes Warten auf Checks (bis zu --ci-retry-max Versuche)

Abschlusssignal

Claude kann „Ich bin fertig“ signalisieren, indem es einen magischen Satz ausgibt:

continuous-claude \
  --prompt "Behebe alle Fehler im Issue-Tracker" \
  --completion-signal "CONTINUOUS_CLAUDE_PROJECT_COMPLETE" \
  --completion-threshold 3  # Stoppt nach 3 aufeinanderfolgenden Signalen

Drei aufeinanderfolgende Iterationen, die den Abschluss signalisieren, stoppen die Schleife und verhindern unnötige Läufe bei abgeschlossener Arbeit.

Wichtige Konfiguration

Flag	Zweck
--max-runs N	Nach N erfolgreichen Iterationen stoppen
--max-cost $X	Nach Ausgabe von $X stoppen
--max-duration 2h	Nach verstrichener Zeit stoppen
--merge-strategy squash	squash, merge oder rebase
--worktree <name>	Parallele Ausführung über git Worktrees
--disable-commits	Trockenlauf-Modus (keine git-Operationen)
--review-prompt "..."	Reviewer-Durchlauf pro Iteration hinzufügen
--ci-retry-max N	CI-Fehler automatisch beheben (Standard: 1)

---

5. Das Entschlampfungsmuster

Ein Add-on-Muster für jede Schleife. Fügen Sie nach jedem Implementierungsschritt einen dedizierten Bereinigungs-/Refactoring-Schritt hinzu.

Das Problem

Wenn Sie ein LLM bitten, mit TDD zu implementieren, nimmt es „schreibe Tests“ zu wörtlich:

• Tests, die die Funktionsweise des TypeScript-Typsystems überprüfen (Testen von typeof x === 'string')
• Übermäßig defensive Laufzeitprüfungen für Dinge, die das Typsystem bereits garantiert
• Tests für Framework-Verhalten anstelle von Geschäftslogik
• Übermäßige Fehlerbehandlung, die den eigentlichen Code verschleiert

Warum keine negativen Anweisungen?

Das Hinzufügen von „teste keine Typsysteme“ oder „füge keine unnötigen Prüfungen hinzu“ zur Implementierungsaufforderung hat nachgelagerte Auswirkungen:

• Das Modell wird zögerlich bei ALLEN Tests
• Es überspringt legitime Randfalltests
• Die Qualität sinkt unvorhersehbar

Die Lösung: Separater Durchlauf

Anstatt den Implementierer einzuschränken, lassen Sie ihn gründlich arbeiten. Fügen Sie dann einen fokussierten Bereinigungsagenten hinzu:

# Schritt 1: Implementieren (lassen Sie es gründlich sein)
claude -p "Implementieren Sie die Funktion mit vollständigem TDD. Seien Sie gründlich bei Tests."

# Schritt 2: Entschlampfen (separater Kontext, fokussierte Bereinigung)
claude -p "Überprüfen Sie alle Änderungen im Arbeitsverzeichnis. Entfernen Sie:
- Tests, die Sprach-/Framework-Verhalten anstelle von Geschäftslogik überprüfen
- Redundante Typprüfungen, die das Typsystem bereits erzwingt
- Übermäßig defensive Fehlerbehandlung für unmögliche Zustände
- Console.log-Anweisungen
- Auskommentierten Code

Behalten Sie alle Geschäftslogiktests. Führen Sie die Testsuite nach der Bereinigung aus, um sicherzustellen, dass nichts kaputt geht."

Im Schleifenkontext

for feature in "${features[@]}"; do
  # Implementieren
  claude -p "Implementiere $feature mit TDD."

  # Entschlampfen
  claude -p "Bereinigungslauf: Änderungen überprüfen, Test-/Code-Schlampigkeit entfernen, Tests ausführen."

  # Überprüfen
  claude -p "Build + Lint + Tests ausführen. Fehler beheben."

  # Commit
  claude -p "Commit mit Nachricht: feat: füge $feature hinzu"
done

Kern-Einsicht

Anstatt negative Anweisungen hinzuzufügen, die nachgelagerte Qualitätseffekte haben, fügen Sie einen separaten Entschlampfungsdurchlauf hinzu. Zwei fokussierte Agenten sind besser als ein eingeschränkter Agent.

---

6. Ralphinho / RFC-gesteuerter DAG (Directed Acyclic Graph) Orchestrierung

Das anspruchsvollste Muster. Eine RFC-gesteuerte, Multi-Agenten-Pipeline, die Aufgaben in einem gerichteten azyklischen Graphen organisiert. Entwickelt von Ralphinho (Quelle: @Ralphinho). Dieses Muster eignet sich für große Funktionen, die mehrere unabhängige, aber koordinierte Arbeitseinheiten erfordern.

Architektur

┌─────────────────────────────────────────────────────────────┐
│  RFC-GESTEUERTER DAG                                              │
│                                                             │
│  1. RFC erstellen – Spezifikation für die gesamte Funktion    │
│  2. Aufgaben aus RFC ableiten – Unabhängige Arbeitseinheiten │
│  3. Abhängigkeitsgraph erstellen – DAG der Aufgaben           │
│  4. Parallele Ausführung – Aufgaben ohne Abhängigkeiten       │
│  5. Merge-Queue – Ergebnisse sequenziell zusammenführen       │
│  6. Validierung – Gesamte Funktion testen                     │
└─────────────────────────────────────────────────────────────┘

Implementierung

Dieses Muster erfordert in der Regel ein benutzerdefiniertes Skript oder eine Integration mit einem Workflow-Manager. Das grundlegende Prinzip ist jedoch:

1. RFC-Erstellung: Ein menschlicher oder KI-Entwickler erstellt ein RFC-Dokument (Markdown), das die vollständige Funktionsspezifikation, Akzeptanzkriterien und architektonische Entscheidungen enthält.
2. Aufgabenableitung: Der Orchestrator analysiert das RFC und leitet unabhängige Aufgaben ab (z. B. „Frontend-Komponente A implementieren“, „Backend-API B implementieren“, „Tests für C schreiben“).
3. Abhängigkeitsgraph: Jede Aufgabe erhält Abhängigkeiten (z. B. müssen Tests auf der Backend-API aufbauen).
4. Parallele Ausführung: Aufgaben ohne Abhängigkeiten werden parallel von separaten Claude-Instanzen ausgeführt.
5. Merge-Queue: Ergebnisse werden sequenziell gemäß dem DAG zusammengeführt, um Konflikte zu vermeiden.
6. Validierung: Die integrierte Funktion wird gründlich getestet.

Wann verwenden

• Große Funktionen mit mehreren unabhängigen Komponenten
• Teams, die parallele Arbeit orchestrieren müssen
• Szenarien, in denen die sequenzielle Ausführung zu langsam ist
• Wenn eine strikte Trennung von Belangen in der KI-gesteuerten Entwicklung erforderlich ist

Einschränkungen

• Erfordert erhebliche Einrichtung und Orchestrierungslogik
• Möglicherweise nicht für kleine Funktionen oder einmalige Aufgaben geeignet
• Merge-Konflikte können trotz DAG-Planung auftreten
• Hängt stark von der Qualität des RFC ab

---

Anti-Patterns und häufige Fehler

1. Zu lange Aufforderungen – Halten Sie Aufforderungen fokussiert. Verwenden Sie Dateien für Kontext, nicht Aufforderungslänge.
2. Negative Anweisungen – Vermeiden Sie „nicht“ in Implementierungsaufforderungen. Verwenden Sie stattdessen separate Bereinigungsschritte.
3. Fehlende Fehlerbehandlung – Verwenden Sie set -e und Exit-Codes in Pipelines.
4. Übermäßiges Vertrauen auf ein einziges Modell – Routen Sie Aufgaben zu verschiedenen Modellen basierend auf Stärken (Opus für Überprüfung, Sonnet für schnelle Implementierung).
5. Ignorieren des Kontextfensters – Lange Schleifen können Kontextgrenzen erreichen. Verwenden Sie SHARED_TASK_NOTES.md oder ähnliche Muster für persistierten Kontext.

Abschluss

Diese Fertigkeit bietet eine umfassende Sammlung von Mustern für die Ausführung von Claude Code in autonomen Schleifen. Die Wahl des richtigen Musters hängt von Ihrem spezifischen Anwendungsfall, der erforderlichen Komplexität und dem gewünschten Automatisierungsgrad ab. Für die meisten neuen Workflows wird die Verwendung von continuous-agent-loop anstelle von autonomous-loops empfohlen.