Autonomer KI-Agent: wie Sie ihn stundenlang arbeiten lassen, ohne Müll zu bekommen

Was ein autonomer KI-Agent ist und worin er sich von einer normalen Anfrage unterscheidet

Bei der üblichen Arbeit mit einem Agenten geht es Schritt für Schritt: Sie schreiben einen Prompt, der Agent führt einen Schritt aus, Sie prüfen das Ergebnis und entscheiden, wie es weitergeht. Ein autonomer KI-Agent arbeitet dagegen in einer Schleife. Sie beschreiben einmal, wie der Endzustand aussieht, und danach wiederholt der Agent selbst den Ablauf »ausführen — prüfen — korrigieren«, bis das Ziel erreicht ist oder das Budget aufgebraucht. Nach dem Start können Sie den Rechner verlassen.

Das klingt einfach, doch die typische erste Erfahrung sieht so aus: Der Agent bekommt die Aufgabe am Morgen, und am Abend stellt sich heraus, dass er stundenlang einen bereits behobenen Fehler korrigiert hat, weil er vergessen hat, was er eine Stunde zuvor getan hat. Niemand hat ihm gesagt, wann er aufhören und wann er einen Menschen fragen soll. Im Folgenden lesen Sie, wie Sie eine Schleife entwerfen, die das verhindert.

Eine wichtige Einschränkung: Die Schleife ersetzt das Harness nicht. Das Harness macht einen einzelnen Lauf verlässlich, die Schleife macht die Läufe fortlaufend. Eine Schleife über einem schwachen Harness erzeugt nur schneller Müll.

Eignet sich die Aufgabe für einen autonomen Agenten?

Die erste Frage lautet, ob die Arbeit eine Ziellinie hat, die sich maschinell prüfen lässt. »Alle Tests im Verzeichnis tests/payments laufen durch«, »alle Features aus der Liste stehen auf passing«, »die Metrik ist gegenüber der Ausgangslinie gestiegen« — das passt. »Mach den Code besser« oder »verbessere die Zahlungen weiter« passt nicht: Ein solches Ziel hat kein Ende, und die Schleife dreht sich, bis das Budget verbraucht ist.

Es lohnt sich, vier Arten von Schleifen zu unterscheiden:

• Schrittweise — Sie geben jeden Prompt selbst ein; das ist die normale interaktive Arbeit.
• Zielgesteuert — Sie setzen ein Ziel, angehalten wird durch eine unabhängige Prüfung oder ein Budget. Genau das ist der autonome Agent für Stunden.
• Zeitgesteuert — Start nach Zeitplan (zum Beispiel eine morgendliche Analyse fehlgeschlagener CI-Builds), Sie stoppen manuell.
• Ereignisgesteuert — ein externer Auslöser (ein neues Issue, ein fehlgeschlagenes Deployment) startet die Arbeit, die Verarbeitung des Ereignisses oder ein Wiederholungslimit beendet sie.

Ein häufiger Fehler ist, die zeitgesteuerte mit der zielgesteuerten Schleife zu verwechseln: »Alle zehn Minuten weiter an den Zahlungen arbeiten.« Eine Schleife nach Zeitplan beginnt jedes Mal mit der Anweisung von vorn und weiß nicht, was bereits erledigt ist. Hat eine Aufgabe ein Ende, brauchen Sie eine zielgesteuerte Schleife mit einem Gedächtnis für den Fortschritt.

Schritt 1. Sandbox: Wo der Agent Fehler machen darf

Ein Agent ohne Aufsicht wird früher oder später etwas Falsches tun: eine Datei löschen, eine Migration überschreiben, einen schweren Befehl starten. Die Frage lautet deshalb nicht, wie Sie verhindern, dass er sich irrt, sondern wie Sie erreichen, dass ein Fehler nichts kostet.

• Eine eigene Arbeitskopie. git worktree gibt dem Agenten ein eigenes Verzeichnis und einen eigenen Branch im selben Repository. Der Hauptbranch bleibt unberührt, mehrere Agenten stören sich nicht, und ein missglückter Lauf wird mit einem Befehl entfernt.
• Container oder virtuelle Maschine. Braucht der Agent vollen Zugriff auf Befehle, starten Sie ihn in einem Container ohne Zugriff auf das Home-Verzeichnis, Schlüssel und Produktionsdatenbanken.
• Testdaten. Lokale Datenbank, Sandbox-Umgebungen der Zahlungsanbieter, Scheinschlüssel. Kein einziges Produktionsgeheimnis in der Umgebung des Agenten.

# eigener Branch und eigenes Verzeichnis für den autonomen Lauf
git worktree add ../shop-agent -b agent/f03-refunds

# nach dem Lauf: Ergebnis ansehen oder verwerfen
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Schritt 2. Rechte: so wenig wie für die Aufgabe nötig

