Mehrwahl-Klärungssystem

Lektion aktualisiert am 2. November 2026. Beispielagenten-Dateien 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 Agenten-Datei) 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.

Wenn Vibe vor dem Handeln fragt

Mistral Vibe ist kein Werkzeug, das Ihre Anweisungen blind ausführt. Wenn eine Anfrage mehrdeutig ist oder mehrere vertretbare Ansätze bestehen, kann das Modell Optionen präsentieren, bevor es fortfährt: Dies ist das Mehrwahl-Klärungssystem. Der Mechanismus stützt sich auf ein integriertes Tool, ask_user_question, das Agenten, aber keine Subagenten, zur Verfügung steht, und er funktioniert auf zwei Arten.

Im programmatischen Modus (vibe --prompt …) deaktiviert Vibe interaktive Tools wie ask_user_question: Niemand ist da, um zu antworten. Ein Agent, der unbeaufsichtigt ausgeführt werden soll, muss wie eine Subagent in seinen Anweisungen Standardoptionen finden.

Die erste Möglichkeit ist die Mehrfachauswahl: Vibe listet nummerierte Optionen auf, und Sie reagieren mit einer Nummer oder dem Optionstext. Dies ist schnell und eindeutig und stellt das Standardformat dar, wann immer eine endliche Anzahl vernünftiger Antworten existiert.

Vibe: Welches Test-Framework verwenden Sie?
  1. Vitest
  2. Jest
  3. Mocha
  4. Pytest
  5. Sonstiges (bitte angeben)

Die zweite Möglichkeit ist der freie Texteingabe, die für Fragen reserviert ist, bei denen die Antwort nicht erraten werden kann: ein Tabellename, eine Kennung, ein Pfad. Vibe erwartet dann eine Textantwort.

Vibe: Wie lautet der Name der Datenbanktabelle, die migriert werden soll?
> users_profiles

Die drei Situationen, die eine Frage auslösen

Der erste Auslöser ist reine Mehrdeutigkeit. Sie bitten um die Refaktorierung des „Login-Komponenten”, als das Repository jedoch zwei enthält; statt auf eine zu wetten und Ihnen Arbeit zu liefern, die Sie wegwerfen müssen, lässt Vibe Sie entscheiden. Beachten Sie die dritte Option, die Hin-und-Her-Gespräche vermeidet, wenn die Antwort „beide” lautet.

Sie: Refaktorieren Sie die Login-Komponente

Vibe: Ich habe zwei login-bezogene Komponenten identifiziert:
  1. src/components/LoginForm.tsx (Formular)
  2. src/components/LoginModal.tsx (Modal)
Welche möchten Sie refaktorieren?
  3. Beide

Der zweite Auslöser ist eine Vielzahl technischer Ansätze. Die Hinzufügung einer Validierung zu einem Formular führt zu einer Abhängigkeit, die jahrelang im Projekt verbleiben wird; diese Art von Entscheidung gehört zu Ihnen, nicht zum Modell.

Sie: Fügen Sie eine Validierung zum Formular hinzu

Vibe: Welchen Validierungsansatz bevorzugen Sie?
  1. Zod (Schema-Validierung, TypeScript-Typisierung)
  2. Yup (deklarative Validierung, Formik-Ökosystem)
  3. Manuelle Validierung (keine Bibliothek)
  4. Valibot (leichtgewichtig, tree-shakable)

Der dritte ist eine Entscheidung mit hoher Auswirkung. Eine scheinbar banale Anfrage – „Abhängigkeiten aktualisieren” – kann eine Hauptversionänderung verbergen. Vibe rangiert dann Optionen von sichersten bis risikoreichsten und stellt explizit das Risikoniveau jeder Option dar.

Sie: Aktualisieren Sie Abhängigkeiten

Vibe: Das Aktualisieren von React 18 → 19 ist eine Hauptänderung.
  1. Nur Patches aktualisieren (sicher)
  2. Minoren aktualisieren (geringes Risiko)
  3. Alles aktualisieren, einschließlich Majors (Verifizierung erforderlich)

Feinabstimmung des Cursor-Agenten pro Agent

Dieses Verhalten ist nicht automatisch: Es hängt davon ab, was Sie autorisieren. Damit ein Agent Sie befragen kann, muss ask_user_question in seinen erlaubten Tools erscheinen.

display_name = "Vorsichtiger Entwickler"
safety = "neutral"

