Dieses Dokument enthält eine detaillierte Aufschlüsselung der vollständigen System-Prompt-Struktur, die vom OpenClaw Agent an das LLM gesendet wird.
Version:
v2.1
Update Time:
2026-03-05
Gesamtarchitektur-Diagramm
Schnellnavigation (TL;DR)
Pflichtlektüre für Einsteiger:
- Schicht 7 (Workspace-Dateien) – Konfigurationsdateien, die du direkt bearbeiten kannst.
- Schicht 8 (Bootstrap-Hook) – Hier kannst du Skripte schreiben, um dynamisch Inhalte einzufügen.
- Andere Schichten werden automatisch vom Framework generiert; es reicht, sie zu verstehen.
Häufige Anliegen:
- Agent-Identität definieren? → Bearbeite IDENTITY.md in Schicht 7.
- Projektdokumentation hinzufügen? → Nutze den bootstrap-extra-files-Hook in Schicht 8.
- Echtzeit-Kontext einfügen? → Nutze den before_prompt_build-Hook in Schicht 8.
- Dateigröße kontrollieren? → Passe die bootstrapMaxChars-Konfiguration an.
Schicht 1: OpenClaw Framework Core
Analogie
Wie der „Gebrauchshinweis“ in einer Bedienungsanleitung – sie sagt dem LLM, wer du bist, was du kannst und wie du antworten sollst.
Komponenten
Praktisches Beispiel
Du läufst als „Creative Partner“, einem KI-Content-Erstellungs-Experten-Agent.
Aktuelle Uhrzeit: 2026-03-05 14:37:00 CST
=== Tool-Calling-Spezifikation ===
- Verwende das XML-ähnliche Tool-Calling-Format.
- Jeder Tool-Aufruf muss eine eindeutige tool_call_id enthalten.
- Tool-Ergebnisse werden über <tool_result>-Tags zurückgegeben.
- Berücksichtige AbortSignal bei der Ausführung von Tools für die Unterstützung von Abbrüchen.
=== Sicherheitsgrenzen ===
- Streng verboten: destruktive Operationen (rm -rf, Formatierung usw.).
- Sensible Benutzerdaten müssen bei der Verarbeitung verschlüsselt werden.
- Verboten, Nachrichten an nicht autorisierte Kanäle zu senden.
Design-Entscheidungen
Warum so gestaltet?
- Abwägung: Flexibilität vs. Konsistenz
- Entscheidung: Einheitliche Generierung auf Framework-Ebene gewährleistet konsistentes Basisverhalten für alle Agents.
- Vorteile: Benutzer müssen keine grundlegenden Regeln für jeden Agent wiederholen. Alle Agents erhalten automatisch neue Funktionen, wenn das Framework aktualisiert wird. Reduziert das Risiko von Konfigurationsfehlern.
- Kosten: Benutzer können diese Kernregeln nicht ändern. Spezielle Verhaltensweisen müssen indirekt über Schicht 7/8 implementiert werden.
Schicht 2: Tool-Definitionen
Analogie
Wie die Werkzeugliste eines Schweizer Taschenmessers – sie sagt dem LLM, welche Werkzeuge du hast, was jedes tut und wie man sie verwendet.
Komponenten
Tool-Definitionsbeispiel
{
"name": "read",
"description": "Liest Dateiinhalte. Unterstützt Textdateien und Bilder (jpg/png/gif/webp). Bilder werden als Anhänge gesendet. Die Textausgabe ist auf 2000 Zeilen oder 50 KB begrenzt.",
"parameters": {
"type": "object",
"properties": {
"path": {
"type": "string",
"description": "Dateipfad (relativ oder absolut)"
},
"offset": {
"type": "number",
"description": "Startzeilennummer (1-basiert)"
},
"limit": {
"type": "number",
"description": "Maximale Anzahl zu lesender Zeilen"
}
},
"required": ["path"]
}
}
Design-Entscheidungen
Warum JSON Schema?
- Abwägung: Flexibilität vs. Typsicherheit
- Entscheidung: Verwende striktes JSON Schema zur Definition von Tool-Parametern.
- Vorteile: LLM versteht die Tool-Nutzung präziser. Das Framework kann Parameter vor dem Aufruf validieren. Generiert automatisch Dokumentation und Typdefinitionen.
- Kosten: Neue Tools erfordern das Schreiben eines vollständigen Schemas. Kann keine völlig dynamischen Parameterstrukturen unterstützen.
Schicht 3: Skills-Registry
Analogie
Wie die „Speisekarte“ eines Restaurants – sie sagt dem LLM, welche professionellen „Rezepte“ verfügbar sind.
Design-Entscheidungen
Warum Verzeichnisscan anstelle manueller Registrierung?
- Abwägung: Flexibilität vs. Wartungsaufwand
- Entscheidung: Automatisches Scannen des Verzeichnisses ~/development/openclaw/skills/.
- Vorteile: Ein neues Skill hinzuzufügen erfordert nur das Ablegen im Verzeichnis; keine Konfigurationsänderungen nötig. Alle Agents erhalten automatisch das neue Skill. Reduziert das Risiko von Konfigurationsfehlern.
- Kosten: Kann nicht genau steuern, welche Skills für jeden Agent verfügbar sind. Alle Skills werden in den System Prompt eingefügt (erhöht Token-Verbrauch).
Komponenten
Schicht 4: Modell-Aliase
Analogie
Wie „Verknüpfungen“ – gibt komplexen Modellpfaden kurze Aliase für einfachen Aufruf.
Design-Entscheidungen
Warum werden Modell-Aliase benötigt?
- Abwägung: Flexibilität vs. Lesbarkeit
- Entscheidung: Benutzern erlauben, kurze Aliase für häufig genutzte Modelle zu definieren.
- Vorteile: Vereinfacht Modellaufrufe (glm-5 statt zhipu/glm-5). Unterstützt Wechsel zwischen mehreren Providern (gleicher Alias kann auf verschiedene Provider verweisen). Erleichtert A/B-Tests und Modellmigration.
- Kosten: Erfordert Pflege einer Alias-Konfigurationsdatei. Kann zu Verwirrung führen (gleicher Alias könnte für verschiedene Agents auf unterschiedliche Modelle verweisen).
Komponenten
Praktisches Beispiel
Im System Prompt werden Modell-Aliase wie folgt angezeigt:
Modell-Aliase
- GLM-5: zhipu/glm-5
- Opus 4.6: xiaowang886/claude-opus-4-6-thinking
- Sonnet 4.5: xiaowang886/claude-sonnet-4-5
LLMs können Aliase verwenden, um Modelle zu wechseln: /model glm-5
Schicht 5: Protokollspezifikationen
Analogie
Wie „Verkehrsregeln“ – definieren standardisierte Protokolle für die Interaktion des Agent mit dem System.
Design-Entscheidungen
Warum werden Protokollspezifikationen benötigt?
- Abwägung: Freiheit vs. Konsistenz
- Entscheidung: Definiere standardisierte Interaktionsprotokolle (Stille Antworten, Herzschläge, Antwort-Tags usw.).
- Vorteile: Stellt konsistentes Verhalten aller Agents sicher. Unterstützt automatisierte Überwachung und Health Checks. Vereinfacht Multi-Agent-Kollaboration.
- Kosten: Schränkt die Ausdrucksfreiheit des Agent ein. Erfordert, dass das LLM Protokolle strikt befolgt (die möglicherweise ignoriert werden).
Komponenten
Praktisches Beispiel
Beispiel für Stille Antworten:
Benutzer: Erhalten
Agent: NO_REPLY
Beispiel für Herzschläge:
System: [Heartbeat Poll]
Agent: HEARTBEAT_OK
Beispiel für Antwort-Tags:
Agent: [[reply_to_current]] Aufgabe erledigt ✓
Schicht 6: Laufzeitinformationen
Analogie
Wie ein „Dashboard“ – sagt dem LLM den Echtzeit-Status der aktuellen Ausführungsumgebung.
Design-Entscheidungen
Warum jedes Mal Laufzeitinformationen einfügen?
- Abwägung: Token-Verbrauch vs. Kontextgenauigkeit
- Entscheidung: Füge mit jeder Anfrage den neuesten Laufzeitstatus ein.
- Vorteile: LLM kennt die aktuelle Uhrzeit (vermeidet Zeitverwirrung). LLM kennt das aktuelle Modell (vermeidet Fehleinschätzung von Fähigkeiten). LLM kennt die aktuelle Umgebung (vermeidet Pfadfehler).
- Kosten: Verbraucht ~2 KB Token pro Anfrage. Informationen können Redundanzen enthalten.
Komponenten
Praktisches Beispiel
Laufzeit
Schicht 7: Workspace-Dateien ★ Vom Benutzer steuerbar
Analogie
Wie „Deine Arbeitsnotizen“ – dies sind statische Konfigurationsdateien, die du direkt bearbeiten kannst.
Design-Entscheidungen
Warum ist nur diese Schicht statisch editierbar?
- Abwägung: Framework-Stabilität vs. Benutzerfreiheit
- Entscheidung: Trenne das „Veränderliche“ vom „Unveränderlichen“; die Framework-Schicht gewährleistet Konsistenz, während die Benutzerschicht Personalisierung erlaubt.
- Vorteile: Benutzer können Agent-Identität, Arbeitsspezifikationen und Speicher definieren. Framework-Upgrades zerstören keine Benutzerkonfigurationen. Konfigurationsdateien können versioniert, gesichert und geteilt werden.
- Kosten: Benutzer können das Kernverhalten des Frameworks nicht ändern. Erfordert das Erlernen des TELOS-Frameworks und der Dateistruktur.
Kern-Dateien
Schicht 8: Bootstrap-Hook-System ★ Vom Benutzer steuerbar
Analogie
Wie eine „programmierbare Spritze“ – du kannst Skripte schreiben, die zur Laufzeit dynamisch Inhalte in den System Prompt einfügen.
Design-Entscheidungen
Warum wird ein Hook-System benötigt?
- Abwägung: Einfachheit der statischen Konfiguration vs. Flexibilität der dynamischen Einfügung
- Entscheidung: Stelle einen dynamischen Hook-Mechanismus neben den statischen Workspace-Dateien bereit.
- Vorteile: Kann eingefügte Inhalte dynamisch an den Kontext anpassen (Kanal, Absender, Uhrzeit). Kann Shell-Befehle ausführen und Ausgaben einfügen (z. B. aktuelles Wetter, Git-Status). Kann externe Dateien lesen und einfügen (z. B. Projektdokumentation, API-Dokumentation). Unterstützt bedingte Logik (if/else).
- Kosten: Erfordert das Erlernen der Hook-System-Syntax und der Auslösemechanismen. Fehler in Hook-Skripten können zu Anomalien im System Prompt führen. Erhöht die Systemkomplexität.
Vier Hook-Mechanismen
- agent:bootstrap-Hook (Internes Hook-System)
Auslöseort: applyBootstrapHookOverrides() in bootstrap-hooks.ts
Fähigkeiten:
- Vollständige Kontrolle über das bootstrapFiles-Array.
- Kann Dateien hinzufügen, löschen oder ändern.
- Kann Dateien neu anordnen.
- Kann Dateiinhalte ändern.
Wer kann registrieren:
- OpenClaw-Plugins.
- Workspace-Hooks (~/.openclaw/workspace-*/hooks/ Verzeichnis).
- Interne Module.
Code-Beispiel:
registerInternalHook("agent:bootstrap", (event) => {
const context = event.context as AgentBootstrapHookContext;
// Vollständige Kontrolle über das bootstrapFiles-Array
context.bootstrapFiles = [
{ path: "CUSTOM.md", content: "Custom Content" }
];
});
- bootstrap-extra-files-Hook (Mitgelieferter Hook)
Auslöseort: handler.ts in hooks/bundled/bootstrap-extra-files/
Fähigkeiten:
- Hängt nur Dateien an; ändert keine vorhandenen.
- Gibt zusätzliche Dateien über Konfigurationsdatei an.
Konfigurationsbeispiel:
{
"hooks": {
"bootstrap-extra-files": {
"enabled": true,
"paths": ["extra/*.md", "docs/CONTEXT.md"]
}
}
}
Anwendungsszenarien:
- Benötige Einfügen von projektspezifischen Kontextdateien.
- Möchte die standardmäßigen 8 Bootstrap-Dateien nicht ändern.
- Benötige dynamisches Laden zusätzlicher Dokumentation.
- before_prompt_build-Hook (Plugin-Hook)
Auslöseort: runBeforePromptBuild() in attempt.ts
Fähigkeiten:
- Ändert den finalen Prompt (nach System-Prompt-Erstellung, vor Senden an LLM).
- Kann Kontext voranstellen (Inhalt vor dem Prompt hinzufügen).
- Kann systemPrompt überschreiben.
Ereignisdaten:
{
prompt: string; // Benutzereingabe
messages: unknown[]; // Sitzungsnachrichtenverlauf
}
Rückgabewert:
{
prependContext?: string; // Inhalt, der vor dem Prompt hinzugefügt wird
systemPrompt?: string; // Überschreibt den System-Prompt
}
Anwendungsszenarien:
- Benötige dynamische Anpassung des Prompts basierend auf Sitzungsverlauf.
- Benötige Einfügen von Echtzeit-Kontext (z. B. aktuelle Uhrzeit, Wetter).
- Benötige vollständiges Ersetzen des System-Prompts.
- bootstrapMaxChars / bootstrapTotalMaxChars (Konfigurationselement)
Typ: Konfigurationselement (kein Hook)
Fähigkeiten:
- Steuert das Zeichenbudget.
- Einzeldatei-Standard: 20K.
- Gesamt-Standard: 150K.
- Überschuss wird abgeschnitten, indem die ersten 70 % + die letzten 20 % genommen werden.
Konfigurationsort:
{
"agents": {
"defaults": {
"bootstrapMaxChars": 20000,
"bootstrapTotalMaxChars": 150000
}
}
}
Praktische Ratschläge
Szenario 1: Ich möchte Projektdokumentation hinzufügen
Empfohlene Lösung: bootstrap-extra-files
{
"hooks": {
"bootstrap-extra-files": {
"enabled": true,
"paths": ["docs/API.md", "docs/ARCHITECTURE.md"]
}
}
}
Szenario 2: Ich möchte basierend auf dem Aufgabentyp dynamisch Dateien laden
Empfohlene Lösung: Benutzerdefinierter agent:bootstrap-Hook
registerInternalHook("agent:bootstrap", (event) => {
const context = event.context as AgentBootstrapHookContext;
const sessionKey = context.sessionKey;
// Unterschiedliche Dateien je nach Sitzungstyp laden
if (sessionKey.includes("coding")) {
context.bootstrapFiles.push({
path: "CODING_GUIDELINES.md",
content: fs.readFileSync("...").toString()
});
}
});
Szenario 3: Ich möchte Echtzeit-Kontext einfügen (z. B. aktuelle Uhrzeit)
Empfohlene Lösung: before_prompt_build-Hook
on("before_prompt_build", (event, ctx) => {
return {
prependContext: Current Time: ${new Date().toISOString()}
};
});
Schicht 9: Eingehender Kontext (Inbound Context)
Analogie
Wie „Echtzeit-Verkehrsinformationen“ – fügt mit jeder Anfrage dynamisch Kontextinformationen des aktuellen Gesprächs ein.
Design-Entscheidungen
Warum jedes Mal Kontext einfügen?
- Abwägung: Token-Verbrauch vs. Gesprächskohärenz
- Entscheidung: Füge mit jeder Anfrage die neuesten Nachrichtenmetadaten, Absenderinformationen und den Gesprächsverlauf ein.
- Vorteile: LLM weiß, wer gerade spricht (vermeidet Verwechslung des Absenders). LLM kennt den Gesprächsverlauf (erhält Kontextkohärenz). LLM weiß, ob es erwähnt wurde (entscheidet, ob es antworten soll).
- Kosten: Verbraucht ~3 KB Token pro Anfrage. Gesprächsverlauf kann Rauschen enthalten.
Komponenten
Vollständiger System-Prompt-Assembly-Prozess
Zusammenfassung der vom Benutzer steuerbaren Schichten
OpenClaw bietet 3 Arten von benutzersteuerbaren Mechanismen:
- Schicht 7 (Workspace-Dateien) - Statische Konfigurationsdateien. Szenario: Definieren von Agent-Identität, Arbeitsspezifikationen, Speicher. Vorteile: Einfach, intuitiv, gute Versionierbarkeit. Nachteile: Kann nicht dynamisch angepasst werden.
- Schicht 8 (Bootstrap-Hook-System) - Dynamische Einfügungsskripte. Szenario: Einfügen von Inhalten basierend auf Kontext, Ausführen von Befehlen, Lesen externer Dateien. Vorteile: Flexibel, leistungsstark, unterstützt Logik und Befehle. Nachteile: Erfordert Lernen des Hook-Systems; Skriptfehler verursachen Probleme.
- Indirekte Steuerung von Schicht 9 (Eingehender Kontext) - Beeinflussung des Kontexts durch Senden von Nachrichten. Szenario: Beeinflussung des LLM-Verhaltens über Chat-Verlauf oder zitierte Nachrichten. Vorteile: Keine Konfiguration nötig, natürliche Interaktion. Nachteile: Kann nicht präzise gesteuert werden.
Größenvergleichstabelle
⚠️
Hinweis: Die folgenden Daten sind Schätzungen; tatsächliche Größen variieren je nach Konfiguration und Laufzeitkontext. Framework-Schichten (Schicht 1-6 + 9) sollten theoretisch gleich sein, können aber aufgrund von Tool-Definitionen, geladenen Skills usw. geringfügig abweichen.
Hinweise:
- Schicht 7 und Schicht 8 sind vom Benutzer steuerbar; Größen variieren je nach Agent-Konfiguration.
- Andere Schichten werden automatisch generiert und sind theoretisch identisch über alle Agents hinweg.
- Tatsächliche Messungen können aufgrund von Tool-Verfügbarkeit, Skills-Laden und Laufzeitkontext abweichen.
Optimierungsvorschläge
- Optimierung des benutzersteuerbaren Teils (Schicht 7 + 8)
Da Schicht 7 und 8 benutzergesteuert sind, hier Optimierungsstrategien:
Optimierung von Schicht 7 (Statische Dateien):
✅ Empfohlene schlanke Strategien:
- IDENTITY.md: Behalte das Kern-TELOS-Framework, entferne redundante Beschreibungen, verwende Tabellen anstelle von Absätzen.
- AGENTS.md: Verwende Checklisten anstelle von langen Absätzen, zeige Befehle in Code-Blöcken, entferne doppelte Regelerklärungen.
- MEMORY.md: Verlasse dich auf den MemOS-Auto-Export; füge keine Inhalte manuell hinzu – lass das System die Pflege übernehmen.
❌ Zu vermeidende Praktiken:
- Wiederhole keine Beschreibungen, die das OpenClaw-Framework bereits kennt.
- Kopiere keine detaillierten Skill-Beschreibungen in Workspace-Dateien.
- Verwende keine übermäßige Rhetorik oder schmückende Sprache.
Optimierung von Schicht 8 (Hook-System):
✅ Empfohlene Nutzungsstrategien:
- Bevorzuge bootstrap-extra-files (einfache Szenarien).
- Verwende agent:bootstrap, wenn bedingte Logik benötigt wird (komplexe Szenarien).
- Verwende before_prompt_build für Echtzeit-Kontext (dynamische Szenarien).
❌ Zu vermeidende Praktiken:
- Führe keine zeitaufwändigen Operationen in Hooks aus (blockiert die System-Prompt-Generierung).
- Füge keine zu vielen Inhalte in Hooks ein (überschreitet Token-Limits).
- Verwende keine instabilen externen Abhängigkeiten in Hooks (führt zu Startfehlern).
- Prompt-Kürzungsstrategie
Falls der System-Prompt zu groß ist, erwäge:
Fazit
Der System-Prompt von OpenClaw ist keine einzelne Datei, sondern eine sorgfältig orchestrierte 9-Schichten-Architektur:
- Schicht 1-6: Automatisch vom Framework generiert, gewährleisten Konsistenz und Stabilität.
- Schicht 7: Vom Benutzer editierbare statische Konfigurationsdateien (IDENTITY.md, AGENTS.md usw.).
- Schicht 8: Vom Benutzer programmierbare dynamische Einfügungsskripte (Bootstrap-Hook-System).
- Schicht 9: Vom Framework automatisch eingefügter Echtzeit-Kontext (Eingehender Kontext).
Es gibt 2 vom Benutzer steuerbare Schichten (Schicht 7 + 8), nicht nur Schicht 7, wie zuvor fälschlicherweise angegeben.
Das Verständnis der Unterschiede und Verbindungen zwischen diesen Schichten ist der Schlüssel zur Beherrschung der OpenClaw-Konfiguration.
