Tiefe Agentenketten — Mistral Agents: Aufbau autonomer KI

Unbegrenzte Agentenketten

Die Mistral Agents API stellt keine Tiefenbegrenzung für die Verkettung von Agenten bereit. Ein Agent kann an einen zweiten weitergeben, dieser an einen dritten und so weiter. Diese Freiheit ermöglicht komplexe, modulare Arbeitsabläufe, überträgt jedoch die Verantwortung für die Topologie auf Sie: Sie entscheiden, wer wen aufrufen darf. Diese Karte bestimmt das Systemverhalten fast so sehr wie die Anweisungen für jeden einzelnen Agenten.

Drei Topologien und ihre Implikationen

Die lineare Kette ist das einfachste Muster: Jeder Agent übergibt an den nächsten ohne Verzweigung.

Agent A → Agent B → Agent C → Antwort

Dies eignet sich für Prozesse, bei denen die Reihenfolge im Voraus bekannt ist und sich nie ändert. Ein typisches Beispiel ist die Suche, gefolgt von der Analyse und dann dem Schreiben: Man schreibt nicht vor der Analyse, und man analysiert nicht vor der Suche.

# Forschungs-Agent
research = client.beta.agents.create(
    model="mistral-large-latest",
    name="research",
    description="Suche nach Fakteninformationen.",
    tools=[{"type": "web_search"}]
)

# Analyse-Agent
analyst = client.beta.agents.create(
    model="mistral-large-latest",
    name="analyst",
    description="Analysiere Daten und extrahiere Erkenntnisse.",
    tools=[{"type": "code_interpreter"}]
)

# Schreib-Agent
writer = client.beta.agents.create(
    model="mistral-large-latest",
    name="writer",
    description="Entwerfe professionelle Berichte.",
    instructions="Schreibe einen strukturierten Bericht auf Basis der analysierten Daten."
)

# Kette: research → analyst → writer
research = client.beta.agents.update(
    agent_id=research.id,
    handoffs=[analyst.id]
)

analyst = client.beta.agents.update(
    agent_id=analyst.id,
    handoffs=[writer.id]
)

Jeder Agent kennt nur seinen unmittelbaren Nachfolger: research ist sich nicht bewusst, dass writer überhaupt existiert. Die Kette existiert nur in den update-Aufrufen, an keiner anderen Stelle.

Die Stern-Kette adressiert das entgegengesetzte Bedürfnis: Ein zentraler Router verteilt Aufgaben an Spezialisten, die nicht miteinander kommunizieren.

          ┌→ Web-Such-Agent
Router ──┼→ Taschenrechner-Agent
          └→ Schreib-Agent

router = client.beta.agents.create(
    model="mistral-large-latest",
    name="router",
    description="Orchestriere Anfragen.",
    handoffs=[research.id, analyst.id, writer.id]
)

Hier ist die Reihenfolge nicht vorbestimmt – die Anfrage selbst entscheidet über das Ziel. Diese Form eignet sich für vielseitige Assistenten, bei denen jede Anfrage unter eine spezifische Kompetenz fällt.

Die hybride Topologie kombiniert beides: Der Router verteilt Aufgaben, und Spezialisten können sich auch gegenseitig weitergeben.

          ┌→ Forschungs-Agent ──→ Analyse-Agent
Router ──┤                          │
          └→ Schreib-Agent ←───────────┘

# Forschung kann an Analyse weitergeben
research = client.beta.agents.update(
    agent_id=research.id,
    handoffs=[analyst.id]
)

# Analyse kann an Schreiben weitergeben
analyst = client.beta.agents.update(
    agent_id=analyst.id,
    handoffs=[writer.id]
)

# Router kann auf alle zugreifen
router = client.beta.agents.update(
    agent_id=router.id,
    handoffs=[research.id, analyst.id, writer.id]
)

Dies ist die leistungsfähigste Form, aber auch die schwierigste zu debuggen. Die gleiche Anfrage kann von einer Ausführung zur nächsten einen anderen Weg nehmen, sodass Protokollierung der Weitergaben unerlässlich ist, sobald Sie den Sandbox-Betrieb verlassen.

Zwei Produktions-Pipelines

Die Datenverarbeitung illustriert die lineare Kette in ihrem natürlichsten Anwendungsfall: Sammeln, Bereinigen, Visualisieren. Die letzten beiden Schritte verwenden das gleiche Werkzeug, doch die Trennung hält jede Anweisungsmenge sauber – Bereinigen und Darstellen sind unterschiedliche Aufgaben.

