Okno Agents w Cursorze: równoległe agenty

Okno Agents (Agents Window) to widok Cursora z linii 3.x, w którym uruchamiasz i obserwujesz kilka agentów naraz, czy to przy osobnych zadaniach, czy przy podzadaniach jednego większego planu, który koordynujesz sam. Opłaca się tylko wtedy, gdy każdy agent ma osobny checkout (worktree albo cloud agenta), spisaną kartę zadania i dowody, które sprawdzi maszyna.

Ta strona jest dla programistów, którzy już pracują z agentem Cursora i chcą, żeby trzy albo cztery agenty działały jednocześnie. Jednego agenta puszczasz na błąd w rozliczeniach, drugiego na niestabilny test, trzeciego na stronę ustawień. Dwadzieścia minut później jeden czeka na odpowiedź, której nie zauważyłeś, dwa zmieniły ten sam helper, a trzeci melduje „gotowe” z diffem, na którego czytanie nie masz czasu. Okno ułatwiło uruchamianie agentów. Nadzór nad nimi musisz zaprojektować sam.

Co dostajesz z tego procesu

• Tabelę decyzyjną: kiedy uruchamiać agenty równolegle, kiedy jedno zadanie na kilka sposobów, a kiedy pasuje jedna skoordynowana praca.
• Kartę zadania i dwa prompty do skopiowania, dzięki którym każdy agent raportuje w tym samym siedmiopolowym bloku statusu, więc segregujesz po statusie, a nie po lekturze kodu.
• Trzy sprawdzenia w shellu, które rozstrzygają, czy gałąź agenta nadaje się do scalenia: zakres, nakładanie się z innymi gałęziami i bramki jakości.
• Kolejność scalania, która nie pozwala równoległym gałęziom psuć sobie nawzajem.
• Brief projektu z testem akceptacyjnym całości, dla planu, który zatwierdzasz w trybie Plan, a potem sam rozdzielasz między agenty.

Co dokumentuje Cursor, a na czym opiera się ta strona

Nie wymieniamy tu przycisków, menu ani skrótów klawiszowych okna Agents. Opieramy się na elementach, które opisywała dokumentacja Cursora sprawdzona 28 sierpnia 2026.

Funkcja	Co dokumentuje Cursor	Ostatnie sprawdzenie	Co zakłada ta strona
Okno Agents	Cursor opisuje je pod cursor.com/docs/agent/agents-window; ta strona nie opiera się na jej sformułowaniach	28 sierpnia 2026	Miejsce do uruchamiania, obserwowania i odpowiadania kilku agentom. Poniższy proces nie zależy od tego, w którym miejscu interfejsu uruchamiasz agenta
Worktrees	„Worktrees let Agent work in isolated Git checkouts.”	28 sierpnia 2026	Każdy lokalny agent dostaje własną gałąź i katalog
Cloud Agents	Cloud agents „run in isolated VMs in the cloud with full development environments instead of on your local machine.”	28 sierpnia 2026	Alternatywa, gdy zadanie potrzebuje pełnego środowiska albo potrwa dłużej, niż twój laptop będzie otwarty
Subagenty	„Subagents are specialized AI assistants that Cursor’s agent can delegate tasks to.”	28 sierpnia 2026	Jeden agent może podzielić własną pracę; ta strona dotyczy kilku agentów najwyższego poziomu, którymi kierujesz ty
Projects	Niezweryfikowane: w dokumentacji Cursora nie udało się potwierdzić, że funkcja o tej nazwie istnieje, ani jej działania, limitów czy dostępności w planach	niezweryfikowane (stan na 2 października 2026)	Nic. Poniższy brief i test akceptacyjny dotyczą skoordynowanej pracy, którą dzielisz sam

Jeśli twoja wersja wygląda inaczej, ufaj swojej wersji i trzymaj się procesu: izolacja, karta zadania, dowody i kolejność scalania nie zależą od tego, gdzie są przyciski.

Kiedy uruchamiać agenty Cursora równolegle?

Uruchamiaj agenty równolegle, gdy zadania są niezależne, a każde ma sprawdzenie, które wykona maszyna. Równoległość mnoży to, co musisz zweryfikować, więc granicą jest twoja zdolność sprawdzania wyników, a nie zdolność Cursora do startowania agentów.

