Produktionssichere Multi-Agenten-Systeme: Was die Demos nicht zeigen

Jede Multi-Agenten-Demo sieht aufgeräumt aus. Produktion ist nicht aufgeräumt. Dieser Artikel behandelt Fehlerbehandlung, Speicherisolierung, Audit-Logging und Human-in-the-Loop-Muster.

Jede Multi-Agenten-Demo auf X/Twitter sieht aufgeräumt aus. Ein Agent ruft ein Tool auf, ein anderer verarbeitet die Ausgabe, ein dritter synthetisiert das Ergebnis. Die Demo ist in 8 Sekunden fertig. Wunderschön. Produktion ist nicht wunderschön. In der Produktion laufen Tools in Timeouts, APIs geben unerwartete Schemas zurück, Agenten loopen ewig, und niemand hat gesagt, dass man ein Rekursionslimit setzen soll. Dieser Artikel behandelt die Muster, die bei jedem echten Multi-Agenten-Deployment implementiert werden, um sie tatsächlich zuverlässig zu machen.

Die Demo-to-Production-Lücke

Demos laufen in einer sauberen Umgebung mit gemockten oder zuverlässigen Daten. Produktionssysteme sehen sich konfrontiert mit: Tool-Calls, die 2 % der Zeit fehlschlagen (was sich über 20 Schritte akkumuliert), LLM-Antworten, die gelegentlich vom erwarteten Format abweichen, nachgelagerten APIs, die langsam oder nicht verfügbar sind, und Nutzern, die dem System Eingaben geben, für die es nie konzipiert wurde. Nichts davon erscheint in einer Demo.

Muster 1: Strukturierte Fehlerbehandlung

Jeder Tool-Call muss einen definierten Fehlermodus haben. Alle Tool-Invocations werden in eine Retry-with-Backoff-Schicht mit maximaler Anzahl an Versuchen eingewickelt, und jedes Tool gibt ein getyptes Ergebnis zurück, das einen Fehlerzustand enthält. Der Agent wird explizit angewiesen, Tool-Fehler zu behandeln — er soll nicht blind nochmal versuchen, sondern überlegen, ob der Fehler wiederholbar ist, auf einen alternativen Ansatz zurückgreifen oder den Fehler an einen Menschen weitergeben.

# Typed tool result with error state
from pydantic import BaseModel
from typing import Any, Optional

class ToolResult(BaseModel):
    success: bool
    data: Optional[Any] = None
    error: Optional[str] = None
    retryable: bool = True

# Agent system prompt addition
TOOL_ERROR_INSTRUCTION = """
If a tool returns success=false:
1. Check if retryable=true. If so, retry once after 2s.
2. If still failing, try an alternative approach.
3. If no alternative exists, respond with:
   {"status": "blocked", "reason": "<specific error>", "needs_human": true}
"""

Muster 2: Speicherisolierung

In einem Multi-Agenten-System teilen sich Agenten eine Aufgabe, dürfen aber keinen Speicherzustand teilen, sofern das nicht explizit so konzipiert ist. Gemeinsamer mutabler State ist der Weg, wie Agenten den Kontext des anderen kontaminieren und inkonsistente Ausgaben produzieren. Strikte Speicherisolierung wird erzwungen: Jeder Agent bekommt seinen eigenen abgegrenzten Kontext, und gemeinsamer State lebt in einem externen Speicher (Redis, Postgres) mit expliziten Lese-/Schreiboperationen — nicht implizit durch das Kontextfenster weitergegeben.

Muster 3: Audit-Logging

Jede Agentenaktion muss mit genug Detail geloggt werden, um nachträglich nachvollziehen zu können, was passiert ist. Das ist kein optionales Feature — es ist der Unterschied zwischen einem System, das man debuggen kann, und einer Black Box.

• •agent_id + run_id — welcher Agent, welche Ausführung
• •Input und Output für jeden Tool-Call (PII vor dem Logging anonymisieren)
• •Token-Verbrauch pro Schritt — außer Kontrolle geratene Kosten erkennen, bevor sie die Rechnung treffen
• •Wanduhrzeit pro Schritt — Latenz-Bottlenecks identifizieren
• •Finaler Entscheidungspfad — warum hat der Agent diesen Weg gewählt?

Muster 4: Human-in-the-Loop-Checkpoints

Nicht jede Entscheidung eines Agenten sollte automatisch ausgeführt werden. Vor dem Deployment eines Multi-Agenten-Systems wird eine klare Grenze definiert: Welche Aktionen sind sicher zu automatisieren, und welche erfordern die Genehmigung eines Menschen? Explizite Pause-und-Notify-Checkpoints werden an diesen Grenzen implementiert. Der Agent schließt sein Reasoning ab und schlägt eine Aktion vor — dann wartet er. Ein Mensch genehmigt, modifiziert oder lehnt den Vorschlag ab, bevor er ausgeführt wird.

Muster 5: Rekursions- und Kostenlimits

Immer eine maximale Schrittanzahl setzen. Immer ein Token-Budget pro Ausführung setzen. Das ist kein Engineering-Pessimismus — das sind die Sicherungsschalter, die verhindern, dass ein fehlerhafter Agent die OpenAI-Credits um 3 Uhr morgens an einem Sonntag erschöpft. LangGraph hat eingebaute Rekursionslimits. Wenn eine eigene Orchestrierung gebaut wird, sollte das als Erstes hinzugefügt werden.

Praktische Pre-Production-Checkliste

• •☐ Jeder Tool-Call hat einen getypten Rückgabewert einschließlich Fehlerzustand
• •☐ Retry-Logik mit Backoff ist implementiert und getestet
• •☐ Maximale Schrittanzahl und Token-Budget sind konfiguriert
• •☐ Alle Agentaktionen werden mit run_id, Schritt, Input, Output, Tokens, Dauer geloggt
• •☐ Human-in-the-Loop-Checkpoints sind für hochriskante Aktionen definiert
• •☐ Speicherisolierung wird erzwungen — Agenten teilen keinen mutablen Kontext
• •☐ Ein Dashboard zeigt Agenten-Runs, Fehler und Kosten in Echtzeit