So verhindern Sie, dass Agentenschleifen Ihr API-Budget aufbrauchen

Warum Agentenschleifen die Kosten explodieren lassen

Ein normaler Chat-Durchlauf hat eine Eingabe und eine Ausgabe. Eine Agentenschleife besteht aus einer Abfolge wie dieser:

1. Der Nutzer stellt eine Frage,
2. das Modell plant,
3. das Modell ruft ein Werkzeug auf,
4. das Werkzeug liefert Daten zurück,
5. das Modell liest die Daten,
6. das Modell entscheidet über den nächsten Schritt,
7. der Ablauf wiederholt sich.

Jede Iteration fügt dem Prompt der nächsten Iteration neue Tokens hinzu. Wenn Sie weiterhin vollständige Werkzeugausgaben und frühere Gedanken anhängen, wächst der Prompt ungefähr treppenförmig.

In der Praxis entstehen dadurch drei Kostenmultiplikatoren:

• Kontextansammlung: Jeder Schritt übernimmt die vorherigen Schritte.
• Übermäßige Werkzeugaufrufe: Dasselbe Werkzeug wird mit leicht veränderten Argumenten aufgerufen.
• Unkontrollierte Wiederholungsversuche: Das Modell versucht immer wieder „noch eine Sache“, obwohl es bereits genug getan hat.

Ein häufiger Fallstrick ist, dass die Tokenverschwendung meist unsichtbar bleibt, bis Sie sich die Traces einzelner Ausführungen ansehen. Die endgültige Antwort mag knapp sein, aber die verborgene Kette kann 10x größer sein als die für den Nutzer sichtbare Ausgabe.

Ein einfaches Kostenmodell

Wenn eine Schleife N Schritte durchläuft, jeweils mit:

• C Tokens an übernommenem Kontext,
• I Tokens an Werkzeugausgabe, die wieder eingespeist werden,
• O Tokens an Modellausgabe,

ergibt sich ungefähr folgende Gesamtsumme:

total_tokens ≈ N * (C + I + O)

Das ist optimistisch, denn C wächst normalerweise im weiteren Verlauf der Schleife. Bei einem realen Agenten sind die späteren Durchläufe oft am teuersten.

Die Stellschrauben, auf die es wirklich ankommt

Es gibt einige Stellen, an denen Sie ansetzen können. Der Trick besteht darin, sie zu kombinieren.

Die effektivsten Produktionskonfigurationen nutzen alle diese Maßnahmen.

1) Begrenzen Sie die Schrittzahl konsequent

Das ist die einfachste und am meisten unterschätzte Lösung: Wenn Sie keine feste Obergrenze setzen, vertrauen Sie darauf, dass das Modell von selbst aufhört.

Ich beginne normalerweise mit:

• 3–5 Schritten für eng umrissene Aufgaben,
• 6–8 Schritten für mittelschwere Aufgaben,
• mehr nur dann, wenn es einen triftigen Grund gibt.

Eine gute Obergrenze ist mehr als nur ein Sicherheitsventil. Sie erzwingt eine bessere Aufteilung der Aufgabe. Wenn der Agent nur vier Schritte zur Verfügung hat, neigt er dazu:

• früher das richtige Werkzeug anzufordern,
• erkundende Umwege zu vermeiden
• und schneller zu einer brauchbaren Antwort zu gelangen.

Beispiel für eine Schleifensteuerung

MAX_STEPS = 5

for step in range(MAX_STEPS):
    action = model.next_action(state)

    if action.type == "final":
        return action.final_answer

    observation = run_tool(action.tool_name, action.arguments)
    state = update_state(state, action, observation)

raise RuntimeError("Agent stopped after step cap")

Ein häufiger Fallstrick: Schrittbegrenzungen sollten für den gesamten Plangelten, nicht für jede Unterroutine einzeln. Andernfalls verlagern Sie die Kostenexplosion vom übergeordneten Agenten in verschachtelte Hilfsroutinen.

2) Kürzen Sie den Kontext bei jedem Durchlauf

Die meisten Agenten führen zu viel Verlauf mit sich. Sie benötigen nicht jede frühere Werkzeugantwort, insbesondere wenn die Antwort umfangreich war und nur ein Detail relevant war.

