KI-Agenten mit mehreren Modellen entwickeln: Ein praktischer Architektur-Leitfaden

Die meisten KI-Agenten verlassen sich auf ein einziges Modell, um jede Phase der Ausführung zu bewältigen. Der Planungsschritt, die Tool-Aufrufe, die Datenextraktion, die Zusammenfassung und die Fehlerbehebung laufen alle über dasselbe LLM. Während dieser Ansatz für erste Prototypen unkompliziert ist, führt er in Produktionsumgebungen zu erheblichen Ineffizienzen.

Ein Planungsschritt, der tiefgreifendes logisches Denken erfordert, benötigt nicht dasselbe Modell wie ein einfacher JSON-Extraktionsschritt. Eine Aufgabe zur Code-Generierung hat andere Anforderungen als eine Klassifizierungsaufgabe. Die Verwendung eines High-End-Modells wie Claude Fable 5 oder Claude Opus 4.8 zur Formatierung eines Datums-Strings ist eine teure Fehlallokation von Ressourcen.

Wenn Sie KI-Agenten mit mehreren Modellen aufbauen, können Sie jeden Schritt eines Workflows an das Modell weiterleiten, das für diese spezifische Aufgabe am besten geeignet ist. Dieser Leitfaden untersucht, wie man solche Multi-Modell-Architekturen entwirft, implementiert und verwaltet.

Wenn Sie eher an der API-Ebene als an der Orchestrierungsebene für Agenten arbeiten, lesen Sie neben diesem Leitfaden auch Agent-First API Design und Warum Teams von direkten Modell-APIs zu einer Unified AI API wechseln. Multi-Modell-Agenten arbeiten am zuverlässigsten, wenn die zugrunde liegende API-Oberfläche stabil genug ist, um Modelle auszutauschen, ohne den Orchestrierungscode neu schreiben zu müssen.

:::info

Wichtige Erkenntnisse

1. Modell an Aufgabenkomplexität anpassen: Verwenden Sie kleine, schnelle Modelle für Routing, Extraktion und Formatierung und reservieren Sie größere Modelle für Planung und komplexe Analysen.
2. Schemas standardisieren: Implementieren Sie bei jedem Übergabepunkt eine strikte Ausgabeprüfung (z. B. Pydantic), um Vertragsabweichungen beim Wechsel zwischen verschiedenen Modellanbietern zu vermeiden.
3. Fallback-Strategien entwerfen: Erstellen Sie automatisierte Fallback-Pfade, um Rate-Limits, Ausfälle von Anbietern oder Latenzspitzen zu bewältigen, ohne den Agenten-Workflow zu unterbrechen.
4. Telemetrie zentralisieren: Verfolgen Sie Latenz, Input/Output-Token-Anzahl und Kosten pro Schritt, um Ihre Routing-Logik kontinuierlich zu optimieren. :::

---

Die Multi-Modell-Agenten-Architektur

Eine Multi-Modell-Agenten-Architektur verteilt Aufgaben basierend auf Komplexität, Kosten und Latenzanforderungen auf spezialisierte Modelle.

Benutzeranfrage
    │
    ▼
┌─────────────┐
│   Router     │  ← Klassifiziert Aufgabenkomplexität
│  (schnelles Modell)│
└──────┬──────┘
       │
   ┌───┴───┐
   ▼       ▼
┌──────┐ ┌──────┐
│Einfaches│ │Komplexes│
│Modell │ │Modell  │
└──┬───┘ └──┬───┘
   │        │
   ▼        ▼
┌─────────────┐
│  Aggregator  │  ← Kombiniert Ergebnisse
│  (schnelles Modell)│
└─────────────┘

Die Kernarchitektur besteht aus fünf Hauptkomponenten:

