Tryby agenta w Cursorze: kiedy planować, pytać, budować i debugować

Poziom 2 Poradnik Zaktualizowano 2026-10-12

Tryby agenta w Cursorze określają, co agent może zmienić w rozmowie. Plan Mode bada kod i przygotowuje plan do przeglądu przed zmianą plików; Agent mode edytuje pliki i uruchamia polecenia. Cursor ma też tryb Ask tylko do odczytu i tryb Debug do błędów wymagających dowodów z działania programu (sprawdzone 2026-10-12). Właściwy tryb zależy od tego, jak dobrze opisano zadanie.

Dotyczy: linii Cursor 3.x; aktualne wydanie na 2026-10-12 to Cursor 3.24 (2026-10-09, informacje o wydaniu Cursora). Dokumentacja i pomoc Cursora wymieniają cztery tryby: Agent, Ask, Plan i Debug. Ask jest tylko do odczytu, Plan edytuje pliki dopiero wtedy, gdy zatwierdzisz plan, a Debug służy do trudnych błędów, które wymagają dowodów z działania programu. Shift+Tab przełącza tryby po kolei, a każdy tryb zaczyna z nowym oknem kontekstu (sprawdzone 2026-10-12). Plan Mode i Agent mode zweryfikowaliśmy w dokumentacji Cursora po raz pierwszy 28 sierpnia 2026. Własny pakiet Cursora @cursor/sdk nadal udostępnia tylko dwa tryby rozmowy: agent i plan; odczytaliśmy to w wersji 1.0.32 w npm 26 września 2026, a w wersji 1.0.37 (2026-10-07, sprawdzone 2026-10-12) nic się nie zmieniło. Każdy opisany niżej workflow działa wyłącznie z Plan Mode i Agent mode.

Ta strona jest dla programistów, którzy codziennie pracują z agentem Cursora, oraz dla tech leadów, którzy chcą, żeby cały zespół korzystał z trybów tak samo. Sytuacja, którą rozwiązuje: zgłoszenie wymaga zmian w endpoincie API, trzech komponentach React, migracji i testach. Wpisujesz je w Agent mode i po 90 sekundach dostajesz diff w 14 plikach, z których kilka idzie w złą stronę. Model nie zawiódł. Kazano mu budować, zanim ktokolwiek, łącznie z tobą, znał kształt zmiany.

Co zyskujesz dzięki trybom Cursora

Tabelę decyzyjną, która przypisuje zadanie do trybu, mówi, co ten tryb może zmienić, i jaki dowód go kończy
Cztery prompty do skopiowania: plan z kryteriami akceptacji i listą plików, analiza wpływu tylko do odczytu, zawężony krok budowy oraz debugowanie zaczynające się od dowodów
Kontrolę zakresu planu: jedno polecenie git, które pokazuje każdy plik zmieniony przez agenta poza zatwierdzonym planem
Trzy wzorce przełączania trybów i sygnał, że czas przełączyć
Sposoby wyjścia z pięciu typowych błędów w doborze trybu

Który tryb Cursora pasuje do zadania?

Tryb to uprawnienie do zapisu, a nie osobowość agenta. Pytanie nie brzmi „który tryb jest najmądrzejszy?”, tylko „czy agent może już zmieniać pliki?”.

Twoja sytuacja	Tryb	Co agent może zmienić	Kiedy wyjść z trybu
Zmiana obejmuje kilka plików albo nie potrafisz teraz spisać jej kryteriów akceptacji	Plan Mode	Nic w kodzie; powstaje plan	Zatwierdziłeś plan, który wymienia każdy plik i test dla każdego kryterium
Musisz zrozumieć kod, prześledzić przepływ albo oszacować zmianę	Tryb Ask	Nic; tryb Ask jest tylko do odczytu	Potrafisz opisać zmianę jednym zdaniem i wymienić pliki
Wiesz dokładnie, co zbudować i jak to sprawdzić	Agent mode	Pliki i polecenia terminala w granicach twojego trybu uruchamiania	Polecenie weryfikujące przechodzi, a diff mieści się w planie
Błąd się odtwarza, ale lektura kodu go nie wyjaśnia	Debug Mode albo Agent mode ograniczony do testów i logowania	Tylko instrumentacja i testy, dopóki przyczyna nie jest udowodniona	Linia logu albo padający test potwierdza jedną hipotezę

