04 — Tryb planu i agenci działający w tle: pracuj mądrzej, a nie szybciej
Nadchodzi taki moment, w którym wielu programistów zdaje sobie sprawę, że tryb agenta jest tradycyjny to nie wystarczy. Podpowiedź jest poprawna, kontekst jest podany, ale agent natychmiast rozpoczyna pisanie kodu zanim naprawdę zrozumiałem problem. Dodaj niepotrzebne pliki, zmodyfikuj niepotrzebne klasy musiałem dotknąć, a po dwudziestu minutach autonomicznego wykonania znajdziesz bazę kodu, która działa ale rósł w złym kierunku.
Odpowiedź kursora na ten problem nazywa się Tryb planu. Przed napisaniem A pojedynczej linijki kodu agent analizuje projekt, zadaje doprecyzowujące pytania, generuje plan zorganizowany w Markdown i prosi o zatwierdzenie. Dopiero po przejrzeniu i zatwierdzeniu każdego kroku, rozpoczyna się egzekucja. I radykalnie inna filozofia: pomyśl zanim zaczniesz kodować.
Oprócz trybu Plan, Cursor 2.0 wprowadził m.in Agenci w tle: Procesy AI które działają równolegle na izolowanych gałęziach Git za pośrednictwem drzew roboczych. Podczas pisania kodu na gałęzi main, do ośmiu agentów może pracować jednocześnie nad różnymi zadaniami, każdy w jednym całkowicie oddzielne środowisko, nie zakłócając swojej pracy ani siebie nawzajem.
W tym artykule dla zaawansowanych omówimy szczegółowo obie funkcje: jak działają i kiedy z nich korzystać, jak je łączyć i jakie wzorce są najskuteczniejsze w przypadku złożonych przepływów pracy programistycznych.
Czego dowiesz się w tym artykule
- Jak tryb planowania zmienia paradygmat rozwoju wspomaganego sztuczną inteligencją
- Kompletny przepływ pracy: od szybkiego wygenerowania do zatwierdzenia planu
- Co to jest agent działający w tle i jak działają drzewa robocze git w Cursorze
- Jak uruchomić do 8 równoległych agentów za pomocą Cursor 2.0
- Kontrola misji: Monitoruj i zarządzaj działającymi agentami
- Praktyczne przypadki użycia: tworzenie rusztowań funkcji, równoległe poprawki błędów, projekty migracji
- Agenci długoterminowi: limity, najlepsze praktyki i zarządzanie kosztami
- Jak reguły kursora kierują wygenerowanym planem
- Rzeczywiste ograniczenia i obejścia przetestowane w produkcji
Pozycja w serii: Cursor IDE i AI-Native Development
| # | Przedmiot | Poziom |
|---|---|---|
| 1 | Cursor IDE: Kompletny przewodnik dla programistów | Początkujący |
| 2 | Reguły kursora: konfigurowanie sztucznej inteligencji dla twojego projektu | Mediator |
| 3 | Tryb agenta: zmodyfikuj bazę kodu za pomocą polecenia | Mediator |
| 4 | Tryb planu i agenci działający w tle (tutaj jesteś) | Zaawansowany |
| 5 | Zaczepy kursora: automatyzuj przepływ pracy | Mediator |
| 6 | MCP i kursor: Połącz IDE z bazą danych i API | Zaawansowany |
| 7 | Debugowanie za pomocą Cursor AI: 3x szybsze | Mediator |
| 8 | Kursor vs Windsurf vs Copilot w 2026 roku | Początkujący |
| 9 | Profesjonalny przebieg pracy: projekt kątowy z kursorem | Zaawansowany |
Co to jest tryb planu i czym różni się od trybu agenta
Aby zrozumieć tryb planu, musisz najpierw zrozumieć problem, który rozwiązuje. W Tryb agenta standardowo, przepływ jest bezpośredni: wydajesz instrukcje, agent czyta odpowiednie pliki i zaczyna wdrożyć natychmiast. Podejście to jest skuteczne w przypadku ograniczonych i dobrze zdefiniowanych zadań, ale systematycznie zawodzi w przypadku złożonych lub niejednoznacznych problemów.
Wyobraź sobie, że pytasz agenta: „Refaktoryzuj moduł uwierzytelniania, aby obsługiwał OAuth2 z Google i GitHub”. Agent w trybie normalnym może rozpocząć edycję istniejące pliki uwierzytelniające bez wiedzy, że używasz JWT, że masz niestandardowe oprogramowanie pośredniczące, lub że architektura obejmuje zarządzanie sesjami po stronie serwera. Rezultatem jest poprawny kod abstrakcyjnie, ale błędnie w kontekście twojego projektu.
Filozofia „Pomyśl, zanim napiszesz kod”.
Tryb planu wprowadza: warstwa rozważań przed egzekucją. Kiedy aktywujesz Tryb Planu, agent nie pisze kodu: zadaje pytania, przeszukuje bazę kodów, identyfikuje zależności i ograniczenia, a następnie tworzy ustrukturyzowany dokument, który dokładnie opisuje, co zamierza to zrobić, plik po pliku, krok po kroku.
Plan jest edytowalnym plikiem Markdown. Możesz go edytować, usunąć kroki, z którymi się nie zgadzasz, dodać ograniczenia, których agent nie wziął pod uwagę, skorygować błędne założenia. Tylko kiedy jesteś zadowolony, kliknij „Buduj” i rozpoczyna się realizacja, kierując się zatwierdzonym planem.
Kiedy używać trybu planu, a kiedy trybu agenta
Wybór pomiędzy dwoma trybami zależy głównie od złożoności i niejednoznaczności zadania:
Przewodnik po wyborze trybu
| Charakterystyka zadania | Zalecany tryb |
|---|---|
| Proste, dobrze zdefiniowane zadanie (naprawa błędów, dodana funkcja) | Tryb bezpośredniego agenta |
| Złożona funkcja wpływająca na wiele modułów | Tryb planu |
| Refaktoryzacja architektoniczna | Tryb planu obowiązkowy |
| Migracja (framework, baza danych, biblioteka) | Tryb planu + agenci w tle |
| Zadania, które dobrze znasz i które już wykonałeś | Tryb agenta z określonymi zasadami |
| Nieznana lub odziedziczona baza kodu | Tryb planu zawsze |
| Ustrukturyzowane generowanie szablonów | Tryb planu lub Agent z szablonem |
Jak działa tryb planu: od planu podpowiedzi do planu wykonywalnego
Tryb Planowania aktywuje się poprzez naciśnięcie Shift + Tab w polu wejściowym agenta, lub jest automatycznie sugerowany przez Cursor, gdy wykryje złożone żądanie. Raz aktywowany, przepływ jest podzielony na cztery odrębne fazy.
Faza 1: Badania i analiza bazy kodu
Agent nie zaczyna od podpowiedzi: zaczyna od bazy kodu. Używanie tych samych narzędzi, co w trybie agenta (wyszukiwanie semantyczne, czytanie plików, grep), przejrzyj projekt, aby zrozumieć kontekst. Zidentyfikuj odpowiednie pliki, czyta istniejącą dokumentację, analizuje zależności i relacje pomiędzy modułami.
W tej fazie agent może to zrobić pytania wyjaśniające. Jeśli twoje żądanie i niejednoznaczne w krytycznym punkcie, prosi o określenie przed kontynuowaniem. Te pytania są cenne: często ujawniają ukryte założenia, których nie wziąłeś pod uwagę.
Faza 2: Generowanie planu
Po zakończeniu analizy agent generuje ustrukturyzowany dokument Markdown. Plan obejmuje: podsumowanie celu, analizę zaangażowanych plików, listę ponumerowanych kroków ze szczegółowym opisem, ścieżką plików, które będą tworzone lub modyfikowane oraz potencjałem ryzyka lub zależności, którymi należy zarządzać.
W Cursor 2.2 plany mogą również obejmować Schematy syreny wygenerowane automatycznie wizualizować przepływy, architektury i relacje pomiędzy komponentami.
Oto przykładowy wygenerowany plan refaktoryzacji uwierzytelniania:
# Piano: Refactoring Autenticazione con OAuth2
## Obiettivo
Aggiungere supporto OAuth2 (Google e GitHub) al sistema di autenticazione esistente,
mantenendo la compatibilità con il flusso email/password attuale.
## Analisi Codebase
- File autenticazione: src/auth/auth.service.ts, src/auth/auth.guard.ts
- JWT gestito in: src/middleware/jwt.middleware.ts
- Session management: server-side (express-session)
- Database: PostgreSQL con tabella `users` (id, email, password_hash, created_at)
## Step da Eseguire
### Step 1: Aggiunta dipendenze OAuth2
- [ ] Installare `passport`, `passport-google-oauth20`, `passport-github2`
- [ ] Aggiornare package.json e package-lock.json
- File: package.json
### Step 2: Configurazione strategy OAuth
- [ ] Creare src/auth/strategies/google.strategy.ts
- [ ] Creare src/auth/strategies/github.strategy.ts
- [ ] Aggiornare src/auth/auth.module.ts per registrare le nuove strategy
- File da creare: 2 nuovi, 1 modificato
### Step 3: Migrazione schema database
- [ ] Aggiungere colonne `oauth_provider` e `oauth_id` alla tabella users
- [ ] Creare migration: db/migrations/20251205_add_oauth_fields.sql
- [ ] Aggiornare User entity per riflettere nuovi campi
- File: User.ts, nuova migration
### Step 4: Aggiornamento route e controller
- [ ] Aggiungere endpoint GET /auth/google e GET /auth/google/callback
- [ ] Aggiungere endpoint GET /auth/github e GET /auth/github/callback
- [ ] Aggiornare auth.controller.ts
- File: auth.controller.ts, app.routes.ts
### Step 5: Test e validazione
- [ ] Aggiornare test esistenti per compatibilità
- [ ] Aggiungere test integrazione per flusso OAuth
- File: auth.spec.ts, nuovi file di test
## Rischi Identificati
- La migrazione DB richiede backup preventivo in produzione
- I callback URL devono essere configurati nelle console Google/GitHub
- I secret OAuth devono essere aggiunti alle variabili d'ambiente
## File NON Toccati
- src/middleware/jwt.middleware.ts (compatibilità preservata)
- Frontend components (fuori scope di questo piano)
Faza 3: Przegląd i edycja planu
Plan otwiera się jako plik Markdown w edytorze. Możesz go edytować bezpośrednio: usuń niepotrzebne kroki, dodaj ograniczenia, popraw nazwy plików, określ podejścia alternatywy. To najważniejsza faza: Twoja interwencja decyduje o jakości kolejnej egzekucji.
Typowy błąd, którego należy unikać
Nie zatwierdzaj planu bez jego przeczytania. Pokusa, aby od razu kliknąć „Buduj” jest silna, ale właśnie tym różni się tryb planu od trybu agenta: twoja recenzja i część integralną częścią procesu. Plan zatwierdzony bez przeglądu jest gorszy niż tryb agenta bezpośrednio, ponieważ daje fałszywe poczucie kontroli.
Faza 4: Wykonanie oparte na planie
Klikając „Buduj”, kursor wchodzi w tryb agenta, ale z planem jako ustrukturyzowanym przewodnikiem. The agent executes the steps in the defined order, using the plan as a "specification" of odniesienie. Możesz monitorować postęp w czasie rzeczywistym: każdy ukończony krok jest zaznaczone, a agent zgłasza wszelkie odchylenia od pierwotnego planu.
Jeśli podczas wykonywania pojawi się nieoczekiwany problem, agent zatrzymuje się i pyta instrukcji, zamiast samodzielnie dążyć do potencjalnie nieprawidłowego rozwiązania.
Agenci w tle: architektura i działanie
Podczas gdy tryb planowania rozwiązuje problem jakości wykonania, tj Agenci w tle rozwiązują problem prędkości i równoległości. Wprowadzony z Cursorem 2.0 w listopadzie 2025 umożliwiają jednoczesne uruchomienie do ośmiu agentów, każdy w jednym środowisku git całkowicie odizolowany.
Drzewa robocze Git: podstawowa technologia
Na czym opierają się agenci tła git drzew roboczych, natywną cechą git, który umożliwia powiązanie wielu katalogów roboczych z tym samym repozytorium, każdy z nich na innej gałęzi. W przeciwieństwie do tradycyjnego klonu (który duplikuje całe repozytorium na dysku), drzewo robocze i lekkie: współdzieli magazyn obiektów git i wymaga tylko miejsca dla plików, które w rzeczywistości różnią się między gałęziami.
W przypadku Kursora oznacza to, że każdy Agent działający w tle ma:
- Un dedykowana gałąź git nad którym pracuje w izolacji
- Una oddzielny katalog roboczy w lokalnym systemie plików
- Un oddzielny indeks bazy kodu do wyszukiwania semantycznego
- Żadnych zakłóceń z Twoją pracą lub z innymi agentami
W rezultacie możesz pracować na gałęzi main podczas gdy trzech agentów edytuje
funkcja/autoryzacja, funkcja/pulpit nawigacyjny i poprawka/wydajność jednocześnie, bez konieczności wchodzenia
w konflikcie.
Uruchamianie agentów działających w tle za pomocą kursora 2.0
Aby uruchomić agenty równoległe, istnieją dwa główne podejścia. Pierwszy i najczęstszy: z panelu Kompozytor otwórz nową zakładkę agenta i przypisz mu konkretne zadanie. Każda zakładka reprezentuje niezależnego agenta, który może działać w tle.
Drugie podejście, wprowadzone w Cursor 2.0, pozwala na uruchomienie wielu agentów z tego samego monitu: główny agent otrzymuje instrukcję, rozkłada je na podzadania i tworzy agenty podrzędne, które pracują równolegle nad każdym z nich podzadania. Agenci podrzędni mogą teraz działać asynchronicznie, umożliwiając element nadrzędny kontynuować podczas występów dzieci.
# Workflow con 3 Background Agents in Parallelo
## Setup iniziale
# Abilita la visualizzazione dei worktrees nel pannello SCM (opzionale)
# Cursor settings.json:
{
"git.showCursorWorktrees": true
}
## Branch principale (il tuo lavoro normale)
$ git branch
* main
feature/auth-oauth
feature/dashboard-redesign
fix/api-performance
## Struttura worktrees (gestita automaticamente da Cursor)
$ git worktree list
/home/user/myproject abc1234 [main]
/tmp/cursor-agent-1/myproject def5678 [feature/auth-oauth]
/tmp/cursor-agent-2/myproject ghi9012 [feature/dashboard-redesign]
/tmp/cursor-agent-3/myproject jkl3456 [fix/api-performance]
## Ogni agente lavora nel suo worktree isolato
# Agent 1 - OAuth2 implementation
# Prompt: "Implementa OAuth2 con Google seguendo il piano auth-plan.md"
# Agent 2 - Dashboard redesign
# Prompt: "Refactoring del dashboard component con nuovi charts per D3.js"
# Agent 3 - Performance fix
# Prompt: "Ottimizza le query N+1 nel modulo ordini identificate dal profiler"
## Al completamento, i branch sono pronti per review e merge
$ git diff main...feature/auth-oauth
$ git diff main...feature/dashboard-redesign
$ git diff main...fix/api-performance
Agenci asynchroniczni i spawn rekurencyjny
Jedną z najważniejszych innowacji Cursora 2.2 jest możliwość pracy agentów w pewnym sensie całkowicie asynchroniczny. W poprzednich wersjach, gdy agent główni podagenci, którzy się pojawili, musieli wcześniej poczekać, aż każdy z nich zakończy działanie kontynuować. Teraz rodzic może kontynuować pracę, podczas gdy dzieci pracują równolegle.
Jeszcze potężniejsza jest zdolność podagentów do tworzenia własnych podagentów, tworzenie skoordynowane drzewo pracy. Główny agent może deleguj funkcję A dziecku, które z kolei dzieli pracę między wnuka na testy i wnuka na wdrożenie. Kursor obsługuje synchronizację drzewa i prezentuje wyniki w spójny sposób.
Kontrola misji: Monitoruj agentów równoległych
W sytuacji, gdy wielu agentów pracuje jednocześnie, posiadanie wglądu w to, co się dzieje, staje się niezwykle istotne to się dzieje. Cursor 2.0 przeprojektował interfejs, dodając paradygmat skoncentrowany na agentach: Zamiast zarządzać plikami, zarządzasz procesami.
Panel agenta
Na pasku bocznym Kursora znajdziesz panel aktywnych agentów. Dla każdego agenta, do którego przychodzą pokaż się:
- Imię i zadanie przypisany (utworzone z początkowego monitu)
- Oddział, git nad którym pracuje
- Państwo: działa, oczekuje na wprowadzenie danych, zakończone, wystąpił błąd
- Ostatni krok wykonany ze szczegółowym logiem
- Pliki zmodyfikowane w bieżącej sesji
- Tokeny zużyte i kosztorys
Wejdź w interakcję z agentami wykonawczymi
Możesz kliknąć dowolnego agenta, aby otworzyć jego historię czatów i wyświetlić pliki które zmodyfikował, wydać nowe instrukcje lub przerwać wykonanie. Jeśli agent utknie lub pójdzie w złym kierunku, możesz go zatrzymać jednym kliknięciem and redirect it with a new message.
Przydatne skróty do Kontroli Misji
| Działanie | Skrót / metoda |
|---|---|
| Nowe tło agenta | Cmd+Shift+N w panelu Kompozytor |
| Przełącza pomiędzy agentami | Kliknij panel agentów lub Cmd+Shift+Tab |
| Włącz tryb planu dla każdego agenta | Shift+Tab na wejściu agenta |
| Zatrzymaj działanie agenta | Kliknij przycisk zatrzymania w nagłówku agenta |
| Przejrzyj agenta różnicowego | Kliknij „Zmienione pliki” w panelu agenta |
| Włącz wyświetlanie drzewa roboczego SCM | Ustawienie git.showCursorWorktrees: true |
Praktyczne przypadki użycia
Przypadek 1: Funkcja rusztowania w trybie planu
Typowy scenariusz: Musisz dodać kompletny moduł do istniejącej aplikacji. Bez trybu planu agent może wygenerować formularz w różnych konwencjach od reszty projektu lub zignorować ujednolicone wzorce architektoniczne.
W trybie planu przepływ jest następujący:
- Otwórz Kompozytora i naciśnij Shift+Tab aby aktywować tryb planu
- Opisz tę funkcję: „Dodaj moduł powiadomień z możliwością zarządzania w czasie rzeczywistym przez WebSocket, preferencjami użytkownika i historią”
- Agent analizuje projekt: identyfikuje istniejące wzorce, konwencje nazewnictwa, architekturę modułów
- Zadaje ci pytania: „Czy projekt wykorzystuje Redux lub Context API do zarządzania stanem?”, „Czy powinienem uwzględnić testy, czy załatwiacie je osobno?”
- Wygeneruj plan z dokładną strukturą plików, przestrzegając konwencji projektowych
- Przeglądasz i ewentualnie usuwasz kroki (np.: „nie dodawaj historii z bajek, nie używamy ich”)
- Kliknij opcję Buduj, a formularz zostanie poprawnie zbudowany już za pierwszym razem
Przypadek 2: Naprawa błędów w przypadku agentów działających w tle
Masz listę 4 izolowanych błędów, każdy w różnych modułach aplikacji. Zamiast napraw je sekwencyjnie, możesz zrównoleglić:
# Esempio: 4 bug fix in parallelo
## Agent 1: Fix validazione form
# Branch: fix/form-validation
# Prompt: "Il form di registrazione accetta email non valide.
# File: src/components/RegisterForm.tsx
# Aggiungi validazione RFC 5322 e mostra errore inline"
## Agent 2: Fix query performance
# Branch: fix/slow-dashboard-query
# Prompt: "La dashboard impiega 8s a caricare.
# File: src/api/dashboard.service.ts, line 45
# La query fa N+1 su orders->items. Aggiungi eager loading"
## Agent 3: Fix mobile layout
# Branch: fix/mobile-navbar
# Prompt: "Su viewport < 768px il navbar si sovrappone al content.
# File: src/components/Navbar.css
# Z-index e position sticky si conflittano"
## Agent 4: Fix gestione errori
# Branch: fix/error-boundaries
# Prompt: "L'app crasha senza error boundary.
# Aggiungi React ErrorBoundary al router e ai moduli critici"
## Risultato dopo ~15 minuti:
## 4 branch pronti, ciascuno con il proprio fix isolato
## Review e merge sequenziale o con stacked PRs
Korzyść nie jest tylko tymczasowa. Z poprawkami wyizolowanymi w oddzielnych gałęziach, recenzja i znacznie prostsze: każdy PR dotyka tylko jednego problemu, różnica jest minimalna i zrozumiała.
Przypadek 3: Projekt migracji z agentami planowymi i działającymi w tle
Najpotężniejszy przypadek użycia: złożona migracja wymagająca planowania dokładność i równoległość. Na przykład przeprowadź migrację aplikacji z JavaScript do TypeScript.
Optymalny przepływ pracy:
- Użyj trybu planu, aby wygenerować pełną strategię migracji
- Plan identyfikuje 30 plików, pogrupowanych w 4 klastry zależności
- Uruchom 4 agentów działających w tle, po jednym na klaster
- Kontekst każdego agenta stanowi plan główny i jego podzbiór plików
- Podczas gdy agenci pracują, Ty monitorujesz je z poziomu Kontroli Misji i zarządzasz konfliktami
- Po zakończeniu przejrzyj 4 gałęzie i połącz je we właściwej kolejności
Agenci działający długo: jak działają i czego się spodziewać
Agenci w tle kursora mogą pracować przez dłuższe sesje, nawet podczas zamknąłeś IDE. Ta funkcja jest szczególnie przydatna w przypadku zadań wymagających kilkadziesiąt minut lub więcej, jak np. migracje, generowanie testów na dużą skalę lub dogłębna analiza bazy kodu.
Ciągłość sesji
W przeciwieństwie do prostego okna czatu, agent działający w tle utrzymuje swoje własne stan pomiędzy sesjami. Można uruchomić agenta, zamknąć laptopa i po powrocie wrócić agent nadal działał (jeśli został skonfigurowany do działania na komputerach zdalnych). Kursor obsługuje oba wykonania lokalny (proces zatrzymuje się, gdy zamknij IDE). zdalny (agent kontynuuje pracę w chmurze infrastruktury).
Limity tokenów i kosztów
Długotrwali agenci zużywają dużo tokenów. Ważne jest monitorowanie zużycia aby uniknąć niespodzianek w rozliczeniach. Kursor pokazuje tokeny w czasie rzeczywistym zużywane dla każdego agenta w panelu Kontroli Misji.
Zwróć uwagę na koszty agentów równoległych
Każdy agent działający w tle zużywa tokeny niezależnie. Uruchom 8 agentów równolegle może zużyć 8 razy więcej żetonów jednego agenta w tym samym okres. W planie Pro (20 USD/miesiąc) masz miesięczny limit: zarządzaj równoległością ostrożnie. Używaj agentów równoległych do zadań, które naprawdę przynoszą korzyści równoległość, a nie domyślna dla każdej operacji.
Tryb planu i reguły kursora: potężna synergia
Tryb planu nie działa w izolacji: duży wpływ na niego mają: Reguły kursora skonfigurowane w projekcie. Kiedy agent generuje planu, zasady pełnią rolę ograniczeń i wskazówek kształtujących jego treść.
Jak zasady kierują planem
Jeśli zdefiniowałeś reguły takie jak „zawsze używaj czystej architektury 3-warstwowej” o „każda nowa funkcja musi obejmować testy jednostkowe z Jest”, wygenerowany plan automatycznie uwzględni te ograniczenia. Agent nie zaproponuje umieszczenia logiki biznesowej u administratora, jeżeli zasady przewidują rozdzielenie obaw.
# Esempio: .cursor/rules/architecture.mdc
---
alwaysApply: true
---
# Architettura del Progetto
## Layer Separation (OBBLIGATORIO)
- Controllers: solo routing e validation input
- Services: logica di business e orchestrazione
- Repositories: accesso dati, zero logica business
- DTOs: trasferimento dati tra layer, tipizzati
## Naming Conventions
- Service: `*.service.ts`
- Repository: `*.repository.ts`
- DTO: `*-request.dto.ts`, `*-response.dto.ts`
- Controller: `*.controller.ts`
## Testing Requirements
- Unit test per ogni Service (copertura min 80%)
- Integration test per ogni Repository
- File test: `*.spec.ts` nella stessa directory
## Quando Plan Mode genera un piano con questa rule attiva:
## - Ogni step crea file nel layer corretto
## - I nomi seguono le convenzioni definite
## - I test sono inclusi come step separato nel piano
## - Non viene mai suggerito codice che attraversa i layer erroneamente
Zasady optymalizacji planów
Można także utworzyć reguły specyficzne dla trybu planowania, które kierują strukturą samego planu, a nie tylko jego realizacji:
# Esempio: .cursor/rules/planning.mdc
---
alwaysApply: true
---
# Linee Guida per la Pianificazione
## Prima di generare un piano, DEVI:
1. Identificare tutti i file che verranno modificati
2. Verificare se esistono test da aggiornare
3. Controllare se ci sono migrazioni DB necessarie
4. Valutare l'impatto sulle API esistenti
## Struttura del Piano (OBBLIGATORIA)
Ogni piano deve contenere:
- ## Obiettivo (1 paragrafo)
- ## Analisi Impatto (file, dipendenze, rischi)
- ## Step Implementazione (numerati, con file paths)
- ## Testing (unit + integration)
- ## File NON Toccati (elenco esplicito)
- ## Rollback Strategy (come annullare se va male)
## Dimensione degli Step
- Ogni step deve essere atomico (completabile in 10-15 min)
- Step troppo grandi vanno spezzati in sub-step
- Evita step che dipendono dallo stato di step paralleli
Rzeczywiste ograniczenia i obejścia
Tryb planu i agenci działający w tle to zaawansowane funkcje, ale nie są pozbawione ograniczeń. Znajomość ograniczeń jest tak samo ważna jak znajomość możliwości.
Tryb planu: Halucynacje w samolocie
Plan może zawierać błędy: nieistniejące ścieżki plików, błędne założenia na architekturze, zbędnych lub brakujących krokach. Agent robi wszystko, co w jego mocy zrozumieć projekt, ale jeśli baza kodu jest duża lub słabo udokumentowana, możesz się mylić.
Obejścia: Zmuś agenta do podania dokładnych ścieżek podczas analizy. Dodaj do zachęty: „Przed wygenerowaniem planu wypisz listę znalezionych plików w swoich badaniach i potwierdź, że są one prawidłowe”. Ten „punkt kontrolny” znacznie zmniejsza błędy w ostatecznym planie.
Agenci w tle: Konflikty scalania
Jeśli dwóch agentów zmodyfikuje ten sam plik w różnych gałęziach w momencie scalania będziesz mieć konflikty. Kursor nie obsługuje automatycznie uzgadniania semantycznego: fuzja to twoje zadanie.
Obejścia: Przed uruchomieniem agentów równoległych przeanalizuj plan i upewnij się, że zadania są naprawdę niezależne. Jeśli dwóch agentów musi się zetknąć ten sam plik (np. centralny plik routingu), ustala kolejność tego konkretnego zadania i zrównoleglić resztę.
Długi kontekst w długich planach
W przypadku bardzo dużych projektów wygenerowany plan może być tak długi, że nie wchodzi do okna kontekstowego agenta podczas wykonywania. Wynik and that the final steps of the plan are executed with less context and can być mniej precyzyjnym.
Obejścia: Zniszcz wielkie plany. Użyj trybu planu, aby wygenerować „metaplan”, który identyfikuje główne fazy, a następnie ponownie korzysta z trybu planu w celu wygenerowania szczegółowych planów dla każdej fazy. To podejście do wodospadu umożliwia zarządzanie kontekstem na każdym etapie.
Blokowanie agentów na podstawie zależności zewnętrznych
An agent that needs to, for example, query a database or call an external API wykonanie zadania zostanie zablokowane, jeśli te zasoby nie będą dostępne w lokalnym lub zdalnym środowisku programistycznym, w którym działa.
Obejścia: Użyj reguł kursora, aby określić sposób obsługi zależności zewnętrzne: „Jeśli potrzebujesz prawdziwych danych z bazy danych, użyj pliku oprawy/przykładowe dane.json jako próbne”. Dzięki temu agenci mogą kontynuować nawet bez bezpośredniego dostępu do zasobów zewnętrznych.
Najlepsze praktyki dotyczące trybu planu i agentów działających w tle
1. Systematyczny przegląd planu
Ustanów proces przeglądu planu przed jego wykonaniem. Nie ograniczaj się aby szybko przewijać: sprawdź, czy każdy krok jest uzasadniony, czy pliki zidentyfikowane faktycznie istnieją, że kolejność wykonania jest prawidłowa. Dobrze sprawdzony plan skutkuje prawie zawsze pomyślną realizacją.
2. Zatwierdź przed uruchomieniem agentów
Zawsze rób to przed uruchomieniem dowolnego agenta (w trybie planu lub w tle). zobowiązanie związane z twoją obecną pracą. Git rozwidla drzewa roboczego z HEAD current: czysty katalog roboczy zapewnia rozgałęzienia agenta rozpocząć od znanego i stabilnego stanu.
3. Szczegółowe zadania dla agentów równoległych
Agent najlepiej radzi sobie z dobrze określonym i ograniczonym zadaniem. Oprzyj się pokusa postawienia agentowi ogromnych zadań („Wdroż cały moduł e-commerce”): podziel je na mniejsze zadania, które możesz zrównoleglić. Równoległość dobrze granulowany i bardziej niezawodny niż równoległy monolit.
4. Użyj trybu planu po raz pierwszy w bazie kodu
Kiedy pracujesz nad bazą kodu, której nie znasz dobrze (odziedziczony projekt, open source, do którego masz swój wkład, nowy klient), zawsze korzystaj z trybu planu do pierwszych zadań. Wygenerowany plan umożliwi szybki podgląd wzorców architektoniczne aspekty projektu, nawet jeśli wówczas zdecydujesz się go nie realizować.
5. Optymalizacja kosztów
Nie wszystkie zadania wymagają trybu planu. Używaj trybu planu selektywnie dla i złożone zadania. Do prostych zadań (zmiana nazwy zmiennej, dodanie importu, napraw literówkę w dokumencie), bezpośredni tryb agenta, wydajniejszy i tańszy. Koszt trybu planowania obejmuje zarówno analizę, jak i wykonanie.
6. Przegląd różnic przed połączeniem
Gdy agent działający w tle zakończy swoje zadanie, nie łącz się automatycznie.
USA git diff main...feature/agent-branch aby przejrzeć każdy
edytować. Różnice między agentami są na ogół czyste i dobrze zorganizowane,
jednak przed integracją niezbędna jest weryfikacja prowadzona przez człowieka.
Tryb planowania a inne podejścia do planowania AI
Tryb planowania nie jest jedynym podejściem do planowania wspomaganego sztuczną inteligencją, ale zapewnia pewne cechy wyróżniające w porównaniu z alternatywami.
Najbardziej powszechnym alternatywnym podejściem jest ręczne napisanie specyfikacji technicznej w dokumencie, a następnie przekaż go agentowi jako kontekst. To działa, ale zajmuje znacznie dłużej i nie wykorzystuje zdolności agenta do analizy bazę kodu niezależnie w celu identyfikacji odpowiednich plików.
GitHub Copilot Workspace, uruchomiony w 2024 r., oferuje podobną funkcjonalność jak Tryb planu zintegrowany z problemami GitHub. Copilot analizuje problem, generuje planu i może automatycznie otwierać PR. Przewaga i integracja kursora bezpośrednio z redaktorem: plan jest generowany i realizowany w tym samym środowisku, z pełnym wglądem w lokalny kod i strukturę projektu.
Wnioski
Tryb planu i agenci w tle stanowią jakościowy skok w drodze gdzie programiści mogą współpracować z sztuczną inteligencją. Nie chodzi tylko o to przyspieszyć pracę: chodzi o zmianę rodzaju pracy, którą możesz delegować.
W trybie planu dostępne są złożone funkcje, które wcześniej wymagały iteracyjnego trybu agenta i wiele nadzoru stają się procesami ustrukturyzowanymi, których plan jest najpierw zatwierdzony wykonania. Jakość wygenerowanego kodu poprawia się po uruchomieniu agenta from a deep understanding of the problem, not from a generic prompt.
Dzięki agentom działającym w tle równoległość nie jest już przywilejem dużych firmy z dużymi zespołami. Pojedynczy programista może koordynować ośmiu agentów którzy pracują jednocześnie, w pewnym sensie pomnażając swoją produktywność co byłoby nie do pomyślenia w przypadku tradycyjnego rozwoju sekwencyjnego.
Połączenie tych dwóch cech – dokładny plan realizowany przez równoległych agentów skoordynowany — i prawdopodobnie najbardziej zaawansowany przepływ pracy dostępny obecnie w środowisku IDE komercyjny. Wymaga praktyki i nauki, ale dla programistów którzy inwestują w jego opanowanie, zwrot jest znaczny.
Kolejne kroki w serii
- Następny: Zaczepy kursora: automatyzuj przepływ pracy - Jak zautomatyzować działania agentów przed i po wykonaniu
- Poprzedni artykuł: Tryb agenta: zmodyfikuj bazę kodu za pomocą polecenia - Kompletny przewodnik po trybie agenta i jego możliwościach
- Powiązany artykuł: Reguły kursora: konfigurowanie sztucznej inteligencji dla twojego projektu - Jak zasady kierują trybem planu i agentami
Połączenia z innymi seriami
- MCP i kursor: Agenci działający w tle mogą używać narzędzi MCP do uzyskuj dostęp do zewnętrznych baz danych i interfejsów API podczas pracy. Zobacz Seria MCP (ID 64-77) po szczegóły.
- Kodowanie Vibe: Tryb planowania i podejście „najpierw specyfikacja” są ze sobą powiązane bezpośrednio do zasad kodowania vibe. Zobacz Seria kodowania Vibe dla uzupełniającej perspektywy.
- Nowoczesny kątowy: W przepływie pracy Angular z kursorem, trybem planowania i idealnym do rusztowania kompletnych modułów. Widzisz Kątowy przebieg pracy z kursorem (ID 297).