Dziesięciu agentów naraz: herdr, Conductor i worktree

Dziesięciu agentów kodujących naraz wymaga trzech warstw: osobnego git worktree na każde zadanie, żeby edycje się nie zderzały, nadzorcy, który pokazuje, który agent na ciebie czeka (agent view w Claude Code, herdr albo Conductor), oraz kolejki review, która scala po jednym zweryfikowanym pull requeście. Worktree izoluje tylko pliki, więc porty, bazy i profile przeglądarki wymagają osobnego planu.

Jest piątkowe popołudnie, a w backlogu leży dwanaście małych, niezależnych zgłoszeń. Otwierasz trzy terminale, w każdym startujesz agenta i idziesz na spotkanie. Po powrocie okazuje się, że jeden agent od 40 minut czeka na zgodę na uprawnienia, serwer deweloperski drugiego po cichu wystartował na kolejnym wolnym porcie, a testy Playwright trzeciego przeszły na serwerze drugiego. W poniedziałek masz dziewięć pull requestów i nie wiesz, które z nich naprawdę przetestowano.

Ta strona jest dla programisty, który uruchamia partię agentów, i dla tech leada, który robi z tego powtarzalny proces zespołu.

Co daje ci konfiguracja na dziesięciu agentów

• Przepis na uruchomienie od trzech do dziesięciu agentów w worktree, w Claude Code, Codex i Cursorze
• Przykład Worktrunk plus herdr: trzy polecenia wt switch i jeden ekran, który pokazuje, kto jest zablokowany
• Plan na porty, bazy danych, sekrety i profile przeglądarki dla każdego worktree
• Workflow od partii zgłoszeń do merge train z trzema promptami do skopiowania
• Dowody, które każdy pull request niesie przed zatwierdzeniem, i typowe awarie

Iloma agentami może zarządzać jedna osoba?

Ograniczeniem nie jest liczba agentów, które da się wystartować, tylko przepustowość review, limit użycia i maszyna.

• Limit użycia. Dokumentacja agent view Anthropic mówi, że sesje w tle „consume your subscription usage the same as interactive sessions, so running ten agents in parallel uses quota roughly ten times as fast as running one” (code.claude.com, odczyt 2026-09-26).
• Dysk i CPU. Plik conductor.json w repozytorium Next.js zaleca "parallel_agents": 3 i zaznacza: „Each worktree uses ~500MB-1GB disk space after build” (vercel/next.js, gałąź canary, odczyt 2026-09-26).
• Review. Raport Faros AI z 2025 roku podaje, że programiści w zespołach intensywnie korzystających z AI scalają o około 98% więcej pull requestów, a czas review rośnie o około 91% (źródło wtórne: wyciąg wyszukiwarki ze strony faros.ai, odczyt 2026-09-26). Więcej agentów przesuwa wąskie gardło do review.
• Pomiar. METR napisał 2026-02-24: „our measurements of time-spent on each task are unreliable for the fraction of developers who use multiple AI agents concurrently”. Mierz raczej scalone i wycofane pull requesty oraz czas w review.

Agentów naraz	Co działa	Gdzie widać granicę
1–3	Natywne worktree i karty terminala albo agent view w Claude Code	Pamiętanie, która karta czeka
3–10	Nadzorca: herdr, cmux albo aplikacja desktopowa w rodzaju Conductora, plus porty per worktree	Kolejka review i limit użycia
10+	Orkiestrator (Gas Town, CLI Agent Orchestrator) z wstrzymaniem nowych zadań, gdy kolejka review jest pełna	Konflikty przy scalaniu i obciążenie recenzentów

Które narzędzie odpowiada za którą warstwę?

Każde narzędzie z tabeli stoi na git worktree i dokłada launcher, terminal świadomy stanu agentów albo GUI do review. Zacznij od funkcji wbudowanych; narzędzie zewnętrzne musi zapracować na miejsce flotą mieszanych agentów, detekcją stanu albo tablicą do review.

