Was ist Loop Engineering? Definition und Erklärung

Was Loop Engineering bedeutet

Loop Engineering bezeichnet die Gestaltung des wiederkehrenden Zyklus, in dem ein KI-Agent arbeitet: wodurch er aktiviert wird, worauf er zugreifen darf, wie seine Ausgabe geprüft wird und wodurch er stoppt. Prompt Engineering gestaltet eine einzelne Nachricht an ein Modell. Loop Engineering gestaltet den Prozess, der Tausende Nachrichten sendet, während Sie schlafen. Die Arbeitseinheit verschiebt sich vom Prompt zum Loop.

Kurz gesagt: Sie schreiben nicht mehr nur Anweisungen, sondern ein Steuerungssystem. Der Agent benötigt weiterhin gute Anweisungen. Sie werden jedoch zu einer Komponente innerhalb eines Zyklus, der nach einem Zeitplan ausgeführt wird, in einer isolierten Kopie Ihres Codes arbeitet, sein eigenes Ergebnis mit einem Test nachweist und abbricht, sobald ein Budget aufgebraucht ist.

Warum der Begriff 2026 aufkam

Der Begriff wird derzeit öffentlich festgelegt. Das GitHub-Repository cobusgreyling/loop-engineering erreichte innerhalb von zwei Monaten nach seinem ersten Erscheinen 9,600 Sterne (Stand: Juli 2026) und verwendet die Zeile „Keine Prompts mehr. Entwerfen Sie die Schleife. Erreichen Sie eine Bewertung.“ Es fasst den Wandel in sechs Bausteinen zusammen: Scheduling, Worktrees, Skills, Plugins und Connectoren, Sub-Agents sowie dauerhafter Speicher außerhalb der Unterhaltung.

Darin wird Boris Cherny zitiert, der Claude Code bei Anthropic leitet:

Ich verwende keine Prompts mehr für Claude. Ich habe Schleifen laufen, die Prompts für Claude ausführen.

Ein zweites Repository, AI-Builder-Club/skills, liegt bei etwa 1,100 Sternen (Stand: Juli 2026) und benennt die beiden Rollen direkt: ein „Codebase-Harness“, das ein Repository für einen Agenten sicher für das Ausführen von Tests und Deployments macht, und ein „Loop Engineer“, der Workflows erstellt, die durch einen Trigger aktiviert werden, die Aufgabe ausführen und ihre Erkenntnisse in eine gemeinsam genutzte Datei schreiben, damit die nächste Schleife sie lesen kann.

Keines der beiden Repositories hat diese Praxis erfunden. Wer bereits einen nächtlichen Build, einen Linter in Continuous Integration oder einen Cronjob ausgeführt hat, der ein Ticket erstellt, kennt das Grundmuster. Neu ist, dass der Worker innerhalb der Schleife nun nicht deterministisch arbeitet. Dadurch ändern sich die Anforderungen an die umgebende Infrastruktur.

Die vier Teile einer Schleife

Jede funktionierende Schleife besteht aus diesen vier Teilen. Eine Schleife, bei der einer davon fehlt, weckt Sie um 3am.

• Auslöser. Das Ereignis, das einen Lauf startet: ein Timer, ein Webhook, ein neuer Pull Request oder ein Alert.
• Grenze. Die Dateien, Zugangsdaten und das Netzwerk, auf die der Agent während dieses Laufs zugreifen darf.
• Überprüfung. Eine Prüfung mit einem Exit-Code, der entscheidet, ob die Ausgabe des Laufs behalten oder verworfen wird.
• Budget. Das Limit für Token, Zeit und Kosten, das einen Lauf beendet, unabhängig davon, ob er erfolgreich war.

Lesen Sie diese vier Punkte als Fragen. Damit haben Sie eine Designprüfung für jeden Agenten, den Sie unbeaufsichtigt laufen lassen möchten.

Auslöser: Was den Agenten startet

Ein Timer ist der einfachste Auslöser. Auf einem Linux-Server ist ein systemd-Timer dafür besser geeignet als cron. Er protokolliert Ausführungen, führt Wiederholungen nach Ihren Vorgaben durch und startet keine zweite Instanz einer noch laufenden Unit. Diese letzte Eigenschaft verhindert den häufigsten Fehler bei Agentenschleifen: Zwei Ausführungen bearbeiten denselben Branch.

