Wzorce orkiestracji wielu agentów: planista, wykonawcy, sędzia

Wzorce orkiestracji wielu agentów to cztery sposoby podziału pracy programistycznej między agentów kodujących: fan-out/fan-in, pipeline, best-of-N z sędzią oraz rozdzielenie autora i recenzenta. Każdy opłaca się tylko wtedy, gdy praca dzieli się na części weryfikowalne niezależnie albo gdy błędna odpowiedź kosztuje więcej niż dodatkowe przebiegi; inaczej tylko mnoży koszt tokenów.

Uruchamiasz ośmiu agentów w serwisie rozliczeń. Po południu trzy gałęzie przepisały ten sam routes/index.ts, dwóch agentów wymyśliło różne kształty jednego zdarzenia, „recenzent” zatwierdził kod z własnego kontekstu, a dzienny budżet zniknął. Narzędzie zrobiło, o co prosiłeś. To wzorzec nie pasował do pracy.

Ta strona jest dla programistów, którzy uruchamiają agentów, i tech leadów, którzy decydują, ilu pracuje naraz i co oznacza „gotowe”.

Co daje działająca orkiestracja

• Tabelę decyzyjną: do którego wzorca pasuje zadanie, a które zostają przy jednym agencie.
• Planistę, wykonawcę i sędziego jako pliki w repozytorium: subagenta Claude Code w worktree, sędziego tylko do odczytu, blok [agents] dla Codex.
• Cztery prompty do skopiowania: dekompozycję, audyt fan-out, ocenę best-of-N, recenzję adwersarialną.
• Łańcuch weryfikacji, który dowodzi poprawności bez czytania linia po linii.
• Kontrolę kosztu w każdym narzędziu i typowe awarie.

Polecenia i ustawienia na tej stronie sprawdzono 26.09.2026 w Claude Code 2.1.283 i codex 0.157.1 (--help i kod źródłowy Codex). Szczegóły Cursora sprawdzono na cursor.com 28.08.2026.

Czym są role planisty, wykonawcy i sędziego?

Każdy wzorzec łączy trzy role inaczej. Nazywaj je w promptach i definicjach agentów: większość awarii bierze się z tego, że jeden agent po cichu gra dwie role.

Rola	Robi	Nie może	Wynik
Planista	Dzieli cel na jednostki, przypisuje każdej jednostce jej pliki, pisze wspólne kontrakty i podaje test akceptacyjny każdej jednostki	Pisać kodu implementacji	Plik planu: jednostki, przypisane ścieżki, zależności, polecenie, które dowodzi każdej jednostki
Wykonawca	Implementuje albo bada dokładnie jedną jednostkę, we własnym worktree lub VM	Dotykać plików spoza swojej jednostki ani edytować testów, które go oceniają	Gałąź albo raport oraz wynik polecenia akceptacyjnego
Sędzia	Najpierw uruchamia deterministyczne sprawdzenia, potem porównuje albo ocenia wyniki wykonawców	Edytować kodu, który ocenia, ani wiedzieć, który agent czy model napisał którego kandydata	Werdykt z dowodami: uruchomione polecenia, kody wyjścia, plik i linia

Zespoły pomijają sędziego. Sędzia, który tylko czyta kod, jest drugą opinią; ten, który uruchamia test reprodukujący, sprawdzenie typów i testy toru, a ocenia tylko resztę, jest bramką. Zobacz sprawdzenia oceniane przez model.

Który wzorzec orkiestracji pasuje do twojego zadania?

Wybieraj na podstawie kształtu pracy, nie liczby agentów, których możesz uruchomić.

