← Alle Beiträge

Der Hype um Loops: Wie ich Loops heute verwende

Wer in letzter Zeit die Entwicklung im KI-Bereich verfolgt hat, kommt an dem Begriff „Loops“ (Schleifen) oder „Agent Loops“ kaum vorbei. Überall wird über den Bau vollautonomer Agenten gesprochen, die in einer Endlosschleife laufen – denken, handeln, beobachten –, bis sie wie von Zauberhand ein Problem lösen.

In einer Demo klingt das fantastisch. Aber sobald man versucht, diese autonomen Agenten in eine echte Produktionsanwendung zu integrieren, prallt der Hype hart auf die Realität.

Hier ist meine Sicht darauf, warum der übliche Ansatz für Agenten-Schleifen in der Produktion scheitert, wie ich über Loops denke und warum strikte Grenzen und Gates der einzige Weg sind, um agentische Features zu bauen, denen man wirklich vertrauen kann.

Das Problem mit „Spielzeug-“ vs. „Produktions-“Agenten

In einer kleinen Test-Demo kann man es sich leisten, einen Agenten in einer unbegrenzten while-Schleife laufen zu lassen:

while (!agent.isDone()) {
  agent.think();
  agent.act();
}

Wenn der Agent dabei 40 Schritte macht, Tokens im Wert von 50 $ verbraucht, sich wegen eines kleinen Syntaxfehlers endlos im Kreis dreht oder die Codebasis verwüstet, ist das nur eine amüsante Anekdote für einen Twitter-Thread.

In einer Produktionssoftware ist das jedoch völlig inakzeptabel. Man kann kein Feature an Nutzer ausliefern, bei dem:

  • Der Agent selbst entscheidet, wann er fertig ist. LLMs arbeiten probabilistisch; sie werden irgendwann Erfolg halluzinieren oder einen kritischen Fehler übersehen und dann selbstbewusst behaupten, sie seien „fertig“.
  • Der Agent unkontrollierten Zugriff hat. Einem Agenten eine breite Palette an Werkzeugen zu geben und ihn selbst entscheiden zu lassen, was er ausführt, wann er Code bearbeitet und in welche Datenbanken er schreibt, ist ein Sicherheits- und Stabilitätsalbtraum.
  • Der Agent sich im Kreis dreht (Thrashing). Wenn man sie sich selbst überlässt, neigen Modelle bei Fehlern oft dazu, denselben fehlschlagenden Befehl immer und immer wieder auszuführen. Das verbrennt Tausende von Tokens, während man selbst im Dunkeln darüber gelassen wird, was der Agent eigentlich zu reparieren versucht.

Wenn wir wollen, dass Agenten echte Arbeit in Produktions-Apps automatisieren, müssen wir aufhören, sie wie magische, autonome Wesen zu behandeln. Wir müssen sie als ersetzbare, probabilistische Arbeiter betrachten, die innerhalb eines streng disziplinierten, deterministischen Software-Harnischs agieren.

Meine Philosophie: Code ist die Steuerungsebene (Control Plane)

Mein Verständnis von einem nützlichen, produktionsreifen Loop ist simpel: Die Anwendung muss den Workflow besitzen, nicht das LLM.

Anstatt einen Agenten frei herumlaufen zu lassen, müssen wir strukturierte Pipelines aus klar abgegrenzten Knoten (Nodes) entwerfen. Jeder Knoten hat eine spezifische Rolle, einen eingeschränkten Tool-Satz, ein dediziertes Modell und ein hartes Timeout. Der Agent führt die aufgabenspezifische Logik nur innerhalb dieser Knoten aus, während der Anwendungscode den Fortschritt, den Zustand und die Berechtigungen steuert.

Trigger (z. B. GitHub-Issue)
  -> deterministische Vorbereitung (Code Node)
  -> LLM-Schritt mit engem Prompt, Kontext, Modell & Tool-Set (LLM Node)
  -> Code-Gate über Output und Ausführungsevidenz (Gate Node)
       | pass        -> nächster Schritt
       | correctable -> begrenzte Wiederholung mit strukturiertem Feedback
       | uncertain   -> Evaluator oder menschliche Freigabe
       | terminal    -> sicherer Abbruch
  -> finale Aktion
  -> abgeschlossener Run

Hier ist, warum diese überwachte Architektur für Produktions-Apps so entscheidend ist:

1. Strikte Rollen- & Tool-Grenzen

In einer Produktions-App muss man einschränken, was ein Agent zu einem bestimmten Zeitpunkt tun darf.

  • Während der Recherche-Phase sollte der Agent nur Dateien lesen oder im Web suchen dürfen. Er hat absolut keinen Grund, Code zu bearbeiten oder in Datenbanken zu schreiben.
  • Während der Implementierungs-Phase erhält er Schreibrechte, hat aber keine Websuch-Tools mehr, damit er sich nicht ablenken lässt oder versehentlich Daten leakt.
  • Während der Review-Phase arbeitet der Agent streng schreibgeschützt (Read-only). Er prüft den Diff und führt Tests aus, kann den Code aber nicht verändern.

