Einheitliche Modi: Kombinieren Sie Werkzeuge, Berechtigungen und Verhaltensweisen

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 Werkzeugnamen (edit, nicht edit_file; kein list_dir-Werkzeug). Erinnerung aus Lektion 3: safety ist ein visueller Indikator, keine Berechtigung. Quelle: Konfigurationsreferenz.

Das Konzept der einheitlichen Modi

Die benutzerdefinierten Agenten, die wir in vorherigen Lektionen besprochen haben, definieren ein statisches Profil: ein Modell, eine Reihe von Werkzeugen und ein Sicherheitsniveau. Einheitliche Modi gehen einen Schritt weiter, indem sie mehrere Dimensionen zu einer einzigen, kohärenten Konfiguration kombinieren, die Sie mit einer einzigen Geste aktivieren können. Ein einheitlicher Modus bündelt autorisierte Werkzeuge, spezifische Berechtigungen, durch System-Prompts gesteuertes Verhalten, Auto-Genehmigungsregeln und kontextuelle Einschränkungen.

Der Nutzen wird offensichtlich, wenn sich Ihre Arbeit im Laufe des Tages mehrfach ändert. Ohne einheitliche Modi müssen Sie jedes Mal, wenn sich Ihr Kontext ändert, mehrere Einstellungen jonglieren: Sie wechseln von der Code-Überprüfung zur Bereitstellung, und Sie müssen Agenten austauschen, Berechtigungen anpassen und den Prompt nachjustieren. Ein einheitlicher Modus fasst all dies in einem Profil zusammen, das Sie beim Start oder mitten in einer Sitzung aktivieren.

# "Deploy"-Modus aktivieren
vibe --agent deploy-mode

# Auf "Review"-Modus wechseln
# Shift+Tab → review-mode auswählen

Struktur eines einheitlichen Modus

Technisch gesehen ist ein einheitlicher Modus ein benutzerdefinierter Agent; der Unterschied zu einem klassischen Agenten ist konzeptioneller Natur. Sie entwerfen die .toml-Datei nicht mehr als “ein Assistent, der X tun kann”, sondern als einen vollständigen Arbeitskontext: was Sie in dieser Projektphase tun dürfen, mit welchem Maß an Vorsicht und in welcher Form die Ergebnisse zurückkommen.

Der untenstehende Review-Modus veranschaulicht dies am deutlichsten. Er ist schreibgeschützt, wird daher ohne Risiko automatisch genehmigt, und sein Prompt erzwingt ein Berichtsformat, das Sie direkt in einen Pull Request einfügen können.

# ~/.vibe/agents/review-mode.toml
display_name = "Review Mode"
description = "Code review mode: read-only, deep analysis, suggestions."

safety = "safe"
active_model = "mistral-medium-3.5"  # in Vibe integriertes Modell

instructions = """
Sie befinden sich im Code-Review-Modus.
Ziel: Analyse der Codequalität, Sicherheit und Wartbarkeit.
Regeln:
- Dateien niemals bearbeiten
- Ein strukturiertes Berichterstattung erstellen (kritische Probleme, Warnungen, Vorschläge)
- Betroffene Codezeilen mit ihren Zeilennummern zitieren
- Reparaturen als Diffs vorschlagen
Ausgabeformat: Markdown mit Abschnitten Critical / Warning / Suggestion
"""

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

[tools.read_file]
permission = "always"

[tools.grep]
permission = "always"

Der Deploy-Modus ist sein genaues Gegenteil, und dieser Kontrast ist beabsichtigt. Er verfügt über bash, sodass er Dinge brechen kann, aber seine ask-Berechtigungen für write_file und bash halten Sie im Bilde, und sein Prompt beschreibt eine strenge Sequenz, die der Agent von Anfang bis Ende einhalten muss.

# ~/.vibe/agents/deploy-mode.toml
display_name = "Deploy Mode"
description = "Deploy mode: build, test, deploy with validation at each step."

safety = "destructive"
active_model = "codestral"  # in config.toml deklariertes Alias (Lektion 2)

instructions = """
Sie befinden sich im Deploy-Modus.
Pflichtsequenz:
1. Verifizieren, dass alle Tests bestehen
2. Projekt bauen
3. Build validieren (keine Fehler, keine Warnungen)
4. Bestätigung vor der eigentlichen Bereitstellung anfordern
5. Bereitstellen
6. Verifizieren, dass der Dienst antwortet
Bereitstellen niemals, wenn Tests fehlschlagen.
"""

