Beim ersten Mal, als ich einen Subagenten verwendete, tat ich es falsch. Ich startete einen, um eine Variable umzubenennen. Eine Variable. Das war, als würde man einen Handwerker rufen, um eine Glühbirne zu wechseln — langsamer, teurer und irgendwie absurd. Bevor ich Ihnen also zeige, wie man einen Subagenten in Claude Code einrichtet, möchte ich klarstellen, wann man es nicht tun sollte.
Ein Subagent ist eine separate Claude-Instanz, der Ihre Hauptsession eine Aufgabe übertragen kann. Er bekommt sein eigenes Kontextfenster — eine leere Tafel —, erledigt die Aufgabe und gibt eine Zusammenfassung zurück. Das Schlüsselwort ist separat. Die Arbeit des Subagenten überfüllt Ihre Hauptkonversation nicht. Er erkundet, durchsucht zehn Dateien, und Ihre Hauptsession sieht nur das Ergebnis.
Das ist der ganze Sinn von Subagenten, und deshalb verwenden die meisten Anfänger sie falsch.
Wann Subagenten wirklich helfen
Sie helfen, wenn eine Aufgabe sonst Ihren Hauptkontext mit Dingen fluten würde, die Sie nicht behalten müssen.
Denken Sie daran, in einer großen Codebasis nach "wo behandeln wir Auth?" zu suchen. Ohne Subagenten liest Claude fünfzehn Dateien in Ihre Hauptkonversation, und diese fünfzehn Dateien bleiben für den Rest der Sitzung im Kontext und verbrauchen bei jedem Durchlauf Tokens. Mit einem Subagenten findet diese Erkundung in einem wegwerfbaren Fenster statt. Sie erhalten zurück "Auth befindet sich in src/auth/, so läuft es ab" — drei Sätze statt fünfzehn Dateien.
Also: Subagenten rechtfertigen ihren Einsatz, wenn die Arbeit explorativ ist (viel Lesen, kleines Ergebnis) oder parallel (mehrere unabhängige Dinge gleichzeitig). Suchen, untersuchen, eine große Testsuite ausführen und Fehler zusammenfassen, einen Diff anhand einer Checkliste überprüfen — das sind perfekte Anwendungsfälle.
Hier ist der Test, den ich jetzt verwende. Fragen Sie sich: Wird diese Aufgabe viel lesen, aber wenig produzieren? Wenn ja, Subagent. Wenn es sich um eine direkte Bearbeitung handelt, bei der Sie schon sehen, wie man sie macht, tun Sie es direkt. Eine Variable umbenennen liest nichts und erzeugt eine präzise Änderung. Kein Subagent.
Wann man sie NICHT nutzen sollte
Verwenden Sie keinen Subagenten für eine einzelne Dateibearbeitung, die Sie verstehen. Verwenden Sie keinen für sequenzielle Arbeit, bei der jeder Schritt davon abhängt, den vorherigen zu sehen. Und verwenden Sie keinen nur, weil es ausgeklügelt klingt. Jeder Subagent hat Overhead — er startet, baut seinen eigenen Kontext auf, berichtet zurück. Für kleine Aufgaben kostet dieser Overhead mehr als er einspart.
Neuere Claude-Modelle sind auch ziemlich zurückhaltend, selbst Subagenten zu erstellen, was normalerweise richtig ist. Wenn Sie Delegation möchten, müssen Sie sie oft explizit anfragen oder einrichten. Was uns zum Wie bringt.
Einen benutzerdefinierten Subagenten einrichten
Claude Code ermöglicht Ihnen, benannte Subagenten als Dateien zu definieren. Legen Sie eine Markdown-Datei in .claude/agents/ in Ihrem Projekt ab (oder in Ihrer Home-Konfiguration für eine globale). Hier ist eine echte Datei, die ich für Code-Reviews verwende:
---
name: reviewer
description: Reviews a diff for bugs and missing edge cases. Use after writing code, before committing.
tools: Read, Grep, Bash
---
You are a focused code reviewer. Given a diff or a set of changed files:
1. Read the changed code and the files it touches.
2. Look for actual bugs — off-by-one, null handling, wrong async behavior.
3. Check for missing edge cases and untested paths.
4. Report findings as a short list, each with a severity (high/medium/low).
Don't rewrite the code. Don't nitpick style. Report what you find and stop.
Ein paar Dinge sind erwähnenswert. Die description-Zeile ist keine Dekoration — sie ist, wie Claude entscheidet, wann er an diesen Agenten delegiert. Schreiben Sie sie so, wie Sie eine Werkzeugbeschreibung schreiben würden: Sagen Sie wann man darauf zurückgreift, nicht nur was er tut. "Verwenden Sie es nach dem Schreiben von Code, vor dem Commit" gibt Claude einen konkreten Auslöser.
Die tools-Zeile begrenzt, was der Subagent anfassen kann. Mein Reviewer bekommt Read, Grep und Bash — genug, um zu inspizieren und Tests auszuführen, nichts zum Bearbeiten. Das ist bewusst. Ein Reviewer sollte Ihren Code nicht ändern. Die Tool-Liste einzuschränken hält den Subagenten auf Kurs und ist eine Sorge weniger.
Der Hauptteil ist der System-Prompt des Subagenten — seine gesamte Persönlichkeit und Aufgabe. Beachten Sie, dass er spezifisch und begrenzt ist. "Berichte, was du findest, und höre auf" ist wichtig, denn sonst beginnt ein eifriger Subagent, Dinge zu reparieren, und jetzt haben Sie Änderungen, die Sie nicht angefordert haben.
Verwenden
Sobald die Datei vorhanden ist, können Sie sie in einer Sitzung aufrufen:
Verwende den Reviewer-Subagenten auf meinem letzten Commit.
Claude startet ihn, der Subagent erledigt seine Lese-und-Bericht-Aufgabe in seinem eigenen Kontext, und Sie erhalten eine saubere Liste von Befunden zurück — ohne dass fünfzehn Dateien in Ihrer Hauptkonversation landen. Für die Erkundung brauchen Sie nicht einmal eine benutzerdefinierte Datei; der eingebaute allgemeine Subagent erledigt ad hoc "Geh und finde X heraus"-Aufgaben gut.
Der mentale Wandel
Das ist es, was Subagenten für mich schließlich einleuchtend machte. Hören Sie auf, sie als "einen stärkeren Claude" zu sehen. Sie sind nicht klüger. Sie sind eine Möglichkeit, Ihren Hauptkontext sauber zu halten, indem unordentliche Arbeit woanders hin geschickt wird.
Sobald Sie es so sehen, beantwortet sich die Frage nach dem Wann von selbst. Unordentliche, leseintensive, wegwerfbare Arbeit? Delegieren Sie sie. Präzise Arbeit, die Sie sich bereits vorstellen können? Tun Sie es einfach. Ein Reviewer, der Ihre Tests ausführt und eine Befundliste zurückgibt — hervorragend. Ein Handwerker zum Glübirnenwechseln — weniger.
Schreiben Sie diese Woche einen Subagenten. Machen Sie ihn zum Reviewer oben. Führen Sie ihn auf Ihrem nächsten Commit aus. Dann spüren Sie den Unterschied, und Sie werden genau wissen, wann Sie zum nächsten greifen.