Narzędzie	Warstwa	Co dodaje	Instalacja (zweryfikowana)	Licencja
Wbudowane w Claude Code	Worktree + nadzorca	--worktree, .worktreeinclude, --bg, claude agents (agent view, research preview), --tmux	w Claude Code 2.1.283	dostawca
Wbudowane w Codex	Worktree + lista sesji	--worktree, codex agents	w codex-cli 0.157.1	dostawca
Cursor	Worktree + chmura	Worktrees, Cloud Agents w izolowanych maszynach wirtualnych	w aplikacji	dostawca
Worktrunk (wt)	Launcher worktree	Worktree i agent jednym poleceniem; hooki; hash_port	brew install worktrunk && wt config shell install	MIT lub Apache-2.0
git gtr (CodeRabbit)	Launcher worktree	git gtr new … --ai, worktree dla PR, sprzątanie scalonych gałęzi	brew tap coderabbitai/tap && brew install git-gtr	Apache-2.0
herdr	Terminal nadzorcy	Panele oznaczone working, blocked, idle, done albo unknown; CLI i socket API; 24 rodzaje agentów	brew install herdr	Apache-2.0
cmux	Terminal nadzorcy (macOS)	Terminal oparty na Ghostty, pierścienie powiadomień, cmux claude-teams	brew tap manaflow-ai/cmux && brew install --cask cmux	GPL-3.0-or-later
Claude Squad (claude-squad)	TUI na tmux + worktree	Podgląd diffa, commit i push per sesja	brew install claude-squad (krótka nazwa cs wymaga dowiązania z README)	AGPL-3.0
ccmanager	TUI sesji	Stan busy/waiting/idle, .worktreeinclude, devcontainery	npm install -g ccmanager	MIT
Conductor	Aplikacja desktopowa (macOS, zamknięta)	Claude Code i Codex w worktree, jedna tablica do review	pobranie z conductor.build	własnościowa
Gas Town (gt)	Orkiestrator	Agent „Mayor” koordynujący workerów przez Beads	brew install gastown	MIT
CLI Agent Orchestrator (cao)	Orkiestrator	Agenci supervisor i worker w tmux, interfejs webowy	uv tool install git+https://github.com/awslabs/cli-agent-orchestrator.git@main --upgrade	Apache-2.0

Popularność na 2026-09-26 (gwiazdki na GitHubie odczytane przez GitHub API na potrzeby dossier ekosystemu tej strony): herdr 40 779; cmux 27 412; Gas Town 18 195; Claude Squad 8533; Worktrunk 8416; git gtr 1786; CLI Agent Orchestrator 1350; ccmanager 1250. Conductor ma zamknięty kod i nie publikuje porównywalnej metryki. Gwiazdki mierzą uwagę, a nie dopasowanie.

Uruchom równoległych agentów na natywnych worktree

Każde z trzech narzędzi potrafi umieścić sesję w osobnym worktree bez dodatkowego oprogramowania.

Claude Code

Uruchom jedną sesję na zgłoszenie, każdą w osobnym worktree. Claude Code tworzy worktree w .claude/worktrees/<name>/ na nowej gałęzi worktree-<name>:

# Terminal (katalog główny repozytorium). Jeden terminal na agenta.
claude --worktree issue-101
claude --worktree issue-102 --tmux     # to samo, w sesji tmux
claude --worktree "#1234"              # worktree z pull requesta 1234

Przy więcej niż trzech agentach wyślij ich w tło i nadzoruj z jednego ekranu; każda sesja w tle przenosi się do własnego worktree, zanim zacznie edytować pliki:

claude --bg --name issue-101 "Fix issue #101: pagination skips the last page. Add a failing test first."
claude --bg --name issue-102 "Fix issue #102: CSV export drops the header row. Add a failing test first."
claude agents          # jeden ekran: Ready for review, Needs input, Working, Completed
claude agents --json   # ten sam stan dla skryptów

