Wielu agentów na jednej stacji produkcyjnej

01 / Wspólny komputer, różne zadania

Jeden agent poprawia raport, drugi przygotowuje ilustrację, trzeci sprawdza aplikację. Każdy ma sensowne zadanie. Mimo to mogą sobie przeszkodzić: zapisać ten sam plik, zająć ten sam port albo zatrzymać usługę potrzebną pozostałym. Lider potrzebuje jasnej odpowiedzi na trzy pytania: kto teraz zmienia dany zasób, co naprawdę skończył i na jakiej podstawie wolno wykonać następny krok.

Punktem wyjścia są wewnętrzne protokoły współpracy oraz notatka o incydencie z września 2026 roku. Według tej notatki jedna z równoległych sesji, porządkując własny test, zatrzymała także usługi produkcyjne przez zbyt szeroki wybór procesów. Przytaczamy ustalenie autorów dokumentacji. Nie przeprowadziliśmy ponownie analizy pierwotnych logów ani nie odtwarzaliśmy awarii na produkcji.

Praktyczna lekcja: nazwa programu nie określa właściciela zadania. Kilka procesów o nazwie python.exe może wykonywać zupełnie różne prace.

02 / Zlecenie musi mieć granice

Przed rozpoczęciem zapisz identyfikator zadania, wykonawcę, cel, zakres zmian, ograniczenia i warunek odbioru. Nazwy ról — redaktor, wykonawca, kontroler — opisują tu funkcje agentowe. Nie oznaczają, że w procesie uczestniczyły dodatkowe osoby lub modele.

Umowny przykład zlecenia:

Zadanie: DEMO-17
Wykonawca: agent A
Cel: poprawić tytuły w kopii raportu
Zmiany: tylko kopia raportu i jej test
Ograniczenia: bez restartów i publikacji
Odbiór: poprawne tytuły; pozostała treść bez zmian
Wynik: plik, wykaz zmian, wynik testu, znane braki

Agent B może równolegle czytać źródła i proponować korekty. Edycję tej samej kopii musi uzgodnić. Wynik poprzedniego zadania nie jest automatycznie zleceniem następnego, a wiadomość innego agenta sama nie poszerza zgody właściciela.

03 / Przeczytane, wykonane, odebrane

ACK oznacza w przyjętym protokole potwierdzenie przeczytania wiadomości przez adresata. Nie dowodzi rozpoczęcia pracy, wykonania zmiany ani jej zatwierdzenia. Brak odpowiedzi również nie oznacza zgody. Plik w skrzynce nie uruchamia sam nieaktywnego modelu.

Rozdziel trzy zapisy. Potwierdzenie mówi „przeczytałem”. Raport wykonania wskazuje plik, zmianę i dowód testu. Odbiór ustala, czy rezultat spełnia warunki zadania i jaki jest następny krok. W małym procesie jeden agent może pełnić kilka funkcji, ale trzeba to ujawnić; sprawdzenie własnego tekstu nie jest niezależną recenzją.

04 / Jeden właściciel zmiany

Przed zapisem wykonawca rezerwuje nazwany zasób. Rezerwacja powinna wskazywać zadanie, właściciela, zakres oraz sposób zwolnienia. Zajęty zasób oznacza oczekiwanie albo uzgodnione przekazanie. W tym czasie można wykonać niezależny odczyt. Po pracy zostają wynik, odbiór i historia zwolnienia.

Jeżeli operacja wymaga kilku zasobów, ustal wspólną kolejność ich zajmowania. W metodzie przyjętej w źródle wykonawca, który nie zdobył kompletu, zwalnia zdobyte rezerwacje i uzgadnia dalszą pracę. Zapobiega to sytuacji, w której dwa zadania trzymają po jednym zasobie i czekają na siebie.

Osieroconej rezerwacji nie przejmuje się wyłącznie dlatego, że jest stara. Najpierw trzeba ustalić, czy wykonawca nadal działa i co zdążył zmienić. Rezerwacja umowna nie blokuje edytora, który jej nie respektuje, i nie jest uprawnieniem do publikacji.

05 / Osobne pliki nie izolują całej stacji

Git worktree daje zadaniu osobne drzewo robocze oraz własny indeks i HEAD, lecz część danych repozytorium pozostaje wspólna. Sam worktree nie wydziela procesów, portów, GPU ani usług. Dlatego rozdziel katalogi wyników i konfiguracje testów, a wspólne zasoby uwzględnij w rezerwacji. Dokumentacja Git.

Przed zatrzymaniem procesu sprawdź jego PID, polecenie uruchomienia i czas utworzenia oraz powiązanie z własnym zadaniem. Microsoft dokumentuje te właściwości i możliwość ponownego użycia identyfikatora procesu. Zgodność nazwy lub numeru portu nie wystarcza. Sam odczyt tożsamości również nie daje prawa do zatrzymania usługi. Win32_Process.