Wzorzec	Kształt	Opłaca się, gdy	Tylko mnoży koszt, gdy	Sędzia sprawdza
Fan-out/fan-in	Ten sam krok na wielu niezależnych elementach, potem jedno scalenie	Elementy mają osobne pliki, nie dzielą zmieniających się kontraktów i każdy ma własne sprawdzenie	Elementy dzielą pliki albo kontrakt, który wciąż się zmienia; scalanie przerabia wszystko	Sprawdzenie każdego elementu, potem jeden przebieg integracyjny po scaleniu
Pipeline	Etapy po kolei (specyfikacja → plan → implementacja → weryfikacja → code review), każdy z własnymi narzędziami i kontekstem	Etapy potrzebują różnych uprawnień albo kontekstu, a każdy przekazuje plik, który da się zwalidować	Etapy przekazują sobie prozę; jeden agent zmieściłby całe zadanie w kontekście	Artefakt na granicy każdego etapu, względem schematu albo listy kontrolnej
Best-of-N z sędzią	N niezależnych prób jednego problemu, jeden sędzia wybiera	Przestrzeń rozwiązań jest szeroka, błędna pierwsza odpowiedź jest droga, a sędzia może orzec na podstawie dowodów	Zmiana jest mechaniczna, więc próby się zbiegają; albo sędzia może wydać tylko opinię	Test reprodukujący, benchmark albo zgodność ze specyfikacją dla każdego kandydata
Autor i recenzent	Jeden agent pisze, drugi, ze świeżym kontekstem, recenzuje, autor poprawia	Prawie zawsze na poziomie pull requesta: to najtańszy wzorzec o najwyraźniejszym zysku	Pętla nie ma reguły zatrzymania i para spiera się przez kolejne rundy	Uwagi z plikiem, linią i nieprzechodzącym poleceniem, a nie preferencje stylistyczne

Resztę obejmują dwie reguły. Problem, który jeden agent mieści w kontekście, zostaje przy jednym agencie: orkiestracja kupuje szerokość, izolację albo niezawodność, nigdy tańszy trudny problem. Zadanie kończące się jednym warunkiem „przechodzi/nie przechodzi” („build jest zielony”) to pętla celu; zobacz polecenie /goal.

Kiedy opłaca się fan-out/fan-in?

Fan-out uruchamia jednego wykonawcę na element; fan-in zbiera i weryfikuje wyniki, jak w audytach, migracjach plik po pliku i uzupełnianiu testów. Wzorzec opłaca się, gdy każdy element ma własne pliki, nie zależy od niczego, co inny wykonawca wciąż pisze, i potrafi udowodnić swoją poprawność samodzielnie własnymi testami, sprawdzeniem typów i lintem. Element, który oblewa którykolwiek warunek, należy do szeregowego kroku bazowego przed fan-outem: migracje, wspólne typy, rejestracje w plikach barrel.

Jakość fan-outu najczęściej ginie na etapie fan-in. Wymagaj trzech rzeczy:

• Rozliczenia pokrycia. Raport wymienia niezakończone elementy; „brak uwag” z 60% plików to nie „brak uwag”.
• Deduplikacji i obalania. Drugi przebieg próbuje obalić każdą uwagę, zanim do ciebie trafi.
• Jednego przebiegu integracyjnego. Pełny zestaw testów uruchamia się raz na scalonym wyniku, bo każdy tor udowodniono tylko w izolacji.

Prompt do skopiowania: audyt fan-out z pokryciem i obalaniem

Audit every route handler under src/routes/ for missing authentication or authorization checks. Use one worker per file; workers must not edit anything. Each finding must carry the file, the line, the missing check and the request that would exploit it. Then run a second pass in which a different agent tries to refute each finding by reading src/middleware/ and the router setup; keep only findings that survive. Finish with a table sorted by severity and a separate list of every file no worker finished.

W Claude Code poprzedź prompt słowem ultracode albo dopisz „use a workflow”, by uruchomić dynamiczny workflow; w Codex i Cursorze agent deleguje pracę subagentom.

Kiedy pipeline wygrywa z jedną długą sesją?

Pipeline uruchamia etapy po kolei, a każdy dostaje tylko potrzebny mu kontekst i narzędzia: planista tylko do odczytu, implementujący w worktree, weryfikator, który uruchamia testy, ale nie edytuje. Opłaca się, gdy te uprawnienia mają znaczenie albo gdy kontekst jednej sesji by się zapełnił.

Cała konstrukcja pipeline’u opiera się na przekazaniu między etapami. Każdy etap zapisuje plik o kształcie, który da się sprawdzić: plan.json względem schematu, gałąź względem jej polecenia akceptacyjnego. Etapy, które przekazują sobie prozę, kumulują nawzajem swoje błędy.

Człowiek zatwierdza plan i scalenie (zobacz łańcuch weryfikacji niżej). Wersję od zgłoszenia do pull requesta opisuje strona od zgłoszenia do PR bez rąk na klawiaturze.

Prompt do skopiowania: planista, który pisze sprawdzalny plan

