Antwortet Claude zu ausführlich? Mit Subagents Ihr persönliches KI-Team aufbauen

Wenn Sie Claude um eine Code-Sicherheitsprüfung bitten, liefert es oft gleich mit Refactoring-Vorschlägen, Performance-Analysen und Testfällen – alles auf einmal, 3.000 Zeilen lang. Das Problem ist nicht, dass die KI zu viel liefert, sondern dass Sie ihr nicht sagen können, sich auf genau eine Sache zu konzentrieren.

Subagents lösen genau das. Jeder Subagent hat einen eigenen Aufgabenbereich, eigene Tool-Berechtigungen und eine eigene Modellwahl – abgelegt im Projektordner .claude/agents/. Code-Review? Den Code-Review-Subagent aufrufen. Dokumentation? Den Dokumentations-Subagent. Die Grenzen stehen fest in der Config – kein Überschreiten, kein Abschweifen.

Dieser Artikel erklärt Konfiguration, Aufrufmechanismen und Multi-Agent-Zusammenarbeit – mit einem Praxisbeispiel aus einem Blog-Schreibsystem.

Was Subagents eigentlich sind

Kurz gesagt: Ein Subagent ist ein maßgeschneiderter Assistent für Claude. Jeder hat eigenen Aufgabenbereich, eigene Tool-Berechtigungen – und kann sogar ein anderes Modell nutzen.

Sie liegen im Ordner .claude/agents/ Ihres Projekts; jede Datei ist ein Assistent. Der Aufbau ist einfach: oben YAML-Config, darunter der ausführliche Prompt in Markdown.

---

name: code-reviewer
description: Assistent für Code-Qualität und Sicherheitslücken
tools: [Read, Grep, Glob]
model: haiku

---

Sie sind ein Code-Review-Experte und konzentrieren sich auf:
- Sicherheitslücken (SQL-Injection, XSS usw.)
- Performance-Engpässe
- Code-Style-Probleme
Sie weisen nur auf Probleme hin – ändern keinen Code.

Im Vergleich zu einer normalen Claude-Konversation unterscheiden sich Subagents in drei Punkten:

Fokus – Sie erledigen nur, was Sie vorgeben. Code-Review bedeutet Review, kein nebenbei geliefertes Refactoring.

Einschränkung – Tool-Berechtigungen legen Sie fest. Ein read-only Review-Assistent kann Ihre Dateien gar nicht ändern.

Wiederverwendbarkeit – Config-Dateien liegen im Projekt; das ganze Team nutzt dieselben Assistenten. Neuer Kollege? Einfach @code-reviewer – und los.

Warum Subagents sinnvoll sind

Ehrlich gesagt dachte ich anfangs, das sei überflüssig – reicht nicht ein normales Gespräch mit Claude?

Nach einiger Zeit merkte ich: Es lohnt sich wirklich.

Fokus

Claude ist zu vielseitig. Fragen Sie nach Code, und es kommen Best Practices, Framework-Empfehlungen und vielleicht gleich noch Dokumentation – manchmal hilfreich, meistens Rauschen.

Subagents zwingen zur Einzelaufgabe. Ein reiner Code-Review-Assistent liefert kein Refactoring; ein Test-Assistent hinterfragt nicht Ihre Architektur.

Kostenoptimierung

Das übersehen viele: Nicht jede Aufgabe braucht das teuerste Modell.

Recherche, Formatkonvertierung, einfache Analysen – Haiku reicht, Kosten etwa ein Drittel von Sonnet. Über einen Monat summiert sich das spürbar.

Parallele Verarbeitung

Das ist für mich der größte Gewinn.

Mehrere Tasks gleichzeitig starten: Nach einem Feature-Commit laufen parallel Unit-Tests, Code-Review und Dokumentation. In der Praxis steigt die Effizienz deutlich.

Wiederverwendbarkeit

Fertige Configs ins Git-Repo – das ganze Team profitiert. Projekterfahrung wird zu ausführbarer Konfiguration.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

