Autonome Agent-Loops: wie die KI von allein arbeitet

Was ein autonomer Agent-Loop ist, einfach erklärt

Stell dir einen Saugroboter vor. Du führst den ja nicht an der Hand durchs Zimmer, oder? Knopf gedrückt - und er dreht selbst seine Runden: fährt los, stößt an die Wand, dreht um, fährt weiter. Und das so lange, bis alles sauber ist oder der Akku leer.

Genau das ist ein autonomer Loop Ein autonomer Loop ist, wenn der Agent von allein, ohne dein Zutun, immer wieder dieselbe Schrittfolge wiederholt, bis die Aufgabe erledigt ist oder er gegen ein Limit läuft. für den Agenten. Du sitzt nicht daneben und diktierst hundertmal „jetzt mach die Tests“, „jetzt fix das“, „jetzt committe“. Einmal die Runde beschrieben, die er drehen soll, Knopf gedrückt - fertig. Danach dreht der Agent seine Runden von allein.

Wozu braucht ein Vibecoder einen Agenten, der von allein arbeitet

Du bist Vibecoder. Wozu brauchst gerade du einen Agenten, der ohne Aufsicht ackert? Vier Gründe.

• Zeit. Die langweilige Routine - Tests, Aufräumen, kleine Fixes - macht der Agent nachts. Und du schaust dir morgens beim Kaffee das Ergebnis an.
• Umfang. Mit einer einzigen Aufgabe „füg Tests zu allen Funktionen hinzu“ deckst du das ganze Projekt auf einen Schlag ab. Du musst den Agenten nicht für jede Funktion einzeln von Hand anstoßen.
• Geld unter Kontrolle. Ein gesunder Loop hat ein Budget-Limit. Er stoppt von allein, statt dir eine Rechnung über das halbe Projekt zu generieren.
• Qualität. In den Loop baut man Prüfungen ein: Der Agent lässt selbst die Tests laufen, bessert selbst nach und speichert erst dann.

Es gibt auch eine Kehrseite. Ein Agent ohne Aufsicht kann sich im Leerlauf drehen, dasselbe im Kreis fixen oder seelenruhig das ganze Budget verbrennen. Deshalb musst du verstehen, wie der Loop von innen aufgebaut ist. Sonst ist das kein Helfer, sondern ein festgefahrener Saugroboter, der die ganze Nacht dieselbe Ecke poliert.

Arten autonomer Loops: von simpel bis komplex

Loops gibt es in verschiedenen „Leistungsstufen“. Du musst nicht gleich ein Raumschiff bauen - fast alles deckt schon die einfachste Art ab.

Pipeline: eine Kette aus einzelnen Agent-Läufen

Die einfachste und zugleich praktischste Art. Du nimmst eine große Aufgabe, schneidest sie in Schritte und startest den Agenten für jeden Schritt einzeln. Die klassische Kette für ein Feature:

1. Mach - schreib den Code nach Beschreibung.
2. Räum auf - wirf Überflüssiges raus: Müll-Prüfungen, Debug-Krempel.
3. Prüf - lass Build, Linter und Tests laufen, fix, was fehlgeschlagen ist.
4. Speicher - mach einen Commit mit verständlicher Nachricht.

Multi-Agent-Loops: wenn es viele Aufgaben gibt und sie zusammenhängen

Das Feature ist groß und zerfällt in Brocken, die ineinandergreifen? Dann gibt es ernstere Loops. Da teilt der Agent die Aufgabe selbst in Teile, startet mehrere „Arbeiter“ parallel, fügt danach die Ergebnisse sauber zusammen und löst Konflikte auf.

Klingt mächtig. Aber als Einsteiger brauchst du das fast nie. Behalt einfach im Kopf: sowas existiert. Geh es an, wenn du an die Grenzen der simplen Pipeline stößt, und keine Sekunde früher.

Brücken-Datei: wie der Agent den Fortschritt zwischen den Runden behält

Und hier ist die Hauptfalle. In der Pipeline ist jeder Lauf eine neue Session mit leerem Tisch. Der Agent im Schritt „fix“ weiß nicht mehr, was er selbst im Schritt „mach“ geschrieben hat. Für ihn ist es wie der erste Arbeitstag.

Die Lösung ist genial einfach: die Brücken-Datei. Am Ende jedes Schritts schreibt der Agent in eine ganz normale Datei (oft heißt sie SHARED_TASK_NOTES.md), was erledigt ist und was noch aussteht. Und zu Beginn der nächsten Runde liest er sie als Erstes. Das war’s.

So sieht der Notizblock ungefähr aus - einfach Text in einer Datei:

• Erledigt: Tests für das Auth-Modul hinzugefügt.
• Erledigt: Bug beim Token-Refresh gefixt.
• Offen: Tests für Request-Limits, Tests für Fehlerfälle.
• Notiz: Den Mock aus tests/helpers kann man wiederverwenden.

Notbremse: wie du mit einem autonomen Agenten nicht dein Budget verbrennst