Indem man Tools pro Knoten einschränkt, anstatt sie global freizugeben, baut man eine Sandbox, die unkontrolliertes Verhalten verhindert.

2. Deterministische Validierungs-Gates

Man sollte niemals einen Modellaufruf verschwenden, um etwas zu prüfen, was einfacher Anwendungscode verifizieren kann. Bevor wir die Arbeit eines Agenten an den nächsten Schritt übergeben, führt ein Gate-Knoten deterministische Prüfungen durch:

  • Hat der Code kompiliert?
  • Sind die Unit-Tests erfolgreich durchgelaufen?
  • Haben die Browser-Smoke-Tests (z. B. via Playwright) React-Laufzeitfehler abgefangen?
  • Hat der Agent die erforderlichen Validierungsbefehle tatsächlich ausgeführt oder das nur behauptet?

Der LLM-Output bleibt so lange unglaubwürdig, bis diese programmatischen Gates grünes Licht geben. Schlägt ein Gate fehl, leitet das System den Agenten zurück zu einem fokussierten Korrekturschritt und übergibt nur die strukturierte Fehlermeldung (z. B. „Test in Zeile 45 fehlgeschlagen“).

3. Timeouts, Budgets und aktives „Steering“

Um Endlosschleifen und ausufernde Token-Kosten zu verhindern, muss die Laufzeitumgebung strikte Timeouts und Budgets erzwingen. Den Agenten jedoch mitten in der Arbeit einfach abzuwürgen, sorgt für eine frustrierende Nutzererfahrung.

Stattdessen sollte eine Produktions-Schleife den Agenten aktiv steuern (steeren), sobald sich Probleme abzeichnen:

  • Proaktive Anstöße (Nudges): Wir können das Verhalten des Agenten in Echtzeit überwachen. Wenn er beispielsweise mehrere Dateien ändert, aber das Test-Framework nicht ausführt, kann die Runtime eine Warnung direkt in den Kontext einfügen: „Du hast Codeänderungen vorgenommen. Führe jetzt Validierungstests aus, bevor du fortfährst.“
  • Dynamische Fehlerbehandlung: Ignoriert der Agent diese Hinweise, hängt in einer Endlosschleife beim Aufruf desselben Tools fest oder nähert sich seinem Timeout, greift die Runtime ein. Sie kann den aktuellen Schritt abbrechen, den Workspace auf einen sauberen Zustand zurücksetzen, das Modell gegen eine leistungsfähigere Version mit höherem Thinking-Budget austauschen oder eine beliebige Wiederholungslogik triggern. Das spart Kosten und bringt den Agenten zurück zu produktiver Arbeit.

4. Bereinigung des Kontexts (Sanitization)

Unüberwachte Agenten sammeln riesige Token-Verläufe an, die trockene Terminal-Logs, Verzeichnislisten und alte Gedankengänge enthalten. In einem Produktions-Loop führen wir nach jedem LLM-Schritt einen Sanitize-Knoten aus. Wir werfen die Chat-Protokolle, die Tool-Verläufe und die Suchergebnisse weg und behalten nur die sauberen Ergebnisse (wie einen strukturierten Bericht oder einen Git-Diff) für den nächsten Knoten. Das hält die Token-Kosten extrem niedrig und verhindert, dass sich der Agent im eigenen historischen Rauschen verliert.

Praktische Umsetzung: Pi Loops

Um diese Philosophie in die Realität umzusetzen, habe ich eine Erweiterung für den Pi-Coding-Agenten namens Pi Loops gebaut.

Laufender Pi Loop

Pi Loops is ein Open-Source-Framework, mit dem man überwachte Loop-Workflows um den Pi-Agenten herum aufbauen kann. Anstatt Pi freien Lauf zu lassen, definiert man eine TypeScript-basierte State Machine mit code-, llm-, gate-, approval- und finalizer-Knoten.

Als Referenz enthält das Repository einen Walkthrough für einen GitHub Issue Automation Loop. Dieser steuert die gesamte Pipeline: Issue abrufen, schnelle Recherche, Fehlerbehebung implementieren, Playwright-Browser-Smoke-Tests ausführen, Code-Reviews mit einem Modell mit hohem Thinking-Budget durchführen und einen PR erstellen – alles abgesichert durch strikte Rollenberechtigungen pro Schritt und ein Budget von maximal zwei Review-Fix-Zyklen.

Du kannst die Erweiterung heute direkt in Pi installieren:

pi install git:github.com/Asm3r96/pi-loops

Der Weg nach vorn für Agenten-Entwickler

Agentische Workflows sind die Zukunft der Software-Automatisierung – aber nur, wenn wir sie mit der gleichen Disziplin entwerfen, die wir bei traditioneller Softwareentwicklung anlegen.

Wenn wir KI-Systeme bauen wollen, die sicher in der Produktion laufen können, müssen wir aufhören zu erwarten, dass sich Agenten selbst kontrollieren. Wir müssen den Code schreiben, der sie anleitet, einschränkt und ihre Arbeit bei jedem einzelnen Schritt validiert.