Mehrzweck-Agenten-Anwendungsfälle
Auf dieser Seite
Vom Konzept zur Realität
Sie verstehen nun Handovers, Ausführungsmodi und Verkettungen. Diese Lektion fasst diese Bausteine zu drei vollständigen Systemen zusammen, die jeweils auf einer anderen Topologie basieren: eine Eskalationskette, ein Pipeline und ein Router. Achten Sie beim Lesen darauf, wie die Architektur vom Problem ausgeht und nicht umgekehrt – die Natur des Bedarfs diktiert die Form, nicht die Technologie.
Fall 1: Mehrstufiger Kundensupport
Support-Bereiche arbeiten in Stufen: die meisten Anfragen werden beim ersten Kontakt gelöst, eine Minderheit erfordert eine technische Diagnose und nur wenige landen bei einem Menschen. Diese Realität lässt sich direkt auf eine Eskalationskette abbilden, bei der jede Ebene nur an die nächste weiterleitet.
from mistralai.client import Mistral
import os
client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])
# Ebene 1: FAQ und einfache Fragen
level1 = client.beta.agents.create(
model="mistral-medium-latest",
name="support-level1",
description="Support-Ebene 1: FAQ, häufige Fragen, grundlegende Informationen.",
instructions="""Sie sind die erste Support-Ebene.
- Beantworten Sie einfache Fragen (Öffnungszeiten, Preise, FAQ)
- Überweisen Sie technische oder komplexe Fragen an Ebene 2
- Seien Sie höflich und professionell""",
tools=[{"type": "document_library", "library_ids": ["faq-library-id"]}]
)
# Ebene 2: Technischer Support
level2 = client.beta.agents.create(
model="mistral-large-latest",
name="support-level2",
description="Technischer Support: Diagnose, Fehlerbehebung, Konfiguration.",
instructions="""Sie sind technischer Support.
- Diagnositizieren Sie technische Probleme
- Vorschlagen Sie schrittweise Lösungen
- Überweisen Sie Probleme, die manuelle Eingriffe erfordern, an Ebene 3""",
tools=[{"type": "web_search"}, {"type": "code_interpreter"}]
)
# Ebene 3: Eskalation an den Menschen (Simulation)
level3 = client.beta.agents.create(
model="mistral-large-latest",
name="support-level3",
description="Eskalation: Kritische Probleme, die menschliches Eingreifen erfordern.",
instructions="""Bereiten Sie eine Zusammenfassung des Problems für das technische Team vor:
- Problemkontext
- Durchgeführte Diagnose-Schritte
- Versuchte Lösungen
- Empfehlung"""
)
# Eskalationen verketten
level1 = client.beta.agents.update(agent_id=level1.id, handoffs=[level2.id])
level2 = client.beta.agents.update(agent_id=level2.id, handoffs=[level3.id])
Zwei Entscheidungen fallen besonders auf. Ebene 1 läuft auf mistral-medium-latest, während die nachfolgenden Ebenen mistral-large-latest verwenden. Ebene 1 absorbiert das höchste Volumen, sodass die Zuweisung des teuersten Modells für Fragen zu Geschäftszeiten unnötige Kosten bedeuten würde. Ebene 3 hingegen löst nichts; sie erstellt einen Fallbericht. Genau das ist das Ziel einer Eskalation an den Menschen: Der Ingenieur, der übernimmt, erhält den Kontext, die bereits durchgeführten Diagnose-Schritte und die bereits versuchten Lösungen, statt die Befragung von vorne beginnen zu müssen.
In der Praxis schreibt ein Kunde: „Ich kann nicht in mein Konto einloggen.” Ebene 1 prüft das FAQ, findet keinen passenden Eintrag und überweist die Anfrage. Ebene 2 diagnostiziert ein Datenbankproblem, das über ihren Umfang hinausgeht, und überweist erneut. Ebene 3 erstellt den Ticket mit der vollständigen Historie.
Fall 2: Pipeline für strategische Intelligenz
Hier ist die Reihenfolge fest und im Voraus bekannt: man kann nicht analysieren, was noch nicht gesammelt wurde, oder schreiben, was noch nicht analysiert wurde. Eine lineare Kette ist daher zwingend erforderlich, und der Einstiegspunkt ist kein Router, sondern das erste Glied.
# Collector – sucht nach Rohinformationen
collector = client.beta.agents.create(
model="mistral-large-latest",
name="intelligence-collector",
description="Sammelt strategische Informationen über Websuche.",
instructions="""Suchen Sie nach Informationen zum angeforderten Thema.
- Erfassen Sie mehrere Quellen
- Beziehen Sie numerische Daten ein
- Notieren Sie Veröffentlichungsdaten""",
tools=[{"type": "web_search"}]
)
# Analyst – extrahiert Erkenntnisse
analyst = client.beta.agents.create(
model="mistral-large-latest",
name="intelligence-analyst",
description="Analysiert und extrahiert Erkenntnisse aus Rohdaten.",
instructions="""Analysieren Sie die gesammelten Daten:
- Identifizieren Sie Trends
- Erkennen Sie Chancen und Risiken
- Quantifizieren Sie, wann möglich""",
tools=[{"type": "code_interpreter"}]
)
# Reporter – erstellt den Bericht
reporter = client.beta.agents.create(
model="mistral-large-latest",
name="intelligence-reporter",
description="Verfasst strukturierte Intelligenzberichte.",
instructions="""Verfassen Sie einen professionellen Intelligenzbericht:
## Zusammenfassung (3 Sätze)
## Wichtige Fakten (Aufzählungszeichen)
## Analyse (2-3 Absätze)
## Empfehlungen (konkrete Maßnahmen)
## Quellen"""
)
# Pipeline
collector = client.beta.agents.update(agent_id=collector.id, handoffs=[analyst.id])
analyst = client.beta.agents.update(agent_id=analyst.id, handoffs=[reporter.id])
# Starten
response = client.beta.conversations.start(
agent_id=collector.id,
inputs="Strategische Intelligenz: Markt für souveräne KI in Europa, Q1 2026."
)
Der Berichtsentwurf ist in den Anweisungen des Reporters schwarz auf weiß festgelegt, bis hin zur Anzahl der Sätze in der Zusammenfassung. Dieses Maß an Präzision macht Intelligenz im Laufe der Zeit handlungsleitend: Jeder Bericht erscheint im gleichen Format, sodass Sie ihn Woche für Woche vergleichen und verteilen können, ohne ihn zu bearbeiten. Beachten Sie auch die Anweisung für den Collector, Veröffentlichungsdaten zu erfassen – ohne diese könnte ein Intelligenzbericht solide wirken, während er auf veraltete Quellen zurückgreift.
Fall 3: Der vielseitige Assistent
Wenn Anfragen unterschiedliche Fähigkeiten betreffen, gibt es weder Eskalation noch Pipeline; es gibt Routing. Der zentrale Router liest die Anfrage und leitet sie an einen seiner vier Spezialisten weiter, von denen keiner etwas von den anderen wissen muss.
# Spezialisten
web_researcher = client.beta.agents.create(
model="mistral-large-latest",
name="web-researcher",
description="Sucht nach aktuellen Informationen im Internet.",
tools=[{"type": "web_search"}]
)
data_analyst = client.beta.agents.create(
model="mistral-large-latest",
name="data-analyst",
description="Datenanalyse, Statistik und Visualisierungen.",
tools=[{"type": "code_interpreter"}]
)
doc_expert = client.beta.agents.create(
model="mistral-large-latest",
name="doc-expert",
description="Abfragt und synthetisiert interne Dokumente.",
tools=[{"type": "document_library", "library_ids": ["docs-lib-id"]}]
)
creative = client.beta.agents.create(
model="mistral-large-latest",
name="creative-agent",
description="Erstellt visuelle Inhalte und Illustrationen.",
tools=[{"type": "image_generation"}]
)
# Zentraler Router
assistant = client.beta.agents.create(
model="mistral-large-latest",
name="research-assistant",
description="Vielseitiger Forschungsassistent.",
instructions="""Sie sind ein Forschungsassistent. Analysieren Sie jede Anfrage und überweisen Sie sie an den zuständigen Spezialisten:
- Aktuelle Informationen → web-researcher
- Berechnungen und Daten → data-analyst
- Fragen zu unseren Dokumenten → doc-expert
- Bedarf an Illustrationen → creative-agent""",
handoffs=[web_researcher.id, data_analyst.id, doc_expert.id, creative.id]
)
Jeder Spezialist verfügt über genau ein Werkzeug, und die vier Beschreibungen überlappen sich nirgendwo. Dieses Fehlen von Überlappungen macht das Routing stabil: Wenn zwei Agenten eine Anfrage plausibel bearbeiten könnten, würde die Auswahl von einer Ausführung zur nächsten variieren, und Ihre Nutzer würden eine inkonsistente Qualität erleben, ohne zu verstehen, warum.
Was unterscheidet einen Prototypen von einem System
Diese drei Systeme teilen sich die gleiche Designregel: ein Agent, eine Verantwortung. Sobald ein Agent zwei Rollen akkumuliert, widersprechen sich seine Anweisungen, und seine Beschreibung wird zu vage, damit der Router korrekt entscheiden kann. Schreiben Sie daher jede Beschreibung mit dem Gedanken an die Entscheidung, die sie ermöglichen soll, und formulieren Sie jede Reihe von Anweisungen so, dass sie ebenso klar darlegt, was der Agent nicht tun muss, wie was er tun muss.
Der Übergang zur Produktion fügt vier Anforderungen hinzu, die ein Prototyp ignoriert. Erstens Protokollierung: Der Client-Modus ermöglicht es Ihnen, jeden Handover mit Ihren eigenen Identifikatoren zu verfolgen, was am Tag, an dem ein Nutzer eine abnorme Antwort meldet, Ihre einzige Möglichkeit sein wird. Zweitens Timeouts, die bei langen Ketten essenziell sind, da ein hängendes Glied den Rest immobilisiert. Drittens Fallbacks, denn die Frage „was passiert, wenn dieser Agent ausfällt?”, muss vor dem Go-Live eine schriftliche Antwort haben, nicht erst nach dem ersten Vorfall. Schließlich Kostenverfolgung: Eine Drei-Agenten-Kette verbraucht Token bei jedem Relay, und nur ein pro-Konversation-Zähler wird Ihnen sagen, ob Ihre Intelligenz-Pipeline ein paar Cent oder viel mehr kostet.
Kernaussagen
- Mehrstufiger Kundensupport ist ein natürlicher Anwendungsfall für Handovers
- Intelligenz-Pipelines (sammeln → analysieren → schreiben) nutzen lineare Verkettungen
- Vielseitige Assistenten verwenden einen zentralen Router für Spezialisten
- In der Produktion: Protokollierung, Timeouts, Fallbacks und Kostenüberwachung sind essenziell
- Ein Agent = eine Verantwortung, mit einer präzisen Beschreibung für das Routing