1. Der Router: Ein schnelles, kostengünstiges Modell, das eingehende Aufgaben nach Komplexität und Absicht klassifiziert.
2. Der Modell-Pool: Eine Sammlung von Modellen, die auf verschiedene Aufgabentypen abgestimmt sind (z. B. Reasoning, Extraktion oder Code-Generierung).
3. Der Aggregator: Ein schnelles Modell, das Ergebnisse aus parallelen Schritten zu einer finalen Antwort zusammenführt.
4. Die Fallback-Richtlinie: Regeln, die festlegen, welches Modell verwendet werden soll, wenn die primäre Wahl fehlschlägt, ein Timeout auftritt oder Rate-Limits erreicht werden.
5. Die Telemetrie-Ebene: Ein Protokollierungssystem, das Modellentscheidungen, Latenz und exakte Token-Kosten pro Schritt aufzeichnet.

Ohne Fallback-Richtlinien und Telemetrie kann ein Multi-Modell-Agent schwer zu debuggen sein und unvorhersehbare Latenz- und Kostenprofile aufweisen.

---

Implementierung mit dem OpenAI SDK

Die Verwendung eines einheitlichen API-Gateways ermöglicht es Ihnen, auf Modelle verschiedener Anbieter über ein einziges SDK und einen API-Schlüssel zuzugreifen. Dies vereinfacht den Modellwechsel und das Routing.

Das folgende Beispiel demonstriert eine grundlegende Routing-Implementierung. Modellverfügbarkeit und Preise sollten im TokenLab-Modellverzeichnis überprüft werden.

from openai import OpenAI

client = OpenAI(
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Modell-Pool mit Kosten- und Fähigkeitsstufen
MODELS = {
    "router": "deepseek-v4-flash",        # Schnelle Klassifizierung
    "simple": "deepseek-v4-flash",        # Extraktion, Formatierung
    "reasoning": "claude-sonnet-5",       # Planung, Analyse
    "complex": "gpt-5.5",                 # Code-Generierung, komplexe Logik
    "budget": "deepseek-v4-flash",        # Massenverarbeitung
}

def route_task(task: str) -> str:
    """Verwendet ein kostengünstigeres Modell zur Klassifizierung der Aufgabenkomplexität."""
    response = client.chat.completions.create(
        model=MODELS["router"],
        messages=[
            {"role": "system", "content": """Klassifiziere diese Aufgabe in genau eine Kategorie:
- simple: Datenextraktion, Formatierung, Übersetzung
- reasoning: Analyse, Planung, Vergleich
- complex: Code-Generierung, mehrstufige Problemlösung
- budget: Massenverarbeitung, nicht-kritische Aufgaben
Antworte nur mit dem Kategorienamen in Kleinbuchstaben."""},
            {"role": "user", "content": task}
        ],
        max_tokens=10
    )
    category = response.choices[0].message.content.strip().lower()
    return MODELS.get(category, MODELS["simple"])

def execute_task(task: str, context: str = "") -> str:
    """Leitet die Aufgabe an das ausgewählte Modell weiter und führt sie aus."""
    model = route_task(task)
    messages = []
    if context:
        messages.append({"role": "system", "content": context})
    messages.append({"role": "user", "content": task})

    response = client.chat.completions.create(
        model=model,
        messages=messages
    )
    return response.choices[0].message.content

---

Praxisbeispiel: Code-Review-Pipeline

Um die praktischen Auswirkungen von KI-Agenten mit mehreren Modellen zu sehen, betrachten wir eine Pipeline zur Überprüfung von Pull Requests. Dieser Workflow unterteilt die Überprüfung in spezialisierte Schritte, anstatt den gesamten Code-Diff an ein einziges teures Modell zu senden.

def review_pr(diff: str) -> dict:
    """Multi-Modell PR-Review-Pipeline."""

    # Schritt 1: Klassifizierung der Änderungen mit einem schnellen, kostengünstigen Modell
    classification = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Klassifiziere diese Code-Änderungen: {diff[:2000]}\n"
                       "Kategorien: bugfix, feature, refactor, docs, test"
        }],
        max_tokens=20
    ).choices[0].message.content

    # Schritt 2: Sicherheits-Scan mit einem starken Reasoning-Modell
    security = client.chat.completions.create(
        model="claude-sonnet-5",
        messages=[{
            "role": "system",
            "content": "Du bist ein Sicherheits-Reviewer. Prüfe auf: "
                       "SQL-Injection, XSS, Auth-Bypass, Secrets im Code, "
                       "unsichere Deserialisierung. Sei spezifisch bei Zeilennummern."
        }, {
            "role": "user",
            "content": f"Überprüfe diesen Diff auf Sicherheitsprobleme:\n{diff}"
        }]
    ).choices[0].message.content

    # Schritt 3: Analyse der Code-Qualität mit einem Allzweck-Modell
    quality = client.chat.completions.create(
        model="gpt-5.5",
        messages=[{
            "role": "user",
            "content": f"Überprüfe die Code-Qualität: Benennung, Struktur, "
                       f"Fehlerbehandlung, Testabdeckung.\n{diff}"
        }]
    ).choices[0].message.content

    # Schritt 4: Zusammenfassung mit einem schnellen, kostengünstigen Modell
    summary = client.chat.completions.create(
        model="deepseek-v4-flash",
        messages=[{
            "role": "user",
            "content": f"Fasse dieses PR-Review in 3 Stichpunkten zusammen:\n"
                       f"Typ: {classification}\n"
                       f"Sicherheit: {security[:500]}\n"
                       f"Qualität: {quality[:500]}"
        }]
    ).choices[0].message.content

    return {
        "classification": classification,
        "security": security,
        "quality": quality,
        "summary": summary
    }

