Mehrere KI-Agenten einsetzen: Wann ein Agent nicht reicht

Die erste Multi-Agenten-Lösung entstand bei uns eher zufällig. Anfangs war nur ein KI-Agent zuständig, der Dokumente analysieren, Daten extrahieren, validieren und Zusammenfassungen erstellen sollte. In Demonstrationen funktionierte das reibungslos. Doch in der Produktion trat ein Problem auf: Der Agent halluzinierte in etwa 15 % der Fälle während der Validierungsphase. Der Grund? Ein einzelner Kontextfenster war mit zu vielen Aufgaben überlastet und verlor den roten Faden. Die Lösung lag nicht in besserem Prompting, sondern darin, die Arbeit auf mehrere Agenten zu verteilen – jeder mit einer klaren, einzelnen Aufgabe.

Diese Erfahrung prägte unsere Herangehensweise an Multi-Agenten-Systeme nachhaltig. Heute betrachten wir diese Architektur nicht als exotische Lösung, sondern als logische Antwort auf spezifische Herausforderungen: wenn Aufgaben zu komplex für einen einzigen Kontext sind, wenn unterschiedliche Teilschritte verschiedene Modelle oder Tools benötigen oder wenn parallele Verarbeitung erforderlich ist, um Engpässe zu vermeiden.

Woran Sie erkennen, dass ein einzelner Agent nicht ausreicht

Ein einzelner KI-Agent zeigt in der Praxis typische Schwächen. Häufig verliert er den Überblick über frühere Kontextinformationen, wenn er später im Prozess angelangt. Oft überspringt er Validierungsschritte oder führt sie nur unzureichend aus, weil er sich auf die Vollendung vorheriger Aufgaben konzentriert. Zudem stoßen lange Workflows schnell an die Grenzen des Kontextfensters.

Ein einfacher Test hilft bei der Entscheidung: Wenn ein Workflow mehr als drei klar getrennte Rollen erfordert – etwa „Du bist ein Rechercheur, gleichzeitig Kritiker und Zusammenfasser“ –, dann sind drei Agenten die bessere Wahl.

Unser Auswahlkriterium ist simpel: Lässt sich der Ablauf als eine Abfolge von Übergaben beschreiben – Agent A liefert Ausgabe X, Agent B nimmt X und erzeugt Y – dann bauen wir es als Multi-Agenten-System. Handelt es sich hingegen um einen durchgehenden Reasoning-Prozess mit Tool-Aufrufen, reicht ein einzelner Agent aus.

Agenten-Pipelines in Django strukturieren

Unsere typische Multi-Agenten-Architektur setzt auf Celery zur Orchestrierung. Jeder Agent wird als separate Aufgabe implementiert. Der Orchestrator-Agent entscheidet über die Reihenfolge der Ausführung, während die Worker-Agenten die eigentliche Arbeit übernehmen. Hier ein vereinfachtes Beispiel aus unserem Code:

from celery import shared_task
from .agents import ResearchAgent, ValidationAgent, SummaryAgent

@shared_task
def run_document_pipeline(document_id: str) -> dict:
    """Orchestrator: Führt die gesamte Multi-Agenten-Pipeline aus."""
    document = Document.objects.get(id=document_id)

    # Schritt 1: Strukturierte Datenextraktion
    research_result = research_agent_task.delay(document.content)
    extracted = research_result.get(timeout=60)

    # Schritt 2: Validierung (separater Agent mit frischem Kontext)
    validation_result = validation_agent_task.delay(extracted)
    validated = validation_result.get(timeout=30)

    if not validated["is_valid"]:
        raise ValueError(f"Validierung fehlgeschlagen: {validated['reason']}")

    # Schritt 3: Zusammenfassung generieren
    summary = summary_agent_task.delay(validated["data"])
    return summary.get(timeout=45)

@shared_task
def research_agent_task(content: str) -> dict:
    agent = ResearchAgent()
    return agent.run(content)

@shared_task
def validation_agent_task(data: dict) -> dict:
    agent = ValidationAgent()
    return agent.run(data)

Jeder Agent-Klasse verwaltet ihren eigenen System-Prompt und die Modellkonfiguration. Entscheidend ist: Agenten teilen sich keinen Kontext. Agent B erhält ausschließlich das, was Agent A explizit zurückgibt – nicht den gesamten Gesprächsverlauf. Diese strikte Trennung verhindert Fehlerfortpflanzung und hält jeden Prompt fokussiert.

