+170 XP

Kosten, Latenz und Zuverlässigkeit: Agents in Produktion bringen

# Kosten, Latenz und Zuverlässigkeit: Agents in Produktion bringen

Ihr Support-Agent hat die Demo-Frage perfekt beantwortet. Dann haben Sie ihn für echte Kunden freigeschaltet, und bis Freitag war er 4.000 Mal gelaufen, hatte 600 $ gekostet und zwölf Nutzer neunzig Sekunden lang auf einen Spinner starren lassen, bevor der Timeout kam.

Eine Demo, die einmal funktioniert, ist ein Partytrick. Ein Produkt ist etwas, das auch beim hundertsten Durchlauf funktioniert, im Budget bleibt und nicht hängt. Diese Lektion behandelt die praktischen Hebel, die Sie dorthin bringen.

Die drei Dinge, die in Produktion kaputtgehen

Wenn Sie einen Agent von „läuft auf meinem Laptop“ zu „verarbeitet echten Traffic“ bringen, tauchen drei Probleme auf:

  • Kosten: Jeder Schritt eines Agents schickt Text an ein Modell, und Sie zahlen pro Texteinheit. Ein geschwätziger Agent verbrennt schnell Geld.
  • Latenz: wie lange der Nutzer wartet. Agents, die über viele Schritte „nachdenken“, sind langsam.
  • Zuverlässigkeit: Wird er fertig, oder hängt er, läuft endlos in der Schleife oder stürzt bei einer fehlerhaften Tool-Antwort ab?

Kurze Definitionen, bevor es weitergeht:

  • Agent: ein Programm, das ein Large Language Model nutzt, um zu entscheiden, was als Nächstes zu tun ist, und dabei oft Tools (eine Suche, eine Datenbankabfrage, einen E-Mail-Versand) in einer Schleife aufruft, bis die Aufgabe erledigt ist.
  • Token: die Abrechnungseinheit der Modelle. Etwa 3 bis 4 Zeichen oder rund 0,75 Wörter. „Reset my password“ sind etwa 4 Tokens.

Hebel 1: Timeouts und Retries

Tools fallen aus. Eine Datenbank ist langsam, eine API liefert einen Fehler, ein Netzwerkaufruf bleibt stehen. Ohne Absicherung wartet Ihr Agent ewig oder stirbt beim ersten Schluckauf.

Zwei Regeln lösen das meiste davon:

Timeout: Legen Sie für jeden externen Aufruf eine maximale Wartezeit fest. Antwortet ein Tool nicht innerhalb von, sagen wir, 10 Sekunden, hören Sie auf zu warten und machen Sie weiter.

Retry: Scheitert ein Aufruf, versuchen Sie es eine kleine Anzahl von Malen erneut und warten Sie zwischen den Versuchen etwas länger (das nennt sich *exponential backoff*: 1s warten, dann 2s, dann 4s). Die meisten Fehler sind vorübergehend und erledigen sich beim zweiten Versuch.

python
import time

def call_tool_with_retry(tool_fn, args, retries=3, timeout=10):
    for attempt in range(retries):
        try:
            return tool_fn(args, timeout=timeout)
        except (TimeoutError, ConnectionError):
            if attempt == retries - 1:
                return {"error": "tool unavailable, continue without it"}
            time.sleep(2 ** attempt)  # 1s, 2s, 4s

Beachten Sie die letzte Zeile: Statt abzustürzen, übergibt sie dem Modell eine klare Meldung. Ein guter Agent kann sich davon oft erholen („Ich konnte das Bestellsystem nicht erreichen, also habe ich den Nutzer stattdessen nach seiner Bestellnummer gefragt“).

Einen soliden, anbieterneutralen Überblick über Retry-Muster finden Sie in Googles SRE-Leitfaden zu handling overload and retries.

Hebel 2: Die Schleife begrenzen

Ein Agent läuft in einer Schleife: denken, ein Tool aufrufen, das Ergebnis lesen, wieder denken. Die Gefahr ist eine Schleife, die nie endet. Das Modell entscheidet immer wieder „ich brauche noch eine Suche“, und Sie zahlen weiter.

Begrenzen Sie immer die Anzahl der Iterationen. Ist der Agent nach, sagen wir, 8 Schritten nicht fertig, brechen Sie ab und geben entweder die bis dahin beste Antwort zurück oder übergeben an einen Menschen.

python
MAX_STEPS = 8

