„Ich benutze Claude Code, aber wenn das Projekt wächst, läuft der Kontext über und die Genauigkeit sinkt."
„Letztendlich ist mein eigenes Eingeben von Korrekturanweisungen an die KI zum größten Engpass geworden."
Viele Leute bleiben wahrscheinlich an diesem Punkt hängen. Mir ging es anfangs nicht anders – ich habe Code, Tests und Design-Diskussionen alle in eine einzige Sitzung gesteckt und zugesehen, wie Claudes Genauigkeit mit wachsendem Verlauf nachließ.
Was ich kürzlich gemerkt habe: Claude Code bietet offiziell drei Mechanismen, um mehrere Sitzungen parallel auszuführen.
Darüber hinaus sind diese drei Mechanismen ähnlich, aber unterschiedlich; wenn man sie verwechselt, kann es zu Unfällen kommen. Wenn man sie jedoch nach Rollen trennt, kann man auf die „Befehlsseite" wechseln, ohne selbst eine einzige Codezeile schreiben zu müssen.
Heute werde ich diese drei Mechanismen und die richtige Methode zur Festlegung von Rollengrenzen organisieren und dabei die Primärinformationen aus der offiziellen Dokumentation prüfen.
Konkret werde ich es in eine Konfiguration aufschlüsseln, bei der 8 Sitzungen auf drei Ebenen (Befehl, Implementierung und Qualität) verteilt sind.
Als Bonus erkläre ich anhand der Primärinformationen, warum gängige Erklärungen wie „Rollennamen in CLAUDE.md schreiben, um zu wechseln" oder „Speicher mit SQLite teilen" vom offiziellen Mechanismus abweichen.
Ich heiße tatsuki (@nobel_824).
Ich unterstütze KMU bei der KI-Nutzung, helfe bei der betrieblichen Umsetzung von Claude / Codex und betreibe selbst den ganzen Tag Claude Code. Parallele Arbeitsabläufe sind ein Bereich, mit dem ich täglich sowohl beruflich als auch privat zu tun habe.
Verwandter Artikel: Einführung in Vibe Coding: 6 Schritte für Nicht-Programmierer, um mit Claude Apps zu bauen. Die Ära der Inhouse-Produktion am Wochenende
https://note.com/nobel/n/n8192ec07d689
1. Warum „Alles in eine Sitzung stopfen" scheitert
Die erste Falle besteht darin, eine einzelne Sitzung mit zu vielen Informationen zu überlasten. Egal wie intelligent das Claude-Modell ist, es stößt an strukturelle Grenzen.
Konkret treten diese drei Probleme auf:
- Kontext-Kontamination: Wenn Implementierungscode, Tests, Debug-Verlauf und Design-Diskussionen im selben Kontext vermischt werden, wird die Argumentationsgrundlage unsauber und die Genauigkeit sinkt.
- Anweisungskonflikte: Wenn „schnell implementieren" und „strenge Sicherheitsanforderungen" im selben Raum existieren, werden Entscheidungen halbherzig.
- Token-Aufblähung: Jedes Mal eine riesige Historie zu laden, ist Zeit- und Kostenverschwendung.
Die Lösung ist die Idee, „ein einziger Befehlshaber zu werden und spezialisierte Claudes aufzustellen". Es ist ähnlich wie ein CTO, der einen Tech Lead und einen Backend Lead hat, aber das Wichtige ist nicht das Bauchgefühl – es ist die korrekte Nutzung der offiziellen Claude-Code-Mechanismen.
Eine Maßnahme, die Sie heute umsetzen können: Denken Sie über Ihre aktuelle Sitzung nach und prüfen Sie, ob „Implementierung", „Recherche" und „Review" in einem Kontext koexistieren. Wenn ja, ist das Ihr Ausgangspunkt für die Aufteilung.
2. Korrektur der offiziell bereitgestellten „drei parallelen Mechanismen"
Das ist der Kern des Artikels. Claude Code hat drei Mechanismen für Parallelität, jeder mit einem unterschiedlichen Geltungsbereich.
Der erste ist Subagent (ein Hilfs-KI, der in einem vom Hauptgespräch getrennten Kontext läuft). Er führt Nebenaufgaben wie Recherche oder Reviews in einem eigenen Kontextfenster, mit einem eigenen System-Prompt und eingeschränkten Tool-Berechtigungen aus und gibt nur eine Zusammenfassung der Ergebnisse an die Hauptsitzung zurück. Der entscheidende Punkt ist, dass Subagenten innerhalb derselben Sitzung laufen, nur an die Hauptsitzung berichten und Subagenten nicht miteinander kommunizieren (Offizielle Docs).
Der zweite ist Agent Teams (ein Mechanismus, bei dem mehrere Claude-Code-Sitzungen als Team zusammenarbeiten). Eine Sitzung wird zum Teamleiter und erzeugt Teammitglieder, die über eine gemeinsame Aufgabenliste und ein gemeinsames Postfach zusammenarbeiten. Im Gegensatz zu Subagenten können Teammitglieder direkt Nachrichten aneinander senden. Dies ist eine experimentelle Funktion und standardmäßig deaktiviert. Sie müssen CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 setzen und Claude Code v2.1.32 oder höher verwenden (Offizielle Docs).
Der dritte ist Git Worktree (eine Git-Funktion, die mehrere Arbeitsverzeichnisse aus demselben Repository ermöglicht). Wenn Sie mit claude --worktree feature-auth starten, wird Claude in einer isolierten Umgebung auf einem anderen Branch/Verzeichnis gestartet. Wenn Sie ein weiteres in einem anderen Terminal ausführen, können sie parallel laufen, ohne sich gegenseitig in die Dateien zu geraten (Offizielle Docs). Bei Verwendung der Desktop-App wird für jede neue Sitzung automatisch ein Worktree erstellt.
Hier ist eine Tabelle zum Vergleich der drei:
Sie werden nicht durcheinanderkommen, wenn Sie sich merken, dass Worktrees die Datei-Isolation übernehmen, während Subagenten und Agent Teams die Koordination der Arbeit selbst übernehmen.
Eine Maßnahme, die Sie heute umsetzen können: Versuchen Sie zuerst, claude --worktree bugfix-test einzugeben, um ein Gefühl für das Starten einer isolierten Sitzung zu bekommen. Wenn Sie nach Änderungen fertig sind, werden Sie gefragt, ob der Worktree erhalten oder gelöscht werden soll.
3. Praxis: 8 Sitzungen in einer „3-Ebenen-Struktur" einsetzen
Wie übersetzen sich diese drei Mechanismen in 8 Sitzungen? Ich verwende ein Layout, das in Befehls-, Ausführungs- und Qualitätsebene unterteilt ist.
Befehls-/Design-Ebene (2 Sitzungen)
- Sitzung 1 PM (Projektmanager): Übergeordnetes Fortschrittsmanagement, Aufgabenaufteilung, Berichterstattung an Menschen.
- Sitzung 2 Architekt: Entscheidet über technische Konsistenz und Verzeichnisstruktur. Erfordert Planfreigabe, um Entwürfe zu erstellen, ohne selbst Code zu schreiben.
Ausführungs-/Implementierungsebene (4 Sitzungen)
- Sitzung 3 Frontend: Komponentenerstellung, UI-Anpassungen.
- Sitzung 4 Backend: Endpunktimplementierung, Query-Optimierung.
- Sitzung 5 Infra/DevOps: Docker, CI/CD-Wartung.
- Sitzung 6 Security: Schwachstellenprüfungen, Härtung der Authentifizierung.
Qualitäts-/Wartungsebene (2 Sitzungen)
- Sitzung 7 QA/Reviewer: PR-Reviews, Aufzeigen von Randfällen.
- Sitzung 8 Technical Writer: README, API-Dokumentationspflege.
Es gibt drei Tipps für dieses Layout: Isolieren Sie die vier Implementierungsebenensitzungen mit Worktrees, damit sie sich nicht gegenseitig in die Dateien geraten. Fixieren Sie die Rollen für die Qualitätsebene als Subagent-Definitionen oder Agent-Team-Mitglieder. Und lassen Sie jede Sitzung Informationen über gemeinsame Markdown-Dateien (Design-Notizen oder Review-Ergebnisse) weiterleiten. Der Architekt aktualisiert das Design, die Implementierungsebene arbeitet darauf aufbauend, und der Reviewer schreibt Ergebnisse zurück. Menschen müssen nur Anweisungen an jede Sitzung geben, die durch diese Dateiaktualisierungen ausgelöst werden.
Ein Hinweis: Die offizielle Richtlinie für ein Agent Team ist 3–5 Personen, also stopfen Sie nicht alle 8 auf einmal in ein Team (Offizielle Docs). Es ist sicherer, Worktree-isolierte Sitzungen mit einem 3–5-Personen-Agent-Team und bei Bedarf Subagenten zu kombinieren, um insgesamt 8 Arbeiter zu erreichen.
Eine Maßnahme, die Sie heute umsetzen können: Wählen Sie zwei Rollen aus den 8 oben aus, die sich in Ihrem aktuellen Projekt leicht aufteilen lassen. In vielen Fällen sind Architekt und Reviewer die ersten Teilungspunkte.
4. Rollengrenzen mit „Subagent-Definitionen" festlegen, nicht mit „CLAUDE.md"
Lassen Sie mich ein häufiges Missverständnis über parallele Arbeitsabläufe korrigieren. Möglicherweise sehen Sie Erklärungen wie „Rollen (ID: arch, ID: dev-main...) in CLAUDE.md schreiben und beim Start die Persona wechseln", aber diesen Mechanismus gibt es eigentlich nicht.
CLAUDE.md ist eine gemeinsame Anweisungsdatei, die Claude Code beim Start liest. Die offiziellen Dokumente stellen jedoch klar, dass CLAUDE.md „Kontext, keine erzwungene Einstellung" ist. Da es als Benutzernachricht nach dem System-Prompt übergeben wird, ist die strikte Einhaltung nicht garantiert. Wenn Sie etwas absolut unterbinden wollen, sollten Sie Hooks verwenden (Offizielle Docs). Betrachten Sie es als starke Empfehlung, nicht als absolute „Verfassung".
Wo also legen Sie Rollen fest? Die Antwort sind Subagent-Definitionen. Indem Sie eine Datei unter .claude/agents/ mit Name, Beschreibung, verfügbaren Tools und Modell im Frontmatter ablegen, erstellen Sie einen wiederverwendbaren Experten. Hier ist ein minimales Beispiel:
name: security-reviewer
description: Prüft Code kritisch aus der Perspektive von Authentifizierung, Eingabevalidierung und Sitzungsmanagement.
tools: Read, Grep, Bash
model: sonnet
Sie sind ein Senior-Sicherheitsprüfer. Konzentrieren Sie sich auf Token-Handling,
Sitzungsmanagement und Eingabevalidierung und melden Sie Ergebnisse mit Schweregraden.
Darüber hinaus können diese Definitionen in Agent-Teams als Teammitglieder namentlich aufgerufen werden. Wenn Sie bitten, „ein Teammitglied mit dem Agententyp security-reviewer einzurichten, um das Auth-Modul zu prüfen", wird es ein Mitglied, das die Tools und das Modell aus dieser Definition erbt (Offizielle Docs). Das Design erlaubt es, eine Rolle einmal als Subagent-Definition zu schreiben und sowohl als Subagent als auch als Teammitglied wiederzuverwenden.
Beispiel-Prompt zum Ausprobieren (Claude eine Rollendefinition erstellen lassen):
Erstellen Sie eine Subagent-Definition, die in .claude/agents/ abgelegt werden soll.
Die Rolle ist „ein Reviewer, der auf Leistungsprobleme und N+1-Abfragen im Implementierungscode hinweist."
Nehmen Sie name / description / tools / model im Frontmatter auf,
und schreiben Sie den Body in der Persona eines Senior Engineers.
5. Aufbau eines „Architekt-Reviewer"-Teams mit Agent Teams zur Steigerung der Genauigkeit
Eine Konfiguration, die sich bei parallelen Arbeitsabläufen als sehr effektiv erweist, ist die separate Einrichtung eines „Erstellers" und eines „Zweiflers". Das ist nicht nur Theorie; die offizielle Dokumentation liefert Praxisbeispiele.
Im offiziellen Beispiel „Paralleles Code-Review" werden für einen PR drei Teammitglieder für Sicherheit, Leistung und Testabdeckung eingerichtet, die jeweils aus einer anderen Perspektive prüfen, während der Lead die Ergebnisse integriert. Darüber hinaus werden im Beispiel „Konkurrierende Hypothesen" fünf Teammitgliedern verschiedene Hypothesen für einen Fehler zugewiesen, um sich gegenseitig zu widerlegen, wobei die überlebende Theorie als Ursache behandelt wird (Offizielle Docs). Da ein einzelner Ermittler dazu neigt, in Richtung der ersten Theorie gezogen zu werden, erzeugt dieser Ansatz absichtlich Konflikte, um die Genauigkeit zu verbessern.
Sie können auch einen Betrieb implementieren, bei dem der Architekt „keine Schreibberechtigung für Code" hat, und zwar mit offiziellen Funktionen. Indem Sie eine Planfreigabe für ein Teammitglied verlangen, bleibt das Teammitglied im schreibgeschützten Planmodus und erstellt nur Entwürfe, bis der Lead sie freigibt. Freigabekriterien können im Prompt des Leads festgelegt werden, z.B. „nur Pläne freigeben, die Testabdeckung enthalten".
Beispiel-Prompt zum Ausprobieren (Konfliktstruktur auf einmal einrichten):
Erstellen Sie ein Agent Team, um PR #142 zu reviewen. Richten Sie drei Teammitglieder ein:
eines für Sicherheit, eines für Leistung und eines für Testabdeckung.
Lassen Sie sie unabhängig reviewen und Ergebnisse mit Schweregraden ausgeben, dann am Ende integrieren.
Es gibt zwei Anzeigemodi: in-process (alle Teammitglieder laufen im selben Terminal, mit Umschalt+Ab durchschalten) und split panes (jedes Teammitglied in einem eigenen Bereich; erfordert tmux oder iTerm2). Es ist einfacher, mit in-process zu beginnen, da keine zusätzliche Einrichtung erforderlich ist.
6. Speicher teilen mit offiziellem Auto Memory (Markdown), nicht mit „SQLite"
Beim Ausführen mehrerer Sitzungen ist die nächste Hürde das „Teilen des Speichers zwischen Sitzungen". Obwohl fortgeschrittene Techniken wie „getaggten Speicher in SQLite speichern und dynamisch einfügen" manchmal vorgestellt werden, ist dies keine Standardfunktion von Claude Code. Es ist möglich, wenn Sie über MCP (Model Context Protocol) eine Datenbank aufbauen, aber das sollten Sie vom offiziell bereitgestellten Speichermechanismus unterscheiden.
Der offizielle Auto Memory funktioniert mit Markdown-Dateien. Innerhalb von ~/.claude/projects/<project>/memory/ werden Dateien wie MEMORY.md (Index) und themenspezifische Dateien wie debugging.md abgelegt, und Claude schreibt während der Arbeit hinein. Die Laderregeln sind klar: Jede Sitzung liest die ersten 200 Zeilen oder 25KB von MEMORY.md, und Claude liest themenspezifische Dateien nur bei Bedarf. Dies ist ab Claude Code v2.1.59 verfügbar, wird pro Repository gespeichert (also über Worktrees hinweg geteilt), und lokal gespeichert (Offizielle Docs).
Die Schönheit dieses Designs liegt darin, dass durch „ständiges Laden des Index und Abrufen von Details nur bei Bedarf" der Kontextfenster sauber bleibt. Selbst bei Tausenden von kleinen Regeln wird der Kontext nicht jedes Mal kontaminiert, solange der Index nicht aufbläht.
Vom Ablauf her sollten Sie den offiziellen Markdown-basierten Auto Memory voll ausschöpfen, bevor Sie eine eigene SQLite-Lösung bauen.
Eine Maßnahme, die Sie heute umsetzen können: Die Eingabe von /memory während einer Sitzung zeigt die Liste der aktuell geladenen CLAUDE.md- und Auto-Memory-Dateien an. Werfen Sie zuerst einen Blick darauf, wo und wie viele Erinnerungen Sie haben.
7. Drei Fallstricke bei parallelen Arbeitsabläufen (Kosten, Datenbank, Berechtigungen)
Nachdem Sie den Mechanismus verstanden haben, hier drei Vorsichtspunkte für den Betrieb.
Erstens die Token-Kosten. Die offiziellen Dokumente geben an, dass jedes Teammitglied in einem Agent Team einen unabhängigen Kontext hat, wodurch die Token-Nutzung proportional zur Anzahl der Personen steigt. Wenn Sie 5 Personen für Routineaufgaben einsetzen, führt das zu einem Kostenverlust. Aus diesem Grund lautet die offizielle Empfehlung 3–5 Personen, mit dem Hinweis, dass „drei fokussierte Mitglieder oft besser sind als fünf abgelenkte" (Offizielle Docs).
Zweitens der Isolationsbereich von Worktrees. Ein Worktree ist nur ein Git-Mechanismus zur Dateitrennung; Datenbanken, Umgebungsvariablen und laufende Dienste werden weiterhin gemeinsam genutzt. Wenn zwei Sitzungen Migrationen auf derselben lokalen Datenbank ausführen, führt das zu Problemen. Die offiziellen Dokumente warnen: „Denken Sie daran, die Entwicklungsumgebung (Abhängigkeiten installieren, virtuelle Umgebungen einrichten) in jedem Worktree zu initialieren", und wenn Aufgaben die Datenbank betreffen, müssen Sie Schemata, Docker-Container oder .env-Dateien trennen (Offizielle Docs).
Drittens die Berechtigungen. Teammitglieder erben die Berechtigungseinstellungen des Leads beim Erzeugen. Wenn Sie den Lead mit --dangerously-skip-permissions ausführen, befinden sich alle Teammitglieder ebenfalls in diesem unbestätigten Zustand. Da die Auswirkungen eines Unfalls parallel verlaufen, ist es sicherer, die Berechtigungen auf der Lead-Seite einzuschränken.
8. FAQ für fortgeschrittene Benutzer: Mitarbeiterzahl, Erweiterung und Qualitätstore
Abschließend einige ergänzende Antworten auf häufige Fragen.
F. Wie viele Sitzungen sind realistisch?
Eine gute Richtlinie ist die bereits erwähnte 3-Ebenen-, 8-Sitzungs-Struktur. Der Schlüssel liegt nicht darin, 8 Personen in ein Agent Team zu stopfen, sondern ein 3–5-Personen-Team als Kern zu verwenden und Worktree-Sitzungen oder Subagenten hinzuzufügen. Dies entspricht den offiziellen Empfehlungen (3–5 Personen pro Team, 5–6 Aufgaben pro Teammitglied). Die ultimative Grenze ist der Bereich, den Sie überwachen und steuern können. Wenn Sie die Anzahl über das hinaus erhöhen, was Sie befehligen können, lässt die Effizienz nach.
F. Was mache ich, wenn ich über Subagenten und Agent Teams hinauswachse?
Wenn Sie viele unabhängige Sitzungen von einem Ort aus überwachen möchten, erwähnt die offizielle Subagenten-Seite einen Mechanismus namens Background Agents. Denken Sie in Schichten: Subagenten für Hilfe innerhalb einer Sitzung, Agent Teams für ein gesprächsbasiertes paralleles Team und Background Agents für die Verwaltung vieler unabhängiger Sitzungen.
F. Wie kann ich die Qualität garantieren?
Empfehlungen in CLAUDE.md sind nur „leicht zu befolgende Anweisungen". Für Prüfungen, die Sie unbedingt ausführen möchten, erzwingen Sie diese mit Hooks. Agent Teams haben Hooks wie TeammateIdle, TaskCreated und TaskCompleted; die Rückgabe von Exit-Code 2 sendet Feedback und zwingt die Arbeit zur Fortsetzung (Offizielle Docs). Das bedeutet, Sie können programmatisch Regeln durchsetzen wie „erst abschließen, wenn die Tests grün sind".
Zusammenfassung: Vom Überwacher zum Designer/Delegator
Der Wert von Claude Code liegt mehr in der Fähigkeit einer Person, mehrere spezialisierte Claudes zu kontrollieren, als nur darin, Code schneller zu schreiben. Hier sind die Kernpunkte:
Verwechseln Sie die drei Mechanismen nicht: Subagenten geben Ergebnisse zurück, Agent Teams sind gesprächsbasierte Teams, Worktrees isolieren Dateien. Teilen Sie 8 Sitzungen in Befehls-, Implementierungs- und Qualitätsebene auf; isolieren Sie die Implementierung mit Worktrees und fixieren Sie die Qualitätsrollen mit Subagent-Definitionen oder Agent Teams. Legen Sie Rollengrenzen in Subagent-Definitionen fest, nicht in CLAUDE.md, und erzwingen Sie absolute Regeln mit Hooks. Organisieren Sie den offiziellen Markdown-basierten Auto Memory, bevor Sie eine eigene SQLite-Lösung bauen. Streben Sie 3–5 Personen pro Team an und bauen Sie durch Hinzufügen von Schichten bis zu 8 Arbeiter auf.
3 Schritte zum sofortigen Ausprobieren ab heute:
- [ ] Geben Sie
claude --worktree test-1ein, um ein Gefühl für das Starten einer isolierten Sitzung zu bekommen. - [ ] Schreiben Sie eine Subagent-Definition für eine „Reviewer"-Rolle in
.claude/agents/und lassen Sie sie Ihre Implementierung reviewen. - [ ] Setzen Sie
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1und versuchen Sie, ein PR-Review parallel mit drei Teammitgliedern auszuführen.
Die Zeit, die Sie damit verbracht haben, in einer einzigen Sitzung ständig Korrekturanweisungen einzugeben, wird sich in Zeit verwandeln, die Sie mit dem Entwerfen und Delegieren von Rollen verbringen. Zu entscheiden, was Sie loslassen und was Sie überwachen, ist die menschlichste Aufgabe, die bei parallelen Arbeitsabläufen übrig bleibt.
Referenzlinks (Offizielle Primärquellen)
- Erstellen Sie benutzerdefinierte Subagenten
- Orchestrieren Sie Teams von Claude Code-Sitzungen
- Führen Sie parallele Sitzungen mit Worktrees aus
- Wie Claude sich an Ihr Projekt erinnert / CLAUDE.md und Auto Memory
Ich plane, nützliche Informationen, die ich nicht auf X posten kann, in diesem Open Chat zu teilen. Wenn Sie interessiert sind, treten Sie jetzt bei.
