Infinite Agent Loop: wenn ein KI-Agent nicht stoppt

Das Problem

Die Anfrage wirkt einfach: Bestellstatus finden und eine kurze Antwort zurückgeben.

In den Logs sieht man, dass der Agent denselben Zyklus wiederholt:

plan → call_tool → analyze → plan → call_tool → analyze

Vor einer Woche wurde so eine Aufgabe in 3-4 Schritten gelöst. Jetzt kann derselbe Anfrage-Typ 20+ Schritte laufen und mit timeout enden. In 15 Minuten kann der Agent 60+ Schritte machen und etwa 12 $ für eine Aufgabe verbrauchen, die normalerweise ~0.08 $ kostet.

Das System fällt nicht sofort aus.

Es verbrennt nur langsam Zeit, Tokens und Geld.

Analogie: Stell dir ein Navi vor, das an jeder Kreuzung sagt "bitte wenden", selbst wenn du schon gewendet hast. Das Auto fährt, aber du kommst dem Ziel nicht näher. Infinite loop bei Agenten funktioniert genauso: es gibt Aktionen, aber keinen Fortschritt.

Warum das passiert

LLM-Agenten sind stochastische Systeme. Schon eine kleine Änderung bei Prompt, Tool-Output oder Kontext kann die Schrittfolge verschieben. Wenn runtime echten Fortschritt nicht prüft, bleibt der Zyklus leicht hängen.

In Production sieht es meist so aus:

1. LLM schlägt die nächste Aktion vor;
2. der Agent ruft tool auf;
3. er bekommt eine Beobachtung, aber ohne neues Signal;
4. er geht wieder in denselben Reasoning Loop zurück.

Infinite loop entsteht nicht dann, wenn der Agent "zu lange nachdenkt", sondern wenn runtime nützliche Arbeit nicht von Wiederholung ohne Fortschritt unterscheidet.

Welche Ausfälle am häufigsten auftreten

Um es nicht zu verkomplizieren, sieht man im Infinite-Loop-Szenario meistens vier Muster.

Harte Schleife (Hard loop)

Der Agent ruft dasselbe tool mit denselben Argumenten viele Male auf.

Typische Ursache: kein dedupe auf tool+args oder Wiederholungen ohne Limit.

Weiche Schleife (Soft loop)

Der Agent macht dieselbe Aktion mit minimalen Argument-Änderungen: zum Beispiel ein Wort zur Suche hinzufügen und erneut probieren.

Typische Ursache: keine Prüfung "ob etwas Neues erschienen ist".

Retry-Sturm (Retry storm)

Das Tool fällt aus, und gleichzeitig retryn sowohl gateway als auch Agent. Dadurch vervielfacht sich die Anzahl der Aufrufe.

Typische Ursache: Retry-Logik über mehrere Schichten verteilt, ohne einheitliche Policy.

Semantische Schleife (Semantic loop)

Der Agent wirkt aktiv, bewegt sich aber nicht: er formuliert den Plan um, re-summarized dieselben Daten oder fragt erneut, was bereits bekannt ist.

Typische Ursache: kein klares Fortschrittskriterium in runtime.

Wie man diese Probleme erkennt

Infinite loop erkennt man besser über eine Kombination von Signalen als über eine einzelne Metrik.

Wie man Fehler von einer wirklich komplexen Aufgabe unterscheidet

Ein langer Run bedeutet nicht immer loop. Die Schlüsselfrage: erscheint ein neues, nützliches Signal.

Normal, wenn:

• jeder 1-2 Schritte neue Fakten oder Artifacts bringt;
• tool-Aufrufe sich inhaltlich ändern, nicht nur kosmetisch;
• Agent sich schrittweise an final_answer annähert.

Gefährlich, wenn:

• 3-5 Schritte in Folge nichts Neues bringen;
• dasselbe tool sich wiederholt (oder dieselbe Absicht);
• Kosten steigen und die Antwortqualität nicht besser wird.

Wie man solche Ausfälle stoppt