Przed pierwszym uruchomieniem dodaj .claude/worktrees/ do .gitignore i utwórz .worktreeinclude w katalogu głównym repozytorium. Plik ma składnię .gitignore i kopiuje tylko pliki, które są jednocześnie wymienione i ignorowane przez git:

.env
.env.local

Agent teams (eksperymentalne, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1) pasują do jednej funkcji podzielonej między współpracujących agentów, a nie do partii niezależnych zgłoszeń; wbudowany skill /batch dzieli jedną dużą zmianę na 5–30 jednostek w osobnych worktree.

Codex

Obsługa worktree w Codex jest domyślnie włączona od codex-cli 0.156.0, ale sesja działa w worktree tylko wtedy, gdy o to poprosisz przez --worktree albo /worktree:

# Terminal (katalog główny repozytorium). Jeden terminal na agenta.
codex --worktree "Fix issue #101: pagination skips the last page. Add a failing test first."
codex --worktree "Fix issue #102: CSV export drops the header row. Add a failing test first."

# Bez interfejsu, dla skryptu rozsyłającego partię:
codex exec --worktree "Fix issue #103: the date filter ignores the time zone. Add a failing test first."

# Wszystkie sesje na lokalnym demonie app-server:
codex agents

Codex 0.157.1 nie dokumentuje odpowiednika .worktreeinclude, więc .env i inne pliki ignorowane przez git kopiuj launcherem, np. Worktrunk (poniżej).

Cursor

Dokumentacja Cursora opisuje Worktrees jako funkcję, która pozwala „Agent work in isolated Git checkouts”, a Cloud Agents jako agentów działających „in isolated VMs in the cloud with full development environments” (cursor.com, sprawdzone 2026-08-28). Dokładnych kroków w interfejsie nie dało się ponownie sprawdzić, więc aktualny przebieg znajdziesz na stronie Worktrees w dokumentacji Cursora. Dla floty terminalowej launchery poniżej nie zależą od agenta: -x w Worktrunk uruchamia dowolny program, a herdr wymienia cursor wśród rodzajów agentów.

Uruchom trzech agentów przez Worktrunk i obserwuj ich w herdr

Worktrunk tworzy worktree i startuje agenta jednym poleceniem, a herdr pokazuje stan każdego agenta w pasku bocznym. Oba narzędzia działają na macOS i Linuksie.

1. Zainstaluj oba narzędzia i integrację herdr dla swojego agenta, dzięki której restart przywraca sesję agenta:

   brew install worktrunk && wt config shell install
   brew install herdr
   herdr integration install claude     # także: codex, cursor, opencode, …

   Na Windowsie winget instaluje Worktrunk jako git-wt, bo wt koliduje z Windows Terminal, więc uruchom git-wt config shell install.

2. Zacommituj konfigurację projektu, żeby każde nowe worktree dostawało pliki ignorowane przez git, zależności i własny port serwera deweloperskiego. Kroki pre-start blokują do zakończenia, więc .env i node_modules istnieją, zanim wystartuje agent; post-start działa w tle, co pasuje tylko do serwera deweloperskiego. hash_port zamienia nazwę gałęzi na stały port z zakresu 10000–19999:

   .config/wt.toml

   [[pre-start]]
   copy = "wt step copy-ignored"
   
   [[pre-start]]
   install = "pnpm install"
   
   [post-start]
   server = "wt step tether -- pnpm dev --port {{ branch | hash_port }} --strictPort"
   
   [list]
   url = "http://localhost:{{ branch | hash_port }}"

   Worktrunk kopiuje wszystkie pliki ignorowane przez git, chyba że ogranicza je .worktreeinclude (jak na karcie Claude Code).

