Zum Inhalt springen

Agenten parallel ausführen

Diese Anleitung zeigt dir, wie du mehrere Agenten gleichzeitig laufen lässt, ohne dass sie einander überschreiben.

Die Einheit der Isolation ist der Bereich, nicht der Agent

Abschnitt betitelt „Die Einheit der Isolation ist der Bereich, nicht der Agent“

Wenn Arbeit in einem Bereich startet, stellt Control Center unter der eigenen Wurzel dieses Bereichs je registriertem Repo einen Copy-on-Write-Checkout bereit, auf einem Branch, der aus der Vorlage für Branch-Namen des Arbeitsbereichs abgeleitet ist. Jeder Agent im Bereich bekommt danach ein eigenes Overlay-Arbeitsverzeichnis — die Overlays teilen sich aber das Verzeichnis repos/ dieses Bereichs.

Das heißt:

  • Zwei Agenten in verschiedenen Bereichen arbeiten in verschiedenen Checkouts, auf verschiedenen Branches. Das ist echte Isolation.
  • Zwei Agenten im selben Bereich arbeiten im selben Checkout, auf demselben Branch. Ihre Overlay-Pfade unterscheiden sich, deshalb serialisiert die Sperre auf dem Dispatch-Pfad (sie serialisiert Läufe nur, wenn sie dasselbe Arbeitsverzeichnis anfordern) sie ebenfalls nicht. Sie können dieselben Dateien gleichzeitig schreiben.

Die Regel, die daraus folgt: ein Bereich je paralleler Aufgabe.

Aufgaben parallel ausführen — getrennte Bereiche

Abschnitt betitelt „Aufgaben parallel ausführen — getrennte Bereiche“
  1. Öffne einen Bereich mit Agent A und schick ihm eine Aufgabe.
  2. Öffne einen zweiten Bereich mit Agent B und schick ihm eine andere Aufgabe.
  3. Beide werden sofort losgeschickt, jeder im eigenen Checkout seines Bereichs auf seinem eigenen Branch.

Dieses Rezept nimmst du, sobald die Agenten Dateien bearbeiten.

In einem Bereich zusammenarbeiten — mehrere Erwähnungen

Abschnitt betitelt „In einem Bereich zusammenarbeiten — mehrere Erwähnungen“

Erwähne in einem einzigen Bereich mehr als einen Agenten mit @:

@alice refactor the auth module. @bob review what alice lands.

Beide Agenten werden parallel losgeschickt und streamen in denselben Bereich, mit Absender markiert. Weil sie sich den Checkout des Bereichs teilen, nimm das für Zusammenarbeit — einer schreibt, einer liest, oder zwei Agenten denken über denselben Baum nach — nicht für zwei unabhängige Bearbeitungen.

Die eingebaute Vorlage pr_review ist das mitgelieferte Beispiel eines Fan-outs: Mehrere Reviewer-Knoten laufen gleichzeitig von einem Auslöser, und ein Knoten Consolidate (join) faltet ihre Befunde zu einem Bericht. Startest du sie vom Bildschirm Pipelines, wird jeder Reviewer parallel losgeschickt.

Der Pipeline-Editor blendet die Endmarke aus und verdrahtet sie neu, sodass sie auf jede erreichbare Senke wartet, wenn du einen Schritt hinzufügst oder verbindest. Zweige, die du selbst zeichnest, laufen deshalb wirklich.

Observability → Live (Fußzeile der Seitenleiste → Observability, dann der Tab Live) zeigt die Agentenliste dieses Arbeitsbereichs und frischt sie jede Sekunde auf: Status (Läuft / Inaktiv / Geparkt / Abgebrochen), was jeder gerade tut, Token und Kosten seines letzten Laufs und eine Steuerung zum Beenden eines laufenden Prozesses. Wählst du eine Zeile, dockt eine Schublade mit dem Live-Transkript an.

Einstellungen → Arbeitsbereich → Agenten zeigt dieselbe Liste mit einem anderen Statusvokabular aus der Laufhistorie jedes Agenten, das Aufmerksamkeit zuerst nimmt — Läuft, Blockiert, Fehlgeschlagen, Inaktiv, Noch keine Ausführungen — sortiert, sodass alles, was Aufmerksamkeit braucht, nach oben steigt. Der Tab Protokolle jedes Agenten hält seine eigene Laufhistorie.

Beide Oberflächen gelten nur für den aktiven Arbeitsbereich.

Über mehrere Bereiche hinweg liegt jeder Bereich auf seinem eigenen Branch, ein Zusammenstoß erscheint also als gewöhnlicher Git-Merge-Konflikt, wenn du den zweiten Pull Request mergst. Löse ihn so, wie du jeden Merge-Konflikt lösen würdest.

Innerhalb eines Bereichs gibt es keine Branch-Grenze und keine Sperre: Die Agenten schreiben dieselben Dateien live, und der Verlierer wird einfach überschrieben. Willst du zwei Agenten in einem Bereich bearbeiten lassen, teile die Arbeit auf zwei Bereiche auf.

Kollisionen reduzierst du in beiden Fällen so:

  • Gib jedem Agenten einen eigenen Umfang — andere Dateien, andere Module.
  • Nutze den Code-Graph, um vor dem Losschicken zu prüfen, was eine Änderung berührt. Siehe Code mit dem Code-Graph suchen.
  • Prüfe den Pull Request jedes Agenten zeitnah und merge ihn.

Jeder laufende Agent kostet:

  • Einen Checkout des Bereichs — auf der Platte vernachlässigbar, solange Copy-on-Write verfügbar ist; unter Windows ein git worktree. Ein Dateisystem ohne Reflink lässt die Bereitstellung scheitern, statt zu kopieren.
  • Einen Prozess auf dem Server-Host
  • Modell-Token, die sich je Agent aufsummieren

Die Kosten stehen unter Observability → Übersicht. Ein normaler interaktiver Zug hat keine Kostenobergrenze; die zwei Befehle, die eine haben, stehen in Kosten verwalten.