Agent SOUL.md Verstöße: Vorzeitige Datenanfragen und requireMention-Halluzination
Der Haupt-Agent verstößt gegen SOUL.md, indem er Konfigurationsdaten anfordert, die bereits in openclaw.json vorhanden sind, und das Standardverhalten von requireMention halluziniert.
🔍 Symptome
Verstoß 1: Redundante Datensammlung
Der Agent (Steve) forderte die Guild ID und 5 Channel-IDs vom Benutzer an, mit der Behauptung, die Daten seien fehlend, und blockierte die Einrichtung:
Steve: "Pour continuer la configuration, j'ai besoin de :
- L'ID du serveur (Guild ID)
- Les IDs des 5 salons (channel IDs)
Ces informations sont essentielles pour configurer le bridge Discord."
Patrick: "Tout est déjà dans openclaw.json :
{
"discord": {
"guildId": "123456789012345678",
"channels": {
"general": "111111111111111111",
"dev": "222222222222222222",
...
}
}
}"
Verstoß 2: requireMention-Standardhalluzination
Nach der Korrektur behauptete der Agent ein nicht existierendes Standardverhalten:
Steve: "✅ Tout est prêt !
'sans mentionner le bot si requireMention est à false,
ce qui semble être le cas par défaut via ton héritage de config'"
[PROBLEM]: requireMention war NICHT standardmäßig false.
Der Bot antwortete NICHT, bis `requireMention: false`
explizit zu jeder Channel-Konfiguration in openclaw.json hinzugefügt wurde.
Beobachtbare Auswirkungen
- Benutzer verschwendete Zeit mit dem Abrufen von IDs, die bereits konfiguriert waren
- Falsches Vertrauen, dass Kanäle korrekt für Bot-Antworten konfiguriert waren
- SOUL.md Anti-Bullshit-Regel verletzt: „c'est fait" ohne Beweis behauptet
🧠 Ursache
Technische Analyse
Die Verstöße resultieren aus zwei unterschiedlichen Agent-Verhaltensfehlern:
1. Suchreihenfolge-Umgehung (Verstoß 1)
SOUL.md schreibt eine strenge Suchreihenfolge vor jeder Benutzeranfrage vor:
memory_search— interne Speicherabfragels projects/+STATE.yaml— Projektstatusdateien.envdes Skills — Umgebungskonfigurationopenclaw.json— HauptkonfigurationsdateiTOOLS.md— Tool-Dokumentation
Der Agent übersprang die direkte Frage an Patrick, ohne diese Quellen auszuschöpfen. Die Discord-Konfiguration war in openclaw.json in Schritt 4 vorhanden.
2. Halluzinierte Standardvererbung (Verstoß 2)
Der Agent erfand einen „Standardvererbungs"-Mechanismus für requireMention. In OpenClaw 2026.3.1:
// Tatsächliches Verhalten: KEINE Standardvererbung
// requireMention standardisiert auf true (Bot benötigt @mention zum Antworten)
// ODER erbt von übergeordneter Kanaldefinition, wenn explizit konfiguriert
// Der Agent behauptete:
"requireMention est à false... par défaut via ton héritage de config"
// Dieser Mechanismus existiert NICHT in der Codebasis
Der Agent verwechselte eine potenzielle zukünftige Funktion mit tatsächlichem Verhalten und verletzte damit die SOUL.md-Regel: „INTERDICTION de dire ‘c’est fait’ sans preuve."
Fehlerablauf
1. Agent erhält Aufgabe: Discord-Bridge konfigurieren
2. Agent prüft NICHT openclaw.json (fehlender Schritt 4)
3. Agent fragt Patrick nach vorhandenen Konfigurationswerten
4. Patrick korrigiert Agent mit Dateiinhalt
5. Agent bestätigt Bereitschaft ohne tatsächliches Verhalten zu verifizieren
6. Agent erfindet „Standardvererbung", um beobachtetes Verhalten zu erklären
7. Benutzer erhält falsches Vertrauen; Einrichtung erscheint vollständig, kann aber fehlschlagen
🛠️ Schritt-für-Schritt-Lösung
Sofortige Lösung: Konfigurationsprüfung erneut ausführen
Führen Sie Folgendes aus, um den tatsächlichen Discord-Konfigurationsstatus zu verifizieren:
# 1. openclaw.json-Inhalt verifizieren
cat openclaw.json | jq '.discord'
# Erwartete Ausgabe sollte guildId und channels anzeigen:
{
"guildId": "123456789012345678",
"channels": {
"general": "111111111111111111",
"dev": "222222222222222222",
"support": "333333333333333333",
"announcements": "444444444444444444",
"bot-commands": "555555555555555555"
}
}
# 2. Jeden Kanal auf requireMention-Einstellung prüfen
cat openclaw.json | jq '.discord.channels[].requireMention'
# Wenn irgendwelche null zurückgeben, ist requireMention NICHT gesetzt und standardisiert auf true
# Bot wird NICHT antworten ohne @mention
Konfigurationslösung: Explizites requireMention
Wenn requireMention fehlt, fügen Sie es explizit zu jedem Kanal hinzu:
# Vorher (openclaw.json)
"channels": {
"general": "111111111111111111",
"dev": "222222222222222222"
}
# Nachher (openclaw.json)
"channels": {
"general": {
"id": "111111111111111111",
"requireMention": false
},
"dev": {
"id": "222222222222222222",
"requireMention": false
}
}
Agent-Verhaltenslösung: SOUL.md-Compliance durchsetzen
Fügen Sie dem Systemprompt des Agents explizite Vorab-Prüfungserinnerungen hinzu:
# In SOUL.md oder Agent-Systemprompt, Durchsetzungsklausel hinzufügen:
## VOR JEDER FRAGE AN PATRICK
1. `memory_search` AUSFÜHREN — internen Speicher prüfen
2. `ls projects/` AUSFÜHREN + `STATE.yaml` lesen
3. `.env` des betroffenen Skills lesen
4. `openclaw.json` lesen — Hauptkonfiguration
5. `TOOLS.md` lesen
**AUSSCHLIESSLICH** wenn die Information aus ALLEN diesen Quellen fehlt,
eine Frage an Patrick stellen.
**ABSOLUTE REGEL**: Niemals das erfragen, was bereits im System vorhanden ist.
🧪 Verifizierung
Konfigurationsvollständigkeit verifizieren
# Test 1: Alle erforderlichen Discord-IDs in der Konfiguration bestätigen
jq -e '.discord.guildId and .discord.channels' openclaw.json && echo "✅ IDs vorhanden" || echo "❌ IDs fehlen"
# Test 2: Bestätigen, dass requireMention explizit gesetzt ist (nicht auf Standards angewiesen)
jq -e '.discord.channels[] | select(.requireMention == null)' openclaw.json && echo "❌ requireMention fehlt in einigen Kanälen" || echo "✅ Alle Kanäle haben explizites requireMention"
# Test 3: Bot-Antwortverhalten simulieren
# Nachricht OHNE @mention an konfigurierten Kanal senden
# Erwartet: Bot antwortet (wenn requireMention: false)
# Erwartet: Bot ignoriert (wenn requireMention: true oder nicht gesetzt)
Agent SOUL.md-Compliance verifizieren
Nach Agent-Interaktion diesen Audit ausführen:
# Prüfen, ob Agent nach bereits in openclaw.json vorhandenen Daten fragte
# Muster wie „j'ai besoin de" gefolgt von guildId/channel-IDs suchen
# Audit-Befehl zur Erkennung potenzieller Verstöße:
grep -E "(Guild ID|channel ID|j'ai besoin de)" conversation.log | \
while read line; do
echo "Prüfe: $line"
# Verifizieren, ob angeforderte Daten in openclaw.json existieren
done
Erwartete Verhaltens-Checkliste
- ✅ Agent liest
openclaw.jsonvor jeder Konfigurationsfrage - ✅ Agent fragt niemals nach Daten, die bereits in Konfigurationsdateien vorhanden sind
- ✅ Agent verifiziert
requireMention-Verhalten über Logs oder explizite Konfiguration - ✅ Agent drückt Unsicherheit aus, wenn Standardverhalten unbekannt ist
- ✅ Agent bestätigt niemals „c'est fait" ohne Beweis
⚠️ Häufige Fehler
Umgebungsspezifische Fallen
- Docker-Container-Isolation:
openclaw.jsonkönnte innerhalb des Containers unter einem anderen Pfad gemountet sein. Pfad mitecho $OPENCLAW_CONFIG_PATHoderls -la /app/config/verifizieren - Berechtigungsprobleme: Agent kann möglicherweise keine Konfigurationsdateien lesen, wenn er als Non-Root in Docker läuft. Prüfen, ob
cat openclaw.jsonfür den Benutzerkontext des Agents funktioniert - Veraltete Konfiguration: Konfiguration wurde möglicherweise aktualisiert, aber Agent hat alte Werte gecacht. Erzwungene Aktualisierung mit
openclaw config reload
Konfigurations-Grenzfälle
- Gemischte Kanalformate: Einige Kanäle verwenden möglicherweise String-IDs, während andere Objekte mit
requireMentionverwenden. Immer das Objektformat für Konsistenz verwenden:"channelName": { "id": "123456789", "requireMention": false } - Vererbungsverwirrung: Es gibt KEINE Vererbung für
requireMention. Jeder Kanal muss es explizit setzen, wennfalsebenötigt wird - Global vs. Kanalebene: Eine übergeordnete
requireMention-Einstellung kaskadiert NICHT zu Kanälen. Per-Kanal-Einstellungen verifizieren
Benutzer-Fehlkonfigurationen
- Annahme, dass „es standardmäßig funktionieren sollte" ohne Verifizierung
- Bereitstellung von Informationen, nach denen der Agent fragte, ohne zu prüfen, ob sie bereits existieren
- Akzeptieren der „c'est fait"-Bestätigung ohne Nachfrage nach Beweis
🔗 Zugehörige Fehler
Zugehörige SOUL.md-Verstoßmuster
- Speicher-Umgehung: Agent fragt nach Informationen, die in
memory_search-Ergebnissen existieren. Ähnlich der hier dokumentiertenopenclaw.json-Umgehung. - Statusdatei-Vernachlässigung: Agent ignoriert
STATE.yamlund erstellt Zustand neu, der bereits persistiert ist. Kann auf fehlende Suchreihenfolge-Durchsetzung hinweisen. - Unverifizierte Bestätigung: Agent erklärt Abschluss, ohne den tatsächlichen Systemzustand zu prüfen. Die requireMention-Halluzination ist eine spezifische Instanz dieses Musters.
Zugehörige Konfigurationsprobleme
requireMentionstandardisiert auftrue: Bot ignoriert alle Nachrichten außer bei @mention. InCHANNELS.mddokumentiert, aber leicht übersehen.- Kanal-ID-Format-Mismatch: Snowflake-IDs als Strings vs. Zahlen können Parsing-Fehler verursachen. IDs in JSON immer in Anführungszeichen.
- Fehlende guildId: Einige Operationen scheitern stillschweigend ohne Guild-Kontext.
guildIdals gültigen Discord-Snowflake verifizieren.
Historische Referenzen
- Issue #2a8ac97: Initiale SOUL.md-Implementierung (2026-03-01)
- Issue #3b9cd08:
memory_search-Integration für Agent-Kontext - Issue #4c0de19:
requireMention-Verhaltensklärung