Oder: Warum du für ein RAG-System keinen autonomen Agenten brauchst 
Aus einer Frage in der WhatsApp-Community ist dieser Beitrag entstanden. Der Use Case war: „OpenClaw soll mir ein RAG-System bauen – passende Tools suchen, testen, aufsetzen.“ Das klingt erstmal logisch, ist aber der falsche Ansatz. Hier erkläre ich warum – und wann welches Werkzeug tatsächlich Sinn macht.
Was OpenClaw eigentlich ist
OpenClaw ist kein Coding-Assistent. Es ist ein dauerhaft laufender, autonomer Agent mit eigenem Gateway-Prozess, Heartbeat-Scheduler, Session-Management über mehrere Messaging-Plattformen, und der Fähigkeit, Sub-Agenten zu spawnen. Das Ding läuft als Daemon im Hintergrund und wartet auf Arbeit – auch wenn du schläfst.
Das ist mächtig. Aber Macht kostet: Tokens, Kontrolle und Komplexität.
Die Architektur im Vergleich
So sieht es aus, wenn du ein Coding-Tool (Claude Code, Cursor, Codex etc.) für eine Buildaufgabe nutzt:
┌─────────────────────────────────────────────┐
│ CODING-ASSISTENT │
│ (Claude Code / Cursor / Codex) │
├─────────────────────────────────────────────┤
│ │
│ DU ──────► ASSISTENT ──────► CODE │
│ │ │ │ │
│ │ direkte Kontrolle │ │
│ │ bei jedem Schritt │ │
│ │ │ │ │
│ └──── review ◄────────────────┘ │
│ │
│ Token-Fluss: DU → 1x LLM → Ergebnis │
│ │
└─────────────────────────────────────────────┘
Und so sieht es aus, wenn du OpenClaw für dieselbe Aufgabe einsetzt:
┌─────────────────────────────────────────────┐
│ OPENCLAW │
│ (Autonomer Agent-Stack) │
├─────────────────────────────────────────────┤
│ │
│ DU ──► Gateway ──► Haupt-Agent │
│ │ │
│ ┌────┴────┐ │
│ ▼ ▼ │
│ Sub-Agent 1 Sub-Agent 2 │
│ │ │ │
│ Tool-Call Tool-Call │
│ │ │ │
│ Ergebnis Ergebnis │
│ │ │ │
│ └────┬───────┘ │
│ ▼ │
│ Haupt-Agent │
│ (aggregiert) │
│ │ │
│ Token-Fluss: │
│ DU → Gateway → Agent → Sub-Agents → LLM │
│ (mehrfache Token-Kosten, weniger │
│ direkte Kontrolle) │
│ │
└─────────────────────────────────────────────┘
Siehst du den Unterschied? Beim Coding-Assistenten steuerst du jeden Schritt. Bei OpenClaw entscheidet der Agent, was die Sub-Agenten tun. Du bezahlst Token für die Orchestrierung und für die Ausführung.
Entscheidungsmatrix: Wann was?
einmalig wiederkehrend
┌─────────────────┬─────────────────┐
│ │ │
einfach │ Coding-Tool │ Coding-Tool │
│ oder manuell │ + Cron/Script │
│ │ │
├─────────────────┼─────────────────┤
│ │ │
komplex │ Coding-Tool │ ★ OPENCLAW ★ │
│ (100%) │ (hier lohnt │
│ │ es sich!) │
│ │ │
└─────────────────┴─────────────────┘
OpenClaw lohnt sich, wenn:
-
Die Aufgabe regelmäßig wiederkehrt (tägliche Recherche, wöchentliche Reports, laufendes Monitoring)
-
Mehrere externe Systeme dauerhaft orchestriert werden müssen (E-Mail + Calendar + Web + Dateien)
-
Der Agent proaktiv handeln soll, ohne dass du ihn jedes Mal anstupst (Heartbeat-basiert)
-
Du ein dauerhaftes System willst, das über Wochen/Monate autonom arbeitet
-
Die Aufgabe kontextübergreifend ist – der Agent muss sich an vorherige Sessions erinnern
Beispiele: Automatisierte Wettbewerber-Recherche, tägliche News-Digests, Projektmanagement über mehrere Tools, dauerhaftes Monitoring mit automatischen Alerts.
Coding-Assistenten (Claude Code, Cursor, Windsurf, Codex, Gemini CLI) lohnen sich, wenn:
-
Du etwas einmalig bauen willst (RAG-System, App, Tool, Script)
-
Du direkte Kontrolle über jeden Schritt brauchst
-
Das Ergebnis ein fertiges Projekt ist, das danach eigenständig läuft
-
Du den günstigsten Token-Verbrauch willst
-
Du bei jedem Schritt reviewen und korrigieren willst
Beispiele: RAG-System aufsetzen, Perplexity-Klon bauen, App entwickeln, Datenbank-Migration, API aufsetzen.
Zurück zum konkreten Use Case
„Baue mir ein RAG-System mit freier Software, teste passende Tools, wenn das Projekt läuft ist OpenClaw raus.“
Das ist exakt ein Fall für Claude Code oder Cursor. Warum?
-
Einmalige Aufgabe – wenn das RAG-System steht, ist die Arbeit getan
-
Du willst Kontrolle – bei der Tool-Auswahl für dein RAG-System willst du mitentscheiden, nicht dem Agenten vertrauen
-
Token-Effizienz – ein Coding-Assistent löst das in einer Session. OpenClaw würde den Agenten-Overhead dazupacken
-
OpenClaw soll danach „raus“ sein – wenn der Agent nach dem Build nicht mehr gebraucht wird, warum den ganzen Stack aufsetzen?
Der Perplexity-Klon auf dem Homeserver via OpenRouter? Selbe Geschichte. Perfekter Job für einen Coding-Assistenten. Einmal bauen, danach läuft’s.
Die Token-Rechnung
Mal vereinfacht, damit es greifbar wird:
Coding-Assistent (z.B. Claude Code):
┌──────────────────────────────────────┐
│ Prompt → LLM → Code → Review │
│ ~50k-200k Token pro Session │
│ Alles geht direkt in dein Projekt │
└──────────────────────────────────────┘
OpenClaw für dieselbe Aufgabe:
┌──────────────────────────────────────┐
│ Prompt → Gateway → Agent-Loop │
│ → Sub-Agent 1 (Recherche) │
│ → Sub-Agent 2 (Testing) │
│ → Sub-Agent 3 (Build) │
│ ~300k-800k+ Token │
│ Davon 40-60% für Orchestrierung │
│ die DU eigentlich selbst steuern │
│ könntest │
└──────────────────────────────────────┘
Das heißt nicht, dass OpenClaw schlecht ist. Es heißt nur: Für diesen Job zahlst du mehr für weniger Kontrolle.
TL;DR
| Kriterium | Coding-Assistent | OpenClaw |
|---|---|---|
| Einmalige Builds |  Perfekt |
 Overkill |
| Wiederkehrende Aufgaben | Manuell |
Automatisch |
| Token-Effizienz | Direkt |
 Overhead |
| Kontrolle | Bei dir |
Beim Agent |
| Proaktives Handeln | Nicht vorgesehen |
Heartbeat |
| Multi-System-Orchestrierung | Session-basiert |
Dauerhaft |
Faustregel: Wenn du sagst „bau mir einmal X“ → Coding-Assistent. Wenn du sagst „mach jeden Tag X für mich“ → OpenClaw.
Fragen, Ergänzungen, andere Erfahrungen? Rein damit – genau dafür ist das Forum da.