Kiedy używać trybu agenta vs trybu zapytań

Tryb agenta kontra tryb zapytań to wybór między dwiema postawami wobec narzędzia AI — analizą tylko do odczytu i wykonywaniem z prawem zapisu — a nad nimi stoi trzeci, nienadzorowany poziom. Cursor nazywa pierwsze dwa Ask i Agent, Claude Code plan mode i normal mode, Codex sandboxami read-only i workspace-write. Zły wybór marnuje kontekst albo wypuszcza nieprzejrzane edycje.

Zadajesz szybkie pytanie o swój handler płatności w Express — „dlaczego processPayment czasem obciąża dwa razy?” — a trzydzieści sekund później agent po cichu przepisał cztery pliki, zmienił logikę idempotencji Stripe i wyedytował migrację, której nie chciałeś ruszać. Teraz przeglądasz diff, o który nie prosiłeś, na ścieżce krytycznej i pod presją czasu.

Ten sam błąd kosztuje też w drugą stronę. Otwierasz narzędzie w domyślnym trybie agenta, żeby zapytać „jak działa tu przetwarzanie płatności?”, a ono zaczyna czytać pliki i puszczać grepy, spalając 40 000 tokenów kontekstu, zanim wyda trzyzdaniową odpowiedź, którą mogłeś dostać za ułamek tego.

Oba przypadki to problem z trybem, a nie z modelem. Każde nowoczesne narzędzie do kodowania wystawia to samo spektrum — eksploracja tylko do odczytu, kierowane wykonywanie, nienadzorowana autonomia — a wybranie na nim złego punktu to najszybszy sposób, by zamienić pięciominutowe pytanie w godzinę sprzątania.

Co daje dyscyplina trybów

• Przejrzyste mapowanie trzech trybów w Cursor, Claude Code i Codeksie
• Konkretny przełącznik, flagę albo politykę zatwierdzania dla każdego z nich
• Dwufazowy przepływ pracy (eksploracja tylko do odczytu, potem wykonanie), który powstrzymuje agenta przed edytowaniem plików, na które się nie umawiałeś
• Gotowy prompt eksploracyjny, który produkuje plan refaktoryzacji do przejrzenia, nie zmieniając ani jednej linii
• Prompt wykonawczy ograniczający agenta do jednego kroku, z twardym zatrzymaniem, zanim ruszy dalej
• Kryteria decyzyjne mówiące, kiedy autonomia jest bezpieczna, i tryby awarii, gdy nie jest

Spektrum trybów w trzech narzędziach

Dwie postawy robią większość roboty. Tylko do odczytu to eksplorator: agent przeszukuje bazę kodu, czyta pliki, śledzi miejsca wywołań i odpowiada na pytania, ale nie może niczego edytować ani uruchamiać komend zmieniających stan. Używaj go, żeby zbudować trafne, wspólne zrozumienie przed jakąkolwiek zmianą kodu. Z prawem zapisu to wykonawca: agent edytuje pliki, uruchamia komendy i naprawia błędy, realizując plan, który już zatwierdziłeś. Nad nimi stoi trzeci poziom — wykonanie nienadzorowane — i zasługuje na osobną decyzję, a nie na traktowanie go jak „tryb agenta z mniejszą liczbą pytań”.

Możliwość	Cursor	Claude Code	Codex
Analiza tylko do odczytu	Ask mode (lub Plan mode, by naszkicować plan)	Plan Mode (Shift+Tab)	--sandbox read-only -c approval_policy=on-request
Kierowane wykonywanie	Agent mode (domyślny)	Normal Mode (domyślny)	--sandbox workspace-write -c approval_policy=on-request
Nienadzorowane wykonanie w sandboxie	Auto-Run “Run Everything” / Cloud Agent	--dangerously-skip-permissions / Sandbox	--sandbox workspace-write -c approval_policy=never (tylko zaufane przebiegi)

Tryb analizy tylko do odczytu

Używaj go, gdy chcesz zrozumieć kod bez modyfikowania go. Agent czyta pliki i odpowiada na pytania, ale nie może wprowadzać zmian.

