Jak bezpiecznie uruchamiać wielu agentów AI do kodowania za pomocą worktree Git i odizolowanych uprawnień

Przydziel każdemu agentowi kodującemu własną gałąź i katalog roboczy, a następnie osobno ogranicz dostęp procesu do plików, danych uwierzytelniających i sieci. Git worktrees ograniczają ryzyko przypadkowego wzajemnego zakłócania zmian, ale nie są piaskownicami bezpieczeństwa. Bezpieczny równoległy przepływ pracy wymaga zarówno przejrzystego stanu repozytorium, jak i skutecznie egzekwowanych uprawnień środowiska uruchomieniowego.

Ten poradnik przedstawia lokalne polecenia worktree, dostęp ograniczony do zakresu zadania, niezależną konfigurację testów i sekwencję integracji weryfikowaną przez człowieka. Korzystaj z repozytorium, które należy do Ciebie lub które masz prawo modyfikować, i zacznij od zadań, które można bezpiecznie porzucić. Procedura nie zależy od używanych narzędzi: interfejs agenta kodującego może zautomatyzować niektóre jej części, ale opisane granice nadal trzeba sprawdzić.

Co może pójść nie tak, gdy agenci współdzielą jeden obszar roboczy?

Dwóch agentów może nadpisać niezapisane zmiany, zmienić ten sam plik zależności lub uznać tymczasowy stan innego zadania za zamierzony projekt. Mogą też uruchamiać testy w katalogu, który zmienia się w trakcie ich wykonywania. Taką awarię może być trudno odtworzyć, ponieważ żaden agent nie testował stabilnej wersji.

Problem wykracza poza pliki źródłowe. Współdzielone porty, nazwy baz danych, pamięci podręczne, katalogi z danymi testowymi i procesy działające w tle mogą powodować zakłócenia, nawet gdy zmiany dotyczą różnych modułów. Jeden agent może zatrzymać usługę, z której korzysta inny, albo ponownie wygenerować pliki na podstawie schematu, który wciąż jest edytowany.

Nasze wyjaśnienie koordynacji wielu agentów opisuje, jak wyznaczanie granic zadań i określanie zależności ogranicza wzajemne zakłócenia. Zanim utworzysz kolejnych agentów, zapisz rezultat każdego zadania, dozwolony zakres edycji, zależności i testy akceptacyjne. „Pracujcie razem nad tą samą funkcją” to za mało, by niezależne zmiany miały jasno określone zasady.

Osobny katalog zmniejsza ryzyko przypadkowego wzajemnego zakłócania pracy; osobny kontekst bezpieczeństwa kontroluje, do czego proces ma dostęp. Traktuj te cele oddzielnie, aby nie pomylić skutecznego rozdzielenia gałęzi z ochroną prywatnych plików lub usług produkcyjnych.

Kiedy używać worktrees zamiast osobnych klonów?

Git worktrees przydają się, gdy potrzebujesz jednocześnie osobnych katalogów roboczych dla kilku gałęzi jednego repozytorium. Osobne klony mogą być lepszym wyborem, jeśli eksperyment wymaga bardziej niezależnej konfiguracji repozytorium lub innego ustawienia zdalnych repozytoriów. Żadne z tych rozwiązań samo w sobie nie ogranicza dostępu użytkownika systemu operacyjnego do poufnych danych ani innych katalogów.

Wybierz rozwiązanie odpowiednie do rzeczywistego przepływu pracy. Worktrees mogą ułatwić przegląd zmian oparty na gałęziach, a osobne klony mogą ułatwić odizolowanie niektórych destrukcyjnych eksperymentów na poziomie repozytorium. W przypadku niezaufanego kodu lub większego ryzyka związanego z jego wykonywaniem używaj odpowiednio izolowanego środowiska uruchomieniowego, niezależnie od sposobu pobrania kodu.

Tabela jest pomocą w planowaniu, a nie certyfikatem bezpieczeństwa. Przetestuj granicę, na której zamierzasz polegać, w tym pliki i usługi widoczne z poziomu rzeczywistej powłoki agenta.

Okładka: Logotyp Conductor z oficjalnego zestawu identyfikacji marki, użyty bez zmian w celach identyfikacji redakcyjnej. Znaki produktów pozostają własnością ich właścicieli; nie sugeruje się żadnego powiązania.

