Step Limits für KI-Agenten: Wie man Schleifen vor einem Incident stoppt

Idee in 30 Sekunden

Step limits sind eine Runtime-Kontrolle, die einen Run erzwungen stoppt, wenn der Agent in eine Schleife gerät oder keinen Fortschritt liefert.

Wann das nötig ist: wenn ein Agent in einer Loop arbeitet, mit Tools interagiert und in Production dieselben Aktionen wiederholen kann.

Problem

Ohne Step Limits macht ein Agent oft "irgendetwas", bewegt sich aber nicht in Richtung Ergebnis. In Demos kann das normal aussehen. In Production wird daraus schnell Kosten, Latenz und Log-Rauschen.

Typisches Muster:

• eine instabile Tool-Antwort
• Wiederholung derselben Aktion
• noch eine Wiederholung
• und wieder derselbe Kreis

Analogie: Das ist wie ein Navigator, der die Route an einer Kreuzung in eine Schleife bringt. Das Auto fährt, kommt dem Ziel aber nicht näher.

Damit das kein Incident wird, müssen Limits in der Runtime-Loop liegen, nicht in UI oder Prompt.

Lösung

Die Lösung ist, die Schrittkontrolle in einen Policy Layer auf Runtime-Ebene zu verschieben. Jeder Schritt wird geprüft, nachdem die nächste Aktion gebildet wurde, aber vor der Ausführung.

Der Policy Layer gibt eine dieser Entscheidungen zurück:

• allow
• stop (reason=max_steps)
• stop (reason=loop_detected)
• stop (reason=no_progress)

Das ist eine eigenständige Systemschicht, nicht Teil von Prompt oder Modelllogik.

Step limits ≠ Budget Controls

Das sind unterschiedliche Kontrollschichten:

• Step limits steuern das Loop-Verhalten (wie viele und welche Schritte der Agent ausführt)
• Budget Controls steuern Run-Ressourcen (Zeit, Geld, Anzahl Aktionen)

Eins ohne das andere reicht nicht:

• ohne Step Limits kann eine Loop lange ohne Fortschritt laufen
• ohne Budget Controls kann selbst eine "begrenzte" Loop teuer sein

Beispiel:

• step limits: max_steps=18, max_repeat_action=3
• budget controls: max_seconds=45, max_usd=1.00

Metriken der Step-Kontrolle

Diese Prüfungen arbeiten bei jedem Agent-Schritt zusammen.

Wie das in der Architektur aussieht

Der Step Policy Layer liegt in der Runtime-Loop zwischen Planung und Aktionsausführung. Jede Entscheidung (allow oder stop) wird im Audit Log festgehalten.

Jeder Agent-Schritt durchläuft diesen Flow vor der Ausführung: Die Runtime führt die nächste Aktion nicht direkt aus, sondern prüft zuerst die Step-Checks.

Flow kurz zusammengefasst:

• Runtime bildet die nächste Aktion
• Step Policy Layer prüft max_steps, Wiederholungen und Fortschritt
• allow -> die nächste Agent-Aktion wird ausgeführt
• stop -> stop reason + partial response werden zurückgegeben
• beide Entscheidungen werden ins Audit Log geschrieben

Beispiel

Ein Support-Agent ruft wegen instabiler externer Antworten immer wieder search.docs auf.

Mit Step Limits:

• max_steps = 18
• max_repeat_action = 3
• no_progress_window = 4

-> der Run stoppt mit einem expliziten stop reason, statt endlos weiterzulaufen.

Step Limits stoppen den Incident auf Ebene der Runtime-Loop und verlassen sich nicht auf Modellverhalten.

Im Code sieht das so aus

Das vereinfachte Schema oben zeigt den Haupt-Control-Flow. In der Praxis laufen die Step-Checks zentral vor jeder Aktion.

Beispiel für eine Step-Konfiguration:

step_limits:
  max_steps: 18
  max_repeat_action: 3
  no_progress_window: 4