3. Uruchom herdr i utwórz jeden workspace na agenta, z paska bocznego albo przez herdr workspace create --label feature-a. W każdym wpisz jedną linię:

   wt switch -c feature-a -x env -- 'PORT={{ branch | hash_port }}' claude 'Add user authentication'
   wt switch -c feature-b -x env -- 'PORT={{ branch | hash_port }}' claude 'Fix the pagination bug'
   wt switch -c feature-c -x env -- 'PORT={{ branch | hash_port }}' claude 'Write tests for the API'

   -c tworzy gałąź i worktree, a -x uruchamia po przełączeniu jeden program z argumentami podanymi po --. Worktrunk rozwija w nich szablony, więc env startuje agenta ze zmienną PORT ustawioną na tę samą wartość hash_port, której używa serwer deweloperski. Prompt wykonawcy i konfiguracja Playwright w dalszej części strony czytają właśnie ten PORT, więc testy agenta trafiają w jego własny serwer.

4. Odczytaj przegląd. Pasek boczny herdr pokazuje stan każdego agenta i zbiera go na poziomie workspace’u, więc przy jednym workspace na agenta zablokowanego agenta widzisz bez odwiedzania każdego panelu. Dla skryptów CLI daje ten sam widok; agent uruchomiony ręcznie nie ma nazwy, więc wskazuj go identyfikatorem panelu z agent list:

   herdr agent list
   herdr agent wait w2:p1 --until blocked --timeout 600000
   herdr agent read w2:p1 --source recent-unwrapped --lines 80

5. Scalaj każdą skończoną gałąź, po jednej naraz. wt merge main robi squash, rebase na main, fast-forward i usuwa worktree; w workflow z pull requestami uruchom gh pr create z worktree, a po scaleniu wt remove.

Co powinieneś zobaczyć: trzy workspace’y, w każdym Claude Code działający w ../repo.feature-a, ../repo.feature-b albo ../repo.feature-c; wt list pokazuje trzy gałęzie z trzema różnymi portami w kolumnie URL; stan każdego workspace’u w pasku bocznym zmienia się z working na idle albo blocked w miarę postępu agenta.

Większą partię uruchom skryptem. Tę pętlę złożyliśmy na podstawie dokumentacji CLI herdr 0.9.1:

# Uruchom z powłoki wewnątrz herdr, w katalogu głównym repozytorium.
while IFS='|' read -r branch task; do
  created=$(herdr workspace create --cwd "$PWD" --label "$branch" --no-focus)
  pane=$(printf '%s\n' "$created" | jq -r '.result.root_pane.pane_id')
  # tekst zadania nie może zawierać apostrofów (pojedynczych cudzysłowów)
  herdr pane run "$pane" "wt switch -c $branch -x env -- 'PORT={{ branch | hash_port }}' claude '$task'"
done <<'EOF'
issue-101|Fix issue #101 (pagination skips the last page). Write a failing test first.
issue-102|Fix issue #102 (CSV export drops the header row). Write a failing test first.
issue-103|Fix issue #103 (date filter ignores the time zone). Write a failing test first.
EOF

Co naprawdę znaczy stan w herdr dla Claude Code, Codex i Cursora

W herdr 0.9.1 stan Claude Code, Codex i CLI agenta Cursora pochodzi z manifestu ekranu, a nie z lifecycle hooków: blocked pojawia się tylko wtedy, gdy ekran pasuje do znanego okna zgody albo pytania, a nierozpoznany prompt wyświetla się jako idle (w Codex jako unknown). Długie idle albo unknown traktuj jako „zajrzyj”, a nie „gotowe”. Pełne API opisuje strona herdr: multiplekser agentów ze skryptowalnym API.

Conductor: ścieżka desktopowa na macOS

Conductor (Melty Labs) to zamknięta aplikacja na Maca, która uruchamia równolegle agentów Claude Code i Codex w worktree, z jedną tablicą do review. Wybierz ją dla graficznej tablicy z diffami na macOS; nie działa na Linuksie ani Windowsie.