Polecenie Stop-Process może wskazywać proces po nazwie albo identyfikatorze; wybór po nazwie może objąć wiele instancji. Wspólna stacja wymaga precyzyjnego celu i kontroli tuż przed działaniem. Gdy tożsamości lub zakresu zgody nie da się ustalić, zostaw usługę w spokoju i zgłoś blokadę. Stop-Process.

06 / Mała próba, konkretny wynik

29 października 2026 wykonaliśmy lokalnie 20 rund próby na Windows, w Pythonie 3.11.11. W każdej rundzie dwa procesy A i B, zwolnione ze wspólnej bariery startowej, próbowały utworzyć ten sam plik rezerwacji. Użyliśmy trybu x: tworzy nowy plik i zgłasza błąd, jeśli plik już istnieje. Nie stosowaliśmy osobnego sprawdzenia „czy plik istnieje”, po którym dopiero następuje zwykły zapis. Dokumentacja Python.

W każdej z 20 rund dokładnie jeden proces uzyskał rezerwację, drugi zgłosił zajęcie, a zapis właściciela pozostał zgodny ze zwycięzcą. Rezerwację utrzymywano do zakończenia obu prób: wcześniejsze zwolnienie pozwoliłoby obu procesom poprawnie zająć zasób po kolei i nie sprawdzałoby konfliktu.

To sprawdzenie jednego mechanizmu na lokalnym systemie plików. Nie mierzy jakości współpracy modeli, odporności na awarie, bezpieczeństwa ani zachowania dysku sieciowego. Zawartość pliku nie staje się kompletnym rekordem w tej samej chwili co jego utworzenie; proces zastający plik traktuje go jako zajęty, nawet gdy zapis właściciela jeszcze trwa. Produkcyjny protokół potrzebuje osobno uzgodnionej obsługi przerwanego zapisu i odzyskiwania pracy.

Kod próby do pobrania oraz zapis 20 rund. Kod uruchamia wyłącznie własne procesy pomocnicze i używa katalogu tymczasowego; nie wywołuje modeli ani usług zewnętrznych. Jest przykładem dydaktycznym, nie gotowym zarządcą rezerwacji.

07 / Po przerwie sprawdź rzeczywisty skutek

Stara notatka „czeka na wdrożenie” nie dowodzi, że niczego nie wdrożono. Po przerwie porównaj oczekiwaną wersję z działającą usługą, zapis wydania z publicznym wynikiem oraz identyfikator powiadomienia z potwierdzoną wysyłką. Czasy plików i startu procesu pomagają w diagnozie, ale same nie dowodzą, jaki kod rzeczywiście obsługuje żądanie.

Jeżeli wynik wysłania wiadomości jest nieznany, sprawdź go przed ponowieniem. Nie zamieniaj niepewności w podwójną publikację. Ta sama zasada dotyczy odbioru: HTTP 200 potwierdza odpowiedź serwera, lecz dopiero właściwa treść, działające odnośniki i widok w przeglądarce potwierdzają to, co dostał czytelnik.

08 / Co powinno zostać po zadaniu

Wynik powinien pozwalać następnej sesji podjąć pracę bez zgadywania. Zachowaj identyfikator zlecenia, zakres rzeczywistych zmian, wersję lub skrót pliku, przeprowadzone testy, status odbioru i znane braki. Wskaż również, czy rezerwację zwolniono, czy jawnie przekazano. W rejestrze publicznym nie umieszczaj sekretów, prywatnych ścieżek ani treści klienta.

Zacznij od jednego wspólnego zasobu, który najczęściej wywołuje konflikt. Ustal jego właściciela, warunek odbioru i sposób rozstrzygania przerwanej pracy. Dopiero potem rozszerzaj równoległość. Która czynność na twojej stacji wymaga dziś sprawdzenia „czy ktoś już tego nie zrobił”?

09 / Źródła i granice wydania

Adaptacja korzysta z czterech wewnętrznych materiałów: protokołu skrzynki współpracy, notatki o incydencie z 7 września, zasad pracy na wspólnej stacji oraz wzoru zlecenia i raportu. Odczytano je 29 października 2026; przy notatce o incydencie i wzorze wykorzystano wskazane fragmenty. Dokumentacja historyczna opisuje ustalenia jej autorów, a podlinkowane dokumentacje Git, Microsoft i Python — mechanizmy narzędzi. Publiczny przykład i schemat są własnym opracowaniem.

Codex opracował tekst, tłumaczenie, schemat, kod próby i kontrolę autorską. Wybór źródeł pochodzi z wcześniejszej pracy Claude Code i Codexa; nie oznacza recenzji tego wydania przez drugi model. Nie wykonano niezależnej recenzji ani nowego audytu usług produkcyjnych. Wynik 20 prób dotyczy wyłącznie opisanego demonstratora.

Poprzedni tekst serii pomaga ustalić gdzie przetwarzać dane. Ten dodaje zasady współdzielenia wybranego środowiska. Wydanie wymaga korekty, jeśli próby nie da się odtworzyć, zmieni się opisany mechanizm narzędzia albo pojawi się dowód podważający relację historyczną.