In der Praxis habe ich mit einer abgestuften Strategie für das Gedächtnis die besten Ergebnisse erzielt:

• Wortgetreu beibehalten: Nutzeranfrage, aktuelles Ziel, endgültige Entscheidungen, noch ungeklärte Rahmenbedingungen.
• Zusammenfassen: bisherige Überlegungen, Versuche in alternativen Lösungszweigen, lange Werkzeugausgaben.
• Verwerfen: Hypothesen, die in eine Sackgasse führen, doppelte Werkzeugergebnisse, alte Zwischenentwürfe.

Was Sie behalten sollten

Ein kompaktes Zustandsobjekt funktioniert besser als das erneute Einspielen des unverarbeiteten Gesprächsverlaufs:

{
  "goal": "Find the failing endpoint and propose a fix",
  "constraints": [
    "No schema changes",
    "Must preserve backward compatibility"
  ],
  "known_facts": [
    "500s started after deploy 1842",
    "Only /v1/search is affected"
  ],
  "open_questions": [
    "Is the new cache layer returning stale payloads?"
  ],
  "step": 3
}

Das ist deutlich günstiger, als dem Modell 20 Gesprächsrunden mit „lautem Nachdenken“ zuzuführen.

Praktisches Muster zum Kürzen

Verwenden Sie drei Puffer:

• working_set: aktuelle Gesprächsrunde, Tool-Ausgaben, aktiver Plan.
• summary_memory: komprimierter Verlauf.
• archive: alles, was Sie möglicherweise für Audits benötigen, aber nicht für den Prompt-Kontext.

Der Agent sieht nur working_set + summary_memory. Wenn working_set zu groß wird, fassen Sie den Inhalt zusammen in summary_memory.

Die Schwierigkeit dabei ist, dass Zusammenfassungen zunehmend vom ursprünglichen Inhalt abweichen können. Wenn Ihr Zusammenfassungsmodell Informationen verliert, kann es Einschränkungen auslassen und dazu führen, dass der Agent Fehler wiederholt. Ich bewahre strukturierte Fakten gern getrennt von frei formulierten Zusammenfassungen auf, damit das Modell sie nicht aus Fließtext erschließen muss.

3) Verwenden Sie günstigere Subagenten für einfache Aufgaben

Nicht jeder Schritt erfordert Ihr bestes Modell.

Wenn die Aufgabe darin besteht:

• Felder aus JSON zu extrahieren,
• ein Ticket zu klassifizieren,
• zu prüfen, ob sich eine Datei geändert hat,
• oder eine kurze Suchanfrage zu generieren,

reicht oft ein kleineres, günstigeres Modell. Heben Sie sich das teure Modell für Planung, Synthese und den Umgang mit Mehrdeutigkeit auf.

Übliche Aufteilung

• Hauptagent: durchdenkt die Aufgabe und entscheidet, wann er aufhört.
• Subagent: erledigt klar begrenzte Aufgaben wie Suche, Extraktion oder Normalisierung.
• Prüfinstanz: prüft Ausgaben auf Format, Vollständigkeit oder offensichtliche Fehler.

Eine praktische Architektur:

User
  -> Orchestrator (strong model)
      -> Search agent (cheap model)
      -> Extract agent (cheap model)
      -> Final synthesis (strong model)

Warum das funktioniert

Das Hauptmodell konzentriert sich auf den Kontrollfluss, statt alles selbst zu erledigen. Der Subagent lässt sich durch den Prompt eng eingrenzen und mit einem festen Token-Limit versehen.

Beispiel-Prompt für einen Such-Subagenten:

Return only:
1. the best search query,
2. 3 likely source categories,
3. no explanation.

Eine derart eng gefasste Vorgabe hält die Ausgaben kurz und vorhersehbar.

Wenn Ihre Plattform Ihnen kostengünstigen Zugriff auf mehrere Modelle bietet, zahlt sich das hier aus: ein leistungsstarkes Modell für die Orchestrierung, ein günstigeres Modell für wiederkehrende Teilaufgaben und kein Grund, Premium-Tokens für routinemäßiges Parsen zu verbrauchen.