Sytuacja	Jak ją uruchomić	Izolacja	Rozstrzygasz na podstawie
Trzy niezwiązane poprawki w różnych modułach	Agenty równoległe, jeden na zadanie	Osobny worktree dla każdego	Bramek i sprawdzenia zakresu każdej gałęzi
Jedno trudne zadanie z kilkoma sensownymi projektami rozwiązania	Ta sama karta zadania uruchomiona dwa lub trzy razy	Osobny worktree dla każdej próby	Tych samych testów dla każdej próby, potem mniejszego diffa
Funkcja lub migracja z wieloma krokami albo w kilku repozytoriach	Praca skoordynowana: jeden zatwierdzony plan, jeden agent na podzadanie	Osobny worktree lub cloud agent dla każdego podzadania	Testu akceptacyjnego całości po każdym podrzędnym pull requeście
Dwa zadania dotykające tych samych plików	Jeden agent, po kolei	Jeden worktree	To nie jest praca równoległa: nakładanie się gwarantuje konflikt przy scalaniu
Zadanie, którego nie opiszesz pięcioma kryteriami akceptacji	Jeszcze nie równolegle	Brak	Najpierw zaplanuj je w trybie Plan

Zacznij od dwóch agentów, nie od pięciu. Raport Faros AI AI Engineering Report 2026 (kwiecień 2026, telemetria od 22 000 programistów u klientów Faros) pokazał wzrost mediany czasu w review o 441,5% i o 31,3% więcej pull requestów scalanych bez żadnego review. Więcej agentów zasila tę samą kolejkę. Zwiększaj ich liczbę wtedy, gdy nadążają twoje sprawdzenia, a nie twoja lektura.

Uruchom równoległe agenty z okna Agents

1. Zanim rozdzielisz pracę, doprowadź gałąź bazową do zielonego stanu. Każdy agent dziedziczy stan swojej bazy. Najpierw uruchom bramki w terminalu:

   git switch main && git pull --ff-only
   npm run typecheck && npm run lint && npm test

   Czerwona baza oznacza, że każdy agent zaczyna od błędu, który nie jest jego zadaniem, a każda jego „poprawka” koliduje z pozostałymi.

2. Trzymaj konfigurację środowiska w repozytorium, nie w głowie. Świeży worktree nie ma node_modules, .env.local ani lokalnej bazy danych. Zacommituj jeden skrypt, który każdy agent uruchamia na początku, na przykład scripts/agent-setup.sh: instaluje zależności, kopiuje .env.example do .env.local z wartościami wyłącznie lokalnymi i uruchamia jednorazowe usługi. Nigdy nie kopiuj produkcyjnych danych dostępowych do worktree ani do cloud agenta.

3. Napisz jedną kartę zadania na agenta. Karta jest umową z agentem i twoją listą kontrolną przy review. Ogranicz ją do celu, plików, które agent może zmieniać, kryteriów akceptacji i polecenia, które je dowodzi. Jak pisać kryteria, opisuje strona o kryteriach akceptacji, których agent nie odczyta źle.

4. Uruchom każdego agenta z osobnym, izolowanym checkoutem, czyli w worktree albo w cloud agencie, i wklej jego kartę zadania razem z promptem startowym poniżej. Nazwij każdą lokalną gałąź agent/<zadanie>, na przykład agent/eu-reverse-charge; sprawdzenie nakładania się poniżej szuka gałęzi po tym prefiksie, więc jeśli Cursor albo twoje cloud agenty nazywają gałęzie inaczej, zmień prefiks w sprawdzeniu. Miejsce w interfejsie, z którego go uruchamiasz, nie zmienia procesu. Wybierz cloud agenta, gdy zadanie potrzebuje usług, których twój laptop nie uruchamia, albo gdy potrwa dłużej niż twoja sesja; środowiska i Builds opisuje strona o cloud agentach i Automations w Cursorze.

5. Segreguj w stałym rytmie, a nie przy każdym powiadomieniu. Co 20–30 minut poproś każdego agenta o blok statusu drugim promptem i posortuj je: zablokowany (odpowiedz teraz), pracuje (zostaw), gotowy (uruchom sprawdzenia przed scaleniem), utknął (zatrzymaj i przepisz kartę).

6. Scalaj po jednej gałęzi, ze sprawdzeniami z następnej sekcji, a po każdym scaleniu rebase’uj pozostałe.

Prompt do skopiowania: start agenta z karty zadania

You are one of several agents working on this repository at the same time.
Work only on the task card below, in this worktree and branch.