Ausfälle verhindern: Robuste Fehlerbehandlung

Fehlermodi in Multi-Agenten-Systemen unterscheiden sich deutlich von denen einzelner Agenten. Ein Agent kann scheitern, ohne dass dies offensichtlich wird – etwa indem er plausible, aber falsche Ergebnisse liefert. Der nachgelagerte Agent hat keine Möglichkeit, dies zu erkennen.

Wir begegnen diesem Risiko durch explizite Validierungskontrakte zwischen den Agenten. Vor jeder Übergabe wird die Ausgabe schema-konform geprüft. Dafür nutzen wir Pydantic:

from pydantic import BaseModel, ValidationError
from typing import Optional

class ExtractionOutput(BaseModel):
    company_name: str
    revenue_figure: float
    reporting_period: str
    confidence_score: float
    raw_excerpt: Optional[str] = None

def research_agent_task(content: str) -> dict:
    agent = ResearchAgent()
    raw_output = agent.run(content)

    try:
        validated = ExtractionOutput(**raw_output)
        return validated.model_dump()
    except ValidationError as e:
        # Protokollieren und mit Klärungs-Prompt neu versuchen
        logger.error(f"Forschungsagent-Ausgabe scheiterte an Validierung: {e}")
        refined = agent.run_with_clarification(content, str(e))
        return ExtractionOutput(**refined).model_dump()

Falls die Validierung auch nach einem erneuten Versuch fehlschlägt, wird die Aufgabe abgebrochen und Celery übernimmt die erneute Ausführung mit exponentiellem Backoff. So stellen wir sicher, dass fehlerhafte Daten niemals unbemerkt an nachgelagerte Schritte weitergegeben werden.

Parallele Agenten: Wenn Sequentialität nicht nötig ist

Nicht alle Multi-Agenten-Pipelines arbeiten sequenziell. Manche Aufgaben lassen sich parallelisieren. Für einen Kunden aus der Marktforschung setzen wir beispielsweise drei Analyse-Agenten gleichzeitig ein – einer für Stimmungsanalyse, einer für Entitätenextraktion und einer für Trenderkennung. Die Ergebnisse aller drei Agenten werden anschließend an einen Synthese-Agenten übergeben.

from celery import group

@shared_task
def run_parallel_analysis(article_ids: list[str]) -> dict:
    # Parallelisierung der Agenten
    analysis_group = group(
        sentiment_agent_task.s(article_id),
        entity_agent_task.s(article_id),
        trend_agent_task.s(article_id),
        for article_id in article_ids
    )
    results = analysis_group.apply_async().get(timeout=120)

    # Synthese-Agent erhält alle Ergebnisse
    return synthesis_agent_task.delay(results).get(timeout=60)

Der Synthese-Agent benötigt in seinem System-Prompt keine Kenntnis darüber, wie die einzelnen Ergebnisse generiert wurden – nur deren Schemata. Diese Entkopplung vereinfacht die Implementierung und Wartung.

Grenzen der Multi-Agenten-Systeme

Multi-Agenten-Systeme bringen zwar Vorteile, aber auch neue Herausforderungen mit sich. Die Koordination mehrerer LLM-Aufrufe pro Nutzeranfrage führt zu höherer Latenz und Kosten. Eine Pipeline, die drei Agenten sequenziell ausführt, ist für einfache Aufgaben langsamer als ein einzelner Agent. Wir nutzen dieses Muster daher nur, wenn die Aufgabe es tatsächlich erfordert – nicht als Standardarchitektur.

Auch die Fehlerbehebung wird komplexer. Wenn ein Ergebnis falsch ist, kann der Ursprung in jedem Agenten liegen. Wir begegnen diesem Problem durch strukturierte Protokollierung jeder Agentenausführung (Eingabe, Ausgabe, Token-Zählung, Latenz), doch die Nachverfolgung bleibt aufwendiger als bei einem einzelnen Agenten.

Multi-Agenten-Systeme sind kein Allheilmittel. Sie lohnen sich dort, wo komplexe Aufgaben, unterschiedliche Tool-Anforderungen oder Parallelverarbeitung den Aufwand rechtfertigen. Die Entscheidung für diese Architektur sollte immer auf einer klaren Analyse der Anforderungen basieren.