Inhaltsverzeichnis
- Übersicht
- Wann verwenden
- Voraussetzungen
- Protokollarchitektur
- Schnellstart
- Koordinationsworkflow
- Modulreferenz
- Integration mit Conjure
- Fehlerbehebung
- Exit-Kriterien
Koordination von Agententeams
Übersicht
Claude Code Agent Teams ermöglicht mehreren Claude-CLI-Prozessen die Zusammenarbeit an gemeinsamen Aufgaben über ein dateisystembasiertes Koordinationsprotokoll. Jedes Teammitglied läuft als unabhängiger claude-Prozess in einem tmux-Panel und kommuniziert über JSON-Dateien, die durch fcntl-Sperren geschützt sind. Keine Datenbank, kein Daemon, keine Netzwerkschicht.
Diese Fähigkeit bietet die Muster zur effektiven Orchestrierung von Agententeams.
Wann verwenden
- Parallele Implementierung über mehrere Dateien oder Module hinweg
- Multi-Agenten-Codeüberprüfung (ein Agent prüft, ein anderer implementiert Korrekturen)
- Großes Refactoring, das koordinierte Änderungen in Subsystemen erfordert
- Aufgaben mit natürlicher Parallelität, die von gleichzeitigen Agenten profitieren
Wann NICHT verwenden
- Einzeldateiänderungen oder kleine Aufgaben (Overhead übersteigt Nutzen)
- Aufgaben, die eine enge sequenzielle Argumentation erfordern (Agenten koordinieren lose)
- Wenn die
claude-CLI nicht verfügbar oder tmux nicht installiert ist
Voraussetzungen
# Claude Code CLI überprüfen
claude --version
# tmux überprüfen (für Split-Panel-Modus erforderlich)
tmux -V
# Experimentelle Funktion aktivieren (wird automatisch vom Spawner gesetzt)
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Protokollarchitektur
~/.claude/
teams/<team-name>/
config.json # Team-Metadaten + Mitgliederliste
inboxes/
<agent-name>.json # Nachrichtenwarteschlange pro Agent
.lock # fcntl exklusive Sperre
tasks/<team-name>/
1.json ... N.json # Auto-inkrementierende Aufgabendateien
.lock # fcntl exklusive Sperre
Entwurfsprinzipien:
- Dateisystem ist die Datenbank: JSON-Dateien, atomare Schreibvorgänge via
tempfile+os.replace - fcntl-Sperren: Verhindert gleichzeitige Lese-/Schreibkorruption in Inboxen und Aufgaben
- Nummerierte Aufgaben: Auto-inkrementierende IDs mit sequenzieller Dateibenennung
- Lose Kopplung: Agenten pollten ihre eigene Inbox; keine Push-Benachrichtigungen
Schnellstart
1. Ein Team erstellen
# Programmatische Team-Einrichtung (über MCP oder direkte API)
# Team-Konfiguration wird nach ~/.claude/teams/<team-name>/config.json geschrieben
Die Teamkonfiguration enthält:
name,description,created_at(ms-Zeitstempel)lead_agent_id,lead_session_idmembers[]— Array von LeadMember- und TeammateMember-Objekten
2. Teammitglieder spawnen
Jedes Teammitglied ist ein separater claude-CLI-Prozess, der mit Identitätsflags gestartet wird:
claude --agent-id "backend@my-team" \
--agent-name "backend" \
--team-name "my-team" \
--agent-color "#FF6B6B" \
--parent-session-id "$SESSION_ID" \
--agent-type "general-purpose" \
--model sonnet
Siehe modules/spawning-patterns.md für tmux-Panel-Verwaltung und Farbzuweisung.
3. Aufgaben mit Abhängigkeiten erstellen
{
"id": "1",
"subject": "API-Endpunkte implementieren",
"description": "REST-Endpunkte für die Benutzerverwaltung erstellen",
"status": "pending",
"owner": null,
"blocks": ["3"],
"blocked_by": [],
"metadata": {}
}
Siehe modules/task-coordination.md für Zustandsautomaten und Abhängigkeitsverwaltung.
4. Über Nachrichten koordinieren
{
"from": "team-lead",
"text": "API-Endpunkte sind bereit für Integrationstests",
"timestamp": "2026-02-07T22:00:00Z",
"read": false,
"summary": "API bereit"
}
Siehe modules/messaging-protocol.md für Nachrichtentypen und Inbox-Operationen.
Koordinationsworkflow
agent-teams:team-created— Teamkonfiguration und Verzeichnisse initialisierenagent-teams:teammates-spawned— Agenten in tmux-Panels startenagent-teams:tasks-assigned— Aufgaben mit Abhängigkeiten erstellen, Besitzer zuweisenagent-teams:coordination-active— Agenten beanspruchen Aufgaben, tauschen Nachrichten aus, markieren Abschlussagent-teams:team-shutdown— Graceful Shutdown mit Genehmigungsprotokoll
Teammitgliedsrollen
Jedes Teammitglied hat eine role, die seine Fähigkeiten und Aufgabenkompatibilität bestimmt. Fünf Rollen sind definiert: implementer (Standard), researcher, tester, reviewer und architect. Rollen schränken ein, welche Risikostufen ein Agent handhaben kann – siehe modules/crew-roles.md für die vollständige Fähigkeitsmatrix und die Rollen-Risiko-Kompatibilitätstabelle.
Gesundheitsüberwachung
Teammitglieder können auf Gesundheit über Herzschlag-Nachrichten und Anspruchsablauf überwacht werden. Der Lead pollt alle 60s die Teamgesundheit mit einem 2-stufigen Erkennungsprotokoll für Stillstand (health_check-Sonde + 30s Wartezeit). Steckengebliebene Agenten haben ihre Aufgaben freigegeben und werden gemäß der Doktrin „ersetzen, nicht warten“ neu gestartet oder ersetzt. Siehe modules/health-monitoring.md für das vollständige Protokoll und den Zustandsautomaten.
Modulreferenz
- team-management.md: Team-Lebenszyklus, Konfigurationsformat, Mitgliederverwaltung
- messaging-protocol.md: Nachrichtentypen, Inbox-Operationen, Sperrmuster
- task-coordination.md: Aufgaben-CRUD, Zustandsautomat, Erkennung von Abhängigkeitszyklen
- spawning-patterns.md: tmux-Spawning, CLI-Flags, Panel-Verwaltung
- crew-roles.md: Rollentaxonomie, Fähigkeitsmatrix, Rollen-Risiko-Kompatibilität
- health-monitoring.md: Herzschlag-Protokoll, Erkennung von Stillstand, automatisierte Wiederherstellung
Integration mit Conjure
Agent Teams erweitert das Conjure-Delegierungsmodell:
| Conjure-Muster | Äquivalent in Agent Teams |
|---|---|
delegation-core:task-assessed | agent-teams:team-created |
delegation-core:handoff-planned | agent-teams:tasks-assigned |
delegation-core:results-integrated | agent-teams:team-shutdown |
| Externe LLM-Ausführung | Ausführung durch Teammitglied-Agenten |
Verwende zuerst Skill(conjure:delegation-core), um zu bestimmen, ob die Aufgabe von einer Multi-Agenten-Koordination profitiert oder eine Einzeldienst-Delegierung ausreicht.
Worktree-Isolationsalternative (Claude Code 2.1.49+)
Für parallele Agenten, die Dateien ändern, bietet isolation: worktree eine leichte Alternative zur dateisystembasierten Koordination. Jeder Agent läuft in seinem eigenen temporären Git-Worktree, wodurch die Notwendigkeit von fcntl-Sperren oder Inbox-basierter Konfliktvermeidung für gemeinsame Dateien entfällt.
- Wann Worktrees gegenüber Agent-Teams-Nachrichten bevorzugen: Agenten arbeiten an überlappenden Dateien, benötigen aber keine Kommunikation während der Ausführung
- Wann Agent-Teams-Nachrichten bevorzugen: Agenten müssen Entdeckungen koordinieren oder Pläne basierend auf dem Fortschritt des jeweils anderen anpassen
- Beides kombinieren: Verwende Agent Teams für die Koordination mit
isolation: worktreepro Teammitglied für Dateisystemsicherheit
Fehlerbehebung
Häufige Probleme
tmux nicht gefunden
Installation über den Paketmanager: brew install tmux / apt install tmux
Veraltete Sperrdateien
Wenn ein Agent während einer Operation abstürzt, können Sperrdateien bestehen bleiben. Entferne .lock-Dateien manuell aus ~/.claude/teams/<team>/inboxes/ oder ~/.claude/tasks/<team>/
Verwaiste Aufgaben
Aufgaben, die von einem abgestürzten Agenten beansprucht wurden, bleiben auf unbestimmte Zeit in_progress. Verwende modules/health-monitoring.md für die herzschlagbasierte Erkennung von Stillstand und die automatische Aufgabenfreigabe. Das Gesundheitsüberwachungsprotokoll erkennt nicht reagierende Agenten innerhalb von 60s + 30s Sondenfenster und gibt ihre Aufgaben zur Neuzuweisung frei.
Nachrichtenreihenfolge Die Zeitstempelauflösung des Dateisystems variiert (HFS+ = 1s Granularität). Verwende nummerierte Dateinamen oder UUID-sortierte Namen, um Kollisionen bei schnellen Nachrichtenstößen zu vermeiden.
Modellfehler auf Bedrock/Vertex/Foundry (vor 2.1.39) Teammitglied-Agenten könnten falsche Modellkennungen auf Unternehmensanbietern verwenden, was zu 400-Fehlern führt. Upgrade auf Claude Code 2.1.39+ für korrekte Modell-ID-Qualifizierung über alle Anbieter hinweg.
Schutz vor verschachtelten Sitzungen (2.1.39+)
Wenn claude sich weigert, innerhalb einer bestehenden Sitzung zu starten, stelle sicher, dass du tmux-Panel-Splitting (keinen Subshell-Aufruf) verwendest. Der Schutz ist beabsichtigt – siehe modules/spawning-patterns.md für Details.
Exit-Kriterien
- Team mit Konfiguration und Verzeichnissen erstellt
- Teammitglieder gespawnt und in der Konfiguration registriert
- Aufgaben mit Abhängigkeitsgraph (keine Zyklen) erstellt
- Agenten koordinieren über Inbox-Nachrichten
- Graceful Shutdown abgeschlossen