Cursor

Wybierz Ask w rozwijanym menu trybów na dole pola czatu. Agent przeanalizuje kod i odpowie na pytania, nie wprowadzając zmian. Oznacz @ pliki, na których ci zależy (@src/routes/payments.ts), żeby startował z precyzyjnego kontekstu. Do badań, które mają skończyć się spisanym planem, a nie edycjami, siostrzanym wyborem jest Plan mode:

How does the authentication flow work? Trace the request from
the login endpoint through middleware to the session store.
Show me the key files and functions involved.

Tryb Ask jest oszczędny tokenowo, bo agent skupia się na odpowiedzi na twoje pytanie, zamiast eksplorować szeroko. Do wyszukiwania używa indeksu bazy kodu, a nie czytania plików jeden po drugim.

Claude Code

Przełącz Plan Mode przez Shift+Tab — cykl prowadzi przez Normal, Auto-Accept i Plan, a na dole terminala pojawia się ⏸ plan mode on. Możesz też wystartować od razu w nim, przez claude --permission-mode plan. Claude czyta pliki i bada bazę kodu, ale nie może zapisać żadnego pliku ani uruchomić destrukcyjnych komend:

Explain the authentication flow. Start from the login endpoint
and trace through middleware, session management, and token
refresh. Identify the key files and any potential issues.

Plan Mode jest szczególnie użyteczny przy przeglądach kodu i analizie architektury. Claude może przeczytać dowolnie wiele plików bez ryzyka przypadkowej modyfikacji.

Codex

Użyj sandboxa read-only, żeby Codex mógł przeglądać i rozumować, ale nie edytować plików. Trzymaj approval_policy=on-request jawnie: polityka zatwierdzania steruje monitami o eskalację, a sandbox egzekwuje granicę systemu plików:

codex --sandbox read-only -c approval_policy=on-request \
  "Explain the authentication flow in this codebase. Trace the request \
   lifecycle from login to session creation. Identify key files and \
   potential security concerns."

W rozszerzeniu Codex do IDE wybierz przepływ planowania tylko do odczytu, gdy chcesz analizy bez edycji.

Najlepsze zastosowania: przegląd kodu, analiza architektury, wdrażanie się w nową bazę kodu, zrozumienie nieznanego kodu, badanie błędów przed ich naprawianiem.

Tryb kierowanego wykonywania

Domyślny tryb we wszystkich trzech narzędziach. Agent czyta pliki, wprowadza zmiany i uruchamia komendy, ale w kluczowych momentach pyta o zgodę. To koń roboczy większości zadań programistycznych.

Cursor

Agent mode jest domyślny. Cursor czyta pliki, proponuje edycje i uruchamia komendy terminala, zapisując punkt kontrolny przed każdym zestawem edycji, więc zły krok to cofnięcie, a nie naprawa. Przeglądaj w widoku diff i akceptuj lub odrzucaj fragment po fragmencie — akceptowanie hurtem to sposób, w jaki wchodzą edycje spoza planu:

Implement the rate limiter middleware following the pattern in
@src/middleware/auth.ts. Write tests in @src/middleware/__tests__/.
Run the tests after implementation.

W ustawieniach Cursora skonfiguruj, z których narzędzi agent może korzystać. Możesz pozwolić na edycje plików, ale wymagać zgody na komendy terminala — albo odwrotnie.

Claude Code

Normal Mode jest domyślny: Claude prosi o pozwolenie na zapis plików i potencjalnie destrukcyjne komendy, ale czyta pliki swobodnie. Shift+Tab przełącza w accept-edits (⏵⏵ accept edits on), który automatycznie stosuje edycje plików, wciąż pytając o komendy powłoki:

Implement the rate limiter middleware following the pattern in
src/middleware/auth.ts. Write tests and run them. Fix any
failures before finishing.

Dostrój poziom uprawnień przez /permissions. Dopuszczenie konkretnych bezpiecznych komend (jak npm test) ogranicza przerwania, zachowując zatwierdzanie operacji destrukcyjnych.

Codex

