Ga naar inhoud

Agenten parallel uitvoeren

Deze gids laat zien hoe je meerdere agenten tegelijk laat draaien zonder dat ze elkaars werk overschrijven.

De eenheid van isolatie is de ruimte, niet de agent

Sectie getiteld “De eenheid van isolatie is de ruimte, niet de agent”

Wanneer er werk in een ruimte start, provisioneert Control Center één copy-on-write-checkout per geregistreerde repo onder de eigen root van die ruimte, op een branch die is afgeleid van het branch-sjabloon van de werkruimte. Elke agent in de ruimte krijgt vervolgens zijn eigen overlay-werkmap — maar de overlays delen de map repos/ van die ruimte.

Dus:

  • Twee agenten in verschillende ruimtes werken in verschillende checkouts, op verschillende branches. Dat is echte isolatie.
  • Twee agenten in dezelfde ruimte werken in dezelfde checkout, op dezelfde branch. Hun overlaypaden verschillen, dus de dispatchpad-vergrendeling (die runs alleen serialiseert wanneer ze dezelfde werkmap aanvragen) serialiseert hen evenmin. Ze kunnen op hetzelfde moment dezelfde bestanden schrijven.

De regel die daaruit volgt: één ruimte per parallelle taak.

  1. Open een ruimte met agent A en stuur er een taak naartoe.
  2. Open een tweede ruimte met agent B en stuur er een andere taak naartoe.
  3. Beide starten meteen, elk in de checkout van zijn eigen ruimte op zijn eigen branch.

Dit is het recept om te gebruiken wanneer de agenten bestanden gaan bewerken.

Samenwerken in één ruimte — meerdere vermeldingen

Sectie getiteld “Samenwerken in één ruimte — meerdere vermeldingen”

Vermeld in één ruimte meer dan één agent met @:

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

Beide agenten starten parallel en streamen naar dezelfde ruimte, met de afzender erbij gemarkeerd. Omdat ze de checkout van de ruimte delen, gebruik je dit voor samenwerking — de één schrijft, de ander leest, of twee agenten redeneren over dezelfde tree — niet voor twee onafhankelijke bewerkingen.

Het ingebouwde pr_review-sjabloon is het meegeleverde voorbeeld van een fan-out: meerdere reviewernodes draaien gelijktijdig vanuit één trigger en een node Consolidate (join) vouwt hun bevindingen samen tot één rapport. Draai het vanaf het pipelinescherm en elke reviewer start parallel.

De pipeline-editor verbergt de terminale sentinel en verbindt hem opnieuw zodat hij op elke actieve sink wacht wanneer je een stap toevoegt of verbindt, dus takken die je zelf tekent draaien wel.

Observeerbaarheid → Live (voettekst van de zijbalk → Observeerbaarheid, dan het tabblad Live) toont de agentenlijst van deze werkruimte, die elke seconde opnieuw bijwerkt: status (actief / inactief / geparkeerd / afgebroken), wat elke agent doet, tokens en kosten van zijn laatste run en een stopknop voor een draaiend proces. Als je een rij selecteert, wordt er een lade met het live transcript vastgezet.

Instellingen → Werkruimte → Agenten toont dezelfde lijst met een andere statusvocabulaire die op aandacht is gericht en is afgeleid van de rungeschiedenis van elke agent — actief, geblokkeerd, mislukt, inactief, nog geen uitvoeringen — gesorteerd zodat alles wat aandacht nodig heeft bovenaan komt. Het tabblad Logboeken van elke agent bevat zijn eigen rungeschiedenis.

Beide oppervlakken zijn beperkt tot de actieve werkruimte.

Tussen ruimtes staat elke ruimte op zijn eigen branch, dus een botsing komt naar boven als een gewoon Git-mergeconflict wanneer je de tweede pull request merget. Los het op zoals je elk mergeconflict zou oplossen.

Binnen één ruimte is er geen branchgrens en geen vergrendeling: de agenten schrijven live naar dezelfde bestanden en de verliezer wordt gewoon overschreven. Wil je twee agenten in één ruimte laten bewerken, splits het werk dan in plaats daarvan in twee ruimtes.

Om botsingen te beperken, in beide gevallen:

  • Geef elke agent een eigen scope — andere bestanden, andere modules.
  • Gebruik de codegraph om te controleren wat een wijziging raakt voordat je hem dispatcht. Zie Code zoeken met de codegraph.
  • Review en merge de pull request van elke agent snel.

Elke draaiende agent kost:

  • Een checkout van de ruimte — verwaarloosbaar op schijf zolang copy-on-write beschikbaar is; op Windows een git worktree. Een bestandssysteem dat niet kan reflinken laat de provisioning mislukken in plaats van te kopiëren.
  • Een proces op de serverhost
  • Modeltokens, die per agent oplopen

Kosten komen terecht in Observeerbaarheid → Overzicht. Let op: een normale interactieve beurt heeft geen bestedingsplafond; zie Kosten beheren voor de twee commando’s die er wel een hebben.