Fehlerbehandlung & Fallbacks

In Multi-Agent-Systemen können und werden Fehler auftreten — LLM-Timeouts, ungültige Outputs, Rate Limits, Netzwerkfehler. Ein robustes System stürzt nicht ab, sondern degradiert graceful. Dieses Kapitel zeigt die wichtigsten Patterns für resiliente n8n Multi-Agent-Pipelines.

Circuit Breaker Pattern

Der Circuit Breaker verhindert, dass ein fehlerhafter Agent das gesamte System blockiert:

         ┌─────────────┐
         │   CLOSED     │ ← Normal: Anfragen gehen durch
         │ (Fehler < 3) │
         └──────┬──────┘
                │ 3 Fehler in Folge
                ▼
         ┌─────────────┐
         │    OPEN      │ ← Blockiert: Anfragen werden sofort abgelehnt
         │ (30s Pause)  │
         └──────┬──────┘
                │ Nach 30 Sekunden
                ▼
         ┌─────────────┐
         │ HALF-OPEN    │ ← Test: Eine Anfrage wird durchgelassen
         │ (1 Versuch)  │
         └─────────────┘

Implementation in n8n

{
  "function": "const state = $getWorkflowStaticData('global');\nconst agent = 'researcher';\nconst failures = state[agent + '_failures'] || 0;\nconst lastFailure = state[agent + '_last_failure'] || 0;\nconst now = Date.now();\n\nif (failures >= 3 && now - lastFailure < 30000) {\n  return [{ json: { circuit: 'OPEN', fallback: true } }];\n}\nreturn [{ json: { circuit: 'CLOSED', proceed: true } }];"
}

Retry-Strategien

Nicht jeder Fehler erfordert einen sofortigen Fallback — viele sind transient:

n8n Retry-Konfiguration

n8n bietet native Retry-Optionen für jeden Node:

• Retry on Fail: Aktivieren pro Node
• Max Tries: 3 (empfohlen)
• Wait Between Tries: Exponential Backoff (1000ms Basis)

Fallback Agents

Wenn der primäre Agent trotz Retries fehlschlägt, übernimmt ein Fallback:

Fallback-Kette in n8n

Primärer Agent → (Fehler?) → Fallback Agent 1 → (Fehler?) → Fallback Agent 2 → (Fehler?) → Default Response

Verwenden Sie den n8n Error Trigger Node, um nach einem fehlgeschlagenen Sub-Workflow automatisch den Fallback zu starten.

Dead Letter Queues

Anfragen, die nach allen Retries und Fallbacks fehlschlagen, landen in der Dead Letter Queue (DLQ):

CREATE TABLE dead_letter_queue (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  pipeline_id UUID NOT NULL,
  agent_name TEXT NOT NULL,
  input_data JSONB NOT NULL,
  error_message TEXT,
  retry_count INTEGER DEFAULT 0,
  created_at TIMESTAMPTZ DEFAULT now(),
  resolved_at TIMESTAMPTZ,
  resolution TEXT -- 'retried', 'manual', 'discarded'
);

Alerting

Konfigurieren Sie Alerts für kritische Fehler:

Praxis-Tipp: Implementieren Sie zuerst einfache Retries (3×, exponential backoff) und einen Default-Fallback. Das fängt 95 % der Fehler ab. Circuit Breaker und DLQ fügen Sie hinzu, wenn Ihr System in Production läuft und Sie reale Fehlermuster sehen.