Was macht Team-Agent-Orchestrierung?
Verwende diese Fähigkeit, wenn Agenten eher wie ein Team als wie ein einzelner Assistent verwaltet werden. Ziel ist es, team-basierte Orchestrierung zuverlässig zu gestalten: klare Arbeitspakete, explizite Verantwortlichkeiten, Agenten-Kanban-Zustand, Branch-Isolation, Steuerpaneel-Sichtbarkeit und Merge-Gates.
Wann aktivieren
- Die Aufgabe umfasst mehrere Agenten, Tools, Harnesses, Branches oder Worktrees.
- Der Benutzer erwähnt Team-Orchestrierung, Agenten-Kanban, Squad, Conductor, Steuerpaneel, Manager, Desktop-App, Zellij, tmux, Hermes, Devin, Codex, Claude Code oder Multi-Agent-Arbeit.
- Ein Projekt benötigt einen gemeinsamen Workflow-Status über Personen und Agenten hinweg.
- Bestehende Agenten-Fan-Outs produzieren Output, aber kein mergebares Produkt.
Betriebsmodell
Behandle jeden Agenten als Teammitglied mit einem engen Vertrag:
- Besitzer (Owner): die Person oder der Agent, der für das Arbeitspaket verantwortlich ist.
- Umfang (Scope): Dateien, Branch, Tool-Oberfläche und verbotene Bereiche.
- Status (State): Backlog, Ready, Running, Review, Blocked, Merged oder Archived.
- Nachweise (Evidence): Tests, Screenshots, Logs, Review-Notizen oder Eval-Berichte.
- Merge-Gate: die genaue Bedingung, die eine Integration erlaubt.
Agenten-Kanban
Verwende Agenten-Kanban, wenn Arbeit über Sitzungen hinweg sichtbar sein muss.
| Spalte | Bedeutung | Austrittskriterien |
|---|---|---|
| Backlog | Kandidat für Arbeitspaket, noch nicht ausgearbeitet | Abnahmekriterien festgelegt |
| Ready | Ausgearbeitet und zuweisbar | Besitzer und Branch/Worktree zugewiesen |
| Running | Agent arbeitet aktiv | Übergabe-Artefakt und geänderte Dateien vorhanden |
| Review | Arbeit abgeschlossen, aber nicht gemergt | Tests, Diff-Review und Risikoprüfung bestanden |
| Blocked | Benötigt externen Input oder Gate fehlgeschlagen | Blocker hat Besitzer und nächste Aktion |
| Merged | In Hauptlinie integriert | PR gemergt oder lokaler Hauptzweig aktualisiert |
| Archived | Nicht mehr relevant | Grund notiert |
Jede Karte sollte diesem Schema folgen:
{
"id": "agent-card-001",
"title": "Dynamischen Workflow-Skill erstellen",
"owner": "codex",
"state": "running",
"branch": "product/dynamic-workflow-team-orchestration",
"worktree": ".",
"acceptance": [
"Skill existiert",
"Tests decken erforderliche Konzepte ab",
"Content-Artefakt enthält Video- und Artikelansätze"
],
"merge_gate": "Lint, fokussierte Tests und Katalog-Check bestehen",
"handoff": "path/to/handoff.md"
}
Team-basierter Orchestrierungsablauf
- Board formen: vage Ambitionen in Arbeitspakete mit Besitzern und Merge-Gates umwandeln.
- Ausführungsmodus wählen: Einzelagent, dynamischer Workflow-Modus, dmux/tmux, Worktree-Fan-Out oder externer Desktop-Orchestrator.
- Grenzen zuweisen: ein Besitzer pro Karte, klarer Dateiumfang, keine überschreibenden Schreibzugriffe ohne Integrator.
- Agenten ausführen: jeder Agent schreibt Nachweise und Übergabenotizen, nicht nur Code.
- Sequentiell reviewen: zuerst Tests, dann Diff-Review, dann Sicherheits-/Risikoprüfungen, dann Content-/Produkt-Polish.
- Bewusst mergen: ein Integrator löst Konflikte und aktualisiert das Steuerpaneel oder das Status-Artefakt.
- Wiederverwendbaren Skill extrahieren: wenn sich das Kartenmuster wiederholt, in
skills/fördern.
Steuerpaneel-Anforderungen
Ein nützliches Steuerpaneel für Team-Orchestrierung sollte anzeigen:
- Aktive Arbeitspakete und ihren Agenten-Kanban-Status.
- Besitzer, Harness, Branch, Worktree und letzten Heartbeat.
- Links zu Übergabe-Artefakten, Tests, Screenshots und PRs.
- Blockaden, gruppiert nach Besitzer und Aktion zur Entblockung.
- Merge-Bereitschaft nach Gate, nicht nach Bauchgefühl.
- Kandidaten für wiederverwendbare Workflows, die zu gemeinsamen Skills werden sollten.
Füge keine Automatisierung hinzu, bis der Operator beantworten kann: wer besitzt dies, was wurde geändert, welches Gate ist fehlgeschlagen, und was kann sicher gemergt werden?
Kompatibilität mit dynamischem Workflow
Wenn eine Karte den dynamischen Workflow-Modus benötigt:
- Lege den aufgabenspezifischen Harness unter den Kartenbesitzer.
- Speichere Eingaben und Ausgaben auf der Karte.
- Fordere ein Eval an, bevor du von Running zu Review wechselst.
- Fördere den Harness erst nach wiederholter Nutzung zu einem gemeinsamen Skill.
Zu beachtende Fehlermodi
- Agentensuppe: viele Agenten laufen, kein Besitzer oder Merge-Gate.
- Unsichtbare Arbeit: nützlicher Output existiert nur in einem Chat-Transkript.
- Board-Theater: ein Kanban-Board existiert, aber Karten haben keine Abnahmekriterien.
- Überschreibende Schreibzugriffe: parallele Agenten bearbeiten dieselben Dateien ohne Worktrees.
- Kein Produkt-Artefakt: der Prozess produziert Dokumente, aber keine ausführbare oder veröffentlichbare Oberfläche.
Output-Standard
Beende jeden Orchestrierungsdurchlauf mit:
- Board/Karten-Änderungen.
- Gemergte oder ausstehende Branches.
- Tests und Eval-Nachweise.
- Blockaden mit Besitzer und nächster Aktion.
- Neue Kandidaten für gemeinsame Skills.