"Der Kernwert von Subagents ist Fokus und Wiederverwendbarkeit. Aus einem Generalisten wird ein Expertenteam – jeder Experte macht nur, was er am besten kann."

YAML-Konfiguration im Detail

Wie schreibt man die Config konkret?

Eine vollständige Subagent-Config hat mehrere Felder – nur zwei sind Pflicht:

---

name: blog-writer          # Pflicht: eindeutige ID
description: Experte für Blog-Erstentwürfe  # Pflicht: kurze Beschreibung, beeinflusst Auto-Trigger
tools: [Read, Write, Grep]  # Optional: Tool-Berechtigungen, Standard ist alles
model: sonnet              # Optional: Modellwahl, Standard ist Hauptkonversation

---

# Prompt steht unter dem YAML-Block
Sie sind ein professioneller Blog-Autor ...

name – ID des Assistenten für Aufrufe. Am besten selbsterklärend: code-reviewer, test-writer.

description – Entscheidend. Claude nutzt sie, um Auto-Trigger zu beurteilen. Schreiben Sie „allgemeiner Helfer für alle Aufgaben“, wird er praktisch nie automatisch aufgerufen.

Schlecht:

description: Ein Helfer

Gut:

description: Tiefe Recherche zu Blog-Themen, strukturierte Content-Planungsdokumente

tools – Liste der erlaubten Tools. Ohne Angabe: alle Tools – meist keine gute Idee (siehe unten).

model – Modellwahl. haiku ist günstig und schnell, sonnet der ausgewogene Standard, opus höchste Qualität, höchste Kosten.

Tool-Berechtigungen

Hier bin ich schon ins Fettnäpfchen getreten – deshalb ein eigener Abschnitt.

Am Anfang hatte jeder Subagent Vollzugriff. Einmal sollte ein reiner Analyse-Assistent Dateien ändern – falsch.

Seitdem gilt: Nur die nötigen Berechtigungen, nicht mehr.

Typische Kombinationen:

Ein konkretes Beispiel:

Schlecht: Zu viele Rechte für Code-Review

---

name: code-reviewer
tools: []  # Leeres Array = Vollzugriff, unsicher

---

Gut: Nur Leserechte

---

name: code-reviewer
tools: [Read, Grep, Glob]

---

Ein read-only Review-Assistent kann Ihren Code nicht versehentlich ändern. Diese Einschränkung ist Schutz.

Drei Aufrufwege

Config steht – wie rufen Sie auf?

Auto-Trigger

Ist die description präzise genug, entscheidet Claude selbst. Steht dort „alle Code-Review-Anfragen“, reicht „Prüf mir diesen PR“ – der Assistent startet.

@-mention

Am direktesten:

@code-reviewer Schau dir diese Funktion an

Task-Tool

Programmatisch, für komplexere Szenarien:

Task(subagent_type="code-reviewer", prompt="Prüfe alle Dateien unter src/")

Ich nutze meist @-mention – einfach und direkt. Auto-Trigger irrt gelegentlich; das Task-Tool lohnt sich in komplexen Workflows.

Multi-Agent-Zusammenarbeit

Bisher ging es um einzelne Assistenten. Die Stärke liegt in der Zusammenarbeit mehrerer Subagents.

Sequenzieller Modus

Am häufigsten nutze ich den sequenziellen Modus – ideal für Content-Workflows:

Nutzer gibt Thema vor
    |
@blog-planner Recherche und Gliederung
    | Output: Planungsdokument
@blog-writer liest Gliederung, schreibt Erstentwurf
    | Output: Erstentwurf
@blog-editor liest Entwurf, poliert für Veröffentlichung
    | Output: Finalversion

Jeder Assistent hat eine Etappe; Output von A ist Input für B. Klar, steuerbar, leicht zu debuggen.

Paralleler Modus

Noch effizienter nach einem Feature:

• @test-writer schreibt Unit-Tests
• @code-reviewer prüft Code
• @doc-writer schreibt Dokumentation

Drei Tasks parallel, ohne gegenseitige Störung. Was seriell 30 Minuten dauert, ist oft in 10 erledigt.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