Schreiben Sie die Unit nach /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

Und den Timer nach /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers sollte eine Spalte NEXT mit einem zukünftigen Zeitpunkt und eine Spalte LEFT mit einem Countdown anzeigen. Ein leeres Ergebnis bedeutet, dass der Timer nicht aktiviert ist, weil enable ohne --now ihn nur für den nächsten Systemstart plant. TimeoutStartSec=1800 ist wichtiger, als es zunächst scheint: Ein Agent, der auf Eingaben wartet, würde die Unit sonst dauerhaft aktiv halten, und der Timer würde nie wieder ausgelöst. Lesen Sie eine Ausführung mit journalctl -u agent-loop.service -n 50.

Wenn Sie die Schleife stattdessen über cron steuern, fügen Sie eine eigene Sperre gegen überlappende Ausführungen hinzu, da cron problemlos eine zweite Instanz starten kann:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n wird sofort mit dem Status 1 beendet, wenn die Sperre gehalten wird. Dadurch wird die zweite Ausführung still beendet, anstatt mit der ersten zu konkurrieren. Dieselbe systemd-Service- und Timer-Konfiguration gilt für jeden lang laufenden Job auf dem System, unabhängig davon, ob es sich um einen Agenten handelt.

Abgrenzung: Jeder Lauf erhält eine eigene Kopie

Ein Agent, der Ihren Arbeitsbaum bearbeitet, kann nicht festgeschriebene Änderungen verlieren. Git worktrees lösen dieses Problem mit geringem Aufwand: Jeder Lauf erhält ein eigenes Verzeichnis und einen eigenen Branch. Alle verwenden denselben Object Store.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list gibt für jeden Tree eine Zeile mit Pfad, Commit und Branch aus. Wenn der Lauf endet, löscht git worktree remove /srv/agent/work/triage-01 das Verzeichnis, und git worktree prune entfernt Einträge, deren Verzeichnis nicht mehr vorhanden ist. Parallele Schleifen sind damit sicher, weil zwei Agenten in zwei Branches und zwei Verzeichnissen einander nicht überschreiben können.

Die Abgrenzung betrifft auch Zugangsdaten. Eine unbeaufsichtigte Schleife verwendet langlebige Tokens, und jeder Lauf kann dazu führen, dass ein Token in ein Log, einen Commit oder einen Modellkontext gelangt. Beschränken Sie das Token auf das eine Repository, auf das die Schleife zugreift. Halten Sie es nach Möglichkeit aus der Umgebung der Shell fern, die der Agent selbst sieht. Lesen Sie wie Sie Geheimnisse von AI agents fernhalten, bevor Sie einer Schleife Zugriff auf Produktionssysteme geben. Für eine noch stärkere Trennung führen Sie die gesamte Schleife auf einer verwerfbaren VM aus, die Sie nach jedem Lauf zerstören können.

Verifizierung: Das Gate, das die Schleife sicher macht

Dies ist der Teil, der eine Schleife von einem Cronjob unterscheidet, der Eingaben simuliert. Die Ausgabe des Agenten ist ein Vorschlag. Das Gate entscheidet.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail leistet in diesem Script echte Arbeit. Ohne -e wird ein fehlgeschlagenes git fetch ignoriert, und die Ausführung wird mit einem veralteten origin/main fortgesetzt. Ohne -u wird ein Tippfehler in einem Variablennamen zu einer leeren Zeichenfolge ausgewertet. Die Bereinigung läuft dann mit dem falschen Pfad, statt sofort mit einem Fehler abzubrechen.

Der Block if ! npm test enthält die gesamte Idee. Der Exit-Code einer Prüfung, der Sie bereits vertrauen, Ihrer Testsuite oder Ihres Typecheckers, entscheidet, ob der Branch gepusht oder verworfen wird. Eine Schleife ohne Gate erzeugt Arbeit, für deren Prüfung niemand Zeit hat. Das ist schlechter als keine Arbeit. Eine Schleife mit Gate erzeugt einen Branch, der bereits dieselben Anforderungen erfüllt wie der Branch eines menschlichen Contributors.

Wählen Sie ein Gate, das Fehler zuverlässig meldet. Eine Testsuite, die bei einem leeren Diff erfolgreich ist, bringt der Schleife bei, dass Nichtstun erfolgreich ist. Repositories mit schwachen Tests erzeugen schwache Schleifen. Deshalb setzen die derzeit beliebten Repositories „die Codebasis für Agenten geeignet machen“ vor „die Schleife schreiben“.