Uruchamiaj z jawnie skonfigurowanymi workspace-write i on-request. Rutynowe odczyty, edycje i komendy dozwolone przez sandbox workspace przechodzą bez monitu; Codex pyta, gdy musi przekroczyć granicę sandboxa:

codex --sandbox workspace-write -c approval_policy=on-request \
  "Implement the rate limiter middleware following existing patterns. \
   Write tests and run them. Fix any failures."

Dla ściślejszej kontroli systemu plików zostaw approval_policy=on-request i przestaw sandbox z powrotem na read-only. danger-full-access rezerwuj dla jednorazowych, jawnie zaufanych środowisk. W rozszerzeniu do IDE Codex pokazuje diffy inline dla każdej proponowanej zmiany — akceptuj lub odrzucaj poszczególne fragmenty, a nie całe pliki.

Najlepsze zastosowania: implementacja funkcjonalności, naprawianie błędów, refaktoryzacja, pisanie testów, większość codziennej pracy programistycznej.

Tryb pełnej autonomii

Agent działa bez przerwań. Potężne przy dobrze zdefiniowanych zadaniach niskiego ryzyka; niebezpieczne przy czymkolwiek, co dotyka wrażliwego kodu.

Cursor

Auto-Run ustawione na Run Everything (nieformalnie nazywane trybem YOLO) automatycznie akceptuje wszystkie zmiany i komendy. Cloud Agent uruchamia zadania asynchronicznie w izolowanym środowisku chmurowym:

Fix all ESLint warnings in src/components/. Run npm run lint
after each fix to verify. Commit each fix separately with a
descriptive message.

Cloud Agent to bezpieczniejsza opcja do pracy autonomicznej: działa na klonie twojego repozytorium, więc lokalny katalog roboczy zostaje nietknięty, dopóki nie przejrzysz i nie scalisz zmian. Własne wskazówki dotyczące bezpieczeństwa Cursora mówią, by nigdy nie używać Run Everything, ponieważ pomija on wszystkie zabezpieczenia.

Claude Code

Użyj --dangerously-skip-permissions do operacji wsadowych albo włącz tryb sandbox (/sandbox) dla bezpieczniejszej autonomii:

claude --dangerously-skip-permissions -p \
  "Fix all ESLint warnings in src/components/. Commit each fix separately."

Tryb sandbox jest lepszy, bo daje autonomię w zdefiniowanych granicach (ograniczenia systemu plików i sieci), zamiast omijać wszystkie zabezpieczenia.

Codex

Przy zaufanym zadaniu bez nadzoru approval_policy=never wycisza monity, ale nie poszerza dostępu sandboxa. Zawsze trzymaj sandbox jawnie; jeśli Codex musi przekroczyć swoją granicę, taka akcja kończy się błędem, zamiast prosić o zgodę:

codex exec --sandbox workspace-write -c approval_policy=never \
  "Fix all ESLint warnings in src/components/. Commit each fix \
   with a descriptive message."

Używaj tego wyłącznie w zaufanej tożsamości CI albo w jednorazowym checkoucie. Zadania Codex Cloud działają w osobnym hostowanym środowisku, więc lokalne pliki pozostają nietknięte, dopóki nie zastosujesz albo nie scalisz wynikowego diffa.

Najlepsze zastosowania: poprawki lintingu, formatowanie, masowa zmiana nazw, generowanie dokumentacji, szablony testów, skrypty migracji wielu plików.

Pełna autonomia wymaga silnych zabezpieczeń

Nigdy nie używaj trybu pełnej autonomii na kodzie związanym z bezpieczeństwem, migracjach baz danych ani zmianach infrastrukturalnych. Nawet z izolacją sandbox agent może popełniać subtelne błędy, które przechodzą testy, ale psują rzeczy na produkcji. Zarezerwuj tryb autonomiczny dla mechanicznych zadań niskiego ryzyka, gdzie definicja „poprawności” jest jasna i weryfikowalna.

Najpierw eksploracja, potem jeden krok wykonania