HITL-Modus (Human In The Loop)

Für Szenarien mit menschlicher Freigabe:

@planner erstellt Plan
    |
Nutzer bestätigt oder passt an
    |
@executor setzt Plan um

Kritische Entscheidungen bleiben bei Ihnen – nichts läuft völlig unkontrolliert.

Sieben Tipps für gute Configs

Nach Monaten mit Subagents – sieben Regeln, die wirklich helfen:

Tipp 1: Präzise description

Die description steuert die Genauigkeit des Auto-Triggers.

Zu vage – fast nie automatisch:

description: Ein allgemeiner Assistent

Präzise – klare Verantwortung:

description: Prüft Python-Code auf Sicherheitslücken und Performance-Probleme

Tipp 2: Konkreter Prompt

Nicht nur „Sie sind Code-Review-Experte“ – sagen Sie, wie geprüft werden soll.

Zu allgemein:

Sie sind Code-Review-Experte und prüfen Code für Nutzer.

Konkrete Anleitung:

Sie sind Python-Sicherheits-Review-Experte.
## Schwerpunkte
1. SQL-Injection – alle DB-Operationen prüfen
2. XSS – Verarbeitung von Nutzereingaben
3. Sensible Daten – Logs und Fehlerbehandlung
## Ausgabeformat
Pro Problem:
- Datei: xxx
- Zeile: xxx
- Risiko: hoch/mittel/niedrig
- Beschreibung: xxx
- Fix-Vorschlag: xxx

Tipp 3: Tools minimieren

Nur nötige Rechte. Weniger Tools machen den Assistenten nicht dümmer – sie begrenzen nur das Handlungsspektrum.

Tipp 4: Passendes Modell

Einfache Tasks: Haiku. Komplexe: Sonnet.

• Haiku: Recherche, Formatkonvertierung, einfache Analysen, Datenaufbereitung
• Sonnet: komplexe Logik, kreative Inhalte, Code-Generierung, Reasoning

Tipp 5: Gründlich testen

Nach dem Schreiben: Auto-Trigger, @-mention, Grenzfälle – alles durchspielen.

Tipp 6: Klare Dokumentation

Der Prompt ist die Dokumentation. Gut geschrieben versteht das Team sofort Aufgabe und Nutzung.

Tipp 7: Häufig iterieren

Nicht auf Perfektion warten. Erst lauffähig, dann nach Feedback anpassen.

Typische Fehler vermeiden

Nach den Tipps – Fehler, die ich selbst gemacht habe:

Fehler 1: Vage description

„Allgemeiner Helfer“ – Claude weiß nicht, wann es ihn rufen soll. Konkret formulieren.

Schlecht:

description: Helfer für Nutzer

Besser:

description: Bei Erwähnung von „Test“ oder „Unit-Test“ automatisch Testfälle generieren

Fehler 2: Zu viele Tool-Rechte

Vollzugriff aus Bequemlichkeit – der Assistent tut Dinge, die Sie nicht wollen. Besonders Write: bewusst freigeben.

Schlecht:

name: format-converter
tools: []  # Leeres Array = Vollzugriff

Besser:

name: format-converter
tools: [Read, Write]

Fehler 3: Prompt zu lang

Subagent-Prompts verbrauchen Token. Tausende Zeichen bei jedem Aufruf – kurz halten, nur Nötiges.

Fehler 4: model vergessen

Ohne model erbt der Subagent das Hauptmodell (meist Sonnet). Einfache Tasks kosten unnötig.

Vergessen:

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

name: text-extractor
tools: [Read]

Richtig:

name: text-extractor
tools: [Read]
model: haiku

Fehler 5: Endlosschleifen

Agent A ruft B, B ruft A – läuft bis Timeout oder Abbruch.

Richtig: A → B → C
Falsch: A → B → A

Fehler 6: Keine Fehlerbehandlung

Subagents scheitern auch. Im Workflow Fehler abfangen und sichtbar machen.

Fehler 7: Config nicht versioniert