Je länger ein Agent allein arbeitet, desto enger müssen seine Rechte sein. In Claude Code werden Berechtigungen in der settings.json festgelegt (Listen allow und deny für Werkzeuge und Befehle). Erlauben Sie explizit, was die Aufgabe braucht — Tests starten, den Linter laufen lassen, Dateien in der Arbeitskopie bearbeiten —, und verbieten Sie das Gefährliche: Push in den Hauptbranch, Zugriff auf Geheimnisse, Netzwerkbefehle, sofern sie nicht gebraucht werden.

Ein Modus, in dem der Agent alles ohne Bestätigung ausführt, ist nur in einer isolierten Sandbox vertretbar, in der das schlimmste Ergebnis ein weggeworfener Container ist. Auf einem Arbeitsrechner mit Zugriff auf Ihre Schlüssel und Repositories ist das keinesfalls zulässig.

Verbote, die nicht verletzt werden dürfen, sollten Sie mit Mechanik absichern, nicht mit Text. Der Satz »Fass migrations/ nicht an« in einer Anweisung ist ein Wunsch; ein Hook, der Änderungen in diesem Verzeichnis blockiert, oder die Dateisystemrechte sind eine Garantie.

Schritt 3. Ziel, Prüfung, Stopp — drei Zeilen vor dem Start

Ein einfacher funktionierender Zyklus steht auf drei Dingen, die Sie vor dem Start festhalten sollten, nicht unterwegs:

1. Ziel — wie der Endzustand aussieht.
2. Verifikation — eine maschinell prüfbare Möglichkeit festzustellen, dass das Ziel erreicht ist: ein Befehl, der Erfolg oder Fehler zurückgibt.
3. Stoppbedingung — eine Grenze für Versuche, Zeit oder Geld, nach der der Zyklus endet, auch wenn das Ziel nicht erreicht ist.

Praktisch ist eine separate Methodikdatei, die nur ein Mensch bearbeitet. Ein Beispiel für ein Zahlungs-Backend:

# program.md — Methodik des autonomen Laufs

## Ziel
Alle Features in .agent/feature_list.json stehen auf passing.

## Metrik
Anzahl der Features auf passing. Sie steigt nur. Regression = sofortiger Rollback.

## Einschränkungen
- Ein Feature gleichzeitig in Arbeit.
- migrations/ und infra/ nicht ändern.
- Abhängigkeiten nur mit Eintrag im Journal ändern.

## Arbeitsablauf
1. Das erste Feature nehmen, das nicht auf passing steht.
2. Umsetzen, pytest und Linter laufen lassen.
3. Grün — Commit und Eintrag in .agent/progress.md. Rot — korrigieren.

## Stopp und Eskalation
- 3 gescheiterte Versuche bei einem Feature — als blocked markieren, zum nächsten wechseln.
- Alle verbleibenden Features blocked — anhalten und einen Bericht schreiben.
- Aufgaben zu Geld der Kunden, Zugriffsrechten oder Datenlöschung — nicht ausführen, sondern eskalieren.

Schritt 4. Schleife aus Prüfen und Korrigieren mit Gedächtnis auf der Festplatte

Das Kontextfenster übersteht lange Arbeit nicht: Es läuft voll, wird komprimiert, die Sitzung startet neu. Deshalb muss der Fortschritt in Dateien leben und nicht im »Kopf« des Agenten: eine Aufgabenliste mit Status, ein Journal dessen, was getan wurde und was nicht funktioniert hat, und die Git-Historie.

Ein gutes Modell ist die »Ratsche, die sich nur vorwärts bewegt«, wie im Projekt autoresearch von Andrej Karpathy, in dem ein Agent über Nacht Hunderte von ML-Experimenten durchführt. Jede Iteration: Methodik lesen, eine Hypothese aufstellen, eine Änderung vornehmen, das Experiment mit festem Zeitbudget laufen lassen, mit der Ausgangslinie vergleichen. Hat es verbessert — Commit, hat es nicht verbessert — Rollback. Das Ergebnis geht ins Journal, dann folgt die nächste Hypothese.

Zwei Entscheidungen aus diesem Schema lohnen sich:

• Festes Budget pro Versuch. Die Versuche werden vergleichbar, und eine gescheiterte Hypothese frisst nicht die ganze Nacht.
• Im Hauptbranch nur Verbesserungen. Alles, was nicht funktioniert hat, wird zurückgerollt und nicht daneben abgelegt. Das git log wird zu einem geprüften Arbeitsjournal, das man am Morgen leicht lesen kann.

Dasselbe Schema zeigt die Aufteilung der Rollen nach Dateien: Die Infrastruktur und die Bewertung ändert niemand, den Code des Experiments ändert nur der Agent, die Methodik nur der Mensch. So kann der Agent das Ergebnis nicht »verbessern«, indem er die Messung verbiegt.

Schritt 5. Wer entscheidet, dass es fertig ist: ein separater Prüfer

Wenn kein Mensch mehr in der Schleife sitzt, wird die Selbsteinschätzung des Agenten zur einzigen Bremse — und diese Bremse wirkt nicht. Ein Agent, der gerade Code geschrieben hat, hält ihn eher für richtig: Er sieht seine eigenen Überlegungen und »weiß«, was er bezwecken wollte.