TASK CARD
Goal: Invoices for EU customers show the reverse-charge note when the buyer has a valid VAT ID.
Files you may change: src/billing/invoice/**, tests/billing/invoice/**
Files you must not change: anything else, including shared utils, config, lockfiles and CI.
Acceptance criteria:
1. A buyer with a valid EU VAT ID outside the seller's country gets the note "Reverse charge: VAT to be accounted for by the recipient".
2. A buyer in the seller's own country never gets the note.
3. A buyer without a VAT ID never gets the note.
4. Existing invoice tests still pass unchanged.
Proof command: npm test -- tests/billing/invoice && npm run typecheck

Rules:
- Run scripts/agent-setup.sh before anything else.
- Write the test for criterion 1 first and show it fails; tests for criteria 2-3 are guards and must pass both before and after your change.
- If you need to change a file outside your allowed paths, stop and ask. Do not work around it.
- Do not edit, skip or weaken an existing test to make it pass.
- When done, commit on this branch and print this status block, one field per line: STATUS (BLOCKED, RUNNING, READY or STUCK), BLOCKED_ON (your question, or "none"), CRITERIA (each criterion with PASS, FAIL or NOT_RUN and the test that proves it), PROOF (the proof command and its final 10 lines of output), FILES (output of `git diff --stat main...HEAD`), OUTSIDE_SCOPE (any file changed outside the allowed paths, or "none"), NEXT (the one next step, or "none").

Linia z dozwolonymi ścieżkami robi dwie rzeczy. Trzyma agenty z dala od cudzych plików i daje ci sprawdzenie, które uruchomisz bez czytania diffa.

Prompt do skopiowania: blok statusu do segregacji

Stop after your current step and report in exactly this format, nothing else:

STATUS: one of BLOCKED | RUNNING | READY | STUCK
BLOCKED_ON: the question you need answered, or "none"
CRITERIA: each acceptance criterion with PASS, FAIL or NOT_RUN and the test that proves it
PROOF: the command you ran last and its final 10 lines of output
FILES: output of `git diff --stat main...HEAD`
OUTSIDE_SCOPE: any file you changed outside the allowed paths, or "none"
NEXT: the one next step you will take, or "none"

If you have tried the same fix three times without the proof command passing, report STUCK and explain what you tried.

Skąd wiesz, że gałąź równoległego agenta nadaje się do scalenia?

„READY” to deklaracja agenta. Poniższe sprawdzenia zamieniają ją w dowód, któremu możesz ufać bez czytania każdej zmienionej linii. Uruchamiaj je w terminalu z głównego checkoutu.

1. Agent nie wyszedł poza zakres. Dozwolone ścieżki z karty zadania stają się filtrem; każda wypisana linia to plik, którego agent nie miał prawa dotknąć:

git diff --name-only main...agent/eu-reverse-charge \
  | grep -vE '^(src/billing/invoice/|tests/billing/invoice/)'

2. Żadne dwie gałęzie nie dotykają tego samego pliku. Uruchom to dla wszystkich gałęzi agentów, lokalnych i wypchniętych, zanim scalisz pierwszą. Polecenie najpierw pobiera zmiany, więc obejmuje też gałęzie, które cloud agenty wypchnęły do origin:

git fetch --prune origin
for b in $(git for-each-ref --format='%(refname:short)' refs/heads/agent/ refs/remotes/origin/agent/); do
  git diff --name-only main..."$b" | sed "s|^|${b#origin/} |"
done | sort -u | sort -k2 | awk '{ if ($2 == last) print prev "\n" $0; last=$2; prev=$0 }' | uniq

Każda wypisana linia to plik zmieniony w dwóch gałęziach. Scal jedną z nich, zrób rebase drugiej i ponownie uruchom jej bramki albo oddaj drugie zadanie jednemu agentowi.

3. Bramki przechodzą na gałęzi, a nie w podsumowaniu agenta. Wyciągnij gałąź do tymczasowego worktree w trybie detached i uruchom te same polecenia co CI: sprawdzenie typów, lint, testy. Potem potwierdź, że nowy test dla kryterium 1 potrafi się wywrócić: cofnij pliki implementacji i uruchom testy jeszcze raz. Nie przełączaj się na gałąź przez git switch: Git odmawia checkoutu gałęzi, którą trzyma już worktree agenta, a praca w tamtym worktree zmieniałaby pliki pod działającym agentem.

git worktree add --detach ../verify-eu agent/eu-reverse-charge && cd ../verify-eu
scripts/agent-setup.sh
npm run typecheck && npm run lint && npm test
git restore --source=main --staged --worktree -- src/billing/invoice/
npm test -- tests/billing/invoice   # the criterion 1 test must fail now
git restore --source=HEAD --staged --worktree -- src/billing/invoice/
cd - && git worktree remove ../verify-eu

Nowy test dla dodanego zachowania musi się wywrócić bez implementacji; testy strażnicze dla tego, co ma się nie zmienić (tu kryteria 2–4), powinny przechodzić także na main. Inne sposoby, w jakie agenty osłabiają testy, opisuje strona o ochronie wyroczni testowej. Wypchnij gałąź, otwórz pull request i pozwól, żeby uruchomiły się na nim CI i agent do review, na przykład Bugbot. Akceptujesz dowody: kryteria przypisane do nazwanych testów, czyste sprawdzenie zakresu i zielone CI. Strona o pakiecie dowodów zamienia to w szablon pull requesta.

Scalaj równoległe gałęzie w bezpiecznej kolejności

Najpierw scal gałąź o najmniejszym zakresie i najmocniejszych testach. Każde scalenie zmienia main, więc każda pozostała gałąź była testowana na bazie, której już nie ma.

1. Scal pierwszą gotową gałąź przez jej pull request, z zielonym CI.
2. Zrób rebase każdej pozostałej gałęzi agenta na nowy main albo poproś o to agenta: „Rebase this branch on main, rerun the proof command and print the status block.”
3. Ponownie uruchom sprawdzenie zakresu i nakładania się. Rebase może ujawnić konflikty, które agent rozwiązał inaczej, niż zamierzałeś.
4. Powtarzaj, aż kolejka się opróżni. Usuń scalone worktree poleceniem git worktree remove <path> i posprzątaj gałęzie, żeby następne rozdzielenie pracy zaczynało się od czystego stanu.

Kiedy koordynować jedną pracę zamiast uruchamiać osobne agenty?

Użyj pracy skoordynowanej, gdy chodzi o jeden rezultat wymagający kilku kroków albo kilku repozytoriów, na przykład funkcję od API po UI albo migrację frameworka. Osobne agenty pasują do osobnych rezultatów. Różnica polega na tym, kto dzieli pracę: przy osobnych agentach piszesz każdą kartę sam; w pracy skoordynowanej plan rozbija jeden rezultat na podzadania. Nie udało się zweryfikować funkcji Cursora o nazwie Projects, która robiłaby to za ciebie (stan na 2 października 2026), dlatego opisujemy pracę, którą koordynujesz sam w trybie Plan i oknie Agents.

Oddanie podziału pracy agentowi przesuwa twoją pracę, a nie ją usuwa. Teraz weryfikujesz dwie rzeczy: czy plan pokrywa rezultat i czy każdy podrzędny pull request niesie swoje dowody. Jeśli twoja wersja oferuje jakąkolwiek funkcję, która dzieli pracę za ciebie, zanim jej zaufasz, potwierdź w dokumentacji Cursora trzy rzeczy: gdzie działają podzadania, czy możesz zatwierdzić plan przed startem pracy i co dzieje się z podzadaniem, które się nie powiedzie. Potem zapisz rezultat jako brief z testem, który musi przejść cała praca.

Prompt do skopiowania: brief projektu dla koordynatora

PROJECT BRIEF: Replace moment.js with date-fns across the web app and the API.

Outcome: no import of moment remains in apps/web or apps/api, and every date shown to users is unchanged.
Repositories and paths in scope: apps/web/src/**, apps/api/src/**, packages/date-utils/**
Out of scope: database migrations, CI config, anything under infra/.

Acceptance test for the whole project (run it after every merged child):
1. `grep -rE --exclude-dir=node_modules "(from|import|require\(|import\()[[:space:]]*['\"]moment([/-][^'\"]*)?['\"]" apps/ packages/` prints nothing (this also catches `import 'moment'`, `moment/locale/*` and `moment-timezone`).
2. `grep -rE --include=package.json --exclude-dir=node_modules '"moment(-[a-z]+)?"[[:space:]]*:' apps/ packages/ package.json` prints nothing, so no package.json lists moment or moment-timezone as a dependency.
3. `npm test` passes in apps/web and apps/api.
4. The snapshot suite `npm run test:dates` shows zero changed snapshots.

How to split the work:
- First, a plan: list child tasks, each with its own allowed paths, acceptance criteria and proof command. No two child tasks may share a file. Show me the plan and wait for my approval before starting any child.
- Start packages/date-utils first; web and api tasks depend on it.
- Each child opens its own pull request with the status block: STATUS, BLOCKED_ON, CRITERIA, PROOF (final 10 lines), FILES, OUTSIDE_SCOPE, NEXT.
- Report after each merged child: the acceptance test output and which child tasks remain.

Najwięcej ratuje bramka akceptacji przed pierwszym podzadaniem. Plan, w którym dwa podzadania edytują ten sam plik, łatwo poprawić przed startem, a drogo po nim.

Uruchom ten brief w trybie Plan, zaakceptuj plan i uruchom kartę każdego podzadania jako osobnego agenta z okna Agents. Koordynatorem jesteś wtedy ty, a test akceptacyjny zostaje ten sam. Pracę w osobnych repozytoriach i kontrakty między nimi opisuje strona o pracy z wieloma repozytoriami w Cursorze.

Co się psuje, gdy uruchamiasz kilka agentów Cursora naraz?

Agent godzinę czeka zablokowany na pytaniu. Równoległe agenty zawodzą po cichu, gdy przestajesz patrzeć. Naprawa: segreguj w stałym rytmie z kroku 5, a odpowiedzi na typowe pytania (które polecenie testowe, która fikstura) wpisz do karty zadania albo do reguł projektu, żeby następny agent już nie pytał.

Dwa agenty edytują ten sam wspólny helper. Sprawdzenie nakładania się wypisuje plik w dwóch gałęziach. Naprawa: scal gałąź, do której należy helper, zrób rebase drugiej i zawęź dozwolone ścieżki w obu kartach. Następnym razem wspólną zmianę daj najpierw jednemu agentowi i rozdziel pracę dopiero po jej scaleniu.

Worktree się nie buduje. Brakuje zależności, brakuje .env.local albo port jest zajęty przez twój główny checkout. Naprawa: popraw scripts/agent-setup.sh raz, w repozytorium, zamiast łatać każdy worktree ręcznie. Daj każdemu worktree własny port i własną nazwę bazy danych.

Agent melduje READY, a test zmieniono tak, żeby przechodził. Naprawa: uruchom sprawdzenie zakresu osobno dla tests/ i obejrzyj każdą zmienioną asercję; dopisz do karty „Do not edit, skip or weaken an existing test”, jeśli tego brakowało. Odrzuć gałąź, zamiast naprawiać ją na miejscu.

Wszystkie próby best-of-N wyglądają sensownie. Trzy przechodzące diffy to trzy rzeczy do porównania. Naprawa: wybieraj po dowodach, nie po lekturze. Zostaw próbę z najmocniejszymi testami (testy nowego zachowania wywracają się bez implementacji) i najmniejszym diffem, a resztę usuń, zanim się rozjedzie.

Koszty rosną szybciej niż scalona praca. Każdy agent zużywa limit modelu, dopóki działa, a agent, który utknął, zużywa go bez postępu. Naprawa: zatrzymaj każdego agenta, który dwa razy zgłosi STUCK, przepisz jego kartę i ogranicz liczbę działających agentów do liczby gałęzi, które zdołasz zweryfikować w ciągu dnia. Limity użycia opisuje strona o zarządzaniu tokenami w Cursorze.

Cloud agent dostaje sekret, którego nie powinien mieć. Naprawa: dawaj środowiskom w chmurze tylko testowe dane dostępowe ograniczone do sandboksa, rotuj wszystko, co trafiło tam przez pomyłkę, i przejrzyj stronę o uprawnieniach i sandboksingu agentów.

Jak Claude Code i Codex uruchamiają równoległe agenty

Ta strona dotyczy Cursora. Ten sam proces (osobny checkout, karta zadania, blok statusu, sprawdzenie zakresu, kolejność scalania) przenosi się bez zmian na inne narzędzia. Claude Code ma agent view (claude agents, research preview w v2.1.283) i --worktree; zobacz Agent view w Claude Code. Codex ma codex agents do przeglądania sesji agentów i --worktree do zarządzanego worktree Gita (codex-cli 0.157.1); zobacz przepływy wieloagentowe w Codexie.

Dokąd dalej z równoległymi agentami w Cursorze

Checkpointy i gałęzie Cofanie zmian, mikrogałęzie i worktree dla jednego agenta.

Cloud agents i Automations Agenty na maszynach w chmurze, według harmonogramu lub zdarzeń.

Wzorce orkiestracji Fan-out, potoki i koordynatorzy w różnych narzędziach.

Dowody zamiast diffów Jak akceptować pracę agenta bez czytania każdego diffa.