def run_agent(user_input):
    messages = [{"role": "user", "content": user_input}]
    for step in range(MAX_STEPS):
        response = model.respond(messages, tools=TOOLS)
        if response.is_final:
            return response.text
        result = call_tool_with_retry(response.tool, response.args)
        messages.append({"role": "tool", "content": result})
    return "I couldn't resolve this fully. Escalating to a human agent."

Die Zeile for step in range(MAX_STEPS) ist das ganze Sicherheitsnetz. Jedes größere Agent-Framework (das OpenAI Agents SDK, das Claude Agent SDK, Googles ADK) hat dafür eine eingebaute Einstellung, meist max turns oder max iterations genannt. Setzen Sie sie bewusst. Der Standardwert liegt oft höher, als Sie möchten.

Hebel 3: Token-Kosten kontrollieren

Sie zahlen für zwei Dinge: was Sie an das Modell schicken (Input-Tokens) und was es zurückschreibt (Output-Tokens). Output kostet pro Token meist ein Mehrfaches von Input.

Drei konkrete Wege, die Rechnung zu senken:

Den Kontext kürzen. Agents sammeln Historie an: jedes Tool-Ergebnis, jede vergangene Nachricht. Bei Schritt 6 schicken Sie womöglich bei jedem Aufruf 20.000 Tokens Transkript erneut mit. Fassen Sie ältere Schritte zusammen oder werfen Sie Tool-Ergebnisse raus, die Sie nicht mehr brauchen.

Das Stabile cachen. Ihr System-Prompt und Ihre Tool-Definitionen sind bei jedem Aufruf identisch. Die meisten Anbieter bieten *Prompt Caching*, das für wiederholten Input nur einen Bruchteil des Preises berechnet. Es einzuschalten ist oft eine einzeilige Konfigurationsänderung und kann die Input-Kosten um 50 bis 90 Prozent senken.

Weniger Output verlangen. „Antworte in weniger als 3 Sätzen“ oder die Rückgabe strukturierter Daten statt Fließtext reduziert direkt die teure Output-Seite.

Hebel 4: Für Routineschritte ein kleineres Modell nutzen

Das ist der größte Hebel, den die meisten Teams übersehen. Sie brauchen nicht für jeden Schritt Ihr leistungsfähigstes und teuerstes Modell.

Der größte Teil der Agent-Arbeit ist Routine: eine Frage klassifizieren, eine Bestellnummer extrahieren, entscheiden, welches Tool aufgerufen wird. Ein kleines, günstiges, schnelles Modell erledigt das problemlos. Heben Sie das große Modell für den wirklich schwierigen Schritt auf, etwa das Verfassen der finalen, nuancierten Antwort.

Das nennt sich Model Routing: Ein günstiges Modell übernimmt die Triage und eskaliert nur bei Bedarf an das teure.

python
def handle(query):
    # günstiges Modell klassifiziert
    category = small_model.classify(query, ["simple_faq", "complex_issue"])

    if category == "simple_faq":
        return small_model.answer(query)      # günstiger Pfad
    else:
        return large_model.run_agent(query)   # teurer Pfad, nur wenn nötig

Wenn 70 Prozent Ihrer Support-Fragen Passwort-Resets und Versandstatus sind, zahlen Sie durch das Routing an ein kleines Modell nur für die verbleibenden 30 Prozent Premium-Preise.

Wissenscheck

1. Was unterscheidet laut Lektion einen produktionsreifen Agent von einer Demo als „Partytrick“?

2. Warum verbrennt ein „geschwätziger“ Agent in Produktion tendenziell schnell Geld?

3. Was ist der Zweck von exponential backoff beim erneuten Versuch eines fehlgeschlagenen Tool-Aufrufs?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten zu den drei Problemen, die typischerweise beim Gang in Produktion auftreten.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten zu Timeouts und Retries als Zuverlässigkeitshebel.

Wählen Sie alle richtigen Antworten aus.

Vorher und nachher: die Kosten pro gelöstem Fall bei einem Support-Agent

Hier ein realistisch geschnittenes Beispiel. Ein Support-Agent bearbeitet 10.000 Tickets pro Monat. Die relevante Kennzahl ist Cost per Resolution: Gesamtausgaben geteilt durch Tickets, die ohne Menschen erfolgreich gelöst wurden.