Weryfikowalna część to konfiguracja w repozytorium. Poniżej skrócona wersja pliku conductor.json, który commituje repozytorium Next.js (odczyt 2026-09-26; pełny plik ma też name, description, TURBO_TELEMETRY_DISABLED i listę notes):

{
  "scripts": {
    "setup": "./.conductor/scripts/setup.sh",
    "run": "./.conductor/scripts/run.sh"
  },
  "worktree": { "default_branch": "canary" },
  "environment": { "NEXT_TELEMETRY_DISABLED": "1" },
  "recommendations": { "parallel_agents": 3 }
}

Szczegóły Conductora, których ta strona nie zweryfikowała

Strona conductor.build była niedostępna podczas pisania. Wyciągi wyszukiwarki z jej dokumentacji (źródło wtórne, 2026-09-26) nazywają conductor.json formatem przestarzałym na rzecz .conductor/settings.toml i opisują osobny dla każdego workspace’u CONDUCTOR_PORT (np. pnpm dev --port $CONDUCTOR_PORT). Najpierw sprawdź oba na conductor.build. Szersze porównanie aplikacji desktopowych znajdziesz w przeglądzie alternatywnych IDE i powłok agentowych.

Daj każdemu worktree własne porty, bazę i przeglądarkę

Worktree izoluje pliki i gałąź. Wszystko inne jest współdzielone, dopóki tego nie rozdzielisz, a większość kolizji jest cicha.

Zasób	Współdzielony domyślnie?	Co się psuje	Rozwiązanie
Pliki i gałąź	Nie	—	Samo worktree
Pliki ignorowane przez git (.env)	Brak w nowym worktree	Testy padają na konfiguracji albo agent wymyśla wartości	.worktreeinclude (Claude Code, Worktrunk, ccmanager), wt step copy-ignored, gtr.copy.include
Port serwera deweloperskiego	Tak	Vite przechodzi na kolejny wolny port, jeśli nie ustawisz strictPort	Stały port per worktree: hash_port, blok portów na indeks worktree albo CONDUCTOR_PORT (źródło wtórne)
Serwer test runnera	Tak	reuseExistingServer w Playwright podłącza się do tego, co nasłuchuje na porcie, nawet do serwera innego agenta	baseURL, webServer.url i port serwera wyprowadzaj z jednej wartości per worktree
Profil przeglądarki	Tak	Z trwałego profilu Playwright MCP może naraz korzystać tylko jedna przeglądarka	Uruchamiaj Playwright MCP z --isolated w każdym agencie
Lokalna baza danych	Tak	Dwóch agentów migruje ten sam schemat	Jedna baza na worktree (zmienne hash_port w Worktrunk, kontener na gałąź) albo sandbox
git config i katalog .git	Tak	Zapis konfiguracji w jednym worktree zmienia wszystkie	Nie pozwalaj agentowi uruchamiać git config; trzymaj ustawienia w commitowanych plikach
Zgody na uprawnienia (Claude Code)	Tak	„Don’t ask again” w jednym worktree obowiązuje we wszystkich	Świadome reguły zapisz w .claude/settings.json i przejrzyj je
Dane produkcyjne, deploye, sekrety, zewnętrzne API	Tak	„Szybkie sprawdzenie” jednego agenta zapisuje dane produkcyjne	Zablokuj te polecenia i dawaj agentom wyłącznie poświadczenia do sandboxa

Powiąż test runner z tym samym PORT, który launcher przekazał agentowi (prefiks env w kroku z Worktrunk), i przerywaj głośno, gdy go brakuje, zamiast wracać do wspólnego portu domyślnego. Dla projektu Vite z Playwright:

playwright.config.ts

import { defineConfig } from '@playwright/test';

// Locally, PORT comes from the agent's launch line; CI runs one server, so a default is safe there.
const port = process.env.PORT ?? (process.env.CI ? '5173' : '');
if (!port) throw new Error('PORT is not set: start the agent with its worktree port');
const baseURL = `http://localhost:${port}`;