Budget: Was einen Lauf beendet

Ein Agent, der endlos wiederholt, verursacht eine unbegrenzte Rechnung. Geben Sie jeder Schleife eine durch TimeoutStartSec erzwungene Obergrenze für die Laufzeit, eine Anzahl von Wiederholungen innerhalb Ihres Skripts und ein vom Provider-Konto erzwungenes Ausgabenlimit. Protokollieren Sie anschließend die Kosten jedes Laufs. So erkennen Sie, dass eine Schleife abweicht, bevor die Rechnung eintrifft. Kostenkontrolle für einen dauerhaft aktiven Agent-VPS behandelt die Abrechnung. Verwalten des Kontexts, den ein Agent zwischen Durchläufen mitführt behandelt den größten einzelnen Hebel für die Kosten pro Lauf. Eine Schleife, die alle 30 Minuten dasselbe Repository erneut einliest, verursacht dafür alle 30 Minuten Kosten.

Die Kosten sind der Grund, warum Schleifen in der Regel besser sind als eine einzige lange Sitzung. Ein Lauf, der mit einem leeren Kontext startet, eine begrenzte Aufgabe erledigt und beendet wird, hält seinen Kontext klein. Eine Sitzung, die acht Stunden geöffnet bleibt, enthält jeden früheren Fehler in ihrem Verlauf und berechnet bei jedem Durchlauf das gesamte Protokoll.

Die Muster, die die derzeit meistbeachteten Repositories festschreiben

Das Repository loop-engineering führt sieben Produktionsmuster auf. Sie sollten eher als Auswahl denn als Manifest gelesen werden. Tägliche Triage. Ein Betreuer für Pull Requests, der auf Review-Kommentare achtet und darauf antwortet. Ein Bereinigungsprozess für Continuous Integration, der fehlgeschlagene Builds aufgreift. Ein Bereinigungsprozess für Abhängigkeiten. Ein Entwurf für das Änderungsprotokoll. Aufräumarbeiten nach dem Merge. Issue-Triage.

Allen gemeinsam ist eine klar abgegrenzte Aufgabe mit einem eindeutigen Prüfkriterium. „Den fehlgeschlagenen Build reparieren“ hat eine Erfolgsbedingung, die die Maschine auswerten kann. „Die Codebasis verbessern“ hat das nicht und wird daher nie zu einer Schleife. Stattdessen entsteht ein unübersichtlicher Prozess mit einem Zeitplan.

Allen gemeinsam ist außerdem eine schriftliche Aufzeichnung. Beide Repositories verlagern den Zustand aus der Unterhaltung in Dateien im Repository: was ausgeführt wurde, was gefunden wurde und was entschieden wurde. Diese Datei ist das Gedächtnis der Schleife. Sie ermöglicht es einer zweiten Schleife, auf der Arbeit der ersten aufzubauen, statt sie erneut zu ermitteln. Außerdem können Sie damit einen Agenten nachträglich prüfen, da der Kontext des Modells verschwunden ist, sobald der Lauf beendet wird.

Wo Schleifen scheitern

Die Fehler sind unspektakulär und treten in verschiedenen Teams immer wieder auf.

• Kein Gate. Die Ausgabe sammelt sich an, niemand prüft sie, das Vertrauen sinkt, und die Schleife wird deaktiviert.
• Überschneidung. Zwei Läufe auf einem Branch oder zwei Agents in einem Working Tree erzeugen Konflikte, die der Agent anschließend zu lösen versucht.
• Stille Abweichung. Die Schleife läuft weiter erfolgreich durch, weil die Prüfung zu schwach ist, um einen Fehler zu melden.
• Unbegrenzter Umfang. Ein Trigger, der bei jedem Commit in einem stark ausgelasteten Repository ausgelöst wird, wird innerhalb eines Tages zu einem Kostenproblem.

Für alle gilt dieselbe Lösung: Begrenzen Sie den Auftrag, präzisieren Sie die Prüfung und protokollieren Sie den Lauf. Wenn Sie die Bedingung für einen erfolgreichen Durchlauf nicht in einem Satz beschreiben können, ist der Auftrag noch nicht für die Automatisierung geeignet.

