Subagenten: Spezialaufgaben delegieren — Mistral Vibe Advanced: Agents, Skills und Local Mode

Lektion aktualisiert am 2. November 2026. Beispiel-Agentendateien verwenden nun von Vibe dokumentierte Schlüssel: instructions (nicht system_prompt), active_model (nicht model), [tools.<tool>]-Blöcke für Genehmigungen (der Schlüssel auto_approve existiert nicht in einer Agentendatei) und echte Tool-Namen (edit, nicht edit_file; kein list_dir-Tool). Erinnerung aus Lektion 3: safety ist ein visueller Indikator, keine Berechtigung. Quelle: Konfigurationsreferenz.

Das Delegationsprinzip

In komplexen Projekten sind bestimmte Aufgaben voneinander unabhängig: Eine Datei auf Sicherheitslücken zu prüfen, während ein anderer Prozess Tests generiert. Anstatt alles sequentiell zu bearbeiten, ermöglicht Mistral Vibe Ihnen, Aufgaben an Subagenten zu delegieren. Ein Subagent ist ein Agent, der unabhängig läuft, seine Mission erfüllt und ein Textergebnis an den Hauptagenten zurückgibt. Er kann dem Nutzer keine Fragen stellen: Er muss vollständig autonom sein.

Diese Einschränkung ist der Schlüssel zu allem, was folgt, und verdient eine detaillierte Betrachtung. Ein Subagent läuft in seinem eigenen Kontext, ohne Zugriff auf den aktuellen Gesprächsverlauf – er weiß nichts darüber, was Sie dem Hauptagenten vor fünf Minuten erklärt haben. Er kann ask_user_question nicht verwenden und muss Mehrdeutigkeiten eigenständig auflösen. Er gibt Text zurück, den der Hauptagent dann in seine Antwort integriert. Da er vom Austausch abgeschnitten ist, macht er nur Sinn, wenn er für eine spezifische, gut definierte Aufgabe konzipiert wurde.

Konfigurieren eines Subagents

Um einen Agenten in einen Subagenten umzuwandeln, fügen Sie das Feld agent_type = "subagent" zur .toml-Datei hinzu. Der Rest der Konfiguration folgt den üblichen Regeln für benutzerdefinierte Agenten.

# ~/.vibe/agents/test-generator.toml
display_name = "Test Generator"
description = "Generiert Unit-Tests für gegebene Funktionen."
agent_type = "subagent"
safety = "neutral"
active_model = "codestral"  # Alias in config.toml deklariert (Lektion 2)

instructions = """
Sie erhalten Quellcode. Generieren Sie umfassende Unit-Tests:
- Tests für den nominalen Fall
- Tests für Randfälle (null, undefined, leere Strings)
- Tests für erwartete Fehler
Framework: Verwenden Sie das Test-Framework des Projekts (Jest, Vitest, Pytest...).
Geben Sie nur den Testcode zurück, bereit zum Kopieren.
"""

enabled_tools = [
  "read_file",
  "grep",
]

Beachten Sie das Fehlen von ask_user_question in den Tools: Dies ist kein oversight. Ein Subagent kann keine Klärung anfordern, und der Systemprompt kompensiert diese Unmöglichkeit, indem er das zu verwendende Test-Framework und das genaue Antwortformat im Voraus festlegt.

Konkrete Anwendungsfälle

Der erste Vorteil ist parallele Arbeit. Der Hauptagent kann mehrere Aufgaben gleichzeitig an verschiedene Subagenten delegieren, die jeweils eigenständig arbeiten und ihr Ergebnis zurückgeben, bevor sie abgeschlossen sind.

Hauptagent
├── Subagent "test-generator" → generiert Tests
├── Subagent "doc-writer" → generiert Dokumentation
└── Subagent "security-checker" → analysiert Schwachstellen

Der zweite Vorteil betrifft hochspezialisierte Aufgaben. Manche erfordern einen Systemprompt, der sich radikal vom des Hauptagenten unterscheidet; anstatt einen einzelnen Agenten mit widersprüchlichen Anweisungen zu überlasten, delegieren Sie. Der untenstehende SQL-Optimierer ist ein gutes Beispiel: Sein Prompt spricht nur über Indizes, Ausführungspläne und N+1-Abfragen, was in einem Generalisten-Agenten keinen Sinn ergeben würde.

# ~/.vibe/agents/sql-optimizer.toml
display_name = "SQL Optimizer"
description = "Analysiert und optimiert SQL-Abfragen."
agent_type = "subagent"
safety = "safe"
active_model = "mistral-medium-3.5"  # in Vibe integriertes Modell