export default defineConfig({
  use: { baseURL },
  webServer: {
    command: `pnpm dev --port ${port} --strictPort`,
    url: baseURL,
    reuseExistingServer: !process.env.CI,
  },
});

Daj każdemu agentowi własną przeglądarkę do sprawdzania UI. Flaga --isolated trzyma profil przeglądarki w pamięci, więc równolegli agenci nie walczą o jeden trwały profil. Polecenia wyprowadziliśmy z instrukcji instalacji dostawcy dla każdego narzędzia:

Claude Code

claude mcp add playwright -- npx @playwright/mcp@latest --isolated

Codex

codex mcp add playwright -- npx @playwright/mcp@latest --isolated

Cursor

.cursor/mcp.json

{
  "mcpServers": {
    "playwright": { "command": "npx", "args": ["@playwright/mcp@latest", "--isolated"] }
  }
}

Schematy narzędzi serwera MCP trafiają do kontekstu każdego agenta. Uruchom /context w Claude Code przed dodaniem serwera i po nim, żeby zobaczyć, ile kosztuje każdą z dziesięciu sesji.

Gdy izolacja na poziomie plików nie wystarcza (usługi, kontenery, sieci), przenieś każdego agenta do sandboxa; opcje porównuje strona sandboksy dla agentów, a wzorzec pełnego stosu opisuje strona efemeryczne środowiska dla każdego zadania agenta.

Przeprowadź workflow od partii zgłoszeń do merge train

Launcher to łatwiejsza połowa. O tym, czy dziesięciu agentów pomaga, decyduje praca wokół nich: partia bez kolizji, standardowy prompt, nadzór tylko przy wyjątkach i kolejka, która scala po jednej zweryfikowanej zmianie.

1. Wybierz partię, która nie może się zderzyć. Wybierz niezależne zgłoszenia z kryteriami akceptacji, żadnych dwóch w tym samym module. Triaż zrobi agent planujący tylko do odczytu.

2. Utwórz jedno worktree na zgłoszenie i nazwij je od zgłoszenia (issue-101), żeby gałąź, pull request i wiersz agenta miały jedną nazwę.

3. Roześlij agentów z jednym standardowym promptem. Każdy agent pisze nieprzechodzący test, naprawia zgłoszenie, uruchamia kontrole na własnym porcie i otwiera draft pull requesta z dowodami.

4. Nadzoruj tylko przy wyjątkach. Obserwuj tylko blocked albo Needs input. Wstrzymaj rozsyłanie, gdy kolejka review dojdzie do limitu; przewodnik po kolejce review pokazuje, jak go wyznaczyć.

5. Recenzuj dowody, a nie każdą linię. Agent recenzent najpierw sprawdza każdy diff względem kryteriów akceptacji (/code-review w Claude Code, codex review --base main w Codex). Człowiek czyta nazwy testów, dowody i uwagi, a kod tam, gdzie wskazuje go uwaga albo poziom ryzyka.

6. Scalaj jak pociąg. Scalaj po jednym pull requeście, kolejny rebase’uj na nowe main i uruchamiaj CI ponownie. W zespole robi to merge queue na GitHubie (dodaj zdarzenie merge_group do workflow, który uruchamia wymagane kontrole); lokalnie robi to wt merge main. Gdy rebase kończy się konfliktem, wyślij przegrane zgłoszenie jeszcze raz na świeżym worktree.

7. Posprzątaj. Usuń scalone worktree: wt remove, git gtr clean --merged --closed albo claude rm <id> dla sesji w tle. Zacommituj i wypchnij pracę, zanim usuniesz sesję w agent view: usunięcie sesji może skasować worktree, które Claude dla niej utworzył (zostaje, gdy zawiera niewypchnięte commity, chyba że podasz --discard-unpushed).

Prompt do skopiowania: triaż backlogu na partię równoległą