Mechanika różni się między narzędziami; dyscyplina nie. Zacznij w trybie tylko do odczytu, żeby zrozumieć i zaplanować, przejrzyj ten plan jako odrębny artefakt i dopiero wtedy przełącz się na wykonanie — po jednym ograniczonym kroku naraz. Cały wzorzec niosą trzy prompty.

Pierwszy uruchamiasz w trybie tylko do odczytu; wymusza plan bez ani jednej edycji:

Gotowy prompt: zmapuj i zaplanuj refaktoryzację, nie zmieniając niczego

In read-only/plan mode: map every call site of `processPayment` in `src/`,
list which modules import it, and identify where Stripe idempotency keys are
set. Then produce a refactor plan to make the handler safely idempotent, as a
numbered TODO where each step names the exact files it touches and the tests
that cover it. Do not edit anything yet — output the plan only.

Drugi uruchamiasz po przejrzeniu planu. Twarde zatrzymanie na końcu jest tu sednem: jeden krok, potem raport, potem twoja decyzja.

Gotowy prompt: wykonaj dokładnie jeden krok i zatrzymaj się

Execute step 1 of the plan only: add an idempotency key derived from the
request to `processPayment` and pass it to the Stripe `charges.create` call.
Update the 3 call sites you listed. Run `npm test -- payments` and paste the
results. Stop and report before touching step 2 — do not start the next step
until I confirm.

Trzeci zamyka pętlę, zanim zaakceptujesz diff. Tryb tylko do odczytu nie sprawia, że plan jest poprawny — sprawia, że jest możliwy do przejrzenia, a to jest druga linia obrony:

Gotowy prompt: wymuś autoprzegląd, zanim zaakceptujesz diff

Before I accept these edits, review your own diff as a hostile senior reviewer
on a payment path: list every edge case, error path, and concurrency concern
you did NOT handle, and call out anywhere you guessed at business rules instead
of reading them from the code. Be specific about line numbers.

Te trzy to produkcyjna wersja wzorca, napisana pod jedną refaktoryzację. Prompt poniżej ma ten sam kształt, ale jako skrypt całej sesji — trzy fazy w jednym miejscu, z wyraźnie zaznaczoną zmianą trybu między nimi, na moment, gdy dopiero układasz pracę, a nie ją wykonujesz:

Gotowy prompt: zmiana trybu w trakcie przepływu pracy

Phase 1 (Analysis - use ask/plan mode):
Read the payment processing module in src/payments/. Explain the
current architecture and identify the three riskiest areas for
our planned refactoring.

Phase 2 (Planning - stay in ask/plan mode):
Based on your analysis, create a refactoring plan. Save it to
docs/payment-refactor-plan.md. Include risk assessment for each step.

Phase 3 (Implementation - switch to agent/normal mode):
Implement step 1 from the plan. Write tests first, then implement.
Run tests after each change.

Ramowy proces decyzyjny przy wyborze trybu

1. Chcesz zrozumieć kod, a nie go zmieniać? Użyj trybu tylko do odczytu/analizy.
2. Zadanie jest dobrze zdefiniowane z jasną weryfikacją? Użyj trybu kierowanego wykonywania i pozwól agentowi przejść przez zadanie z twoim okresowym przeglądem.
3. Zadanie jest mechaniczne i niskiego ryzyka? Rozważ pełną autonomię z odpowiednią izolacją (cloud agent, sandbox, wątek cloudowy).
4. Zadanie dotyka wrażliwego kodu? Użyj kierowanego wykonywania z zatwierdzaniem per plik.
5. Nie jesteś pewien? Zacznij od kierowanego wykonywania. Uprawnienia zawsze możesz poluzować w trakcie sesji; nie cofniesz edycji, której nigdy nie zobaczyłeś.

Dwa tryby naraz

Zaawansowane zespoły używają różnych trybów jednocześnie w wielu sesjach.

Cursor

Uruchom Cloud Agent na zadaniu poprawek lintingu (autonomicznie), a jednocześnie używaj głównego Agenta do rozwoju funkcjonalności (kierowane). Przejrzyj zmiany Cloud Agenta, gdy będą gotowe, bez przerywania pracy nad funkcjonalnością.