4) Cachen Sie Tool-Ergebnisse konsequent

Agentenschleifen bezahlen oft mehrfach für dieselben Informationen:

• wiederholtes Lesen von Dateien,
• wiederholte Datenbankabfragen,
• wiederholte Websuchen,
• wiederholte Embedding- oder Retrieval-Aufrufe.

Das Cachen von Tool-Ausgaben gehört zu den Änderungen mit dem besten Kosten-Nutzen-Verhältnis.

Cachen Sie nach semantischem Schlüssel statt nach Rohtext

Ein Cache für unverarbeitete Prompts liefert keinen Treffer, wenn sich die Formulierung leicht ändert. Bessere Schlüssel basieren auf der normalisierten Absicht:

def cache_key(tool_name, args):
    normalized = normalize_args(args)
    return f"{tool_name}:{hash(normalized)}"

Beispiel für einen Cache-Eintrag:

{
  "tool": "repo_search",
  "query": "auth middleware rate limit bug",
  "result": {
    "files": ["src/middleware/auth.py", "src/api/routes.py"],
    "ts": 1710001123
  }
}

Wann Caching am meisten hilft

• Agenten zur Untersuchung von Repositorys,
• Dokumentensuche,
• stabile Wissensdatenbanken,
• deterministische Transformationen,
• wiederholtes Retrieval in Workflows mit mehreren Gesprächsrunden.

Wo Caching schaden kann

• Daten, die sich schnell ändern,
• nutzerspezifische Ergebnisse,
• alles mit zeitkritischen Anforderungen an die Aktualität.

Ein häufiger Fallstrick besteht darin, Tool-Ausgaben zu cachen, ohne dem Agenten deren Aktualität mitzuteilen. Wenn das Modell glaubt, Live-Daten erhalten zu haben, obwohl es Daten aus dem Cache bekommen hat, kann es schlechte Entscheidungen treffen. Fügen Sie den Tool-Metadaten Zeitstempel oder Gültigkeitszeiträume hinzu.

5) Zeigen Sie die Ausgaben im Dashboard

Wenn Sie nur Latenz und Erfolgsquote erfassen, übersehen Sie das eigentliche Fehlverhalten: teuren Erfolg.

Sie benötigen für jeden Durchlauf Einblick in:

• Eingabe-Tokens,
• Ausgabe-Tokens,
• Tool-Aufrufe,
• Tool-Latenz,
• Gesamtausgaben,
• Anzahl der Schritte,
• Beendigungsgrund.

Minimales Ereignisschema

{
  "run_id": "r_8f2c",
  "step": 4,
  "model": "gpt-5.5",
  "input_tokens": 1842,
  "output_tokens": 221,
  "tool_name": "repo_search",
  "tool_latency_ms": 312,
  "estimated_cost_usd": 0.087,
  "stop_reason": "step_cap"
}

Worauf Sie in der Praxis achten sollten

• Tokens pro erfolgreich abgeschlossener Aufgabe: der aussagekräftigste Kostenindikator.
• Tokens pro Schritt: macht aufgeblähte Prompts sichtbar.
• Wiederholte Tool-Aufrufe: meist ein Planungsfehler.
• Verteilung der Beendigungsgründe: wenn viele Durchläufe durch ein Limit enden, plant Ihr Agent nicht ausreichend.

Eine der nützlichsten Grafiken zeigt die Kosten nach Aufgabentyp. Einige Kategorien sind naturgemäß teuer. Das ist in Ordnung. Erkennen möchten Sie die Aufgabe, die günstig sein sollte, es aber nicht ist.

6) Stoppen Sie ausufernde Schleifen frühzeitig

Eine Schleife sollte aus mehr Gründen enden als nur „Ich habe das Schrittlimit erreicht“.

Nützliche Beendigungsbedingungen sind:

• das Modell hat eine endgültige Antwort erzeugt,
• derselbe Tool-Aufruf wird ohne neue Informationen wiederholt,
• die Änderung der Konfidenz oder des Nutzens liegt unter dem Schwellenwert,
• die Aufgabe ist laut einer Prüfinstanz gelöst,
• der Plan kommt nicht mehr voran.