Z tabeli wynikają dwie rzeczy. Po pierwsze, Agent mode jest właściwym domyślnym wyborem tylko dla zadań, które już są wyspecyfikowane. Po drugie, tryby planowania i badania dają artefakt, który da się sprawdzić (plan, listę dotkniętych plików), a jego przegląd kosztuje dużo mniej niż przegląd diffu w 14 plikach.

Zaplanuj zmianę w Plan Mode

Plan Mode, jak pisze Cursor, „creates detailed implementation plans before writing any code” („tworzy szczegółowe plany implementacji, zanim powstanie jakikolwiek kod”; strona Cursora o Plan Mode, zweryfikowana 28 sierpnia 2026). Agent czyta kod i zwraca plan, zanim cokolwiek powstanie; poniższy prompt dodatkowo każe mu najpierw zadać ci otwarte pytania.

Zacommituj albo odłóż (git stash) swoją pracę, żeby git diff pokazywał później tylko zmiany agenta.
Otwórz nowy czat i przełącz selektor trybów na Plan Mode. Wklej poniższy prompt z treścią zgłoszenia.
Odpowiedz na pytania agenta. Pytanie, na które nie znasz odpowiedzi, to luka w zgłoszeniu, więc zanieś je do właściciela zgłoszenia, zamiast pozwolić agentowi zgadywać.
Proś o poprawki, aż każde kryterium akceptacji będzie miało test, a każdy plik, którego dotknie zmiana, będzie na liście. Każ agentowi usunąć kroki, których nie chcesz.
Przed pierwszą edycją poproś agenta o zapisanie zatwierdzonego planu i listy plików w repozytorium, żeby kroki budowy i kontrola zakresu miały na co wskazywać. Zacommituj zapisany plan, a potem zapamiętaj bazę do porównań poleceniem PLAN_BASE=$(git rev-parse HEAD). Uruchom też echo "$PLAN_BASE" > docs/plans/rate-limit.base, żeby wartość przetrwała otwarcie nowego terminala.

Plan this change. Do not edit any file yet.

Ticket:
Add per-API-key rate limiting to the public REST API: 100 requests per minute
per key, a 429 response with a Retry-After header when exceeded, and no limit
on GET /health. Limits must survive a restart of one instance.

Before proposing anything, read how existing middleware is structured in
src/middleware/ and how configuration is loaded, and tell me which store the
counters should live in and why.

Your plan must contain:
1. Acceptance criteria, numbered, each one testable.
2. For each criterion, the test that proves it (file path and test name).
3. Numbered build steps. Each step leaves the test suite green and is small
   enough to review with `git diff --stat`.
4. A "## Files" section listing every file the change will create or modify,
   one path per line.
5. Out of scope: what this change deliberately does not do.
6. Open questions: ask me up to three before you finish.

When I approve, save the plan to docs/plans/rate-limit.md and the file list
alone to docs/plans/rate-limit.files, one path per line.

Przeglądaj plan, a nie kod, który jeszcze nie istnieje. Plan jest gotowy, gdy przechodzi cztery kontrole: każde kryterium ma nazwany test; lista plików nie zawiera niczego, czego się nie spodziewasz; lista „poza zakresem” mówi, co inaczej musiałbyś odrzucić w code review; żaden krok nie zależy od biblioteki ani funkcji pomocniczej, której agent nie pokazał ci w kodzie. Poprawka planu, który nie przechodzi którejś z kontroli, kosztuje teraz jedną wiadomość, a później revert.

Ten sam pomysł istnieje w pokrewnych narzędziach: Claude Code startuje w trybie planowania z --permission-mode plan (sprawdzone w claude --help, v2.1.283), a Codex ma /plan. Zobacz planowanie funkcji w Claude Code i planowanie w Codeksie. Wersję kontraktu planu niezależną od narzędzia opisuje etap budowy w cyklu życia.

Zbadaj kod bez edycji, zanim zaczniesz budować

Niektóre zadania nie są gotowe na plan, bo nie znasz jeszcze zasięgu zmiany. Zrób przebieg tylko do odczytu: w trybie Ask albo w Plan Mode z wyraźnym zakazem edycji. Chcesz dostać listę, którą da się sprawdzić, a nie esej.

