Przejdź do głównej zawartości

Uruchamiaj agentów równolegle

Ten poradnik pokazuje, jak uruchomić kilku agentów jednocześnie, aby nie nadpisywali nawzajem swojej pracy.

Gdy w przestrzeni rozpoczyna się praca, Control Center przygotowuje jedną kopię roboczą copy-on-write na każde zarejestrowane repozytorium, w katalogu głównym samej przestrzeni, na gałęzi wywiedzionej z szablonu nazwy gałęzi obszaru roboczego. Każdy agent w przestrzeni dostaje następnie własny nakładkowy katalog roboczy — ale nakładki współdzielą katalog repos/ tej przestrzeni.

A zatem:

  • Dwaj agenci w różnych przestrzeniach pracują w różnych kopiach roboczych, na różnych gałęziach. To prawdziwa izolacja.
  • Dwaj agenci w tej samej przestrzeni pracują w tej samej kopii roboczej, na tej samej gałęzi. Ich ścieżki nakładek się różnią, więc blokada ścieżki wysyłania (która szereguje uruchomienia tylko wtedy, gdy żądają identycznego katalogu roboczego) też ich nie szereguje. Mogą zapisywać te same pliki w tym samym czasie.

Wniosek z tego jest taki: jedna przestrzeń na równoległe zadanie.

Uruchamiaj zadania równolegle — osobne przestrzenie

Dział zatytułowany „Uruchamiaj zadania równolegle — osobne przestrzenie”
  1. Otwórz przestrzeń z agentem A i wyślij mu zadanie.
  2. Otwórz drugą przestrzeń z agentem B i wyślij mu inne zadanie.
  3. Obaj zostają wysłani natychmiast, każdy we własnej kopii roboczej przestrzeni, na własnej gałęzi.

Po ten przepis sięgaj zawsze wtedy, gdy agenci będą edytować pliki.

W jednej przestrzeni oznacz przez @ więcej niż jednego agenta:

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

Obaj agenci zostają wysłani równolegle i strumieniują do tej samej przestrzeni, z oznaczeniem nadawcy. Ponieważ współdzielą kopię roboczą przestrzeni, używaj tego do współpracy — jeden pisze, drugi czyta albo dwaj agenci rozumują o tym samym drzewie — a nie do dwóch niezależnych edycji.

Wbudowany szablon pr_review to dostarczany przykład rozgałęzienia: kilka węzłów recenzentów uruchamia się współbieżnie z jednego wyzwalacza, a węzeł Consolidate (join) składa ich ustalenia w jeden raport. Uruchom go z ekranu potoków, a każdy recenzent zostanie wysłany równolegle.

Edytor potoków ukrywa wartownika końcowego i przepina go tak, aby czekał na każde aktywne ujście, gdy dodasz lub połączysz krok — dzięki temu narysowane przez Ciebie gałęzie faktycznie się uruchamiają.

Obserwowalność → Na żywo (stopka paska bocznego → Obserwowalność, a następnie karta Na żywo) pokazuje listę agentów tego obszaru roboczego, odświeżaną co sekundę: status (W trakcie / Bezczynny / Zaparkowany / Przerwany), co robi każdy z nich, tokeny i koszt jego ostatniego uruchomienia oraz kontrolkę zatrzymania działającego procesu. Wybranie wiersza przypina panel transkryptu na żywo.

Ustawienia → Obszar roboczy → Agenci pokazuje tę samą listę, ale z innym zestawem statusów, nastawionym na to, co wymaga uwagi, wywiedzionym z historii uruchomień każdego agenta — Działa, Zablokowany, Niepowodzenie, Bezczynny, Brak uruchomień — posortowaną tak, aby wszystko, co wymaga uwagi, trafiało na górę. Karta Logi każdego agenta zawiera jego własną historię uruchomień.

Oba widoki są ograniczone do aktywnego obszaru roboczego.

W przypadku różnych przestrzeni każda z nich jest na własnej gałęzi, więc kolizja ujawnia się jako zwykły konflikt scalania Git przy scalaniu drugiego pull requesta. Rozwiąż go tak, jak każdy inny konflikt scalania.

W obrębie jednej przestrzeni nie ma granicy gałęzi ani blokady: agenci zapisują te same pliki na żywo, a przegrany jest po prostu nadpisywany. Jeśli zdarzy Ci się chcieć, aby dwaj agenci edytowali w jednej przestrzeni, rozbij pracę na dwie przestrzenie.

Aby zmniejszyć liczbę kolizji w obu przypadkach:

  • Daj każdemu agentowi odrębny zakres — inne pliki, inne moduły.
  • Przed wysłaniem sprawdź w grafie kodu, czego dotyczy zmiana. Zobacz Szukaj kodu w grafie kodu.
  • Niezwłocznie recenzuj i scalaj pull request każdego agenta.

Każdy działający agent kosztuje:

  • Kopię roboczą przestrzeni — znikomą na dysku, dopóki dostępny jest copy-on-write; w Windows git worktree. System plików, który nie potrafi reflink, kończy przygotowanie niepowodzeniem, zamiast kopiować.
  • Proces na hoście serwera
  • Tokeny modelu, które narastają z każdym agentem

Koszty trafiają do Obserwowalność → Analizy. Zauważ, że zwykła interaktywna tura nie ma limitu wydatków; dwa polecenia, które go mają, opisano w Zarządzaj kosztami.