Plan this change; do not write implementation code: add per-channel notification preferences (email, SMS, push) for each notification type.
Write plan.json with:
- "foundation": the serial steps that must land first (migrations, shared types, route registration), each with the files it owns.
- "units": the parallel units, each with id, goal, owned_paths (globs), depends_on (unit ids), and acceptance (the exact test, type-check and lint commands that prove it alone).
- "integration": the commands to run once after every unit is merged.
Rules: no path may appear in two units' owned_paths; any file two units need goes into "foundation". If a unit cannot be proven by its own commands, merge it into another unit. Print the plan as a table after writing the file.

Kiedy best-of-N z sędzią jest wart dodatkowych przebiegów?

Best-of-N uruchamia N niezależnych prób jednego problemu, a sędzia wybiera jedną. Opłaca się przy błędzie o niejasnej przyczynie, poprawce wydajności z kilkoma sensownymi podejściami albo decyzji projektowej, pod warunkiem że test reprodukujący albo benchmark rozstrzyga, która próba zadziałała.

Tylko mnoży koszt przy pracy mechanicznej (zmiana nazwy, codemod, podbicie zależności), gdzie próby się zbiegają, albo z sędzią bez dowodów.

Trzy reguły sprawiają, że sędzia jest wart swojej ceny:

• Dowody przed gustem. Sędzia uruchamia na każdym kandydacie test reprodukujący, dotknięty zestaw testów i ewentualny benchmark, a czytelność ocenia tylko wśród tych, którzy przeszli.
• Porównanie w ciemno. Usuń z kandydatów nazwę agenta, model i numer próby, zanim zobaczy je sędzia, i zmieniaj ich kolejność między przebiegami.
• Brak prawa edycji. Sędzia może uruchamiać kandydatów w jednorazowych worktree, ale nigdy nie „dopracowuje” zwycięzcy. Jeśli żaden nie przechodzi, werdykt brzmi „żaden”.

Daj każdej próbie inny punkt startu (nieprzechodzący test, ostatnie commity, przepływ danych na granicy API); identyczne prompty na jednym modelu często dają niemal identyczne próby. Jeśli diffy nadal się zbiegają, zadanie jest mechaniczne: zostań przy jednej próbie.

Prompt do skopiowania: sędzia dla kandydatów best-of-N

You are the judge. Candidates A, B and C are three independent fixes for the bug described in BUG.md; you do not know who wrote them. Do not edit any candidate.
For each candidate: create a throwaway worktree with git worktree add, apply its diff with git apply, run the reproduction (npx vitest run tests/billing/proration.test.ts) and then the full billing suite (npx vitest run tests/billing), and record the exit codes. Remove the worktree afterwards.
Disqualify any candidate that fails either command or modifies a test file. Among the rest, prefer the smallest diff that fixes the root cause rather than the symptom, and explain why in two sentences.
Output: a table (candidate, repro exit code, suite exit code, files changed, disqualified yes/no and why), then "WINNER: <letter>" or "WINNER: none".

Dlaczego oddzielać autora od recenzenta?

Agent recenzujący własną pracę wnosi martwe pola, które spowodowały błąd. Recenzent ze świeżym kontekstem, narzędziami tylko do odczytu i stałym formatem raportu wyłapuje inne błędy; inny model albo dostawca odbiega jeszcze bardziej.

Dwa ograniczenia chronią przed pętlą bez końca. Recenzent zgłasza tylko uwagi poparte plikiem, linią i poleceniem pokazującym problem, więc styl nie blokuje. Autor dostaje najwyżej dwie rundy poprawek, potem otwarte uwagi trafiają do człowieka. Akceptacja nigdy nie zastępuje CI.

Prompt do skopiowania: recenzja adwersarialna przez osobnego agenta

Review the diff between this branch and main as an adversarial reviewer. You did not write this code and must not edit it. Look for: behaviour the tests do not cover, error paths that swallow failures, race conditions, and changes to tests that weaken an assertion. Report only findings you can support with a file and line plus a command or test that demonstrates the problem; run the command and include its output. Classify each as BLOCKER or NOTE. End with APPROVE if there are no blockers, otherwise REQUEST_CHANGES.

Jak każde narzędzie realizuje te wzorce?

Wszystkie trzy narzędzia realizują cztery wzorce innymi mechanizmami: skryptowane workflow w Claude Code, subagenci i próby w chmurze w Codex, subagenci i agenci w chmurze we własnych VM w Cursorze.