Do not edit any file. This is analysis only.

I want to replace `name: string` on the User type with `firstName: string`
and `lastName: string`.

1. List every file that reads or writes `user.name`, the User type, or a
   serialized `name` field (API responses, database columns, fixtures,
   snapshots). Give the file path and line for each.
2. Mark each hit as: compile error (TypeScript catches it), runtime-only
   (the compiler will not catch it), or external contract (API consumers,
   stored data, analytics events).
3. List the tests that currently cover each runtime-only and external hit,
   and say which hits have no test at all.

End with the three riskiest hits and why.

To klasyfikacja z punktu 2 czyni odpowiedź użyteczną. Błędy kompilacji same się zweryfikują po zmianie typu; trafienia tylko w czasie działania i na kontraktach zewnętrznych to miejsca, gdzie wiarygodnie wyglądający diff psuje produkcję. Trafienia bez testu to testy, które piszesz jako pierwsze. Jeśli agent pomija kod, o którym wiesz, wskaż mu katalog wzmianką @ i sprawdź indeks bazy kodu; diagnozę opisuje zarządzanie kontekstem w Cursorze.

Buduj w Agent mode, jeden krok planu naraz

Agent mode czyta i edytuje pliki, uruchamia polecenia w terminalu i iteruje. Ta swoboda jest bezpieczna tylko wtedy, gdy agent może sam sprawdzić swoją pracę, więc zanim przekażesz mu plan, muszą być gotowe dwie rzeczy:

Polecenie weryfikujące, które jednym wywołaniem uruchamia typy, lint i testy, na przykład npm run verify.
Tryb uruchamiania, który pozwala agentowi uruchamiać to polecenie bez pytania, a polecenia destrukcyjne nadal zatrzymuje do twojej decyzji. Cursor grupuje to w run modes; niezbędna konfiguracja ustawia listę dozwolonych poleceń, Auto-review i hook, który ponownie uruchamia bramkę po zakończeniu pracy agenta.

Potem wykonuj plan po jednym kroku na prompt. Gdy krok kończy się zielonym poleceniem weryfikującym, zacommituj go sam. Commit to punkt powrotu niezależny od edytora.

Implement step 2 of @docs/plans/rate-limit.md and nothing else.

Rules:
- Only modify files listed in @docs/plans/rate-limit.files. If you need a
  file that is not listed, stop and tell me which file and why.
- Write the tests named for this step first and run them. Show me that they
  fail for the expected reason before you implement.
- Then implement until `npm run verify` passes. Do not change, skip, or
  delete existing tests to get there.
- Follow the middleware structure in @src/middleware/auth.ts.

When done, report: the tests you added, the output summary of
`npm run verify`, and `git diff --stat`.

Agent mode sprawdza się najlepiej przy zadaniu, które dotyka kilku plików i ma już kryteria akceptacji. Najgorzej, gdy zadanie wymaga reguł biznesowych, których nikt nie spisał, bo agent wypełnia lukę domysłem, który się kompiluje. Jeśli krok okaże się większy niż w planie, wróć do Plan Mode i go podziel, zamiast pozwalać Agent mode improwizować.

Debuguj na dowodach z działania, nie na domysłach

Przy błędzie, który się odtwarza, ale którego lektura kodu nie wyjaśnia (wyścig, problem z czasem, sporadyczny błąd 500), najszybsza droga to najpierw dowody, potem edycje. Cursor opisywał Debug Mode jako automatyzację tej pętli: tryb proponuje hipotezy, dodaje logi, prosi o odtworzenie błędu i naprawia na podstawie tego, co pokazały logi (opisu jego pętli nie sprawdzaliśmy ponownie; sam tryb jest wymieniony w dokumentacji Cursora, sprawdzone 2026-10-12). Poniższy prompt robi to samo w Agent mode w każdej wersji i sprawia, że instrumentację łatwo znaleźć i usunąć.

Checkout fails intermittently: about 1 in 5 attempts returns 500 with
"Cannot read properties of undefined (reading 'price')". It happens only when
the user has items in both the wishlist and the cart. Code:
@src/services/checkout.ts and @src/services/cart.ts.

