Die Verwendung eines kleineren Modells als Laufzeit-Hygieneschicht verbessert die Zuverlässigkeit des OpenClaw-Agenten.

Problem: Schlampige Ausgaben beeinträchtigen langlebige Agenten

Bei lokalem Betrieb von OpenClaw auf einem Mac Studio M4 (36 GB) mit Qwen 3.5 27B (4-Bit, oMLX) als Haushaltsagent wurde das Modell mit der Zeit nicht weniger fähig – es wurde schlampig. Konkrete Probleme umfassten:

• Tool-Aufrufe, die als Rohtext statt als strukturierte Tool-Nutzung durchsickern
• Planungsgedanken, die in endgültige Antworten einfließen
• Wiederholung von Tool-Ergebnissen und Richtlinientexten an den Nutzer
• Fehlgeformte Ausgaben, die den Kontext vergiften und mit jedem weiteren Durchgang zu Verschlechterung führen

Das Kernproblem war nicht die Fähigkeit, sondern die Laufzeithygiene: Das Modell wusste, was zu tun ist, scheiterte aber an korrektem Verhalten innerhalb der OpenClaw-Laufzeitumgebung.

Lösung: Vier-Schichten-Architektur für Laufzeithygiene

Der Entwickler implementierte einen Vier-Schichten-Ansatz, der sich als effektiver erwies als einfach ein größeres Modell zu verwenden:

• Zusammenfassung: Kontextkomprimierung via lossless-claw (DAG-basiert, freshTailCount=12, contextThreshold=0,60). Dies brachte die größte Verbesserung.
• Sheriff: Regex- und Heuristikprüfungen, die fehlgeformte Antworten abfangen, bevor sie OpenClaw erreichen. Dies verhindert, dass durchgesickerte Tool-Markups, Planungsgeschwafel und rohes JSON zu dauerhaftem Kontext werden.
• Richter: Ein kleineres, günstigeres Modell, das grenzwertige Ausgaben als „gültige Endantwort“ vs. „Müll“ klassifiziert. Dieses Modell dient nicht der Intelligenz, sondern der Laufzeithygiene – es ist ein Immunsystem, kein zweites Gehirn. Es übernimmt auch alle Zusammenfassungen für lossless-claw.
• Ozempic (interner Name): Aggressives Speicherbereinigen, das sicherstellt, dass das Modell in späteren Durchgängen nur Nutzeranfragen, Endantworten und kompakte, tool-abgeleitete Fakten erneut liest – nicht Planungsgeschwafel, rohes Tool-JSON, Wiederholungsartefakte oder Richtlinien-Selbstgespräche.

Warum dies besser ist als ein größeres Modell

Ein einzelnes Modell muss gleichzeitig Aufgaben lösen, Formatierungsdisziplin wahren, Kontextkohärenz managen, Selbstvergiftung durch eigene Ausgaben vermeiden und sich von schlechten Ausgaben erholen – besonders herausfordernd bei lokalen Quantisierungsstufen. Die Aufteilung der Verantwortung, sodass das Hauptmodell die Arbeit erledigt und ein kleineres Modell die Laufzeithygiene aufrechterhält, erwies sich als effektiver als das Hinzufügen weiterer Parameter.

Ergebnis: Dauerbetrieb ohne Neustarts

Der Ansatz führte von notwendigen /new-Neustarts alle 20-30 Minuten hin zu dauerhaftem Einzelsitzungsbetrieb auf einem Mac Studio M4 mit 36 GB RAM, vollständig lokal und ohne API-Aufrufe.