Cursor

Wzorzec	Mechanizm w Cursorze
Fan-out/fan-in	Subagenci; od wydania z 19.08.2026 „can now run on their own virtual machines”. Worktrees do torów, które uruchamiasz sam.
Pipeline	Automations uruchamiają agentów w chmurze według harmonogramu albo na zdarzenia (GitHub, Slack, Linear, webhooki i inne), więc każdy etap może reagować na pull request albo etykietę z poprzedniego etapu.
Best-of-N	Ten sam prompt na kilku Cloud Agents, każdy z innego punktu startu, oceniony promptem sędziego z tej strony; skryptuje to Cursor SDK.
Autor i recenzent	Bugbot recenzuje pull requesty jako osobny agent.

Wyzwalacze i API: agenci w chmurze i automatyzacje.

Claude Code

Wzorzec	Mechanizm w Claude Code 2.1.283
Fan-out/fan-in	Subagenci w .claude/agents/. /batch <instruction> dzieli zmianę na 5–30 jednostek, po jednym subagencie w worktree na każdą. Dynamiczne workflow (ultracode albo „use a workflow”) uruchamiają ze skryptu od kilkudziesięciu do kilkuset agentów.
Pipeline	Bloki phase() w skrypcie workflow ze schema JSON w każdym wywołaniu agent(); albo łańcuch wywołań claude -p --json-schema w CI.
Best-of-N	Workflow, który przepuszcza N kandydatów przez pipeline(), a potem wywołuje sędziego przez agent(); albo kilku subagentów z isolation: worktree.
Autor i recenzent	Subagent-recenzent tylko do odczytu; /code-review albo /code-review ultra w chmurze. Plugin Codex od OpenAI dodaje drugiego dostawcę przez /codex:adversarial-review.

Poza twoją maszyną claude --cloud "TASK" uruchamia sesję w chmurze na tor. Agent teams są eksperymentalne i domyślnie wyłączone (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1). Szczegóły: własne subagenty i dynamiczne workflow.

Codex

Wzorzec	Mechanizm w codex 0.157.1
Fan-out/fan-in	Subagenci (domyślnie włączeni), ograniczani przez [agents] max_threads. Dla torów kodu: codex --worktree na tor albo git worktree add i codex exec -C <dir> ze skryptu.
Pipeline	Łańcuch wywołań codex exec --output-schema FILE -o out.json, w którym każdy etap czyta plik poprzedniego.
Best-of-N	codex cloud exec --env ENV_ID --attempts 3 (cloud jest eksperymentalne), potem codex cloud diff i codex cloud apply TASK_ID --attempt N dla zwycięzcy.
Autor i recenzent	codex exec review --base main albo /review w świeżej sesji, albo własna rola reviewer tylko do odczytu w [agents].

~/.codex/config.toml

[agents]
max_threads = 4
default_subagent_reasoning_effort = "medium"

[agents.reviewer]
description = "Read-only reviewer. Reports findings with file and line; never edits files."
config_file = "./agents/reviewer.toml"

Opis nie czyni roli tylko do odczytu; robi to warstwa konfiguracji. Ścieżka config_file jest względna wobec config.toml:

~/.codex/agents/reviewer.toml

sandbox_mode = "read-only"
developer_instructions = "Review only. Report each finding with file, line and a command that shows it; never edit files."

Skrypty torów: wieloagentowe workflow w Codex. Próby best-of-N: środowiska chmurowe Codex.

Uruchom planistę, wykonawców i sędziego w Claude Code

Ten przykład łączy trzy role w fan-out jednostek implementacyjnych. Zacommituj pliki, żeby cały zespół miał tych samych wykonawców i sędziego.

1. Zaplanuj i zatwierdź. Uruchom prompt planisty z tej strony. Czytaj plan.json, nie kod: żadna ścieżka w dwóch jednostkach, polecenie akceptacyjne dla każdej. Najpierw scal szeregowo kroki bazowe.

2. Odgałęziaj wykonawców od swojej pracy, nie od main. Subagent z isolation: worktree odgałęzia się od domyślnej gałęzi i nie zobaczyłby kroków bazowych. Dodaj to do .claude/settings.json:

   .claude/settings.json

   {
     "worktree": {
       "baseRef": "head"
     }
   }