enabled_tools = [
  "read_file",
  "write_file",
  "bash",
  "grep",
  "ask_user_question"
]

[tools.write_file]
permission = "ask"

[tools.bash]
permission = "ask"

Entwurf komplementärer Modi

Die Idee besteht darin, eine Reihe von Modi zu erstellen, die Ihren Entwicklungszyklus abdecken, von der Entdeckung bis zur Behebung. Der Explore-Modus führt den Weg: schreibgeschützt und automatisch genehmigt, hilft er Ihnen, ein Repository zu verstehen, bevor Sie es berühren.

display_name = "Explore Mode"
safety = "safe"
instructions = """Den Codebase erkunden, Architektur, Muster und Abhängigkeiten identifizieren."""
enabled_tools = ["read_file", "grep",]

[tools.read_file]
permission = "always"

[tools.grep]
permission = "always"

Als Nächstes kommt der Dev-Modus, in dem Sie den Großteil Ihrer Zeit verbringen werden. Er schreibt und führt Befehle aus – zum Beispiel, um Tests auszuführen –, aber er fragt nach Ihrer Genehmigung, und sein Prompt verknüpft jede Änderung mit dem Schreiben von Tests.

display_name = "Dev Mode"
safety = "neutral"
instructions = """Die angeforderten Funktionen implementieren. Für jede Änderung Tests schreiben."""
enabled_tools = ["read_file", "write_file", "edit", "bash", "grep",]

[tools.write_file]
permission = "ask"

[tools.edit]
permission = "ask"

[tools.bash]
permission = "ask"

Schließlich ist der Fix-Modus absichtlich eng gefasst. Kein write_file, nur edit: Der Agent ändert bestehenden Code, ohne neue Dateien zu erstellen, was verhindert, dass er einen Fehler, den Sie einfach nur beheben lassen, “während des Prozesses refaktoriert”. Da er so eingeschränkt ist, können wir ihn sicher automatisch genehmigen.

display_name = "Fix Mode"
safety = "neutral"
instructions = """Berichtete Fehler beheben. Änderungen minimieren. Nur den betroffenen Code berühren."""
enabled_tools = ["read_file", "edit", "grep"]

[tools.read_file]
permission = "always"

[tools.edit]
permission = "always"

[tools.grep]
permission = "always"

Wechseln zwischen Modi und Organisieren

In einer interaktiven Sitzung zyklisiert Shift+Tab durch Modi: Vibe zeigt die Liste aller Ihrer Agenten, eingebaut und benutzerdefiniert, mit ihren Beschreibungen an – hier zahlt sich die sorgfältige Beschreibung aus, die in der vorherigen Lektion besprochen wurde. Von der Kommandozeile aus starten Sie direkt in einem Modus oder inspizieren den Inhalt des Agenten-Verzeichnisses.

# Direkt in einem Modus starten
vibe --agent review-mode

# Verfügbare Agenten auflisten
ls ~/.vibe/agents/

Schließlich sollten Sie eine klare Namenskonvention übernehmen. Der Suffix -mode unterscheidet sofort Ihre Arbeitskontexte von eher ad-hoc-Nutzungsagenten, und die alphabetische Reihenfolge des Verzeichnisses bleibt auch nach einer Dutzend Dateien lesbar.

~/.vibe/agents/
├── review-mode.toml      # Code-Überprüfung
├── deploy-mode.toml      # Bereitstellung
├── dev-mode.toml         # Entwicklung
├── fix-mode.toml         # Fehlerbehebungen
├── explore-mode.toml     # Erkundung
└── doc-mode.toml         # Dokumentation

Kernaussagen

• Ein einheitlicher Modus ist ein benutzerdefinierter Agent, der als vollständiger Arbeitskontext konzipiert ist
• Er kombiniert Werkzeuge, Berechtigungen, System-Prompt und Modell in einer einzigen Konfiguration
• Erstellen Sie komplementäre Modi, um Ihren Entwicklungszyklus abzudecken
• Shift+Tab ermöglicht es Ihnen, Modi in Echtzeit zu wechseln
• Benennen Sie Ihre Dateien konsistent, damit Sie sie leicht finden können
• Jeder Modus muss ein klares Ziel und angemessene Berechtigungen haben