Wenn du agentische Systeme in Produktion bringst, ist „es läuft bei mir“ wertlos. Du brauchst Mechanismen, die bei Netzwerkproblemen, langsamen Tools, Modell-Latenz und Teil-Ausfällen vorhersehbar reagieren. Drei Klassiker sind Timeouts, Retries und der Circuit Breaker. Zusammen reduzieren sie die Failure-Surface und verhindern, dass ein einzelnes wackliges Dependency deine ganze Pipeline lahmlegt.
Ein Timeout ist eine harte Zeitgrenze für einen Schritt (z.B. Tool-Call, DB-Query, HTTP-Request, Modell-Response). Ohne Timeouts stauen sich Requests, Worker blockieren, und du bekommst Kaskadenfehler (Queue wächst, CPU steigt, Nutzer warten ewig). Wichtig ist, Timeouts pro Layer zu setzen: ein kurzer Timeout für einzelne Tool-Requests, ein etwas längerer für den Gesamt-Task, plus ein „globales“ Budget für die gesamte User-Interaktion. In agentischen Flows lohnt sich außerdem ein progressive time budgeting: frühe Schritte bekommen weniger Zeit, spätere nur, wenn der Agent schon „auf Kurs“ ist.
Retries sind kein Pflaster für logische Fehler. Sie helfen bei transienten Problemen: kurzzeitige Netzwerk-Drops, 502/503, Rate-Limits, sporadische Timeouts. Best Practice: exponential backoff (z.B. 200ms, 500ms, 1s) plus jitter, damit nicht alle Clients gleichzeitig wieder anklopfen. Entscheidend ist die Frage: Ist die Operation idempotent? Ein Retry bei „charge credit card“ ist gefährlich, bei „GET status“ meist okay. Für nicht-idempotente Operationen brauchst du Idempotency-Keys oder einen dedizierten „exactly-once“ Ansatz.
Der Circuit Breaker schützt dich, wenn ein Dependency dauerhaft kaputt oder langsam ist. Zustände:
Im Agenten-Kontext heißt das: Wenn ein Tool wiederholt scheitert, sollte der Agent nicht stur weiterhämmern. Stattdessen: fail fast mit einem klaren Fehler, oder degradieren (Fallback-Tool, cached data, human handoff). Das ist nicht nur stabiler, sondern auch billiger (weniger Token/Tool-Kosten).
Ein typisches Exam-Szenario: Ein Agent ruft ein externes CRM-Tool auf. Du setzt (1) Tool-Timeout 3s, (2) max. 2 Retries mit backoff+jitter nur bei 5xx/timeout, (3) Circuit Breaker öffnet bei >50% Fehlern über 1 Minute, Cooldown 30s. Ergebnis: Ein kurzer Aussetzer wird abgefedert, ein echter Outage führt zu schnellem, kontrolliertem Verhalten statt System-Death-Spiral.
1. Timeouts sind Kapazitäts-Schutz: ohne sie riskierst du Queue-Backlog und Kaskaden.
2. Retries nur für transiente Fehler, mit backoff+jitter und nur bei (quasi) idempotenten Aktionen.
3. Circuit Breaker verhindert „Retry-Storms“ und erzwingt fail fast oder sinnvolle Degradation.
Du betreibst einen Agenten, der ein Drittanbieter-Tool für „Create Ticket“ nutzt. Das Tool liefert sporadisch 503 und braucht manchmal 8–12 Sekunden. Welche Kombination aus Timeout/Retry/Circuit Breaker ist sinnvoll, und warum ist ein blindes Retry riskant?
Setze ein Tool-Timeout (z.B. 3–5s) und erlaube wenige Retries nur bei 503/Timeout mit exponentiellem Backoff und Jitter. Ergänze einen Circuit Breaker, der bei anhaltenden Fehlern öffnet und fail-fast/degradiert (z.B. Queue für später, human handoff). Blindes Retry ist riskant, weil „Create Ticket“ nicht sicher idempotent ist, du könntest Duplikate erzeugen, und bei Outage erzeugst du zusätzlich Last (Retry-Storm).