3. Zdefiniuj wykonawcę. Jedna jednostka na wywołanie, własne worktree i polecenie akceptacyjne jako warunek zatrzymania:

   .claude/agents/unit-implementer.md

   ---
   name: unit-implementer
   description: Implements exactly one unit from plan.json in an isolated worktree. Use for each parallel unit after the foundation has landed.
   tools: Read, Grep, Glob, Edit, Write, Bash
   isolation: worktree
   ---
   
   You implement one unit from plan.json. The unit id is in your task.
   Edit only files matching that unit's owned_paths. Never edit files under tests/ that existed before you started.
   When done, run the unit's acceptance commands and commit.
   Report: unit id, branch name, files changed, each acceptance command with its exit code.
   If an acceptance command fails after three attempts, stop and report the failure instead of widening your scope.

4. Zdefiniuj sędziego. Bez Edit i Write, więc nie może sam sprawić, że jego werdykt stanie się prawdą:

   .claude/agents/unit-judge.md

   ---
   name: unit-judge
   description: Verifies one finished unit against plan.json. Use after a unit-implementer reports done.
   tools: Read, Grep, Glob, Bash
   ---
   
   You verify one unit branch. You never edit files.
   1. Run git diff --name-only against the base and fail the unit if any path is outside its owned_paths.
   2. Fail the unit if any pre-existing test file changed.
   3. Run the unit's acceptance commands yourself and record exit codes.
   4. Only then read the diff for correctness issues the tests cannot catch.
   Output: PASS or FAIL, then each check with its evidence (command, exit code, file:line).

5. Fan-out. Poproś Claude: „Start one unit-implementer per unit in plan.json whose depends_on is satisfied, then run unit-judge on each finished branch.” Postęp śledź w /tasks.

6. Fan-in. Scalaj przechodzące gałęzie w kolejności zależności, uruchom raz polecenia integration i otwórz pull request. CI powtarza bramki; scalenie zatwierdza programista, który uruchomił przebieg.

Żeby orkiestracja była powtarzalna, zapisz ją jako dynamiczny workflow. Poniższy best-of-three uruchamia trzy propozycje tylko do odczytu z różnych punktów startu, potem sędziego, który testuje każdą w jednorazowym worktree.

.claude/workflows/best-of-three-fix.js

export const meta = {
  name: 'best-of-three-fix',
  description: 'Three independent fix proposals for one bug, judged against its reproduction test',
}

const proposal = {
  type: 'object',
  required: ['root_cause', 'diff', 'evidence'],
  properties: {
    root_cause: { type: 'string' },
    diff: { type: 'string' },
    evidence: { type: 'string' },
  },
}

phase('Propose')
const angles = [
  'start from the failing test and trace inward',
  'start from the recent commits that touched this module',
  'start from the data flow at the API boundary',
]
const candidates = await pipeline(angles, (angle) =>
  agent(
    `Bug: ${args.bug}. Reproduction: ${args.repro}. Investigate; ${angle}. ` +
      'Do not edit files. Return the root cause, a unified diff that fixes it, and command output that supports it.',
    { label: angle, schema: proposal },
  ),
)

phase('Judge')
return await agent(
  'You are the judge; do not edit the main checkout. For each candidate below, create a throwaway worktree, ' +
    `apply its diff, run ${args.repro} and the module's test suite, record exit codes, then remove the worktree. ` +
    'Disqualify any candidate that fails or changes a test file. Pick the smallest passing root-cause fix, or none.\n' +
    JSON.stringify(candidates.filter(Boolean)),
)

Uruchom go promptem w rodzaju Run /best-of-three-fix with bug "proration is off by one day at month end" and repro "npx vitest run tests/billing/proration.test.ts". Kandydaci nie niosą nazw agentów, więc sędzia porównuje ich w ciemno. Kolejność wyznacza tablica angles; żeby ją przetasować, przekaż ziarno albo permutację przez args (skrypty workflow nie mogą wywołać Math.random()).

Czy potrzebujesz zewnętrznego orkiestratora?

Wbudowane mechanizmy wystarczą przy jednym dostawcy. Orkiestrator dodaj dla mieszanej floty, interfejsu nadzoru albo przekazania pracy między narzędziami.

