SOUL.md: Wie man System-Prompts schreibt, die das Verhalten deines Agenten wirklich verändern
Das Problem mit den meisten SOUL.md-Dateien
Jeder, der OpenClaw ein paar Tage betreibt, stellt irgendwann fest: Der Agent verhält sich immer noch wie ein generischer Chatbot. Er sagt "Gerne helfe ich dir dabei!", er erklärt Dinge, die nicht erklärt werden müssen, er fragt nach, wenn er einfach handeln sollte.
Der häufigste Grund: Die SOUL.md ist zu vage.
Typisches Beispiel einer schlechten SOUL.md:
```markdown
# Mein Agent
Du bist ein hilfreicher KI-Assistent.
Sei freundlich und effizient.
Hilf dem Nutzer bei seinen Aufgaben.
```
Das ist kein System-Prompt. Das ist eine Beschreibung, die auf jeden LLM zutrifft. Der Agent liest das — und verhält sich wie ein generischer LLM, weil nichts Konkretes gesagt wurde.
Dieser Post zeigt, wie echte SOUL.md-Dateien aussehen, die das Verhalten tatsächlich verändern.
---
Was SOUL.md in OpenClaw wirklich tut
Technisch gesehen ist SOUL.md der erste Abschnitt des System-Prompts jeder Sitzung. OpenClaw lädt diese Datei beim Starten, bevor der Agent irgendeine Konversation aufnimmt.
Das bedeutet: Alles in SOUL.md prägt jede einzelne Antwort. Es ist der Charakter, nicht die Aufgabe. Es ist "wer der Agent ist" — nicht "was er tun soll".
Der häufige Fehler: SOUL.md mit Aufgabenbeschreibungen füllen. Aufgaben gehören in Cron-Job-Prompts, HEARTBEAT.md oder direkte Nachrichten. SOUL.md ist für Verhalten, Persönlichkeit und dauerhafte Prinzipien.
---
Die vier Bausteine einer wirksamen SOUL.md
Baustein 1: Identität (wer ist der Agent?)
Nicht "du bist ein hilfreicher Assistent". Sondern: ein konkreter Charakter mit einer Rolle.
```markdown
Identität
Du bist Sam — Teamlead und KI-Assistent bei Humanizing Technologies.
Du arbeitest seit Monaten eng mit Dimitrios zusammen und kennst sein System in- und auswendig.
Du bist kein Chatbot. Du bist ein Teammitglied mit eigenem Urteilsvermögen.
```
Das klingt subtil, aber es macht einen messbaren Unterschied. Ein Agent, der sich als "Teammitglied" versteht, reagiert anders als einer, der sich als "hilfreicher Assistent" sieht. Er handelt proaktiver, er widerspricht wenn nötig, er denkt mit.
Baustein 2: Kommunikationsstil (wie redet der Agent?)
Das ist der Bereich, in dem die meisten sycophantischen Verhaltensweisen ihren Ursprung haben. Wenn du hier nichts sagst, füllt das Modell die Lücke mit "freundlich und ausführlich".
```markdown
Kommunikation
Keine Füllsätze. "Gerne helfe ich!", "Natürlich!", "Super Frage!" — niemals.
Antworten sind so kurz wie möglich und so lang wie nötig.
Bestätige Aufgaben kurz bevor du anfängst: "Erledigt." oder "Bin dabei."
Wenn du unsicher bist: Frage einmal, direkt. Nicht nach dem Anfangen.
In Gruppenkanälen: Nur sprechen wenn es Mehrwert gibt.
```
Diese Anweisungen sind testbar: Du kannst dem Agenten eine Aufgabe geben und prüfen, ob er Füllsätze verwendet. Wenn ja — die SOUL.md wird verfeinert.
Baustein 3: Verhaltensprinzipien (wie entscheidet der Agent?)
Das ist der Kern. Hier definierst du, wie der Agent mit Unsicherheit, Konflikten und Entscheidungen umgeht.
```markdown
Verhaltensprinzipien
Handeln statt Fragen: Bei eindeutigen Aufgaben nicht nachfragen — handeln.
Nur bei echten Ambiguitäten oder potenziellem Schaden: klären.
Simplizität zuerst: Die einfachste Lösung ist die beste.
Kein Over-Engineering, keine spekulativen Features.
Chirurgische Änderungen: Nur das anfassen, was gefragt wird.
Nicht "verbessern" was nicht kaputt ist.
Fehler direkt ansprechen: Wenn etwas schiefläuft: sofort melden, Kontext geben.
Kein Herumreden, kein Verschönern.
```
Das sind keine philosophischen Aussagen — das sind operationale Regeln. Der Agent kann sich in einer Situation fragen: "Handeln oder Fragen?" — und eine Antwort finden.
Baustein 4: Grenzen (was tut der Agent nicht?)
Grenzen sind genauso wichtig wie Erlaubnisse. Sie verhindern die häufigsten Fehler proaktiv.
```markdown
Grenzen
Private Informationen bleiben privat. Kein Leak in Gruppenkanälen.
Keine destruktiven Befehle ohne explizite Bestätigung (rm -rf, Drop Database, etc.).
Keine E-Mails, Tweets oder öffentlichen Posts ohne Freigabe.
Keine Tailscale Funnel — niemals. Nur Tailscale Serve.
```
Beachte die Spezifität: "Kein Tailscale Funnel" ist präziser als "keine öffentlichen Ports". Der Agent kann abstrakte Prinzipien missverstehen; konkrete Verbote werden eingehalten.
---
Echte Beispiele: Vorher und Nachher
Beispiel 1: Bestätigungen
Schlechte SOUL.md:
```markdown
Sei proaktiv und handlungsorientiert.
```
Ergebnis: Agent beginnt sofort mit Arbeit, ohne Bestätigung. Dimitrios weiß nicht, ob die Aufgabe empfangen wurde — startet zweimal.
Gute SOUL.md:
```markdown
Bei jeder Aufgabe: zuerst eine kurze Bestätigung senden.
"Bin dabei." / "Erledige ich jetzt." — dann arbeiten, dann Ergebnis melden.
```
Ergebnis: Klare Kommunikation. Keine Doppelanfragen.
---
Beispiel 2: Gruppenkanal-Verhalten
Schlechte SOUL.md:
```markdown
Sei in Gruppenkanälen zurückhaltend.
```
Ergebnis: Agent schweigt manchmal, antwortet manchmal auf jede Nachricht — inkonsistent.
Gute SOUL.md:
```markdown
In Gruppenkanälen antworten wenn:
Nicht antworten wenn:
```
Ergebnis: Verhält sich wie ein Mensch im Gruppenkanal.
---
Beispiel 3: Fehlerbehandlung
Schlechte SOUL.md:
(nichts über Fehler)
Ergebnis: Bei einem Fehler in einem Cron-Job schreibt der Agent eine lange Erklärung, warum der Fehler passiert ist, ohne das eigentliche Problem zu benennen.
Gute SOUL.md:
```markdown
Bei Fehlern:
1. Problem in einem Satz benennen
2. Was versucht wurde (konkret)
3. Was jetzt gebraucht wird (wenn unklar)
Kein langer Erklärtext. Kein "Leider ist ein Problem aufgetreten."
```
Ergebnis: Fehlerberichte sind direkt und umsetzbar.
---
SOUL.md für verschiedene Agenten-Typen
Die SOUL.md ist nicht für alle Agenten gleich. Jede Rolle braucht andere Schwerpunkte.
Teamleitung (Sam)
Schwerpunkt: Koordination, Urteilsvermögen, proaktives Handeln.
```markdown
Du trägst Verantwortung für das Gesamtbild. Wenn du siehst, dass etwas schiefläuft,
handelst du — auch ohne expliziten Auftrag. Delegation ist deine Stärke, nicht Schwäche.
```
Coding-Agent (Peter)
Schwerpunkt: Präzision, keine Annahmen, immer Tests.
```markdown
Du schreibst keinen Code, den du nicht verstehst. Du stellst lieber eine Frage mehr
als einmal falschen Code zu committen. Tests sind kein Optional — sie sind Standard.
```
Marketing-Agent (Maya)
Schwerpunkt: Ton, Konsistenz, Brand Voice.
```markdown
Du schreibst wie ein Mensch, nicht wie ein Unternehmens-Newsletter.
Kein Passiv, keine Buzzwords, keine "revolutionären Lösungen".
Schreib so, wie Dimitrios es selbst schreiben würde — nur besser.
```
CEO-Assistent (Atlas)
Schwerpunkt: Vertraulichkeit, Priorität, kurze Briefings.
```markdown
Alles, was du von Dimitrios erfährst, bleibt bei dir. Keine Details in Gruppenkanälen.
Ein Briefing ist maximal 5 Punkte. Wenn du mehr schreibst, schreibst du zu viel.
```
---
SOUL.md iterieren: Wie wir unsere Prompts verfeinern
SOUL.md ist kein einmaliges Dokument. Wir aktualisieren es regelmäßig — wenn ein Agent sich falsch verhält, oder wenn wir eine bessere Formulierung finden.
Unser Prozess:
1. Verhalten beobachten: Wo weicht der Agent vom Gewünschten ab?
2. Ursache finden: Fehlt eine Regel? Ist eine Regel zu vage?
3. Konkrete Regel formulieren: Nicht "sei besser" — sondern "bei X tue Y"
4. Sofort testen: Neue Nachricht senden, Verhalten prüfen
5. Wenn behoben: Regel bleibt. Wenn nicht: weiter verfeinern.
Das klingt nach Aufwand, ist aber in der Praxis schnell. Wir schreiben selten mehr als eine Zeile pro Iteration.
---
Häufige Fehler
Zu abstrakt: "Sei ehrlich und transparent" — der Agent weiß nicht, was das in einer konkreten Situation bedeutet.
Zu lang: Eine SOUL.md mit 2.000 Wörtern füllt das Kontextfenster und verdrängt wichtigere Informationen. Weniger ist mehr.
Widersprüche: "Sei kurz und präzise" und "erkläre alles ausführlich" im gleichen Dokument verwirren den Agenten. Entscheide dich.
Aufgaben statt Charakter: SOUL.md ist nicht für "prüfe täglich E-Mails". Das gehört in HEARTBEAT.md oder Cron-Job-Prompts.
Einmalig schreiben, nie anpassen: SOUL.md sollte sich mit dem Agenten entwickeln. Was in Woche 1 gut genug war, reicht in Woche 8 nicht mehr.
---
Fazit
Eine SOUL.md, die wirklich funktioniert, ist kein Essay — sie ist eine Sammlung konkreter Verhaltensprinzipien. Jede Zeile sollte testbar sein: Verhält sich der Agent so? Wenn nein — überarbeiten.
Die vollständigen SOUL.md-Dateien für alle 6 Agenten aus unserem Setup — inklusive Kommentaren, warum jede Regel so formuliert ist — sind im OpenClaw Setup Playbook dokumentiert.
18 Kapitel. Das echte Setup, nicht ein hypothetisches Framework.
Komplett auf Deutsch verfügbar. 🇩🇪