Multi-Agent-KI-Architektur in der Praxis: Designmuster und Produktionsleitfaden

Zwischen 2024 und 2025 wanderten Agenten aus dem Labor in die Produktion. Viele Teams packten alle Aufgaben in einen LLM-Agenten — und erlebten beim Skalieren einen strukturellen Kollaps. Die Ursachen sind architektonisch, nicht modellbedingt:

• Kontextfenster-Obergrenzen: Zwischenzustände füllen das Fenster; die Reasoning-Qualität bricht ein.
• Generalist-Problem: Ein Agent für Suche, Code und Audit beherrscht keines davon tief.
• Keine Parallelität: Gesamtlatenz = Summe aller Schrittlatenzen.
• Single Point of Failure: Ein fehlerhafter Modellaufruf stoppt den gesamten Workflow.

Googles interner Agent Bake-Off (MLflow-Produktionsleitfaden 2026) zeigte: dekomponierte Multi-Agent-Architekturen reduzierten die Verarbeitungszeit von einer Stunde auf zehn Minuten — Faktor 6. AdaptOrch (2026) belegt formal: die Orchestrierungstopologie hat größeren Einfluss auf die Systemleistung als die Wahl des Basismodells, mit 12–23 % Verbesserung bei passender Topologie auf SWE-bench und vergleichbaren Benchmarks.

• Fehlende Handoff-Validierung: Halluzinationen eines Agenten werden zur „Ground Truth" des nächsten.
• HTTP-200-Falle: Laut MAST-Analyse (1.642 Traces) betreiben 57 % der Organisationen Agenten in Produktion, nur 8 % haben Observability vollständig implementiert.
• Kostenexplosion: Retry-Schleifen und Tool-Spiralen können die Kosten pro Task um Größenordnungen steigern.
• Over-Engineering: Eine Zwei-Schritt-LLM-Kette in acht Agenten zu zerlegen, erhöht die Debug-Komplexität exponentiell.

Ein MAS ist eine Sammlung unabhängiger KI-Agenten, die über definierte Kommunikationsprotokolle und Orchestrierung zusammenarbeiten, um Aufgaben zu lösen, die kein einzelner Agent effizient bewältigen kann.

Drei Kontrolltopologien dominieren: zentralisiert (Orchestrator, auditierbar, aber Bottleneck), dezentralisiert (Peer-to-Peer, resilient, schwer debugbar) und hierarchisch (Supervisor-of-Supervisors, Kompromiss aus Kontrolle und Skalierung).

Über 95 % produktiver Multi-Agent-Systeme lassen sich mit diesen Mustern beschreiben.

Muster 1: Sequential Pipeline

Ausgabe von Agent A wird Eingabe von Agent B — strikt linear. Geeignet bei harten Abhängigkeiten, festen Workflows und Compliance-Audit. Nachteil: Gesamtlatenz = Summe der Schritte; ein Fehler blockiert alles Downstream.

from langgraph.graph import StateGraph, START, END
from typing import TypedDict

class PipelineState(TypedDict):
    query: str
    retrieved_docs: str
    analysis: str
    final_report: str

def retrieval_agent(state: PipelineState):
    docs = search_knowledge_base(state["query"])
    return {"retrieved_docs": docs}

def analysis_agent(state: PipelineState):
    result = llm.invoke(f"Analyze: {state['retrieved_docs']}")
    return {"analysis": result.content}

builder = StateGraph(PipelineState)
builder.add_node("retriever", retrieval_agent)
builder.add_node("analyzer", analysis_agent)
builder.add_edge(START, "retriever")
builder.add_edge("retriever", "analyzer")
builder.add_edge("analyzer", END)
pipeline = builder.compile()

Muster 2: Parallel Fan-out / Fan-in

Unabhängige Sub-Tasks laufen parallel; ein Synthesizer aggregiert. Latenz wird max(T1, T2, …, Tn). LangGraphs Send API mit Annotated[list, operator.add] merged parallele Ergebnisse ohne manuelle Synchronisation.

