User.md erklärt — Personalisierung deines OpenClaw-Agenten
Direkte Antwort: User.md ist die OpenClaw-Datei, in der Infos über dich stehen — Name, Rolle, Vorlieben, Arbeitskontext. Sie wird zusammen mit der Soul.md bei jedem Request mitgegeben, damit der Agent dich kennt und personalisiert antwortet, ohne dass du es jedes Mal neu erklärst.
Was ist User.md?
User.md ist die zweite Schicht der OpenClaw-Konfiguration nach der Soul.md. Während die Soul den Agenten beschreibt (wer er ist, wie er sich verhält), beschreibt die User.md DICH (den Nutzer): Name, Rolle, Hintergrund, Vorlieben, aktuelle Projekte.
Damit weiß der Agent jederzeit, mit wem er spricht. Du musst nicht in jeder Session neu erklären "Ich heiße Maria, bin Marketing-Lead bei XYZ und arbeite gerade an Q4-Planning". Die User.md schickt diesen Kontext einmal pro Request mit.
Kontext
In der OpenClaw-Architektur trennen sich die Konfigurations-Layer klar nach Verantwortung:
| Datei | Beschreibt | | --- | --- | | Identity File | WER ist der Agent (Name, Modell) | | Soul.md | WIE verhält sich der Agent (Persönlichkeit) | | User.md | WER ist der Nutzer (du, dein Kontext) | | Memory | WAS weiß der Agent aus früheren Gesprächen |
Diese Trennung erleichtert es, Soul.md mit verschiedenen User.mds zu kombinieren — z.B. eine Familie, die sich einen OpenClaw-Server teilt, kann pro Family-Member eine User.md haben, aber eine gemeinsame Soul.
Funktionsweise
Beim Start des Gateways wird User.md gelesen und als Teil des System-Prompts an das LLM mitgegeben. Bei jedem Turn weiß der Agent also automatisch:
- Wie heißt sein Gegenüber
- Welche Rolle/Beruf
- Welche Tonalität gewünscht (du-Form, Sie-Form)
- Welche Vorlieben (Bullet-Points, ausführlich, technisch)
- Welche Projekte aktuell relevant sind
Das Format ist freier Markdown — keine starre Schema-Vorgabe. Hauptsache, das LLM kann es lesen.
Praxis-Beispiel
Eine typische User.md für einen DACH-Selbstständigen:
# Wer bin ich
Name: Maria Schulz
Beruf: Marketing-Lead bei einer SaaS GmbH (50 Mitarbeiter)
Sprache: Deutsch (du-Form bevorzugt)
Standort: Berlin
# Aktuelle Projekte
- Q4 Content-Plan für LinkedIn (3 Posts/Woche)
- Relaunch Pricing-Page (kommendes Quartal)
- Hiring: Senior Performance-Marketer
# Tools die ich nutze
- LinkedIn (privat + Company-Page)
- Notion (zentrales Wiki)
- Slack (Team-Communication)
- Google Workspace (Mails, Docs, Calendar)
- HubSpot (CRM und Marketing-Automation)
# Vorlieben
- Antworten lieber kompakt mit Bullet Points statt Fliesstext
- Bei strategischen Themen: erst Optionen, dann Empfehlung
- Code-Beispiele in TypeScript bevorzugt
- Keine Geviertstriche im Text (Bindestriche bevorzugt)
# Privacy
- Keine Kunden-Namen in Memory speichern
- Keine Gehaelter / interne Finanzdaten
- Keine geheimen Strategien aus dem Strategie-Notion-Space
Der Agent kann jetzt z.B. spontan einen LinkedIn-Post entwerfen, der zu Maria passt — ohne dass sie jedes Mal "Ich bin Marketing-Lead und blogge auf LinkedIn" neu schreiben muss.
Was gehört in die User.md?
Sinnvoll:
- Name und Rolle
- Sprache, Tonalität, Du/Sie-Form
- Aktuelle Projekte (mittelfristige Themen)
- Tools und Plattformen, die du nutzt
- Format-Vorlieben für Antworten
- Wichtige Stakeholder/Kontakte (allgemein, nicht private Details)
Sinnvoll, aber privacy-sensitiv:
- Wohnort/Region (für Wetter, lokale Empfehlungen)
- Familie/Kinder (für Kalender-Logik, Erinnerungen)
- Gesundheits- oder Diätaspekte (für Rezept-Empfehlungen)
Nicht in User.md:
- Passwörter und API-Keys (separate
.env) - Bankdaten / Kreditkartennummern
- Sehr private medizinische Daten
- Daten von dritten Personen ohne deren Einverständnis
Multi-User-Setups
Wenn mehrere Personen denselben OpenClaw-Server nutzen (z.B. Familie, kleines Team), kannst du verschiedene User.md-Dateien anlegen und je nach Telegram-Chat oder Slack-User die richtige laden. Das geht typischerweise per Skill oder Custom-Logic im Gateway.
Wichtig: Memory sollte dann auch user-specific sein, sonst leckt das System Infos zwischen Usern.
User.md und DSGVO
User.md ist personenbezogen und unterliegt der DSGVO, sobald sie nicht nur deine eigenen Daten enthält. Wenn du User.md fürs Team einsetzt:
- Jeder User.md-Inhaber muss dem Speichern zugestimmt haben
- Lösch- und Auskunftsrechte müssen gewährt werden
- Bei Selbsthosting auf deinem Hetzner-VPS bist du Verantwortlicher gemäß DSGVO
Für reine Eigennutzung ist DSGVO entspannter, da du Daten über dich selbst verarbeitest.
Privacy-Considerations
- Backups verschlüsseln: User.md mit privaten Infos darf nicht im Klartext in einem Cloud-Backup landen.
- Repo-Sharing: Wenn du Soul-Templates auf GitHub teilst, exclude
user.mdper.gitignore. - LLM-Provider-Daten: Anthropic, OpenAI etc. sehen User.md bei jedem Request. Wer das nicht will, muss zu lokalen Modellen greifen oder sensible Felder weglassen.
- Memory-Hygiene: Auch wenn User.md sauber ist, der Agent kann später aus Konversationen Inhalte ins Memory schreiben. Regelmäßig prüfen.
- Soul-zu-User-Confusion: Schreibe nicht "Du bist Maria Schulz" in die Soul.md. Das verwirrt den Agenten und kann zu Halluzinationen über sich selbst führen.
Häufige Fehler / Stolperfallen
- Zu viele Details: Eine 5-seitige Lebensgeschichte bläht jeden Token-Verbrauch auf. Halte User.md schlank, lass Memory den Rest erinnern.
- Statisch lassen: Wenn sich dein Job/Projekt-Fokus ändert, aktualisiere die User.md. Veraltete Infos führen zu schlechtem Agent-Verhalten.
- Identity-Felder reinmischen: Modell, Provider, Bot-Token gehören NICHT in User.md.
- Inkonsistenz mit Memory: Wenn User.md sagt "Single", Memory aber von der Frau spricht, verwirrt das den Agenten. Konsistenz halten.
- Vergessen, dass es einsehbar ist: User.md ist eine normale Datei. Wer Server-Zugriff hat, liest sie. Schütze entsprechend.
Verwandte Begriffe
User.md im Detail: Modul 1 und Modul 3 der Masterclass.