Das Ziel ist einfach: den Run nicht um jeden Preis fortsetzen, sondern kontrolliert beenden.

Praktisch heißt das:

1. harte runtime-Limits setzen: max_steps, timeout, max_tool_calls, max_tokens;
2. dedupe über tool+args plus Wiederholungs-Limit hinzufügen;
3. Run stoppen, wenn über N Schritte kein Fortschritt da ist;
4. kontrollierten stop reason und Teilergebnis zurückgeben, nicht stillen Fehler.

Minimaler loop-guard in runtime:

class LoopGuard:
    def __init__(self):
        self.max_steps = 12
        self.max_repeat = 3
        self.max_flat_steps = 4
        self.steps = 0
        self.flat_steps = 0
        self.seen = {}

    def on_step(self):
        self.steps += 1
        if self.steps > self.max_steps:
            return "max_steps_reached"
        return None

    def on_tool_call(self, signature: str):
        self.seen[signature] = self.seen.get(signature, 0) + 1
        if self.seen[signature] >= self.max_repeat:
            return "loop_detected:repeated_tool_signature"
        return None

    def on_progress(self, has_new_signal: bool):
        self.flat_steps = 0 if has_new_signal else self.flat_steps + 1
        if self.flat_steps >= self.max_flat_steps:
            return "loop_detected:no_progress"
        return None

Wichtig: In jeder Iteration zuerst on_step() aufrufen, dann on_tool_call(...), und nach der Ergebnisanalyse on_progress(...).

Dieser Guard "heilt" den Agenten nicht. Er verhindert, dass der Loop zu einem Production-Incident wird.

Wo das in der Architektur umgesetzt wird

In Production-Systemen liegt Loop-Kontrolle meist nicht im Agent selbst, sondern in separaten Architekturschichten.

Agent Runtime ist für den execution loop zuständig: Limits (max_steps, timeout, max_tokens), stop reasons und erzwungene Run-Beendigung. Hier werden LoopGuard und Fortschrittsprüfung üblicherweise umgesetzt.

Tool Execution Layer ist für sichere Ausführung von tool_call zuständig: dedupe von Aufrufen, retry policy und Fehlernormalisierung. Viele Loops - retry storm, repeated tool calls und tool spam - entstehen hier, wenn keine einheitliche Retry-Policy oder Deduplizierung existiert.

Selbstcheck

Schneller Check vor dem Release. Hake die Punkte ab und sieh dir den Status unten an.
Das ist ein kurzer Sanity-Check, kein formales Audit.

FAQ

Q: Löst ein stärkeres Modell infinite loop?
A: Teilweise manchmal, aber nicht die Wurzel. Ohne runtime-gates kann selbst ein starkes Modell loopen.

Q: Wie wählt man max_steps am Anfang?
A: Starte mit einem kleinen konservativen Limit und erhöhe nur dort, wo du bestätigten Qualitätsgewinn siehst.

Q: Muss man immer retries machen?
A: Nein. Bei 401/403 und stabilen Validierungsfehlern verschlechtern retries den loop meistens nur.

Q: Was dem Nutzer zeigen, wenn der Run gestoppt wurde?
A: Stop-Grund, was schon versucht wurde, und Teilergebnis. Das reduziert Wiederholungsstarts ohne Änderungen.

Infinite loop sieht fast nie wie ein großer Ausfall aus. Es ist eine langsame Degradation, die Budget und Zeit auffrisst. Deshalb braucht ein Production-Agent nicht nur ein "smartes" Modell, sondern harte runtime-Kontrolle.

Verwandte Seiten

Um dieses Problem tiefer zu schließen, sieh dir an:

• Warum KI-Agenten scheitern - allgemeine Karte von Production-Ausfällen.
• Tool-Spam - wie man doppelte Tool-Aufrufe begrenzt.
• Budget Explosion - wie ein loop zu unkontrollierten Ausgaben wird.
• Agent Runtime - wo loop guards und stop reasons umgesetzt werden.
• Tool Execution Layer - wo retries, timeout und Aufrufvalidierung hingehören.