Muster 3: Hierarchical Supervisor-Worker

Der Supervisor erkennt Intent, zerlegt Tasks und routet. Zwei-Stufen-Routing: Keyword-Fast-Path (<1 ms, ohne LLM) plus LLM-Fallback für mehrdeutige Anfragen.

KEYWORD_ROUTING = {
    "code": "code_agent",
    "search": "search_agent",
    "data": "data_agent",
}

def supervisor_with_fast_path(state):
    query = state["query"].lower()
    for keyword, agent_name in KEYWORD_ROUTING.items():
        if keyword in query:
            return {"next": agent_name}
    decision = llm.invoke(f"Route request: {state['query']}")
    return {"next": decision.content.strip()}

Muster 4: Swarm (Peer-to-Peer)

Agenten kommunizieren ohne zentralen Koordinator. Sinnvoll für mehrstufige Debatten (Code-Review), aber hoch nicht-deterministisch — in Produktion nur mit harten max_round-, Timeout- und Konsensregeln.

Muster 5: Blackboard Architecture

Gemeinsamer strukturierter Workspace; Agenten lesen/schreiben autonom, wenn Vorbedingungen erfüllt sind. Ideal für stunden- bis tagelange asynchrone Jobs und heterogene Team-Services.

Muster 6: Hybrid

Intent Router leitet einfache Queries direkt; komplexe Reports durchlaufen Supervisor mit parallelem Research-Fan-out plus Quality-Pipeline inklusive Human Approval.

LangGraph für regulierte Branchen, Long-Running-Workflows und feingranulare Human-Checkpoints. CrewAI für 1–2-Tage-Prototypen mit intuitiven Rollen. AutoGen bei Microsoft/Azure-Stack und iterativer Konversation.

Zitierfähige Kennzahl 1: Agent Bake-Off — 6× schnellere Verarbeitung (60 min → 10 min) durch Multi-Agent-Dekomposition.

Zitierfähige Kennzahl 2: AdaptOrch — richtige Topologie liefert 12–23 % Verbesserung über Coding-, Reasoning- und RAG-Benchmarks.

Zitierfähige Kennzahl 3: MAST — 41,77 % Systemdesign-Fehler, 36,94 % Inter-Agent-Misalignment, 21,30 % Verifikationsfehler.

2026 standardisiert die Agentic AI Foundation (Linux Foundation) zwei komplementäre Schichten: MCP (vertikal) für Agent↔Tools/DBs/APIs und A2A (horizontal) für Agent↔Agent-Delegation und Capability Discovery. Analog zu TCP und HTTP — unterschiedliche Layer, gemeinsamer Stack.

async def discover_and_delegate(agent_url: str, task: str):
    card = (await httpx.get(f"{agent_url}/.well-known/agent.json")).json()
    skills = [s["id"] for s in card["skills"]]
    if "web_research" not in skills:
        raise ValueError("web_research not supported")
    payload = {
        "jsonrpc": "2.0",
        "method": "message/send",
        "id": "task-001",
        "params": {"message": {"role": "user", "parts": [{"type": "text", "text": task}]}}
    }
    return (await httpx.post(card["url"], json=payload)).json()

A2A: Google-April-2025-Launch, v1.0 Anfang 2026, 50+ Partner (Atlassian, Salesforce, SAP). MCP-Details: MCP Deep Dive.

• State Persistence: LangGraph PostgresSaver mit thread_id — Recovery nach Prozessneustart.
• Human-in-the-Loop: interrupt() vor Hochrisiko-DB-Änderungen.
• Circuit Breaker: Nach Schwellenwert-Fehlern Zustand OPEN — externe Agent-Aufrufe blockiert.
• Token Budget: TokenBudgetManager erzwingt Obergrenzen pro Agent und Request.

MAX_ITERATIONS = 10
MAX_TOOL_CALLS_PER_AGENT = 20
MAX_TOTAL_TOKENS = 50_000

graph = builder.compile(
    checkpointer=checkpointer,
    interrupt_before=["high_cost_tool"]
)

