Die meisten KI-Agenten nutzen ein einziges Modell für alles. Den Planungsschritt, die Tool-Aufrufe, die Zusammenfassung, die Fehlerbehebung. Das funktioniert für Demos. In der Produktion ist es verschwenderisch.
Ein Planungsschritt, der tiefgreifendes Reasoning erfordert, benötigt nicht dasselbe Modell wie ein Schritt zur JSON-Extraktion. Eine Aufgabe zur Code-Generierung hat andere Anforderungen als eine Klassifizierungsaufgabe. Claude Opus 4.6 ($25/1M Output-Token) zur Formatierung eines Datums-Strings zu verwenden, ist so, als würde man einen leitenden Architekten engagieren, um eine Wand zu streichen.
Hier erfahren Sie, wie Sie Agenten erstellen, die jeden Schritt an das optimale Modell weiterleiten.
Wenn Sie eher auf der API-Ebene als auf der Agenten-Ebene arbeiten, lesen Sie parallel zu dieser Seite Agent-First API Design und Warum Teams von direkten Modell-APIs zu einer Unified AI API wechseln. Multi-Modell-Agenten funktionieren am besten, wenn die zugrunde liegende API-Oberfläche stabil genug ist, um Modelle auszutauschen, ohne den Orchestrierungscode neu schreiben zu müssen.
Die Multi-Modell-Agenten-Architektur
Benutzeranfrage
│
▼
┌─────────────┐
│ Router │ ← Klassifiziert die Aufgabenkomplexität
│(schnelles M.)│
└──────┬──────┘
│
┌───┴───┐
▼ ▼
┌──────┐ ┌──────┐
│Einfach│ │Komplex│
│Modell│ │Modell│
└──┬───┘ └──┬───┘
│ │
▼ ▼
┌─────────────┐
│ Aggregator │ ← Kombiniert Ergebnisse
│(schnelles M.)│
└─────────────┘
Drei Komponenten:
- Ein Router, der eingehende Aufgaben nach Komplexität klassifiziert
- Ein Pool von Modellen, die auf verschiedene Aufgabentypen abgestimmt sind
- Ein Aggregator, der bei Bedarf Ergebnisse kombiniert
In der Praxis benötigen Produktions-Agenten meist zwei weitere Teile:
- Eine Fallback-Policy, wenn das bevorzugte Modell ausfällt oder langsam wird
- Eine Telemetry-Ebene, die Modellwahl, Latency und Kosten pro Schritt aufzeichnet
Ohne diese beiden Komponenten verwandelt sich ein Multi-Modell-Agent schnell in eine Blackbox mit unvorhersehbarem Verhalten.
Implementierung mit dem OpenAI SDK
Durch die Verwendung eines einzigen API-Keys über einen Aggregator können Sie auf alle Modelle zugreifen, ohne mehrere SDKs verwalten zu müssen:
from openai import OpenAI
client = OpenAI(
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Modell-Pool mit Kosten-/Leistungsstufen
MODELS = {
"router": "gpt-4.1-mini", # $0.40/1M in - schnelle Klassifizierung
"simple": "gpt-4.1-mini", # $0.40/1M in - Extraktion, Formatierung
"reasoning": "claude-sonnet-4-6", # $3.00/1M in - Planung, Analyse
"complex": "gpt-4.1", # $2.00/1M in - Code-Gen, mehrstufig
"budget": "deepseek-chat", # $0.28/1M in - Massenverarbeitung
}
def route_task(task: str) -> str:
"""Verwendet ein günstiges Modell, um die Aufgabenkomplexität zu klassifizieren."""
response = client.chat.completions.create(
model=MODELS["router"],
messages=[
{"role": "system", "content": """Klassifiziere diese Aufgabe in eine Kategorie:
- simple: Datenextraktion, Formatierung, Übersetzung
- reasoning: Analyse, Planung, Vergleich
- complex: Code-Generierung, mehrstufige Problemlösung
- budget: Massenverarbeitung, unkritische Aufgaben
Antworte nur mit dem Kategorienamen."""},
{"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 entsprechende 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
Hier ist ein praktischer Multi-Modell-Agent, der Pull Requests prüft:
def review_pr(diff: str) -> dict:
"""Multi-Modell PR-Review-Pipeline."""
# Schritt 1: Änderungen klassifizieren (günstiges Modell)
classification = client.chat.completions.create(
model="gpt-4.1-mini",
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: Security-Scan (Reasoning-Modell)
security = client.chat.completions.create(
model="claude-sonnet-4-6",
messages=[{
"role": "system",
"content": "Du bist ein Security-Reviewer. Prüfe auf: "
"SQL-Injection, XSS, Auth-Bypass, Secrets im Code, "
"unsichere Deserialisierung. Nenne spezifische Zeilennummern."
}, {
"role": "user",
"content": f"Prüfe diesen Diff auf Sicherheitsprobleme:\n{diff}"
}]
).choices[0].message.content
# Schritt 3: Code-Qualität (allgemeines Modell)
quality = client.chat.completions.create(
model="gpt-4.1",
messages=[{
"role": "user",
"content": f"Prüfe die Code-Qualität: Benennung, Struktur, "
f"Fehlerbehandlung, Testabdeckung.\n{diff}"
}]
).choices[0].message.content
# Schritt 4: Zusammenfassung (günstiges Modell)
summary = client.chat.completions.create(
model="gpt-4.1-mini",
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
}
Kostenaufschlüsselung für ein typisches PR-Review (2K Token Diff):
| Schritt | Modell | Input-Token | Kosten |
|---|---|---|---|
| Klassifizieren | GPT-4.1-mini | ~2.100 | $0.0008 |
| Sicherheit | Claude Sonnet 4.6 | ~2.500 | $0.0075 |
| Qualität | GPT-4.1 | ~2.500 | $0.0050 |
| Zusammenfassung | GPT-4.1-mini | ~1.200 | $0.0005 |
| Gesamt | ~$0.014 |
Die Verwendung von Claude Sonnet 4.6 für alle vier Schritte würde ~$0.028 kosten. Der Multi-Modell-Ansatz senkt die Kosten um 50 %, während das stärkste Modell dort eingesetzt wird, wo es am wichtigsten ist (Security-Review).
Routing nach Fähigkeiten, nicht nur nach Preis
Viele Teams beginnen das Multi-Modell-Routing mit einer einfachen Regel: Teure Aufgaben gehen an teure Modelle, günstige Aufgaben an günstige Modelle.
Das ist ein guter erster Schritt, aber es reicht nicht aus.
Eine stärkere Routing-Policy berücksichtigt vier Dimensionen:
- Reasoning-Tiefe
- Kontextlänge
- Zuverlässigkeit der Tool-Nutzung
- Latenzempfindlichkeit
Dies führt zu besseren Regeln:
- Planung und Dekomposition gehen an ein Modell mit starkem Reasoning
- Extraktion und Formatierung gehen an ein günstiges, schnelles Modell
- Code-Reviews gehen an das Modell mit dem besten Bug-Finding-Verhalten
- Repository-weite Analysen gehen an das Modell mit dem größten Kontextfenster
Aus demselben Grund sollten der Vergleich von Coding-Modellen und der Preisvergleich Ihren Router informieren, anstatt in einem separaten Recherche-Ordner zu verstauben.
LangChain Integration
from langchain_openai import ChatOpenAI
# Modell-Instanzen mit verschiedenen Konfigurationen erstellen
fast = ChatOpenAI(
model="gpt-4.1-mini",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
reasoning = ChatOpenAI(
model="claude-sonnet-4-6",
api_key="sk-lemon-xxx",
base_url="https://api.lemondata.cc/v1"
)
# Verwendung in LangChain-Chains
from langchain_core.prompts import ChatPromptTemplate
classify_chain = ChatPromptTemplate.from_template(
"Klassifiziere: {input}"
) | fast
analyze_chain = ChatPromptTemplate.from_template(
"Analysiere tiefgreifend: {input}"
) | reasoning
Wann man Multi-Modell-Agenten einsetzen sollte
Multi-Modell-Routing erhöht die Komplexität. Es lohnt sich, wenn:
- Ihr Agent unterschiedliche Aufgabentypen verarbeitet (nicht nur Chat)
- Die monatlichen API-Kosten $100 übersteigen (Einsparungen werden relevant)
- Sie spezifische Modellstärken benötigen (Claude für Code, Gemini für langen Kontext, GPT für Geschwindigkeit)
- Latency für einige Schritte wichtig ist, für andere jedoch nicht
Für einfache Chatbots oder spezialisierte Agenten reicht ein einziges Modell aus. Der Overhead des Routings ist nicht gerechtfertigt, wenn jede Anfrage dieselben Fähigkeiten erfordert.
Der Wendepunkt ist meist einer dieser Faktoren:
- Sie zahlen für High-End-Reasoning bei Aufgaben mit geringem Wert
- Ausfälle eines einzelnen Anbieters sind mittlerweile ein echtes Geschäftsrisiko
- Die Kontextanforderungen variieren innerhalb des Workflows extrem
- Sie benötigen günstigere Review- / Extraktions- / Zusammenfassungsphasen um eine teure Kernphase herum
Wenn nichts davon zutrifft, ist ein einzelnes Modell immer noch die richtige Antwort.
Häufige Fehlerquellen
Multi-Modell-Systeme scheitern auf vorhersehbare Weise:
1. Der Router ist zu "schlau"
Wenn der Router-Prompt zu einer gigantischen Taxonomie-Übung wird, geben Sie zu viel dafür aus, zu entscheiden, was zu tun ist. Halten Sie den Router günstig und grobmaschig.
2. Output-Verträge driften auseinander
Ein Modell liefert sauberes JSON, ein anderes liefert Fließtext mit einem JSON-Block, und Ihr nachgelagerter Parser bricht ab. Verwenden Sie explizite Schemas und Validierung bei jeder Übergabe.
3. Fallbacks ändern die Qualität lautlos
Das Routing zu einem günstigeren Modell bei Überlastung eines Anbieters kann den Agenten unzuverlässig erscheinen lassen, wenn der Benutzer ein völlig anderes Qualitätsprofil sieht. Deshalb gehört eine Rate-Limiting-Strategie ins Design und nicht erst im Nachhinein hinzugefügt.
4. Kostenberichte fehlen
Wenn Sie Modellwahl, Kosten und Latency nicht pro Schritt aufzeichnen, können Sie nicht sagen, ob das Multi-Modell-Design tatsächlich Geld spart.
Ein minimaler Evaluierungs-Loop
Sie benötigen keine riesige Eval-Plattform, um einen Multi-Modell-Agenten verantwortungsvoll zu betreiben.
Beginnen Sie mit einer Tabelle oder einer Datenbank-Tabelle pro Durchlauf:
- Benutzer-Aufgabenkategorie
- Router-Entscheidung
- Final verwendetes Modell pro Schritt
- Latency pro Schritt
- Gesamte Token-Kosten
- Ob ein Fallback ausgelöst wurde
- Ob der Benutzer die Antwort akzeptiert hat
Das gibt Ihnen genug Signale, um die wichtigen Fragen zu beantworten:
- Wählt der Router oft genug das richtige teure Modell?
- Welcher Schritt verbraucht den Großteil des Budgets?
- Retten Fallbacks die Durchläufe oder verbergen sie nur Instabilität?
- Ist der günstige Pfad gut genug für repetitive Aufgaben?
Dies ist auch der Grund, warum ein Unified Gateway hilft. Wenn die Modellnutzung über viele Anbieter verteilt ist, ist es schwieriger, ein vergleichbares Protokoll zu erstellen. Wenn alles über eine API-Ebene läuft, sinkt der Aufwand für die Instrumentierung.
Halten Sie die Architektur "langweilig"
Die besten Multi-Modell-Agenten fühlen sich nicht exotisch an. Sie fühlen sich operativ langweilig an.
Das bedeutet:
- Eine stabile Request-Struktur in Ihrer Orchestrierungsebene
- Ein Ort, an dem Routing-Regeln definiert werden
- Ein Ort, um Kosten und Latency zu prüfen
- Eine Fallback-Policy pro Aufgabenfamilie
- Eine Single Source of Truth für Modell-Allowlists
Wenn Ihr Agenten-Graph clever aussieht, aber Ihre Operator nicht erklären können, warum eine Anfrage an ein bestimmtes Modell ging, ist das Design noch nicht fertig.
Wann man keinen Multi-Modell-Agenten verwenden sollte
Es gibt auch klare Fälle, in denen das einfachere Design gewinnt.
Fügen Sie kein Routing hinzu, nur weil der Modellkatalog groß ist.
Bleiben Sie bei einem Modell, wenn:
- Das Produkt eine einzige, eng gefasste Aufgabe wiederholt ausführt
- Qualitätsunterschiede zwischen Modellen für den Benutzer irrelevant sind
- Ihr Traffic zu gering ist, als dass Kostenoptimierung eine Rolle spielen würde
- Ihre Ops-Oberfläche bereits unter-instrumentiert ist
- Sie noch keine Evals haben, die stark genug sind, um zu sagen, ob das Routing geholfen oder geschadet hat
Ein einzelnes, gut gewähltes Modell mit guten Retries, Prompt-Hygiene und Observability schlägt oft einen schillernden Multi-Modell-Graphen, dem niemand vertraut.
Die richtige Frage ist nicht „Können wir routen?“, sondern „Erzeugt Routing eine bessere Qualität, geringere Kosten oder ein sichereres Fehlerverhalten für diesen Workflow?“
Wenn die Antwort vage ist, halten Sie die Architektur einfach, bis der Workflow selbst vielfältiger wird.
Wichtige Erkenntnisse
- Verwenden Sie das günstigste Modell, das jeden Schritt gut bewältigt
- Reservieren Sie teure Modelle für Aufgaben, die sie wirklich benötigen
- Klassifizierungs-/Routing-Schritte sollten immer das günstigste verfügbare Modell verwenden
- Messen Sie die tatsächlichen Kosten pro Agenten-Durchlauf, nicht nur die Preise pro Token
- Ein API-Aggregator mit einem Key vereinfacht den Multi-Modell-Zugriff erheblich
Multi-Modell-Agenten sind nicht von Natur aus besser. Sie sind besser, wenn der Workflow tatsächlich verschiedene Arten von Arbeit enthält.
Greifen Sie auf jedes Modell über eine API zu: LemonData bietet über 300 Modelle mit einem einzigen API-Key. Erstellen Sie Multi-Modell-Agenten, ohne mehrere Anbieter-Accounts zu verwalten oder das Routing für jedes Anbieter-Paar neu zu erfinden.