Jak utworzyć osobną gałąź i drzewo robocze dla każdego agenta?

Zacznij od znanej, sprawdzonej gałęzi bazowej. Zapisz istniejące zmiany przed przełączeniem gałęzi i sprawdź katalog roboczy zamiast zakładać, że jest czysty. Poniższy przykład zakłada lokalne repozytorium, którego sprawdzoną gałęzią bazową jest main; użyj właściwej gałęzi dla swojego projektu. Nie kopiuj polecenia z niewłaściwą nazwą gałęzi, a potem nie wymuszaj jego wykonania.

git status --short
git branch --show-current
git worktree list
git switch main
git worktree add -b agent/docs ../agent-docs main
git worktree add -b agent/tests ../agent-tests main
git worktree list

Przydziel każdemu agentowi ścieżkę do jego własnego drzewa roboczego i ograniczone zadanie. Zapisz bazowy commit i wyjaśnij, które współdzielone pliki wymagają koordynacji. Nie kopiuj całego osobistego środowiska programistycznego do każdego katalogu dla wygody; może to spowodować powielenie danych uwierzytelniających i niezwiązanych z zadaniem prywatnych materiałów.

Zastosuj następującą sekwencję od początku do końca:

1. Potwierdź, że stan repozytorium jest czysty lub bezpiecznie zachowany, i wybierz sprawdzoną gałąź bazową.
2. Utwórz unikalną gałąź i drzewo robocze dla każdego zadania.
3. Przekazuj tylko kontekst niezbędny do wykonania zadania oraz jasno określ kryteria jego ukończenia.
4. Skonfiguruj dedykowane dane uwierzytelniające o ograniczonym zakresie tylko wtedy, gdy wymaga tego zadanie.
5. Przydziel testom odrębne ścieżki tymczasowe, porty i stan usług przeznaczony do usunięcia.
6. Sprawdź każdy diff i wynik testów przed zaproponowaniem integracji.
7. Scalaj zmiany zgodnie z procedurami kontroli projektu i repozytorium, z udziałem człowieka.
8. Zachowaj potrzebne dowody, zwyczajnie usuwaj ukończone drzewa robocze i cofaj tymczasowy dostęp.

Te polecenia tworzą stan repozytorium; nie konfigurują piaskownicy. Jeśli narzędzie agenta ma własny menedżer obszaru roboczego, sprawdź utworzone gałęzie i ścieżki, aby te same zasady były zrozumiałe także poza interfejsem.

Jak izolować klucze, pliki środowiskowe i tokeny?

Drzewo robocze nie powinno dziedziczyć pełnego zestawu danych uwierzytelniających dewelopera. Lepiej użyć dedykowanej tożsamości z uprawnieniami tylko do repozytorium i usług niezbędnych do wykonania zadania. Przechowuj sekrety w zatwierdzonym miejscu i przekazuj je za pomocą mechanizmu obsługiwanego przez narzędzie, a nie w poleceniu, pliku zadania ani zatwierdzonym pliku .env.

Dokumentacja tokenów GitHub wyjaśnia uprawnienia tokenów i cykl ich życia. Wybierz możliwie najwęższy zakres uprawnień, odpowiedni termin ważności i sposób unieważnienia tokenu. Token potrzebny do odczytu kodu źródłowego nie oznacza uprawnień do zmiany plików przepływów pracy, scalania pull requestów ani administrowania repozytorium.

Zmienne środowiskowe to sposób przekazywania danych, a nie kompletna granica izolacji. Proces potomny może je odziedziczyć, a polecenie debugowania lub dziennik może je ujawnić. Sprawdź, które zmienne trafiają do poszczególnych procesów roboczych, i nie udostępniaj testom wartości produkcyjnych. W przypadku usług, które można symulować, używaj syntetycznych danych uwierzytelniających.

Wytyczne OWASP dotyczące zarządzania sekretami zawierają informacje o kontrolowaniu dostępu i rotacji. Jeśli agent odczyta sekret, którego nie potrzebował, potraktuj to jako problem konfiguracji, nawet jeśli nie zaobserwowano jego ujawnienia. Środowisko powinno uniemożliwiać niepotrzebny dostęp lub celowo go ograniczać, zamiast polegać na tym, że model powstrzyma się od zwrócenia na niego uwagi.