Do not fix anything yet.
1. Give me up to three hypotheses, each with the observation that would
   rule it out.
2. Add log statements that distinguish them. Prefix every line you add with
   `// DEBUG-CHECKOUT` so I can remove them with one search.
3. Write a test that reproduces the failure, and tell me exactly how to
   reproduce it by hand as well.
Stop and wait for my logs.

Gdy wkleisz zebrane logi, poproś o jedną poprawkę wymierzoną w potwierdzoną przyczynę, z testem odtwarzającym jako dowodem. Pełny workflow, łącznie z git bisect run dla regresji i wyjściem z pętli „napraw–zepsuj–napraw”, opisuje debugowanie z AI w Cursorze.

Kiedy przełączać tryb w trakcie zadania?

Przełączaj, gdy zmienia się niepewność zadania, a nie gdy tracisz cierpliwość. Większość sesji obejmują trzy wzorce.

Wzorzec	Zastosowanie	Sygnał do przełączenia
Plan → Agent → (Plan)	Funkcja obejmująca kilka plików	Zatwierdziłeś plan, więc przejdź do Agent mode. Wróć do Plan Mode, gdy krok wymaga pliku spoza listy
Agent → Debug albo Agent z instrumentacją → Agent	Błąd, który przetrwał pierwszą próbę naprawy	Pierwsza poprawka nie zazieleniła testu odtwarzającego. Przestań edytować i zbieraj dowody
Tylko odczyt → Agent, powtarzane w małych pętlach	Małe zmiany w nieznanym kodzie	Potrafisz wskazać plik i jednozdaniowy zamiar. Wróć do odczytu, gdy nie potrafisz