instructions = """
Analysieren Sie die bereitgestellten SQL-Abfragen:
1. Identifizieren Sie Leistungsprobleme (N+1, Volltabellenscan, fehlender Index)
2. Vorschlagen Sie optimierte Abfragen
3. Empfehlen Sie zu erstellende Indizes
Geben Sie einen strukturierten Bericht mit Vorher/Nachher für jede Abfrage zurück.
"""

enabled_tools = ["read_file", "grep"]

Der dritte Vorteil, weniger offensichtlich, ist die Sicherheitsisolierung. Ein Subagent mit safety = "safe" kann Dateien nicht ändern, auch wenn der Hauptagent im destructive-Modus läuft: Berechtigungen werden nicht nach unten vererbt. Sie können also in einem permissiven Modus arbeiten, während Sie Analysen an eingeschränkte Subagenten übergeben, die keinen Zugriff auf das Repository haben.

# Subagent, der NUR lesen darf
agent_type = "subagent"
safety = "safe"
enabled_tools = ["read_file", "grep"]

[tools.read_file]
permission = "always"

[tools.grep]
permission = "always"

Vibe stellt zudem einen integrierten explore-Subagenten bereit, den es automatisch verwendet, wenn es Ihren Codebase durchsuchen muss, um eine Frage zu beantworten. Er arbeitet im Lese-only-Modus und gibt eine Zusammenfassung dessen zurück, was er gefunden hat – genau das Muster, das Sie mit Ihren eigenen Subagenten replizieren.

Design eines guten Subagents

Alles hängt von der Autonomie des Systemprompts ab: Er muss alle Anweisungen enthalten, die notwendig sind, damit der Subagent das Ende erreicht, ohne jemals eine Frage zu stellen. Dies erfordert die Antizipation von Fällen, in denen Dinge schiefgehen, und das genaue Festlegen dessen, was der Agent in diesen Situationen tun muss, wie im folgenden Beispiel.

instructions = """
Analysieren Sie ALLE TypeScript-Dateien im Projekt.
Wenn eine Datei nicht gefunden wird, wechseln Sie zur nächsten.
Wenn das Test-Framework nicht identifizierbar ist, verwenden Sie Vitest als Standard.
Geben Sie immer ein Ergebnis zurück, auch wenn es nur teilweise ist.
"""

Zwei Reflexe vervollständigen diese Arbeit. Geben Sie dem Subagenten strikt nur die Tools, die er benötigt – ein Analyse-Subagent benötigt kein write_file – und legen Sie das erwartete Ausgabeformat im Systemprompt fest. Der Hauptagent muss das Ergebnis ohne Mehrdeutigkeit ausnutzen können: Er, nicht Sie, wird diesen Text zuerst lesen.

Von Vibe festgelegte Regeln

Die Dokumentation von Vibe definiert mehrere Regeln, die Sie kennen sollten, bevor Sie Ihre Subagenten entwerfen:

Ein Subagent gibt nur Text an den Hauptagenten zurück und kann dem Nutzer keine Fragen stellen;
er kann nur die integrierten Tools verwenden, die sein Dateiautor freigibt, niemals MCP-Tools, Konnektoren oder Plugins, und niemals mit breiteren Berechtigungen als der übergeordnete Agent: Seine [tools.<tool>]-Blöcke können ihn weiter einschränken, aber nicht erweitern;
seine description ist obligatorisch: Dies zeigt dem Agenten, wann er ihn verwenden soll; eine Datei ohne Beschreibung wird markiert statt geladen;
er läuft auf seinem active_model oder auf dem Sitzungsmodell, wenn keines gesetzt ist;
der Hauptagent startet ihn über Delegation, unter Verwendung des task-Tools; er wird nicht mit --agent ausgewählt;
standardmäßig können bis zu 32 Subagenten gleichzeitig existieren und laufen (max_subagents, max_concurrent_subagents), und enable_subagents = false in config.toml verbietet alle Delegationen.

Ohne einen benutzerdefinierten Subagenten kann der Agent dennoch einen generischen Subagenten starten, der mit eigenen Anweisungen und Tools ausgestattet ist.

Kernaussagen

Ein Subagent ist ein unabhängiger Agent, der nicht mit dem Nutzer interagieren kann
Konfigurieren Sie ihn mit agent_type = "subagent" in der .toml-Datei
Subagenten sind ideal für parallele Arbeit und spezialisierte Aufgaben
Sie bieten eine natürliche Sicherheitsisolierung
instructions muss vollständig autonom sein: Keine Fragen erlaubt
Legen Sie immer ein klares Ausgabeformat im Prompt fest