Read the open issues labelled "ready" (use gh issue list --label ready --json number,title,body).
Do not change any files.
Group them into a batch of at most 8 issues that can be worked on in parallel:
- every issue has testable acceptance criteria (if not, list it under "needs spec")
- no two issues in the batch are likely to edit the same file or module; name the files you expect each to touch
- exclude anything that needs a schema migration, a dependency upgrade, or a change to CI
Output a table: issue number, one-line task, expected files, risk (low/medium/high), and the branch name issue-<number>.

Prompt do skopiowania: jeden agent wykonawca na zgłoszenie

You are working on issue #101 in your own git worktree. Stay inside this worktree.
1. Read the issue with gh issue view 101 and restate the acceptance criteria as a checklist.
2. Write a failing test that proves the bug, run it, and show it failing.
3. Make the smallest change that makes it pass. Do not refactor unrelated code.
4. Run the type check, the linter and the full test suite for the packages you touched.
   Start the dev server only on the port in $PORT, never on a default port.
5. Commit, push the branch, and open a draft pull request titled "Fix #101: <summary>".
   In the description, add an "Evidence" section: the checklist with each item ticked,
   the commands you ran and their results, and anything you could not verify.
Stop and ask me before touching configuration, migrations, lockfiles or CI.

Prompt do skopiowania: agent recenzent dla kolejki

Review the pull request for issue #101 against main. Do not edit code.
Check, and report each as PASS, FAIL or UNSURE with the file and line:
- every acceptance criterion in the issue is covered by a test that would fail without the change
- the diff touches only files the issue needs; list any unrelated change
- no secrets, no new dependencies, no changes to CI, migrations or lockfiles
- the Evidence section matches what the CI run actually shows
End with one line: MERGE, FIX (with the list), or ESCALATE (with the reason a human must look).

Start agentów z trackera zgłoszeń opisuje potok od zgłoszenia do PR, a podział jednego zadania między agentów — wzorce orkiestracji wielu agentów.

Skąd wiesz, że dziesięć równoległych pull requestów można bezpiecznie scalić?

Każda zmiana musi się obronić bez człowieka czytającego każdą linię. Wymagaj czterech rzeczy od każdego pull requesta, a ostatnią niech wymusza merge queue.

Dowód	Kto go wytwarza	Kto go sprawdza
Test, który nie przechodzi bez zmiany i przechodzi z nią	Agent wykonawca, w sekcji Evidence	Agent recenzent (PASS w pierwszym punkcie)
Type check, lint i testy uruchomione we własnym worktree agenta, na jego porcie	Agent wykonawca	CI na pull requeście
Diff ograniczony do plików zgłoszenia, bez zmian w konfiguracji, migracjach i lockfile’ach	Agent wykonawca	Agent recenzent, potem reguła CODEOWNERS dla wrażliwych ścieżek
Zielone CI na HEAD zrebase’owanym na najnowsze main	Merge queue	Wymagany status check

Zatwierdzenie zostaje przy człowieku. Programista, który rozesłał partię, odpowiada za każde scalenie. Tech lead odpowiada za reguły: rozmiar partii, limit kolejki review, ścieżki, które zawsze wymagają człowieka, i liczby do obserwacji (scalone pull requesty dziennie, czas w review, wycofania w ciągu tygodnia). Rosnąca liczba wycofań oznacza za dużą partię albo za słabe kryteria; rozwiązaniem jest mniej agentów, nie szybsze review. Boty, które mogą zrobić pierwszy przebieg review, opisuje strona boty AI do code review.

Co się psuje, gdy uruchamiasz dziesięciu agentów naraz?

Pułapki przy instalacji narzędzi do równoległych agentów