while True:
    # Hier zählt ein Schritt als Aktionsabsicht, nicht als bereits ausgeführte Aktion.
    state = state.with_step_increment()
    action = planner.next(state)  # planner bildet die Aktion für diesen Schritt
    repeat_key = make_repeat_key(action.name, action.args)  # normalisierter tool+args-Schlüssel

    decision = step_policy.check(state, action, repeat_key=repeat_key)
    if decision.outcome == "stop":
        audit.log(
            run_id,
            decision.outcome,
            reason=decision.reason,
            step=state.steps,
            action=action.name,
            repeat_key=repeat_key,
        )
        return stop(decision.reason)

    result = tool.execute(action.args)
    state = state.apply(action, result)

    decision = Decision.allow(reason="step_ok")
    audit.log(
        run_id,
        decision.outcome,
        reason=decision.reason,
        step=state.steps,
        action=action.name,
        repeat_key=repeat_key,
        result=result.status,
    )

    if result.final:
        return result

Step Policy prüft üblicherweise drei Signale: Schrittlimit, Aktionswiederholung und fehlender Fortschritt. Für Loop Detection wird ein tool+args-Schlüssel verwendet, nicht nur action.name.

Wie das während der Ausführung aussieht

Szenario 1: max_steps erreicht

1. Runtime bildet Schritt 19 und erhöht den Schrittzähler.
2. Policy sieht die Überschreitung von max_steps.
3. Entscheidung: stop (reason=max_steps).
4. Stop-Grund wird ins Audit Log geschrieben.
5. User erhält eine partial response.

Szenario 2: Loop erkannt

1. Runtime bildet mehrfach search.docs mit denselben Args.
2. Policy zählt Wiederholungen über tool+args.
3. Entscheidung: stop (reason=loop_detected).
4. Run stoppt vor dem nächsten unnötigen Aufruf.
5. In Logs sind Ursache und Aktion klar sichtbar.

Szenario 3: Normale Ausführung

1. Runtime bildet einen neuen Schritt.
2. Policy prüft Limits: alles im Rahmen.
3. Entscheidung: allow.
4. Die nächste Agent-Aktion wird ausgeführt.
5. Ergebnis und Entscheidung werden im Audit Log festgehalten.

Typische Fehler

• max_steps nur in der UI setzen, nicht in der Runtime-Loop
• keinen expliziten stop reason in der Response zurückgeben
• nur Tool-Calls zählen und Schritte ignorieren
• Wiederholungen (tool + args) und no-progress nicht prüfen
• nur Erfolgs-Schritte loggen, aber keine Stop-Entscheidungen
• max_steps "zur Sicherheit" zu hoch setzen

Ergebnis: Der Run wirkt aktiv, aber die Loop wächst schneller, als das Team es sieht.

Selbstcheck

Schneller Step-Limits-Check vor dem Production-Start:

FAQ

Q: Mit welchem max_steps sollte ich starten?
A: Für die meisten synchronen Runs starte mit 15-25. Danach anhand der Häufigkeit von Stop-Events in realen Szenarien nachjustieren.

Q: Reicht nur max_steps aus?
A: Nein. Mindestens max_repeat_action und no-progress-Kontrolle hinzufügen. Für Production brauchst du auch Budgets (max_seconds, max_usd, max_tool_calls).

Q: Was ist wichtiger: Repeat Detection oder no-progress?
A: Du brauchst beides. Repeat Detection erkennt klare Wiederholungen, no-progress erkennt "weiche" Loops, bei denen Aktionen variieren, aber Fortschritt fehlt.

Q: Was sollten User bei einem Stop sehen?
A: Partial response + expliziten stop reason + eine kurze nächste Aktion (Anfrage umformulieren oder mit anderem Scope neu starten).

Q: Ersetzen Step Limits den Kill Switch?
A: Nein. Step Limits steuern jeden Run, während ein Kill Switch für einen globalen Notfallstopp nötig ist.

Wo Step Limits im Gesamtsystem liegen

Step Limits sind eine Ebene von Agent Governance. Zusammen mit RBAC, Budgets, Approval und Audit bilden sie ein einheitliches System zur Ausführungskontrolle.

Verwandte Seiten

Als Nächstes zum Thema:

• Agent Governance Überblick — Gesamtmodell für Agent-Kontrolle in Production.
• Budget Controls — wie Ausgaben für Zeit, Aktionen und Geld begrenzt werden.
• Rate limiting für Agenten — wie Anfragefrequenz zu Tools und APIs begrenzt wird.
• Kill switch — wie ein Agent im Incident-Response-Fall gestoppt wird.
• Infinite loop — ein typisches Loop-Failure-Muster und wie man es erkennt.