Vorher (naiver Aufbau):

  • Jedes Ticket nutzt für alle Schritte das große Modell.
  • Die vollständige Gesprächshistorie wird bei jedem Schritt erneut geschickt. Kein Caching.
  • Keine Iterationsgrenze, hängende Tickets laufen bis zu 20 Mal in der Schleife.
  • Durchschnitt: 15 Modellaufrufe pro Ticket, je ~18.000 Tokens.

Das ergibt rund 0,42 $ pro Ticket, und etwa 8 Prozent der Tickets laufen bis zum Timeout in der Schleife, werden also gar nicht gelöst. Manche Nutzer warten 60+ Sekunden.

Nachher (Produktionsaufbau):

  • Ein kleines Modell übernimmt die Triage. 65 Prozent der Tickets (FAQs, Statusabfragen) werden auf dem günstigen Pfad gelöst.
  • Prompt Caching für System-Prompt und Tools.
  • Kontext gekürzt: alte Tool-Ergebnisse werden nach 3 Schritten zusammengefasst.
  • Iterationsgrenze bei 8, mit sauberer Eskalation an einen Menschen.

Neue Zahlen:

| Kennzahl | Vorher | Nachher |

|---|---|---|

| Cost per Resolution | 0,42 $ | 0,09 $ |

| Mediane Wartezeit | 22s | 6s |

| Hängende Tickets | 8% | 0% |

Gleicher Agent, gleiche Antwortqualität, rund 4x günstiger und deutlich schneller. Nichts davon erforderte ein intelligenteres Modell. Es erforderte Disziplin darüber, *wann* man das teure einsetzt, und Guardrails, damit nichts aus dem Ruder läuft.

Messen, bevor Sie optimieren

Raten Sie nicht, wohin Geld und Zeit fließen. Schalten Sie Tracing ein (ein Log jedes Schritts: welches Modell, wie viele Tokens, wie lange, Erfolg oder Fehler). Jedes größere Agent-SDK bringt Tracing mit, und offene Tools wie Langfuse geben Ihnen ein anbieterneutrales Dashboard.

Suchen Sie zuerst nach den offensichtlichen Gewinnen:

  • Welcher Schritt verbraucht die meisten Tokens? (Meist ein aufgeblähter Kontext.)
  • Welches Tool ist am langsamsten? (Timeout ergänzen.)
  • Wie viele Schritte braucht ein typisches Ticket? (Liegt es nahe an Ihrer Grenze, nachsehen.)

Optimieren Sie die ein, zwei obersten Zeilen. Ignorieren Sie den Rest, bis er relevant wird.

Reliable Agents in Production

Watch on YouTube

Eine einfache Checkliste vor dem Launch

Bevor Sie echten Traffic auf einen Agent leiten, prüfen Sie:

1. Jeder Tool-Aufruf hat ein Timeout und ein Retry-Limit.

2. Die Agent-Schleife hat eine harte Iterationsgrenze mit sauberem Fallback.

3. Prompt Caching ist aktiv, und der Kontext wird gekürzt.

4. Routineschritte nutzen ein kleineres Modell.

5. Tracing ist aktiv, damit Sie Kosten und Latenz pro Durchlauf sehen.

Anbieterspezifische Details (genaue Bezeichnungen der Einstellungen, wie man Caching aktiviert) stehen in den Deep-Dive-Blöcken zu OpenAI, Claude und Gemini. Die obigen Hebel gelten für alle.

Key Takeaways

  • Begrenzen Sie die Schleife und setzen Sie Timeouts auf jedes Tool. Diese zwei Guardrails verhindern die beiden schlimmsten Produktionsfehler: ausufernde Kosten und hängende Requests.
  • Routen Sie nach Schwierigkeit. Nutzen Sie ein günstiges, schnelles Modell für Triage und Routineschritte; reservieren Sie das teure Modell für die wirklich harte Arbeit. Das ist meist Ihr größter Kostengewinn.
  • Verfolgen Sie Cost per Resolution, nicht Kosten pro Aufruf. Das koppelt Ausgaben an tatsächlich gelieferten Wert und deckt Tickets auf, die Geld verbrennen, ohne gelöst zu werden.
  • Kürzen Sie den Kontext und schalten Sie Prompt Caching ein. Agents schicken unbemerkt immer längere Historien erneut; beide Maßnahmen senken die Input-Kosten mit wenig Aufwand deutlich.
  • Schalten Sie Tracing ein, bevor Sie optimieren. Messen Sie, welcher Schritt langsam oder teuer ist, beheben Sie die ein, zwei größten Posten und hören Sie dann auf.

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.