Jak kontenery lub piaskownice mogą ograniczać dostęp?

Sprawdź rzeczywistą konfigurację: tożsamość użytkownika, montowane ścieżki, zasady sieciowe, uprawnienia, gniazda i dostępne dane uwierzytelniające. Kontener z zamontowanym katalogiem domowym hosta i gniazdem silnika kontenerów może mieć dostęp daleko wykraczający poza katalog zadania. Etykieta „piaskownica” nie dowodzi, że dostęp do tych zasobów jest ograniczony.

Przegląd bezpieczeństwa Docker omawia istotne kwestie związane ze środowiskiem uruchomieniowym. Korzystaj z obsługiwanych przez platformę mechanizmów kontroli, aby ograniczać uprawnienia, montować tylko niezbędne dane i oddzielać stan usług. Sprawdź, czy proces roboczy może uzyskać dostęp do lokalizacji, które powinny być poza zakresem. Skuteczna odmowa dostępu to przydatny dowód, że kontrola działa.

Dostęp do sieci powinien odpowiadać zakresowi zadania. Zadanie może wymagać dostępu do rejestru pakietów i hosta repozytorium, ale nie dowolnych adresów zewnętrznych ani produkcyjnych baz danych. Stosuj kontrole na poziomie, na którym można je egzekwować, i dokumentuj wyjątki. Nie wyłączaj weryfikacji certyfikatów, aby umożliwić instalację zależności; rozwiąż rzeczywisty problem z zaufaniem lub łącznością.

Dokumentacja rootless Docker opisuje jedną z metod ograniczania uprawnień demona i kontenerów. Nie oznacza to, że każde obciążenie jest nieszkodliwe ani że można pominąć przegląd montowanych zasobów i sekretów. Dobierz izolację do wykonywanego kodu i wartości środowiska hosta.

Jak przeglądać i scalać zmiany?

Sprawdzaj zarówno niezatwierdzone zmiany, jak i commity. Agent może zgłosić zakończenie zadania, pozostawiając istotne pliki poza commitem lub testując katalog roboczy różniący się od proponowanej gałęzi. Poproś o wskazanie faktycznego wyniku, a następnie sprawdź go niezależnie.

git -C ../agent-docs status --short
git -C ../agent-tests status --short
git diff --stat main...agent/docs
git diff main...agent/docs
git diff --stat main...agent/tests
git diff main...agent/tests

Uruchom odpowiednie testy projektu w każdym katalogu roboczym, a następnie ponownie na zintegrowanej wersji, jeśli istotne są interakcje między zmianami. Sprawdź współdzielone interfejsy, wygenerowane pliki i aktualizacje zależności. Jeśli baza zmieni się w trakcie przeglądu, ustal, które dowody są nieaktualne. Nie podtrzymuj pozorów akceptacji po zmianie kodu, którego dotyczyła.

Dokumentacja GitHub dotycząca chronionych gałęzi opisuje mechanizmy kontroli po stronie repozytorium, które mogą uzupełnić ten proces. Oddziel ludzką akceptację istotnych zmian od możliwości agenta tworzenia propozycji. Agent weryfikujący może przedstawić dodatkową opinię, ale nie powinien być jedynym podmiotem uprawnionym do scalania.

Nasz poradnik przeglądu agentic-autofix zawiera powiązaną listę kontrolną akceptacji. W razie konfliktu najpierw ustal oczekiwane działanie. Prośba do modelu o usunięcie znaczników konfliktu bez wyjaśnienia założeń może doprowadzić do powstania czystego pliku o niewłaściwym, połączonym działaniu.

Po bezpiecznym zachowaniu i zintegrowaniu zaakceptowanej pracy wykonaj zwykłe porządki:

git worktree list
git worktree remove ../agent-docs
git worktree remove ../agent-tests
git branch -d agent/docs
git branch -d agent/tests

Nie dodawaj flag wymuszających, by ominąć odmowę. Nieczysty katalog roboczy ani gałąź, której Git nie uznaje za scaloną, wymagają sprawdzenia. Zachowaj niedokończone zmiany i poznaj historię, zanim zdecydujesz, co można usunąć.