Jedna zasada obowiązuje we wszystkich trzech: po przełączeniu powtórz cel i wskaż zapisany plan wzmianką @. Nie licz na to, że rozmowa pamięta plan sprzed 40 wiadomości: według pomocy Cursora każdy tryb zaczyna nowe okno kontekstu (sprawdzone 2026-10-12). Zapisany plik docs/plans/*.md jest taki sam w każdym trybie i w każdym czacie.

Gdy chcesz porównać dwa podejścia naraz, na przykład dwa plany albo plan i szybki prototyp, uruchom je jako osobnych agentów, zamiast przełączać się tam i z powrotem w jednym czacie. Okno Agents i Projects opisuje uruchamianie agentów obok siebie, a worktree trzymają ich edycje osobno. Jeśli sterujesz agentem Cursora z kodu, @cursor/sdk przyjmuje mode: "plan" albo mode: "agent" przy tworzeniu agenta; zobacz Cursor SDK.

Jak zweryfikować wynik bez czytania każdego diffu?

Każdy tryb kończy się dowodem i to dowód sprawdzasz ty oraz recenzent. Czytanie całego diffu staje się wyjątkiem zarezerwowanym dla plików, które dowody wskażą.

Tryb	Dowód, który go kończy	Kto zatwierdza
Plan Mode	Zapisany plan, w którym każde kryterium akceptacji ma test, plus lista plików	Programista, a przy zmianach wspólnych kontraktów także tech lead
Przebieg tylko do odczytu	Sklasyfikowana lista trafień ze ścieżkami, z oznaczonymi trafieniami bez testów	Programista
Agent mode	Testy napisane najpierw i pokazane jako padające, zielone `npm run verify`, diff w granicach listy plików	CI na pull requeście, potem recenzent
Debug	Linia logu albo test potwierdzający jedną hipotezę i ten sam test zielony po poprawce	Programista; recenzent sprawdza test, nie poprawkę

Kontrola zakresu jest z nich najtańsza i najczęściej pomijana. Uruchom ją w terminalu przed otwarciem pull requesta:

# Pliki zmienione od zacommitowania planu, których plan nie wymienia,
# łącznie z niezacommitowanymi edycjami i nowymi, nieśledzonymi plikami.
PLAN_BASE=${PLAN_BASE:-$(cat docs/plans/rate-limit.base)}
{ git diff --name-only "$PLAN_BASE"; git ls-files --others --exclude-standard; } \
  | sort -u | grep -v '^docs/plans/' | grep -vxF -f docs/plans/rate-limit.files

Puste wyjście oznacza, że agent został w granicach zatwierdzonego planu. Każda wypisana ścieżka to albo uzasadniona luka w planie, którą dopisujesz do listy plików i wyjaśniasz w pull requeście, albo dryf, który cofasz. W obu przypadkach czytasz uważnie ten plik i tylko ten. Sam pull request przegląda Bugbot, szukając błędów i problemów bezpieczeństwa, a CI ponownie uruchamia to samo polecenie weryfikujące, więc wynik nie zależy od raportu agenta. Szerszy argument za przeglądaniem dowodów zamiast diffów znajdziesz w tekście dowody zamiast kodu.

Co się psuje, gdy wybierzesz zły tryb w Cursorze?

Agent mode edytuje znacznie więcej plików, niż się spodziewałeś. Zadanie nie było wyspecyfikowane, więc agent wyspecyfikował je edycjami. Wyjście: odrzuć zmiany przez git restore ., potem przejrzyj nowe, nieśledzone pliki przez git clean -nd i usuń je przez git clean -fd (albo git reset --hard "$PLAN_BASE", jeśli zacommitowałeś już kroki, które teraz odrzucasz) lub cofnij się do checkpointu; potem zacznij nowy czat w Plan Mode i nie wracaj do Agent mode, dopóki plan nie ma listy plików. Nie naprawiaj złego diffu w 14 plikach kolejnymi promptami; dopracowany plan i świeże uruchomienie są prawie zawsze szybsze.

Plan jest mglisty. Plan odzwierciedla wejście: „dodaj uwierzytelnianie” daje kroki w rodzaju „zaimplementuj logikę uwierzytelniania”. Wyjście: wklej kryteria akceptacji ze zgłoszenia, wskaż pliki lub katalogi przez @ i wymagaj numerowanych sekcji z promptu planu powyżej. Jeśli agent nadal nie potrafi nazwać testów, kryteria akceptacji nie są jeszcze testowalne, a to problem zgłoszenia, nie trybu.

Przebieg tylko do odczytu edytuje plik. Czat był w Agent mode albo prompt zachęcał do poprawki. Wyjście: sprawdź git status, przywróć zmienione pliki, przed wysłaniem potwierdź tryb w selektorze i zaczynaj każdy prompt badawczy od „Do not edit any file”.

Instrumentacja z debugowania zostaje w kodzie. Logi dodane podczas polowania na błąd trafiają do pull requesta. Wyjście: wyszukaj prefiks, o który prosiłeś (DEBUG-CHECKOUT wyżej), usuń każde trafienie i dodaj regułę lintera albo grep w CI, który kończy build błędem, gdy znajdzie ten prefiks, żeby następne polowanie też nic nie przemyciło.

Agent zapomina plan po przełączeniu. Przełączenie trybu zaczyna nowe okno kontekstu (pomoc Cursora, sprawdzone 2026-10-12), a poza tym długie czaty gubią wczesny kontekst, więc agent odtwarza plan z pamięci z drobnymi różnicami. Wyjście: wskazuj @docs/plans/*.md w każdym prompcie budowy, zaczynaj nowy czat dla każdego kroku planu, gdy rozmowa jest długa, i pozwól kontroli zakresu złapać to, co się prześlizgnie.

Co dalej z trybami Cursora

Niezbędna konfiguracja Polecenie weryfikujące, tryb uruchamiania i hook ponownie uruchamiający bramkę, dzięki którym Agent mode może pracować bez nadzoru.

Pierwsza funkcja z agentem Cursora Pętla Plan, potem Agent od początku do końca, z testem dla każdego kryterium akceptacji.

Checkpointy i gałęzie Punkty powrotu na wypadek, gdy Agent mode pójdzie tam, czego nie planowałeś.

Strategie dla dużych baz kodu Dlaczego planowanie i przebiegi tylko do odczytu zyskują na znaczeniu wraz z rozmiarem repozytorium.

Własne reguły i szablony Zapisz format planu i zasady kroków budowy w regułach projektu, żeby każdy czat zaczynał od nich.

Debugowanie z AI w Cursorze Pełny workflow debugowania od dowodów, na którym opiera się wzorzec Debug z tej strony.