Kosten- und Effizienzoptimierung

Die folgende Tabelle skizziert die Modellzuweisung für diese Pipeline. Die genauen Preise variieren je nach Anbieter und Volumen; überprüfen Sie die aktuellen Tarife im TokenLab-Modellverzeichnis.

Schritt	Modell	Input-Token	Rolle / Spezialisierung
1. Klassifizieren	DeepSeek V4 Flash	~2.100	Schnelle Klassifizierung, kostengünstiges Routing
2. Sicherheit	Claude Sonnet 5	~2.500	Tiefgründiges Reasoning, Sicherheitsanalyse
3. Qualität	GPT-5.5	~2.500	Fortgeschrittene Code-Qualität und strukturelle Prüfung
4. Zusammenfassung	DeepSeek V4 Flash	~1.200	Schnelle, kostengünstige Text-Aggregation

Das Ausführen aller vier Schritte über ein Flaggschiff-Reasoning-Modell wie Claude Sonnet 5 oder GPT-5.5 würde die Kosten erheblich steigern. Durch das Routing einfacherer Aufgaben an kostengünstigere Modelle wie DeepSeek V4 Flash reduziert die Multi-Modell-Pipeline die Gesamtkosten für Token, während das tiefe Reasoning für den kritischen Sicherheitsanalyseschritt erhalten bleibt.

---

Routing nach Fähigkeiten, nicht nur nach Preis

Obwohl Kostensenkung ein häufiges Ziel ist, sollten Routing-Entscheidungen auch spezifische Modellfähigkeiten berücksichtigen. Eine robuste Routing-Richtlinie bewertet Modelle anhand von vier Schlüsseldimensionen:

• Reasoning-Tiefe: Komplexe Logik, Planung und mehrstufige Schlussfolgerungen.
• Kontextfenster: Das Volumen an Hintergrundinformationen oder Code, das für die Aufgabe erforderlich ist.
• Zuverlässigkeit bei der Tool-Nutzung: Die Genauigkeit von Funktionsaufrufen und der Generierung strukturierter Ausgaben.
• Latenzempfindlichkeit: Die Geschwindigkeitsanforderungen der benutzerseitigen Anwendung.

Diese Dimensionen helfen dabei, klare Routing-Regeln aufzustellen:

• Dekompositions- und Planungsaufgaben werden an Reasoning-starke Modelle geleitet.
• Datenextraktions- und Formatierungsaufgaben werden an schnelle, kostengünstige Modelle geleitet.
• Code-Generierung und Syntaxanalyse werden an Modelle geleitet, die für Coding-Aufgaben optimiert sind.
• Repository-weite Analyseaufgaben werden an Modelle mit großen Kontextfenstern geleitet.

Um Ihren Router auf diese Anforderungen abzustimmen, konsultieren Sie den Vergleich von Coding-Modellen und den Preisvergleich, um Ihre Workflow-Schritte mit aktuellen Modell-Benchmarks abzugleichen.

---

LangChain-Integration

Sie können Multi-Modell-Routing auch innerhalb von Orchestrierungs-Frameworks wie LangChain implementieren. Das folgende Beispiel konfiguriert verschiedene Modelle über eine einheitliche API-Basis-URL:

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

# Initialisierung der Modelle mit unterschiedlichen Konfigurationen
fast_model = ChatOpenAI(
    model="deepseek-v4-flash",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

reasoning_model = ChatOpenAI(
    model="claude-sonnet-5",
    api_key="sk-tokenlab-xxx",
    base_url="https://api.tokenlab.sh/v1"
)

# Definition spezialisierter Chains
classify_chain = ChatPromptTemplate.from_template(
    "Klassifiziere die Absicht dieser Anfrage: {input}"
) | fast_model

analyze_chain = ChatPromptTemplate.from_template(
    "Führe eine detaillierte Analyse dieses Problems durch: {input}"
) | reasoning_model

---

Wann man Multi-Modell-Agenten einsetzen sollte

Die Einführung mehrerer Modelle erhöht die architektonische Komplexität. Dieser Ansatz ist in der Regel am sinnvollsten, wenn:

• Vielfältige Aufgabenanforderungen: Der Agent bewältigt eine Mischung aus einfachen Aufgaben (wie Klassifizierung oder Formatierung) und komplexen Aufgaben (wie strategische Planung oder Code-Generierung).
• Hohes Volumen und Kosten: Die monatlichen API-Ausgaben sind so hoch, dass Optimierungen zu signifikanten Einsparungen führen.
• Spezialisierte Modellstärken: Der Workflow profitiert von spezifischen Stärken der Anbieter, wie dem Kontextfenster von Gemini, den Coding-Fähigkeiten von Claude oder der Geschwindigkeit bei der Tool-Nutzung von GPT.
• Asymmetrische Latenzanforderungen: Bestimmte Teile des Workflows müssen sofort Ergebnisse liefern, während andere Hintergrundschritte länger dauern können.

Für Single-Purpose-Agenten oder einfache Chat-Interfaces ist ein einzelnes Modell oft einfacher zu warten. Der operative Aufwand für das Routing ist möglicherweise nicht gerechtfertigt, wenn jede Anfrage das gleiche Leistungsniveau erfordert.

---

Häufige Fehlermodi

Multi-Modell-Architekturen führen spezifische Fehlermodi ein, die gemindert werden müssen:

1. Übermäßig komplexe Router

Wenn der Router-Prompt zu komplex wird, kann der Klassifizierungsschritt selbst langsam und teuer werden. Halten Sie Routing-Prompts prägnant und Klassifizierungskategorien breit gefächert.

2. Abweichungen im Ausgabevertrag (Output Contract Drift)

Verschiedene Modelle können Ausgaben unterschiedlich formatieren, selbst wenn sie angewiesen werden, JSON zurückzugeben. Ein Modell könnte rohes JSON zurückgeben, während ein anderes es in Markdown-Blöcke einbettet. Um Parser-Fehler nachgelagert zu verhindern, erzwingen Sie strikte Schemas mit Validierungsbibliotheken wie Pydantic bei jedem Übergabeschritt.

3. Stille Qualitätsverschlechterung

Wenn eine Fallback-Richtlinie eine Anfrage während eines Ausfalls eines primären Anbieters an ein Modell niedrigerer Stufe weiterleitet, liefert der Agent möglicherweise Antworten von geringerer Qualität, ohne einen Fehler auszulösen. Die Implementierung einer klaren Rate-Limiting-Strategie und eines Warnsystems hilft dabei, zu verfolgen, wann Fallbacks aktiv sind.

4. Fragmentierte Telemetrie

Wenn die Modellnutzung auf mehrere direkte Anbieter-APIs aufgeteilt ist, wird die Aggregation von Kosten- und Leistungskennzahlen schwierig. Die Zentralisierung der Anfragen über ein einziges Gateway vereinfacht die Protokollierung und Kostenverfolgung.

---

Eine minimale Evaluierungsschleife

Um einen Multi-Modell-Agenten zu warten, etablieren Sie eine grundlegende Evaluierungsschleife, um die Leistung zu verfolgen. Sie können die folgenden Metriken für jeden Durchlauf in einer Datenbanktabelle protokollieren:

• Aufgabenkategorie: Die vom Router zugewiesene Klassifizierung.
• Ausgewähltes Modell: Das für jeden Schritt gewählte Modell.
• Schritt-Latenz: Die Zeit, die für den Abschluss jedes Schritts benötigt wurde.
• Token-Nutzung: Die exakte Anzahl der Input- und Output-Token.
• Fallback-Status: Ob ein Fallback-Modell ausgelöst wurde.
• Benutzerfeedback: Ein binärer Indikator dafür, ob die finale Ausgabe erfolgreich war.

Die Analyse dieser Daten hilft festzustellen, ob der Router die richtigen Modelle auswählt, welche Schritte den Großteil Ihrer Kosten verursachen und ob Fallback-Modelle eine akzeptable Qualität beibehalten.

---

FAQ

Wie gehen Sie mit unterschiedlichen Prompt-Formaten bei verschiedenen Modellen um?

Verschiedene Modelle reagieren am besten auf unterschiedliche Prompt-Strukturen. Zum Beispiel funktionieren einige Modelle besser mit System-Prompts, während andere Anweisungen bevorzugen, die in den Benutzer-Prompt eingebettet sind. Um dies zu handhaben, abstrahieren Sie Ihre Prompts in Vorlagen, die sich an das Zielmodell anpassen, anstatt identische Roh-Strings an jedes Modell in Ihrem Pool zu senden.

Führt Routing zu zu viel Latenz bei benutzerseitigen Anwendungen?

Routing führt zu einer geringen Latenz für den Klassifizierungsschritt. Sie können dies minimieren, indem Sie hochoptimierte Modelle mit geringer Latenz für den Router verwenden, die maximalen Token-Limits niedrig halten (unter 10 Token) oder Schritte parallelisieren, wenn die Klassifizierung aus dem Anwendungsstatus des Benutzers oder dem Einstiegspunkt abgeleitet werden kann.

Wie verhindern Sie JSON-Parsing-Fehler beim Wechsel zwischen Modellen?

Um Parsing-Fehler zu verhindern, verwenden Sie Funktionen für strukturierte Ausgaben (wie JSON-Modus oder Tool-Calling), die von den Modellanbietern unterstützt werden. Wickeln Sie zusätzlich alle Modellausgaben in eine Validierungsschicht mit Pydantic oder ähnlichen Bibliotheken ein, um die Nutzlast zu parsen, zu validieren und zu reparieren, bevor sie an den nächsten Schritt in Ihrer Pipeline weitergegeben wird.

---

Greifen Sie über eine API auf jedes Modell zu: Starten Sie mit TokenLab, um mit einem einzigen API-Schlüssel auf über 300 Modelle zuzugreifen. Erstellen Sie Multi-Modell-Agenten, ohne mehrere Anbieterkonten verwalten oder Routing-Logik für verschiedene APIs neu schreiben zu müssen.