+170 XP

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

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

Eine Demo, die einmal funktioniert, ist ein Partytrick. Ein Produkt ist etwas, das auch beim hundertsten Lauf noch 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 Agenten von „läuft auf meinem Laptop“ zu „verarbeitet echten Traffic“ bringen, tauchen drei Probleme auf:

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

Kurze Definitionen, bevor wir weitermachen:

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

Hebel 1: Timeouts und Retries

Tools fallen aus. Eine Datenbank ist langsam, eine API gibt einen Fehler zurück, ein Netzwerkaufruf bleibt hängen. Ohne Absicherung wartet Ihr Agent endlos oder stirbt beim ersten Schluckauf.

Zwei Regeln lösen das meiste davon:

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

Retry: Wenn ein Aufruf fehlschlägt, versuchen Sie es eine kleine Anzahl von Malen erneut und warten Sie zwischen den Versuchen jeweils etwas länger (das nennt man *exponential backoff*: 1s warten, dann 2s, dann 4s). Die meisten Fehler sind temporär und verschwinden 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 Nachricht. Ein guter Agent kann sich davon oft erholen („Ich konnte das Bestellsystem nicht erreichen, deshalb habe ich den Nutzer stattdessen nach seiner Bestellnummer gefragt“).

Einen soliden, anbieterneutralen Überblick über Retry-Patterns gibt 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. Wenn der Agent nach, sagen wir, 8 Schritten nicht fertig ist, brechen Sie ab und geben entweder die bisher 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 Default ist oft höher, als Sie wollen.

Hebel 3: Token-Kosten kontrollieren

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

Drei konkrete Wege, die Rechnung zu senken:

Den Context kürzen. Agenten sammeln Historie an: jedes Tool-Ergebnis, jede vergangene Nachricht. Bei Schritt 6 schicken Sie vielleicht bei jedem Aufruf 20.000 Token Transkript erneut mit. Fassen Sie alte Schritte zusammen oder werfen Sie Tool-Ergebnisse weg, die Sie nicht mehr brauchen.

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

Weniger Output anfordern. „Antworte in weniger als 3 Sätzen“ oder strukturierte Daten statt Prosa zurückzugeben reduziert direkt die teure Output-Seite.

Hebel 4: Ein kleineres Modell für Routineschritte nutzen

Das ist der größte Hebel, den die meisten Teams übersehen. Sie brauchen nicht für jeden Schritt Ihr leistungsfähigstes, 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. Behalten Sie das große Modell für den wirklich schwierigen Schritt, etwa das Schreiben der abschließenden, nuancierten Antwort.

Das nennt man Model Routing: Ein günstiges Modell macht 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 auf ein kleines Modell nur bei den restlichen 30 Prozent Premium-Preise.

Wissenscheck

1. Was unterscheidet laut Lektion einen produktionsreifen Agenten von einer „Partytrick“-Demo?

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

3. Welchen Zweck hat exponential backoff beim Wiederholen eines fehlgeschlagenen Tool-Aufrufs?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten zu den drei Problemen, die typischerweise auftreten, wenn ein Agent in Produktion geht.

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: Kosten pro Lösung bei einem Support-Agenten

Hier ein realitätsnahes Beispiel. Ein Support-Agent bearbeitet 10.000 Tickets pro Monat. Die Kennzahl, die zählt, sind die Kosten pro Lösung: Gesamtausgaben geteilt durch die 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 gesendet. Kein Caching.
  • Keine Iterationsbegrenzung, hängende Tickets laufen bis zu 20 Mal in der Schleife.
  • Durchschnitt: 15 Modellaufrufe pro Ticket, je ~18.000 Token.

Das ergibt rund 0,42 $ pro Ticket, und etwa 8 Prozent der Tickets laufen bis zum Timeout in der Schleife, lösen sich also überhaupt nicht. Manche Nutzer warten 60+ Sekunden.

Nachher (Produktionsaufbau):

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

Neue Zahlen:

KennzahlVorherNachher
Kosten pro Lösung0,42 $0,09 $
Mediane Wartezeit22s6s
Tickets, die hängen8%0%

Derselbe Agent, dieselbe Antwortqualität, etwa 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 gehen. Schalten Sie Tracing ein (ein Log jedes Schritts: welches Modell, wie viele Token, wie lange, Erfolg oder Fehler). Jedes größere Agent-SDK enthält Tracing, und offene Tools wie Langfuse geben Ihnen ein anbieterneutrales Dashboard.

Suchen Sie zuerst die offensichtlichen Gewinne:

  • Welcher Schritt nutzt die meisten Token? (Meist ein überfüllter Context.)
  • Welches Tool ist am langsamsten? (Timeout hinzufügen.)
  • Wie viele Schritte braucht ein typisches Ticket? (Wenn es nahe an Ihrer Begrenzung liegt, nachsehen.)

Optimieren Sie die oberste eine oder zwei Zeilen. Ignorieren Sie den Rest, bis er relevant wird.

Reliable Agents in Production

Watch on YouTube

Eine einfache Checkliste fürs Ausliefern

Bevor Sie echten Traffic auf einen Agenten lenken, prüfen Sie:

  1. Jeder Tool-Aufruf hat einen Timeout und ein Retry-Limit.
  2. Die Agent-Schleife hat eine harte Iterationsbegrenzung mit einem saubereren Fallback.
  3. Prompt Caching ist an, und der Context wird gekürzt.
  4. Routineschritte nutzen ein kleineres Modell.
  5. Tracing ist an, damit Sie Kosten und Latenz pro Lauf sehen.

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

Wichtigste Erkenntnisse

  • Begrenzen Sie die Schleife und setzen Sie Timeouts auf jedes Tool. Diese zwei Guardrails verhindern die zwei schlimmsten Produktionsfehler: außer Kontrolle geratene 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 schwere Arbeit. Das ist normalerweise Ihr größter Kostengewinn.
  • Verfolgen Sie Kosten pro Lösung, nicht Kosten pro Aufruf. Das verknüpft Ausgaben mit tatsächlich geliefertem Wert und deckt Tickets auf, die Geld verbrennen, ohne gelöst zu werden.
  • Kürzen Sie den Context und schalten Sie Prompt Caching ein. Agenten senden still und leise immer größere Historien erneut; beide Maßnahmen senken die Input-Kosten mit geringem Aufwand deutlich.
  • Schalten Sie Tracing ein, bevor Sie optimieren. Messen Sie, welcher Schritt langsam oder teuer ist, beheben Sie die oberste eine oder zwei Ursachen, und hören Sie dort auf.

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.