Co monitorować podczas równoległych zadań?

Monitoruj właściciela zadania, czas działania procesu, zużycie zasobów, żądania zewnętrzne oraz kolejkę wyników oczekujących na weryfikację. Proces roboczy, który działa nadal po zakończeniu zadania, może wciąż korzystać z danych uwierzytelniających lub modyfikować współdzielone usługi. Ustal, jak go zatrzymać i jak potwierdzić, że rzeczywiście się zatrzymał.

Ustal rozsądne limity i warunki eskalacji dla każdego zadania. Powtarzające się awarie zależności, nieoczekiwane prośby o uprawnienia lub zmiany wykraczające poza zakres powinny skłaniać do kontroli, a nie do nieograniczonego ponawiania prób. Zadbaj, by logi były użyteczne, ale nie zapisuj w nich wartości sekretów ani niepotrzebnych prywatnych treści.

Nasza lista kontrolna uprawnień agenta osobistego pomaga przygotować przegląd dostępu. Analiza przejścia Conductor pokazuje również, dlaczego praca powinna pozostać przenośna: commity, stan zadań i dowody z przeglądu muszą przetrwać zmianę produktu do orkiestracji.

Przed rozpoczęciem kolejnej serii sprawdź, czy tymczasowe poświadczenia zostały w razie potrzeby cofnięte, usługi działające w tle są uwzględnione, a dla ukończonych gałęzi ustalono dalsze postępowanie. Mierz zaakceptowane wyniki i nakład pracy osób przeglądających zmiany, a nie tylko liczbę aktywnych agentów. Jeśli wąskim gardłem jest integracja, ogranicz liczbę zadań w toku zamiast dostarczać jeszcze więcej wyników do kolejki.

Przed porządkami sprawdź procedurę odzyskiwania plików, aby znaleźć materiały spoza historii Gita. Nieśledzony zbiór danych, lokalny plik konfiguracyjny lub stan zewnętrznej usługi mogą wymagać osobnego planu odzyskiwania.

FAQ

Czy dwóch agentów może bezpiecznie pracować na jednej gałęzi?

Koordynacja wspólnej pracy jest możliwa, ale niezależnym agentom należy zazwyczaj przydzielać odrębne gałęzie i katalogi robocze. W przeciwnym razie trudno ustalić, kto wprowadził zmiany i uzyskał wyniki testów, oraz je odtworzyć.

Czy dodanie pliku .env do .gitignore chroni jego zawartość przed agentem?

Nie. Reguły ignorowania dotyczą śledzenia przez Git, a nie uprawnień do odczytu systemu plików. Niepotrzebne sekrety trzymaj poza środowiskiem dostępnym dla agenta.

Czy każdy agent powinien mieć token umożliwiający scalanie zmian?

Nie. Przyznawaj wyłącznie uprawnienia potrzebne do wykonania zadania. Przygotowanie proponowanej zmiany i zaakceptowanie jej w chronionej gałęzi to odrębne uprawnienia.

Co zrobić, jeśli usunięcie worktree nie jest możliwe?

Sprawdź katalog pod kątem niezacommitowanych lub nieśledzonych zmian i zachowaj to, co istotne. Nie używaj wymuszania jako rutynowego sposobu na porządki.

Czy wystarczy, że testy w każdej gałęzi przechodzą pomyślnie?

Nie, jeśli zmiany na siebie wpływają. Uruchom odpowiednie kontrole na faktycznie zintegrowanej wersji i sprawdź działanie na styku poszczególnych elementów.

Wnioski

Bezpieczne programowanie równoległe łączy izolację kodu źródłowego z kontrolą środowiska uruchomieniowego i poświadczeń. Worktree ułatwiają oddzielanie i przeglądanie zmian, a osobne uprawnienia i odpowiednio skonfigurowane piaskownice ograniczają dostęp agenta.

Zacznij od czystej bazy, przypisz każdemu zadaniu jasno określonego właściciela i kontrakt oraz integruj wyłącznie wyniki, które można zweryfikować. Zabezpiecz dowody przed sprzątaniem, cofnij tymczasowy dostęp i zwiększaj równoległość tylko wtedy, gdy uzasadniają to zaakceptowane rezultaty, biorąc pod uwagę koszt koordynacji.