# Schritt 1: Sammlung
collector = client.beta.agents.create(
    model="mistral-large-latest",
    name="data-collector",
    description="Sammele Daten aus dem Internet.",
    tools=[{"type": "web_search"}]
)

# Schritt 2: Bereinigung und Transformation
transformer = client.beta.agents.create(
    model="mistral-large-latest",
    name="data-transformer",
    description="Bereinige und transformiere Rohdaten.",
    tools=[{"type": "code_interpreter"}]
)

# Schritt 3: Analyse und Visualisierung
visualizer = client.beta.agents.create(
    model="mistral-large-latest",
    name="data-visualizer",
    description="Erstelle Visualisierungen und Diagramme.",
    tools=[{"type": "code_interpreter"}]
)

# Kette
collector = client.beta.agents.update(agent_id=collector.id, handoffs=[transformer.id])
transformer = client.beta.agents.update(agent_id=transformer.id, handoffs=[visualizer.id])

Ein wissenschaftlicher Forschungsassistent folgt derselben Struktur, jedoch mit einer anderen Art von Zwischenverbindung. Der Synthesizer verfügt über keine Werkzeuge: Sein Wert liegt ausschließlich in seinen Anweisungen, die ihn auffordern, Quellen zu konfrontieren – gemeinsame Punkte, Abweichungen, Lücken – statt sie lediglich zu stapeln.

# Sucher
searcher = client.beta.agents.create(
    model="mistral-large-latest",
    name="academic-searcher",
    description="Suche nach wissenschaftlichen Artikeln und Publikationen.",
    tools=[{"type": "web_search"}]
)

# Synthesizer
synthesizer = client.beta.agents.create(
    model="mistral-large-latest",
    name="synthesizer",
    description="Synthetisiere und vergleiche mehrere Quellen.",
    instructions="Identifiziere gemeinsame Punkte, Abweichungen und Lücken."
)

# Schreiber
academic_writer = client.beta.agents.create(
    model="mistral-large-latest",
    name="academic-writer",
    description="Strukturiertes wissenschaftliches Schreiben mit Zitaten.",
    instructions="Schreibe im wissenschaftlichen Format mit Einleitung, Methodik, Ergebnissen und Diskussion."
)

# Pipeline: searcher → synthesizer → writer
searcher = client.beta.agents.update(agent_id=searcher.id, handoffs=[synthesizer.id])
synthesizer = client.beta.agents.update(agent_id=synthesizer.id, handoffs=[academic_writer.id])

Tiefe angemessen halten

Das Fehlen einer technischen Begrenzung ist keine Einladung, wild zu experimentieren. In der Praxis decken Ketten aus zwei bis vier Agenten den Großteil der Bedürfnisse ab. Ab fünf Agenten steigen sowohl die Latenz als auch die Kosten stark an. Der Grund ist mechanischer Natur: Jeder Agent fügt seine eigenen Kontext-Token hinzu, einschließlich Anweisungen, aufbauend auf einer Gesprächshistorie, die seit dem ersten Handoff nur gewachsen ist. Ein fünfter Agent arbeitet nicht auf der ursprünglichen Anfrage, sondern auf allem, was die vorherigen vier produziert haben.

Bevor Sie eine Kette verlängern, sollten Sie sich fragen, ob der zusätzliche Schritt einen eigenen Agenten verdient oder ob er in die Anweisungen eines bestehenden Agenten passt. Eine Formatierungsrichtlinie rechtfertigt beispielsweise fast nie einen zusätzlichen Link.

Beachten Sie zudem, dass ein Agent nicht auf ein einziges Ziel beschränkt ist. Er kann mehrere Ziele deklarieren und basierend auf dem Kontext wählen.

analyst = client.beta.agents.update(
    agent_id=analyst.id,
    handoffs=[writer.id, visualizer.id, calculator.id]
)

Dieser Analyst wird an den Schreiber weitergeben, wenn das Ergebnis bereit zur Mitteilung ist, an den Visualisierer, wenn die Daten ein Diagramm erfordern, oder an den Taschenrechner, wenn eine Figur noch fehlt. Die Entscheidung beruht, wie immer, auf den Beschreibungen der drei Ziele – der einzigen verfügbaren Information, um die Entscheidung zu treffen.

Kernaussagen

Keine Tiefenbegrenzung für die Verkettung von Agenten
Drei Muster: linear (A→B→C), Stern (Router→Spezialisten), hybrid (Graph)
Jeder Agent kann mehrere Weitergabeziele haben
Begrenzen Sie in der Produktion Ketten auf 2–4 Agenten, um Latenz und Kosten zu kontrollieren
Agentenbeschreibungen sind entscheidend für eine effektive Routierung