Narzędzie	Realizowany wzorzec	Instalacja	Gwiazdki GitHub (26.09.2026)
oh-my-claudecode	Zespoły fan-out w Claude Code (/team 3:executor "fix all TypeScript errors"); omc team uruchamia wykonawców Claude, Codex albo Gemini w tmux	/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode, potem /plugin install oh-my-claudecode	39 357
Plugin Codex dla Claude Code (OpenAI)	Autor i recenzent u różnych dostawców: /codex:review, /codex:adversarial-review	/plugin marketplace add openai/codex-plugin-cc, potem /plugin install codex@openai-codex	33 594
Gas Town	Planista i wykonawcy: instancja Claude Code w roli „Mayor” koordynuje agentów wykonawców przez rejestr Beads	brew install gastown (macOS)	18 195
Claude Squad	Fan-out pod twoim nadzorem: jedna sesja tmux i jedno worktree na agenta, z widokiem diffu	brew install claude-squad	8533
CLI Agent Orchestrator (AWS Labs)	Przekazanie od nadzorcy do wykonawców przez tmux, z małym interfejsem webowym	uv tool install git+https://github.com/awslabs/cli-agent-orchestrator.git@main --upgrade	1350

Pułapki przy instalacji orkiestratorów

Pakiet npm oh-my-claudecode to niezwiązany projekt innego autora; właściwe CLI to oh-my-claude-sisyphus. Pakiet npm claude-squad też jest niezwiązany; Claude Squad instaluj przez Homebrew albo jego install.sh. Vibe Kanban jest wygaszany i utrzymywany przez społeczność. Każdy orkiestrator uruchamia agentów z twoimi poświadczeniami, więc stosuj te same reguły uprawnień co dla samych agentów; zobacz uprawnienia i sandboxing.

Pełny katalog: uruchamianie wielu agentów naraz i przegląd narzędzi agentowych.

Jak zweryfikować wynik orkiestracji bez czytania każdego diffu?

Zbuduj łańcuch z bramek, które działają bez ciebie, tak by każdy etap produkował dowody:

1. Bramka toru. Polecenia akceptacyjne jednostki przechodzą na jej gałęzi, a sprawdzenie ścieżek dowodzi, że nie wyszła poza swój tor. Zwykły skrypt sprawdza ścieżki bez modelu, a potem uruchamia polecenie akceptacyjne:

   scripts/lane-gate.sh

   #!/usr/bin/env bash
   # Usage: scripts/lane-gate.sh BASE_BRANCH 'src/notifications/|src/api/preferences/' npx vitest run tests/notifications
   set -euo pipefail
   outside=$(git diff --name-only "$1"...HEAD | grep -Ev "^($2)" || true)
   if [ -n "$outside" ]; then
     echo "Lane violation, files outside the lane:"; echo "$outside"; exit 1
   fi
   "${@:3}"   # the unit's acceptance command

2. Sędzia. Osobny agent tylko do odczytu ponownie uruchamia rozstrzygające sprawdzenia; każda linia werdyktu niesie polecenie i kod wyjścia.

3. Bramka integracyjna. Po fan-in pełny zestaw testów, sprawdzenie typów i lint uruchamiają się raz na połączonej gałęzi i wyłapują interakcje, których żaden tor nie widział.

4. CI. Pull request przechodzi te same bramki na czystej maszynie. APPROVE od agenta nigdy go nie zastępuje.

5. Akceptacja człowieka. Programista, który uruchomił przebieg, zatwierdza plan przed fan-outem i scalenie po CI. Tech lead jest właścicielem .claude/agents/, .claude/workflows/ i ról [agents] w Codex przez CODEOWNERS: zmiana sędziego zmienia znaczenie słowa „zweryfikowane”.

Dołącz plan, werdykty i wyniki CI do pull requesta jako pakiet dowodów. Jak powstrzymać wykonawców przed osłabianiem testów, które ich oceniają, opisuje strona o ochronie wyroczni.

Ile kosztuje orkiestracja i jak ją ograniczyć?

Koszt rośnie z liczbą agentów, a nie z rozmiarem wyniku. Inżynier z DoltHub napisał, że godzina pracy z Gas Town „cost me about $100 in Claude tokens. That’s about 10X the cost of a normal Claude Code session per unit time” (Tim Sehn, blog DoltHub, 15.01.2026; jeden użytkownik i jedna konfiguracja, nie benchmark). Dokumentacja workflow Anthropic mówi, że pojedynczy przebieg workflow „can use meaningfully more tokens than working through the same task in conversation”.