Configs ins Git. Bei Problemen Rollback auf die letzte funktionierende Version.

Praxisbeispiel: Blog-Schreibsystem

Genug Theorie – ein System, das ich selbst nutze: drei Subagents.

Architektur

Nutzer liefert Thema
    |
blog-planner: Recherche + Planung (20 Min.)
    | Output: docs/[Thema]-Content-Plan.md
blog-writer: Erstentwurf (40 Min.)
    | Output: docs/[Thema]-Erstentwurf.md
blog-editor: Feinschliff (20 Min.)
    | Output: docs/[Thema]-Final.md

blog-planner (Planer)

---

name: blog-planner
description: Tiefe Themenrecherche und Content-Planungsdokumente
tools: [Read, Write, Grep, WebSearch, WebFetch]
model: sonnet

---

Sie sind Content-Planer und:
1. recherchieren Trends per WebSearch
2. analysieren Zielgruppe und Pain Points
3. entwerfen Struktur und SEO-Strategie
4. speichern Planungsdokumente unter docs/

blog-writer (Autor)

---

name: blog-writer
description: Blog-Erstentwurf aus Planungsdokument
tools: [Read, Write, Grep]
model: sonnet

---

Sie sind Content-Autor und:
1. lesen Planungsdokument
2. schreiben vollständigen Erstentwurf nach Gliederung
3. sorgen für natürlichen, nicht-KI-typischen Ton
4. speichern Erstentwurf unter docs/

blog-editor (Editor)

---

name: blog-editor
description: Erstentwurf bearbeiten und Ausdruck humanisieren
tools: [Read, Edit]
model: haiku

---

Sie sind Content-Editor und:
1. lesen Erstentwurf
2. entfernen KI-typische Formulierungen
3. verbessern Lesbarkeit und Natürlichkeit
4. speichern Finalversion unter docs/

Workflow:

# Schritt 1: Planung
@blog-planner Claude Code Subagent Tipps
# Schritt 2: Schreiben
@blog-writer
# Schritt 3: Bearbeiten
@blog-editor

Jede Etappe hat klaren Input und Output – Fehler lassen sich leicht eingrenzen.

Kostenoptimierung

Zum Schluss die Kosten.

Haiku und Sonnet unterscheiden sich im Preis etwa im Verhältnis 1:3 (aktuelle Preise: Anthropic-Website). Bei sinnvoller Modellwahl spart ein typischer Blog-Workflow spürbar.

Modellstrategie

Haiku

• Recherche und Zusammenfassungen
• Einfache Formatkonvertierung
• Datenaufbereitung und Kategorisierung
• Code-Review (nur Lesen)

Sonnet

• Content (Blog, Doku)
• Komplexe Code-Generierung
• Analysen mit Reasoning
• Hohe Qualitätsanforderungen

Modellvergleich

Opus nutze ich selten – nur bei wirklich kritischen Qualitätsanforderungen. Für den Alltag reicht Sonnet.

Merksätze

• Wo Haiku reicht, kein Sonnet
• Tools einschränken statt All tools
• Prompt kurz statt Roman
• Output begrenzen statt alles erlauben

Fazit

Subagents sind kein Geheimtrick – sie teilen Claudes Fähigkeiten gezielt auf. Ein Generalist wird zum Expertenteam; jeder Experte macht sein Ding.

Wenn Sie noch „ein Claude für alles“ nutzen: Probieren Sie Subagents. Eine halbe Stunde Config spart unzählige „Claude ist wieder abgeschweift“-Momente.

Kernprinzipien:

1. Ein Agent, eine Aufgabe
2. Nur nötige Tool-Rechte
3. Einfache Tasks mit Haiku
4. Konkrete, klare Prompts
5. Multi-Agent-Workflow über Dokumente verketten

Probleme? Meist ist die Config schief. Die sieben Tipps und sieben Fehler oben lösen die meisten Fälle.

Und zum Schluss: Nicht auf Perfektion warten – starten und iterieren.

Viel Erfolg beim Aufbau Ihres eigenen KI-Teams!