Beispiel für einen Schleifenabbruch

seen_calls = set()

for step in range(MAX_STEPS):
    action = model.next_action(state)
    signature = (action.tool_name, canonicalize(action.arguments))

    if signature in seen_calls:
        return fail("repeated tool call with no new information")
    seen_calls.add(signature)

    observation = run_tool(action.tool_name, action.arguments)
    state = update_state(state, action, observation)

    if verifier_says_done(state):
        return finalize(state)

Damit lässt sich ein sehr häufiges Fehlverhalten abfangen: Das Modell „möchte hilfreich sein“ und formuliert einfach dieselbe Anfrage um.

Eine weitere nützliche Schutzmaßnahme: Fortsetzung nur bei zusätzlichem Nutzen

Wenn ein Schritt den Zustand nicht ausreichend verändert, fahren Sie nicht fort. Dafür können schon einfache Kriterien genügen:

• keine neuen Dateien gefunden,
• keine neuen Entitäten extrahiert,
• keine Verbesserung der Antwortkonfidenz,
• keine neuen Belege hinzugefügt.

Die genaue Kennzahl hängt von der Aufgabe ab, aber ein Maß für den zusätzlichen Nutzen ist unerlässlich.

Was tatsächlich passiert, wenn Sie das gut abstimmen

Sobald Sie die Schleife straffer gestalten, verbessert sich der Agent meist auf eine Weise, die anfangs leicht übersehen wird:

• Er wird weniger gesprächig und entschlossener.
• Er fordert das passende Tool früher an.
• Er durchläuft weniger „Ich untersuche das noch“-Zyklen.
• Er wird günstiger und schneller, weil weniger Gesprächsrunden weniger Kontext und geringere Latenz bedeuten.

Der wesentliche Zielkonflikt besteht darin, dass feste Limits und aggressives Kürzen das System bei wirklich schwierigen Aufgaben anfällig machen können. Tun Sie daher nicht so, als würde der Agent Probleme „lösen“, wenn er tatsächlich nur in ein Zeitlimit läuft. Machen Sie das in Protokollen und in Meldungen für Nutzer transparent.

Meine Faustregel: Optimieren Sie auf Kompetenz innerhalb klarer Grenzen statt auf endloses Umherirren.

Ein praxistaugliches Setup für den Produktivbetrieb

Wenn ich morgen einen Agenten ausliefern würde, würde ich mit Folgendem beginnen:

• MAX_STEPS = 5
• strukturierter Zustand statt erneuter Verarbeitung des gesamten Gesprächsverlaufs
• zusammenfassender Speicher nach jedem Gesprächsschritt
• kostengünstige Unteragenten für Suche und Extraktion
• Cache für Werkzeugergebnisse mit Metadaten zur Aktualität
• Protokollierung von Tokenverbrauch und Kosten pro Durchlauf
• Erkennung wiederholter Aufrufe
• explizite Abbruchgründe

Dieses Setup ist nicht glamourös, verhindert aber, dass die Rechnung schneller wächst als das Produkt.

Praktische Empfehlungen

• Begrenzen Sie zuerst die Anzahl der Schritte; das ist der günstigste Schutz vor außer Kontrolle geratenen Schleifen.
• Kürzen Sie den Kontext konsequent und halten Sie den strukturierten Zustand von Zusammenfassungen getrennt.
• Nutzen Sie kostengünstigere Unteragenten für eng umrissene Aufgaben, statt überall teure Premium-Tokens einzusetzen.
• Speichern Sie wiederverwendbare Werkzeugausgaben im Cache, machen Sie aber deren Aktualität sichtbar, damit das Modell veralteten Daten nicht blind vertraut.
• Protokollieren Sie die Ausgaben pro Durchlauf, pro Schritt und pro Werkzeugaufruf, damit Kostensteigerungen sofort sichtbar werden.
• Beenden Sie Schleifen bei Wiederholung, Stillstand oder bestätigtem Abschluss – nicht erst, wenn das Budget aufgebraucht ist.
• Entwerfen Sie für Kompetenz innerhalb klarer Grenzen: Gut genug, schnell und vorhersehbar schlägt clever, aber teuer jedes Mal.