Claude Code

Uruchom bezobsługową sesję Claude do naprawy ostrzeżeń lintingu w jednej zakładce terminala, jednocześnie pracując interaktywnie nad funkcjonalnością w drugiej. Użyj --continue, aby wrócić do dowolnej sesji później:

# Terminal 1: Autonomous lint fixes
claude -p "Fix all ESLint warnings in src/. Commit each fix." --allowedTools "Edit,Bash(npm run lint)"

# Terminal 2: Interactive feature development
claude

Codex

Uruchom wątek cloudowy dla zadania mechanicznego i pracuj lokalnie nad funkcjonalnością. Codex wykonuje oba równolegle:

Cloud thread: Fix all TypeScript strict mode errors in src/utils/.
Commit each fix with type: "fix(types)" message.

W międzyczasie pracuj nad funkcjonalnością lokalnie w rozszerzeniu IDE lub CLI.

Autonomiczna połowa takiego podziału potrzebuje spisanego zakresu, bo nikt jej nie pilnuje:

Gotowy prompt: ograniczona autonomiczna operacja wsadowa

Fix all [ISSUE TYPE] in [DIRECTORY]. For each fix:

1. Make the minimal change needed
2. Run [VERIFICATION COMMAND] to confirm the fix
3. Commit with message: [COMMIT FORMAT]
4. Move to the next instance

Only modify files in [DIRECTORY]. Do not change test files.
Do not install new dependencies. Do not modify configuration files.

Gdzie wybór trybu zawodzi

• Agent wyprzedza nieprzejrzany plan. Pomiń fazę tylko do odczytu, a będzie wykonywał pracę w oparciu o własne założenia. Przejrzyj plan jako odrębny artefakt przed przełączeniem trybów.
• Zostajesz w trybie analizy zbyt długo. Trzydzieści minut pytań zżera kontekst, którego potrzebowała implementacja. Ustaw limit pięciu, dziesięciu minut i przełącz.
• Mieszasz tryby w jednym prompcie. „Przeanalizuj moduł auth, a potem go zrefaktoryzuj” wymusza wewnętrzne przełączenie trybu, a agent zwykle pomija analizę i skacze do refaktoryzacji. Rozdziel je na osobne prompty.
• Tryb agenta edytuje pliki, których nie zamierzałeś ruszać. Niejasny prompt w trybie wykonania zaprasza do rozpełzania się zakresu. Wymień pliki, używaj punktów kontrolnych do cofania i odrzucaj fragmenty dotykające czegokolwiek poza planem.
• Sandbox workspace Codeksa obejmuje wrażliwe pliki repozytorium. workspace-write może edytować pliki takie jak .env czy manifesty wdrożeniowe, jeśli leżą w workspace, a on-request nie pyta przed każdą taką edycją. Trzymaj sekrety poza workspace i w przypadku wrażliwych repozytoriów zostań przy read-only, dopóki plan nie zostanie przejrzany.
• Pełna autonomia przy zadaniu, które wymagało osądu. Autonomia działa tam, gdzie „poprawne” jest mechaniczne i weryfikowalne. Projektowanie API, strategia obsługi błędów i praca nad wydajnością dają lepsze wyniki w trybie kierowanym.
• Zapominasz przełączyć z powrotem. Po badaniu w trybie analizy agent, który wydaje się nie reagować na prośby o implementację, zwykle po prostu wciąż jest w trybie tylko do odczytu. Sprawdź wskaźnik trybu, zanim zaczniesz debugować prompt.

Dokąd pójść dalej po wyborze trybu

Człowiek w pętli Bramki przeglądu i nawyki nadzoru, które łączą się z dyscypliną trybów.

Okna kontekstowe Jak wybór trybu wpływa na zużycie kontekstu i długość sesji.

Koszt kontekstu Implikacje kosztowe różnych trybów i poziomów autonomii.

Grill Me i Grill With Docs Tryb zapytania doprowadzony do logicznego końca — agent przepytuje cię po jednym pytaniu naraz, aż się dogadacie.