Einstieg ohne Fachbegriffe

Sie benötigen kein Framework. Ein kleiner, dauerhaft laufender Linux-Server, ein Git-Repository, dessen Testsuite erwartungsgemäß fehlschlägt, ein systemd-Timer und ein Shell-Skript mit einem if darin bilden bereits einen vollständigen Ablauf. Genau damit sollten die meisten beginnen, weil sich die Designfragen durch das Ausführen des Systems beantworten und nicht durch die Auswahl eines Tools. Sobald ein Ablauf stabil ist, besteht das Einrichten eines zweiten Ablaufs meist nur aus einem weiteren Timer und einem weiteren Worktree. Siehe wie Sie einen Coding-KI-Agent auf einem VPS ausführen für die grundlegende Einrichtung und die aktuellen Optionen für selbst gehostete KI-Agents, wenn der Agent selbst auf Hardware laufen soll, die Sie kontrollieren.

FAQ

Unterscheidet sich Loop Engineering von Prompt Engineering?

Prompt Engineering optimiert eine einzelne Nachricht: Formulierung, Beispiele und Ausgabeformat. Loop Engineering optimiert den Ablauf um diese Nachricht: den Trigger, der einen Lauf startet, die Sandbox, in der er ausgeführt wird, die Prüfung, die die Ausgabe akzeptiert oder ablehnt, und das Budget, das den Lauf beendet. Innerhalb der Schleife benötigen Sie weiterhin einen guten Prompt. Der Prompt ist nicht mehr der Teil, den Sie täglich anpassen, weil Gate und Trigger das Ergebnis stärker beeinflussen.

Benötige ich ein Framework, um eine Agentenschleife zu erstellen?

Nein. Ein systemd-Timer, ein git worktree pro Lauf, ein Shell-Skript, das mit einem Testbefehl endet, und ein Ausgabenlimit für das Provider-Konto decken alle Bestandteile der Definition ab. Frameworks bieten Schnittstellen für die Planung, Formate für gemeinsamen Speicher und Routing für mehrere Agents. Das ist nützlich, sobald Sie mehrere Schleifen ausführen. Für die erste Schleife sind sie nicht erforderlich.

Was ist ein Codebase Harness?

Damit ist die Gesamtheit der Komponenten gemeint, mit denen ein Agent ohne anwesenden Menschen in einem Repository arbeiten kann: eine Einrichtung mit einem einzigen Befehl, Tests, die nicht interaktiv ausgeführt werden und Fehler eindeutig melden, ein Linter sowie eine Möglichkeit, eine Änderung bereitzustellen oder als Vorschau anzuzeigen. Der Begriff stammt aus derselben Repository-Welle des Jahres 2026 wie Loop Engineering. Der praktische Test ist einfach: Wenn ein neuer menschlicher Mitwirkender nicht mit einem einzigen Befehl vom Clone bis zu erfolgreichen Tests gelangt, kann ein Agent das ebenfalls nicht.

Wie verhindere ich, dass eine Agentenschleife eine hohe Rechnung verursacht?

Begrenzen Sie die Kosten an drei Stellen. Setzen Sie TimeoutStartSec für die systemd-Unit, damit ein hängender Lauf beendet wird. Begrenzen Sie die Wiederholungsversuche im Skript, anstatt bis zum Erfolg zu wiederholen. Setzen Sie ein hartes Ausgabenlimit für das API-Konto, denn nur diese Obergrenze kann der Agent nicht durch Argumentation umgehen. Protokollieren Sie anschließend die Kosten pro Lauf. Wenn sich die Kosten einer Schleife verdoppeln, wurde ihr Umfang meist unbemerkt erweitert.

Welche Aufgaben eignen sich zuerst für eine Schleife?

Wählen Sie eine Aufgabe mit einer maschinenlesbaren Erfolgsbedingung und begrenzten Auswirkungen. Das Beheben eines fehlgeschlagenen Builds, das Aktualisieren einer Abhängigkeit und das erneute Erzeugen eines Changelogs eignen sich, weil eine Testsuite oder ein Diff das Ergebnis bestätigen kann. Offene Aufgaben wie Refactoring oder Design eignen sich zunächst nicht. Es gibt noch nichts, was das Gate prüfen kann. Eine Schleife ohne Gate ist eine teure Methode, um Review-Rückstände zu erzeugen.