enabled_tools = [
  "read_file",
  "write_file",
  "edit",
  "grep",
  "ask_user_question"  # Ermöglicht Klärungen
]

[tools.write_file]
permission = "ask"

[tools.edit]
permission = "ask"

Umgekehrt muss ein Agent, der ohne Aufsicht ausgeführt werden soll – in einer Pipeline, nachts oder einfach für repetitive Aufgaben, die Sie nicht arbitrieren möchten – dieses Tool beraubt werden. Das Entfernen von ask_user_question reicht jedoch nicht aus: Ohne Rückfall-Anweisungen würde der Agent stocken oder zufällig wählen. Der Systemprompt muss ihm daher mitteilen, was er stattdessen tun soll.

display_name = "Stiller Arbeiter"
safety = "neutral"

instructions = """
Niemals Fragen stellen. Im Falle von Mehrdeutigkeit:
- Wählen Sie die konservativste Option
- Dokumentieren Sie Ihre Wahl in einem Kommentar
"""

enabled_tools = [
  "read_file",
  "write_file",
  "edit",
  "grep"
  # Kein ask_user_question
]

[tools.read_file]
permission = "always"

[tools.write_file]
permission = "always"

[tools.edit]
permission = "always"

[tools.grep]
permission = "always"

Zwischen allem und nichts erlaubt der Prompt eine Feinabstimmung. Ein Agent, der Sie alle zwei Minuten unterbricht, um einen Variablennamen zu wählen, ist so nervig wie ein stummer Agent riskant; formulieren Sie daher eine explizite Schwelle, damit er Sie nur zu Fragen auffordert, die wirklich wichtig sind.

instructions = """
Regeln für Klärungen:
- Stellen Sie eine Frage NUR, wenn die Wahl die Architektur betrifft
- Folgen Sie bei kosmetischen Entscheidungen den Projekt-Konventionen
- Bieten Sie immer maximal 3 Optionen an
- Schließen Sie immer eine Option „Beide" oder „Alle" ein, wenn relevant
"""

Der Sonderfall von Subagenten

Wichtige Erinnerung: Subagenten können keine Fragen stellen. Dies ist eine Designbeschränkung, kein oversight – ein Subagent muss vollständig autonom sein. Wenn er auf Mehrdeutigkeit stößt, hat er drei Möglichkeiten: die Standardoption anwenden, die in seinem Prompt dokumentiert ist, diese Wahl im Ergebnis dokumentieren, das er zurückgibt, und die Mehrdeutigkeit dem Hauptagenten signalisieren, der Sie dann befragen kann. Das Schreiben dieser Standardwerte ist kein Luxus; es ist die Bedingung, damit ein Subagent ein nutzbares Ergebnis liefert.

# Subagent mit klarem Rückfall
agent_type = "subagent"
instructions = """
Im Falle von Mehrdeutigkeit gelten diese Standardregeln:
- Test-Framework: Vitest
- Code-Stil: Projekt-Konventionen (über Konfiguration erkannt)
- Ausgabeformat: Markdown
Dokumentieren Sie jede Standardwahl in Ihrem Bericht.
"""

In der Praxis reservieren Sie Klärungen für Entscheidungen, die Architektur oder Sicherheit betreffen, und lassen Sie den Agenten entscheiden, wie er Formatierung oder temporäre Variablennamen handhabt. Halten Sie sich an drei bis fünf Optionen, um zu vermeiden, dass jede Frage zu einem Formular wird, und platzieren Sie immer die Wahl, die als vernünftiger Standard dienen würde, an erster Stelle. Der Kompromiss ist einfach zu formulieren: Weniger Fragen ergeben mehr Flüssigkeit, erhöhen aber das Risiko einer stillen schlechten Wahl.

Kernaussagen

• Vibe verwendet ask_user_question, um Klärungen mit Mehrfachauswahl oder freier Texteingabe anzufordern
• Das System aktiviert sich, wenn die Anfrage mehrdeutig ist oder mehrere Ansätze möglich sind
• Fügen Sie ask_user_question zu enabled_tools hinzu, um Klärungen zu aktivieren
• Subagenten können keine Fragen stellen – sie müssen autonom sein
• Leiten Sie das Klärungsverhalten über den Systemprompt
• Weniger Fragen = mehr Flüssigkeit, aber höheres Risiko einer stillen schlechten Wahl