Ein Loop dreht per Definition von allein. Also muss jemand ihm „genug“ sagen. Besser, du bist das jetzt - und nicht dein Geldbeutel um drei Uhr nachts. Jeder autonome Loop muss ein Limit haben. Es gibt vier Arten, und du kannst gleich mehrere setzen:

• Nach Anzahl - „mach maximal 10 Runden und Stopp“.
• Nach Geld - „hör auf, wenn du 5 Dollar ausgegeben hast“.
• Nach Zeit - „arbeite nicht länger als 8 Stunden“.
• Signal „ich bin fertig“ - der Agent sagt selbst ein Codewort, wenn die Arbeit erledigt ist, und der Loop schaltet sich aus.

Vor- und Nachteile des autonomen Loops

Verbiete dem Agenten nichts - füg einen eigenen Aufräum-Schritt hinzu

Ein häufiger Einsteigerfehler: einen Berg „mach das nicht“, „schreib nichts Überflüssiges“, „fass das nicht an“ in den Prompt zu stopfen. Von einem Stapel Verbote wird der Agent ängstlich und fängt überall an zu pfuschen - selbst da, wo man sich hätte Mühe geben müssen.

Der funktionierende Kniff ist ein anderer. Im Schritt „mach“ soll der Agent mit Herzblut und gründlich arbeiten. Und den ganzen Müll danach sammelt ein eigener Aufräum-Schritt mit frischem Tisch ein. Zwei fokussierte Agenten - einer macht, der andere räumt auf - schlagen einen einzigen, der in ein Korsett aus Verboten gepresst ist.

Beispiel: wie du das Projekt über Nacht mit Tests abdeckst

Sagen wir, du willst, dass der Agent über Nacht das ganze Projekt mit Tests abdeckt. Schreibst du einfach „füg überall Tests hinzu“ und gehst schlafen? Dann riskierst du, morgens entweder Chaos oder eine Rechnung über das halbe Budget zu sehen. Ein Vibecoder, der’s versteht, beschreibt den Loop mit Brücke und Notbremse. Etwa so:

Arbeite im Modus eines autonomen Loops: füg dem Projekt Tests hinzu, bis du alle Funktionen ohne Tests abgedeckt hast.
Loop-Regeln:

Lies zu Beginn jeder Runde die Datei SHARED_TASK_NOTES.md. Wenn es sie nicht gibt - leg sie an. Hol dir daraus die Liste, was schon erledigt ist und was noch aussteht.
Nimm pro Runde EIN Modul. Schreib die Tests gründlich.
Räum als eigene Aktion das Überflüssige weg: Müll-Prüfungen, Debug-Ausgaben. Lass die Tests laufen und fix, falls etwas fehlgeschlagen ist.
Schreib am Ende der Runde in SHARED_TASK_NOTES.md, was du gemacht hast und was noch aussteht.
Notbremse: mach maximal 8 Runden. Wenn alle Module früher abgedeckt sind - schreib die Zeile ARBEIT ABGESCHLOSSEN und hör auf.
Wenn derselbe Test zwei Runden hintereinander fehlschlägt - wiederhol nicht blind, beschreib die Ursache in den Notizen und geh zum nächsten Modul über.

Der Loop ist falsch abgebogen: Debug-Checkliste

Den Agenten im Loop gelassen und Chaos vorgefunden? Ganz ruhig. Geh die Checkliste durch:

1. Gab es eine Notbremse? Keine Limits - setz sie als Erstes.
2. Gibt es eine Brücke? Ohne Fortschritts-Datei vergisst der Agent das Erledigte und macht es neu.
3. Hat er den Reinfall wiederholt? Schlägt derselbe Schritt Runde für Runde fehl, muss der Fehlertext in die nächste Runde durchgereicht werden - nicht ein nacktes „versuch’s nochmal“.
4. Hat er alles auf einen Tisch gekippt? Lange Schritte zerlegt man besser in einzelne Läufe mit frischem Kontext.
5. Gab es Verbote statt Aufräumen? Ersetz „mach X nicht“ durch einen eigenen Aufräum-Schritt.

Häufige Einsteigerfehler bei autonomen Loops

• Loop ohne Notbremse. Das Schlimmste. Setz immer ein Limit nach Runden, Geld oder Zeit.
• Keine Brücken-Datei. Der Agent vergisst den Fortschritt zwischen den Runden und dreht sich buchstäblich im Kreis.
• Blinde Wiederholung des Reinfalls. Schritt fehlgeschlagen - reich den Fehlertext weiter, nicht einfach „los, von vorn“.
• Riesenaufgabe in einer Runde. Schneid in kleine Schritte à ein Modul oder eine Datei.
• Verbote statt Aufräumen. „Mach X nicht“ bricht den Agenten - füg einen eigenen Aufräum-Schritt hinzu.
• Alles in einem Kontext. Bei ernsten Loops verteil die Schritte auf einzelne Läufe mit frischem Tisch.