• npm install -g herdr instaluje zarezerwowany placeholder (0.0.0). Użyj brew install herdr, mise use -g herdr albo skryptu instalacyjnego z herdr.dev.
• npm install -g claude-squad instaluje niezwiązany pakiet innego autora. Użyj brew install claude-squad.
• npm i conductor to niezwiązana biblioteka JavaScript; Conductor jest aplikacją na Maca.
• herdr i Herd to różne produkty (herdr.dev to multiplekser, joinherd.ai to aplikacja desktopowa).
• Claude Squad ma licencję AGPL-3.0, a cmux GPL-3.0-or-later: uzgodnij je z działem prawnym, zanim je osadzisz albo zahostujesz.

Testy przechodzą na niewłaściwym serwerze. Serwer deweloperski przeszedł na kolejny wolny port, a test runner użył serwera innego agenta. Naprawa: zatrzymaj wszystkie serwery deweloperskie, przekaż każdemu agentowi stały PORT z --strictPort i uruchom ponownie testy każdego pull requesta z tej partii.

Dwóch agentów edytuje ten sam plik. Drugi rebase kończy się konfliktem. Naprawa: scal pierwszy i wyślij drugie zgłoszenie ponownie na świeżym worktree z nowego main. Zapobiegaj temu, wypisując oczekiwane pliki na etapie triażu.

Nikt nie zauważa zablokowanego agenta. herdr pokazuje nierozpoznany prompt jako idle (w Codex jako unknown). Naprawa: sprawdzaj przez herdr agent read wszystko, co jest idle albo unknown od kilku minut, albo rozsyłaj przez claude --bg, żeby sesja trafiała do Needs input.

W worktree brakuje .env albo zależności. Testy padają na konfiguracji albo agent wpisuje wartości zastępcze. Naprawa: dodaj pliki do .worktreeinclude (albo wt step copy-ignored), dodaj instalację zależności jako hook pre-start i uruchom agenta ponownie.

Kończy się miejsce na dysku. Next.js podaje od 500 MB do 1 GB na worktree. Naprawa: git worktree list, a potem git worktree remove dla scalonej pracy; gdy git odmawia z powodu blokady, którą Claude Code zostawił po uruchomieniu z -p, najpierw uruchom git worktree unlock.

Praca znika. Usunięcie sesji w agent view może skasować jej worktree (zostaje, gdy zawiera niewypchnięte commity, chyba że podasz --discard-unpushed), a git worktree remove --force wyrzuca niezacommitowaną pracę. Naprawa: commituj i pushuj przed usunięciem; jeśli zniknęła gałąź, git fsck --lost-found wypisze jej commity do czasu garbage collection.

Limit użycia kończy się w połowie partii. Naprawa: ogranicz partię, rutynowe zgłoszenia przenieś na tańszy model, gdy potwierdzą to twoje ewaluacje (zobacz hub modeli), a długie partie uruchamiaj poza godzinami pracy.

Agent dotyka współdzielonego stanu. Migracja na wspólnej lokalnej bazie, zapis git config albo polecenie na produkcji dotyka wszystkich worktree. Naprawa: odtwórz dane z backupu, zablokuj to polecenie i dawaj agentom wyłącznie poświadczenia do sandboxa. Aktualizuj Claude Code: jego zgłoszenia bezpieczeństwa wymieniają „Sandbox Escape via Git Worktree Path Confusion” z oceną High (2026-06-25).

Dokąd dalej z równoległymi agentami

Równolegli agenci w izolowanych worktree Wymaganie wstępne: kontrakt izolacji dla dwóch do czterech worktree.

Agent view w Claude Code Rozsyłanie, podgląd i podłączanie się do sesji w tle z jednego ekranu.

Worktree w Codex Jak Codex tworzy worktree i nimi zarządza.

herdr: multiplekser agentów Detekcja stanu, CLI agentów i agent orkiestrator.

tmux dla flot agentów Równolegli agenci bez nowych zależności.

Kolejka code review Następny krok: limity WIP, budżety rozmiaru PR i czas w review.

Równoległość w zespole: izoluj pracę i ogranicz kolejkę Ta sama zmiana z perspektywy tech leada.