Wenn dein Agent plötzlich dumm wirkt: openclaw tools.profile-Fail

Florian · · ~3 Min. Lesezeit
AI Blog
Wenn dein Agent plötzlich dumm wirkt: openclaw tools.profile-Fail

Zuletzt aktualisiert: 16.03.2026

Du wechselst vom Top-Modell auf ein günstigeres Modell (oder rutschst in einen Fallback) und plötzlich wirkt dein Agent wie ausgebremst: viel Erklärung, wenig Ausführung. Das fühlt sich nach „Modell wurde dümmer“ an, ist aber oft ein anderer Fehler: Capability-Drift durch ein falsches Tool-Profil.

Wir hatten genau diesen Praxisfall im OpenClaw-Setup: Bei tools.profile: messaging waren nur Messaging/Sessions verfügbar — aber kein exec, kein Dateisystem, keine Browser-Automation. Ergebnis: Der Agent plant sauber, kann aber die eigenen Schritte nicht mehr durchführen.

In diesem Guide bekommst du: schnelle Diagnose, klare Fixes, Break-Glass-Recovery und konkrete Tipps, wann du für Troubleshooting besser ein starkes Modell wie Codex oder Claude Code dazunimmst.

Warum das passiert: Capability-Drift statt IQ-Problem

Ein Modellwechsel ändert nicht nur Antwortqualität, sondern manchmal auch indirekt den verfügbaren Tool-Scope. Wenn dabei das Profil auf messaging fällt, verliert der Agent operative Fähigkeiten. Das ist kein „Prompting-Problem“, sondern ein Runtime-/Policy-Thema.

  • Symptom: Agent erklärt dir Schritte statt sie auszuführen.
  • Fehldiagnose: „Das Modell ist zu schwach.“
  • Echte Ursache: Toolrechte fehlen (exec/FS/browser weg).

Die typischen Warnsignale in der Praxis

  • Der Agent wiederholt denselben Plan in mehreren Antworten.
  • Er bittet ständig um manuelle Shell-Schritte, obwohl der Task automatisierbar wäre.
  • Dateiänderungen bleiben aus (read/write/edit faktisch nicht genutzt).
  • Browser-/Web-Schritte werden angekündigt, aber nicht ausgeführt.
  • Fehlertexte klingen nach Berechtigungs-/Tool-Limit statt Fachfehler.

Schnelldiagnose in 2 Minuten

Gehe strikt in dieser Reihenfolge vor:

  1. Session-Status prüfen: Welches Modell ist aktiv? Gab es Fallback?
  2. Toolprofil prüfen: Ist tools.profile unerwartet auf messaging?
  3. Mini-Probe: Lässt sich ein harmloser exec-Befehl ausführen?
  4. Datei-Probe: Kann der Agent eine Testdatei lesen/schreiben?
  5. Browser-Probe: Kann ein Snapshot/Navigation erfolgen?

Wenn Punkt 3–5 scheitern, ist es fast sicher kein „dummes Modell“, sondern fehlende Capabilities.

Der schnelle Fix (bewährt)

  • tools.profile auf full setzen.
  • Session/Task frisch starten (kein halbkaputter Zustand weiterverwenden).
  • Kurz Smoke-Checks ausführen (siehe unten).

Genau das war auch bei uns die Lösung: Nach Rückstellung auf full kam die komplette Tool-Chain zurück (exec, Filesystem, Browser, Memory), und der Loop war sofort weg.

Break-Glass: Wenn der Agent sich nicht mehr selbst retten kann

  1. Offene hängende Tasks stoppen.
  2. Profil/Config explizit korrigieren.
  3. Neue saubere Session starten (ohne Altlast-Kontext).
  4. Nur einen kleinen Probe-Task laufen lassen.
  5. Erst danach produktive Jobs reaktivieren.

Pro-Tipp: Bei kritischen Automationen lieber kurz „hart resetten“ als in einem teildefekten Zustand weiterzudebuggen. Das spart meist Stunden.

Wenn OpenClaw hängt: Nutze für die Fehlersuche ein starkes LLM als Co-Debugger

Wichtig in der Praxis: Wenn OpenClaw bereits in einem schwachen Fallback hängt, hilft „frag OpenClaw nach der Lösung“ oft nur begrenzt. In genau diesem Zustand ist Tool-Calling häufig eingeschränkt oder unzuverlässig. Du brauchst dann einen externen, starken Copilot für die Diagnose.

Bewährter Shortcut: Nimm Codex , Claude Code oder ein vergleichbar starkes LLM für die Analyse. Lass dir dort strukturiert einen Recovery-Plan bauen und spiele ihn dann gezielt in OpenClaw ein.

  • Schritt 1: Symptome + Logs + aktuelles Modell/Fallback kurz zusammenfassen.
  • Schritt 2: Vom starken LLM eine priorisierte Hypothesenliste erstellen lassen (Config, Toolprofil, Rechte, Session-State).
  • Schritt 3: Konkrete Prüfkommandos/Checks erzeugen lassen (kein generisches BlaBla).
  • Schritt 4: Fixes in kleiner Reihenfolge ausrollen und nach jedem Schritt verifizieren.
  • Schritt 5: Erst danach wieder in den Normalbetrieb wechseln.

Das spart oft massiv Zeit, weil du nicht versuchst, mit einem bereits eingeschränkten Agenten seine eigene Einschränkung zu debuggen.

Weiterführende Artikel

Fazit

Wenn dein Agent plötzlich „dumm“ wirkt, prüfe zuerst Capabilities statt nur Modellqualität. In unserem Fall war der Kernfehler ein falsches Tool-Profil — und der Fix auf tools.profile: full hat den Betrieb sofort normalisiert. Mit kurzen Smoke-Tests und klaren UAT-Kriterien vermeidest du, dass so ein Fehler wieder unbemerkt in den Live-Flow rutscht.

CTA: Nutze für kritische Störungen zuerst einen starken externen Co-Debugger (z. B. Codex oder Claude Code), erstelle einen klaren Recovery-Plan und übertrage die Fixes dann strukturiert in OpenClaw. Gerade bei schwachen Fallback-Zuständen sparst du damit meist die meiste Zeit.

Weiterführende Artikel