Fan-out agentów i git worktrees: równoległe edycje bez kolizji

Wzorzec: jeden rodzic, wiele dzieci z prawem zapisu

Muse Code opiera się na prostej zasadzie: gdy zadanie rozpada się na kilka odrębnych podzadań, praca automatycznie rozchodzi się na osobne agenty. Agent-rodzic uruchamia po jednym dziecku z prawem zapisu na każde podzadanie. Niczego tu nie konfigurujesz i nie włączasz żadnego specjalnego trybu równoległego — dekompozycja i rozdzielanie pracy to zachowanie domyślne, o ile tylko robota jest na tyle duża, że się to opłaca.

Od razu nasuwa się oczywiste pytanie: skoro kilka agentów może jednocześnie pisać kod w tym samym repozytorium, dlaczego wszystko nie kończy się konfliktami przy merge i nadpisanymi plikami?

Prawdziwa sesja z fan-outem: sześć zadań w jednej grze, cztery po merge, dwa wciąż w toku — każde w swoim worktree pod .muse/worktrees/, a główny checkout nietknięty.

Worktrees: izolacja po gitowemu

Każdy agent-dziecko dostaje własny git worktree — osobny checkout repozytorium, który dzieli historię z twoją główną kopią, ale ma własny katalog roboczy i własną gałąź. Dwa dzieci mogą edytować ten sam plik w swoich worktree i nigdy nie zobaczą nawzajem swoich zmian w trakcie pracy. Strukturalnie kolizja po prostu nie ma jak zajść.

Równie ważne: twoja kopia robocza pozostaje czysta. Katalog, który masz otwarty w edytorze, nigdy nie jest tym, w którym grzebie agent. Nic nie przesuwa się pod kursorem, żadna niedokończona edycja agenta nie ląduje w twoim diffie, a porzucenie pracy agenta kosztuje tyle, co wyrzucenie jego worktree. Zmiany trafiają na twoją gałąź dopiero wtedy, gdy praca jest skończona i przejrzana.

Czemu nie zwykłe gałęzie? Albo kontenery?

Zwykłe gałęzie dzielą jeden katalog roboczy — przełączenie gałęzi w trakcie zadania wyrwałoby dywan spod nóg działającemu agentowi. Pełne kontenery albo klony repozytorium by zadziałały, ale to ciężka artyleria: zduplikowane magazyny obiektów, wolny setup, niewygodne merge’owanie. Worktrees trafiają w sam środek. Tworzą się niemal natychmiast, współdzielą bazę obiektów gita, a wmerge’owanie skończonej gałęzi dziecka z powrotem to zwyczajny git — bez własnej warstwy synchronizacji, której trzeba ufać, bez zamkniętego stanu, który trzeba debugować.

Sześć feature’ów naraz, na dowód

Dema z premiery mocno opierały się na tym mechanizmie: w przykładzie z tworzeniem gry Muse Code budował sześć funkcji gry jednocześnie, każdy agent w swoim worktree, i każda gałąź zmerge’owała się czysto. To jest ta praktyczna wygrana — czas zegarowy sprintu z wieloma feature’ami spada do długości najdłuższego pojedynczego zadania, zamiast być sumą wszystkich.

Wypróbuj przepis

Fan-out agentów to jeden z trzech wzorców, do których Meta dostarcza gotowe przepisy w cookbooku — rozbij jedno duże zadanie na subagentów tak, żeby nic nie kolidowało w locie. W cookbooku znajdziesz wersję do uruchomienia. A ponieważ pracę rozdzieloną fan-outem prędzej czy później zechcesz zaudytować, każde uruchomienie dziecka, każde wywołanie narzędzia i każdy merge trafiają do dziennika zdarzeń — nic nie dzieje się poza rejestrem tylko dlatego, że działo się równolegle.