Regeln für die Trennung von Erzeuger und Prüfer:

• Die Arbeit prüft nicht die Sitzung, die sie erledigt hat. In Claude Code eignen sich dafür Subagenten: Jeder hat seinen eigenen Kontext.
• Der Prüfer bekommt einen sauberen Kontext: die Anforderung, den Diff und die Ergebnisse der Läufe — und nichts aus den Überlegungen des Ausführenden.
• Nach Möglichkeit ist der Prüfer ein anderes Modell oder zumindest ein anderer Prompt mit einer anderen Rolle.
• Das Urteil fällt nach einer Bewertungsmatrix, und jeder Punkt verweist auf einen Beleg: eine Testzeile, die Ausgabe eines Befehls, eine Stelle im Diff.

Die maschinellen Prüfungen bleiben trotzdem das Erste. Der Prüfer wird für das gebraucht, was Tests nicht erkennen: Die Anforderung wurde falsch verstanden, der Test wurde an den Code angepasst, die Änderung ist über den Auftrag hinausgegangen.

Stoppkriterien: Wann der Agent aufgeben muss

Eine Schleife ohne Stoppbedingungen dreht sich — nur eine Frage der Zeit. Das Minimum sind folgende Kriterien:

Prüfen Sie den Fortschritt inhaltlich, nicht an der Zahl der Versuche: »40 Iterationen erledigt« sagt nichts, »die Zahl der grünen Features stieg von 5 auf 9« sagt etwas. Wenn eine Aufgabe festhängt, ist das ein Grund, sie einem Menschen zu übergeben, und kein Grund, die Schleife noch einmal laufen zu lassen.

Risiken des autonomen Agenten, die nicht sofort sichtbar sind

Die offensichtlichen Risiken — gelöschte Dateien und ein kaputter Build — fängt die Sandbox mit den Rechten ab. Gefährlicher sind die stillen Kosten, die sich über Wochen ansammeln:

• Verifikationsschuld. »Sieht normal aus« statt »maschinell bestätigt«. Dagegen hilft nur eine maschinell prüfbare Stoppbedingung, ohne Ausnahmen.
• Verlust des Verständnisses. Sie kennen Ihren eigenen Code immer schlechter. Dagegen hilft das verpflichtende Lesen der Diffs: Das Tempo der Schleife darf nicht schneller sein als Ihr Lesen.
• Kognitive Kapitulation. Sie haben keine Meinung mehr zum Ergebnis und nehmen alles hin. Zählen Sie ehrlich die Fälle mit »schaue ich später« und die, bei denen Sie nicht geschaut haben.
• Aufblähen des Kontexts. Ein langer Lauf sammelt Verlauf an, und jeder weitere Schritt wird teurer und schlechter. Kontextkomprimierung und externes Gedächtnis brauchen Sie ab dem ersten Zyklus, nicht erst, wenn alles schon aus dem Ruder gelaufen ist.

Wie Sie den ersten autonomen Zyklus an einem Abend starten

Beginnen Sie nicht mit »Der Agent findet die Aufgaben selbst und erledigt sie«. Autonomie wächst in Stufen: zuerst eine Aufgabe mit Ziel und Stoppbedingung, dann eine Automatisierung nach Zeitplan, dann getrennte Ausführung und Prüfung in einer isolierten Arbeitskopie, und erst danach Schleifen, die die Arbeit selbst finden und parallel laufen.

1. Wählen Sie eine Aufgabe, die Sie mindestens zweimal pro Woche von Hand erledigen und die ein prüfbares Ende hat.
2. Schreiben Sie Ziel, Verifikation und Stoppbedingung auf — drei Zeilen.
3. Legen Sie einen eigenen Worktree an und richten Sie die Rechte ein: Tests und Dateibearbeitung erlaubt, Push und Geheimnisse nicht.
4. Legen Sie eine Fortschrittsdatei an und bitten Sie den Agenten, sie nach jeder Iteration zu aktualisieren.
5. Trennen Sie die Rollen: Der Ausführende schreibt, der Prüfer bewertet den Diff in einem eigenen Kontext.
6. Setzen Sie eine Gesamtgrenze und prüfen Sie das erste Ergebnis nach einer Stunde, nicht erst am Morgen.

Fazit

Ein autonomer KI-Agent ist genau so verlässlich wie sein Rahmen: eine Sandbox, in der ein Fehler nichts kostet, minimale Rechte, ein maschinell prüfbares Ziel, ein Gedächtnis auf der Festplatte, ein separater Prüfer und harte Stoppbedingungen mit Eskalation an einen Menschen. Ohne das ist ein langer Lauf keine Zeitersparnis, sondern die spätere Aufräumarbeit an einem Scherbenhaufen. Wie Sie eine solche Schleife an einem durchgehenden Projekt aufbauen — vom program.md bis zum unabhängigen Prüfer — wird im Kurs zum Harness Engineering praktisch behandelt.