Ograniczenia w każdym narzędziu:

Kontrola	Claude Code 2.1.283	Codex 0.157.1
Współbieżność	Domyślnie 20 działających subagentów na sesję (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS); domyślnie 16 równoległych agentów workflow (CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS, od 1 do 256)	[agents] max_threads
Rozmiar jednego przebiegu	1000 agentów na przebieg workflow; ostrzeżenie Large workflow powyżej 25 agentów albo prognozowanych 1,5 mln tokenów; workflowSizeGuideline (/config) ustala docelowy rozmiar — domyślnie medium (mniej niż 10 agentów), small w planie Pro	--attempts w codex cloud exec przyjmuje wartości od 1 do 4
Wydatki	claude -p --max-budget-usd dla przebiegów headless	[goals] max_goal_token_budget; tokeny zagnieżdżonych subagentów się do niego wliczają
Model dla roli	model i effort w pliku każdego subagenta	default_subagent_reasoning_effort, default_subagent_model

Cursor rozlicza agentów w chmurze według cennika API wybranego modelu (sprawdzone 28.08.2026); każdy przebieg uruchomiony skryptem przez @cursor/sdk anuluj po czasie (sterowanie agentami z kodu).

Każdą rolę zaczynaj na domyślnym modelu narzędzia, dostrajaj effort, zanim zmienisz model, i przenoś na tańszy model tylko mechanicznych wykonawców, gdy zaakceptowana praca nie spada (przegląd modeli). Zacznij od jednego katalogu i mierz koszt na zaakceptowaną zmianę.

Co się psuje przy orkiestracji wielu agentów?

Wykonawcy zderzają się na tym samym pliku

Konflikty w plikach barrel, rejestracji tras albo wspólnych typach oznaczają, że planista przypisał wspólny plik do dwóch jednostek. Przenieś go do kroku bazowego, scal i zrób rebase pozostałych torów; powtórce zapobiega bramka toru.

Wykonawcy implementują od nowa kod, który już jest na twojej gałęzi

Wykonawca Claude Code z isolation: worktree odgałęził się od domyślnej gałęzi, bo worktree.baseRef ma domyślnie wartość "fresh". Ustaw "baseRef": "head" albo sam utwórz worktree z właściwej gałęzi.

Sędzia zatwierdza wszystko

Kandydaci przechodzą przez sędziego, a potem oblewają CI: sędzia czyta zamiast uruchamiać sprawdzenia, dzieli kontekst z autorem albo może edytować. Odbierz sędziemu Edit i Write, wymagaj polecenia i kodu wyjścia w każdej linii werdyktu i porównaj pięć ostatnich werdyktów z CI; jeśli się nie zgadzają, błąd tkwi w prompcie sędziego.

Czysty raport ukrywa brak pokrycia

Wykonawców zatrzymano albo trafili na nienaprawialny błąd API (lub na limit zużycia w przebiegu claude -p albo w tle), a fan-in pominął ich puste wyniki (takie wywołanie agent() w workflow Claude Code zwraca null). Wymagaj listy „niezakończone” i uruchamiaj ponownie tylko te elementy.

Przebieg stoi albo autor i recenzent nie mogą się zbiec

Wykonawca w tle czekający na niezatwierdzone narzędzie stoi godzinami: zezwól z góry na polecenia testów, lintu i odczytu, a destrukcyjne zostaw zabronione. Para autor–recenzent w piątej rundzie potrzebuje reguły zatrzymania: dwie rundy poprawek, potem człowiek.

Dokąd dalej z orkiestracją wielu agentów

Dynamiczne workflow i ultracode Fan-out sterowany skryptem w Claude Code, z wbudowanymi fazami weryfikacji.

Wieloagentowe workflow w Codex Równoległe tory, bramki torów i kolejność scalania z worktree i zadaniami w chmurze Codex.

Sterowanie agentami z kodu Własny orkiestrator na Claude Agent SDK, Codex SDK albo Cursor SDK.

Poziom 5: prowadzisz fabrykę oprogramowania Gdzie orkiestracja pasuje w przejściu od czytania diffów do prowadzenia systemu.

Zobacz też harnessy wieloagentowe i porównanie agentów w tle i w chmurze.