Empirisch optimal: 3–8 Agenten pro Produktionssystem. Darüber überwiegt Koordinations-Overhead den Nutzen.

OpenTelemetry-correlation_id über Agent-Grenzen hinweg propagieren. Kernmetriken: task_success_rate (Ziel >85 %), e2e_latency_p95 (<30 s), agent_error_rate (Alarm >5 %), hallucination_rate. LLM-as-a-Judge bewertet Vollständigkeit, Genauigkeit und Halluzinationen als JSON.

• Context Pollution: JSON-Schema- und confidence_score-Validierung an jedem Handoff.
• Runaway Loops: Harte Caps für Iterationen, Tool-Calls und Tokens.
• Over-Engineering: Mit Sequential Pipeline starten; Agenten nur bei messbarem Bedarf hinzufügen.
• Demo-to-Production Gap: Input-Limits, Prompt-Injection-Erkennung, PII-Redaktion, Content-Klassifikation.
• Parallel-Sync (LangGraph): Supervisor-Node mit defer=True, damit alle Branches abgeschlossen sind.

Strikte sequenzielle Abhängigkeiten? → Bei Parallelisierbarkeit Fan-out-Hybrid, sonst Sequential Pipeline. Keine sequenzielle Abhängigkeit, aber Entscheidungsautorität? → Supervisor-Worker oder mehrschichtige Hierarchie. Lang laufend und asynchron? → Blackboard. Kleine Agentenzahl mit klaren Terminierungsregeln? → Swarm (begrenzt), sonst hierarchisch restrukturieren.

• Orchestrierungstopologie schlägt Modellwahl (AdaptOrch)
• Einfach beginnen: Sequential Pipeline, dann Parallelität und Hierarchie
• MCP + A2A als Standard in neuen Projekten
• Observability ist Pflicht: 57 % vs 8 %-Lücke ist die Unfallursache
• Jeder Handoff = versionierte API mit Schema-Validierung

Trends: Federated Orchestration, multimodale Multi-Agent-Systeme, adaptive Topologie-Auswahl (AdaptOrch), EU AI Act mit verpflichtenden Entscheidungs-Audit-Trails.

1. 01
   Muster und Framework festlegen: Regulierte Long-Running-Workflows → LangGraph; schneller Rollen-Prototyp → CrewAI. MCP-Tools gemäß MCP-Server-Leitfaden als separaten Server auslagern.
2. 02
   Cloud-Mac provisionieren: In der NUKCLOUD-Konsole Knoten mit 16 GB+ RAM wählen (32 GB bei drei oder mehr parallelen Workern). Stundenweise testen über Preise.
3. 03
   Runtime installieren: Per SSH pip install langgraph langchain-openai mcp httpx opentelemetry-sdk. Postgres-Connection-String für Checkpoints als Umgebungsvariable setzen.
4. 04
   Graph deployen und Checkpoint prüfen: PostgresSaver mit thread_id auf Recovery testen. MCP-Server per stdio (lokal) oder HTTP+SSE (Team) mit Bearer Token starten.
5. 05
   Observability und Guardrails: OpenTelemetry-Exporter, Token-Budget, Circuit Breaker, Handoff-Schema-Validierung unter Last testen. Alarme für task_success_rate und e2e_latency_p95. Hilfe: Hilfe-Center.
6. 06
   Produktion fixieren: launchd-Plist für 7×24-Betrieb, dann Spezifikation über Bestellen sichern. Siehe NUKCLOUD Produktions-Runbook.

Auf Laptops oder geteilten VPS treten bei Multi-Agent-Stacks häufig SSE-Abbrüche bei Langverbindungen, Bandbreiten-Jitter und Prozess-Konkurrenz zwischen Entwicklern auf. Für 7×24-Betrieb von Cursor Background Agents oder MCP+A2A-Stacks bieten NUKCLOUD Multi-Region Bare-Metal Mac / Cloud-Mac-Knoten mit dedizierten Tenant-Grenzen und elastischen Specs die stabilere Basis.