04 – Režim plánu a agenti na pozadí: Pracujte chytřeji, nikoli rychleji
Je přesně okamžik, kdy si mnoho vývojářů uvědomí, že Agent Mode je tradiční to nestačí. Výzva je správná, kontext je poskytnut, ale agent okamžitě začne psát kód než jsem problém skutečně pochopil. Přidejte soubory, které nejsou potřeba, upravte třídy, které nejsou potřeba museli dotknout a po dvaceti minutách autonomního provádění zjistíte, že máte kódovou základnu, která funguje ale rostla špatným směrem.
Odpověď kurzoru na tento problém se nazývá Režim plánu. Před psaním a jeden řádek kódu, agent analyzuje projekt, klade objasňující otázky, generuje plán strukturován v Markdown a požádá vás o schválení. Teprve když zkontrolujete a potvrdíte každý krok, exekuce začíná. A radikálně odlišná filozofie: přemýšlejte, než začnete kódovat.
Vedle Plan Mode představil Cursor 2.0 i Pozadí agenti: Procesy AI které pracují paralelně na izolovaných větvích git prostřednictvím pracovních stromů. Zatímco píšete kód na větev hlavní, až osm agentů může pracovat současně na různých úkolech, každý v a zcela oddělené prostředí, aniž by to narušovalo vaši práci nebo sebe navzájem.
V tomto článku pro pokročilé prozkoumáme obě funkce do hloubky: jak fungují a kdy používat je, jak je kombinovat a jaké vzory jsou nejúčinnější pro komplexní vývojové pracovní postupy.
Co se dozvíte v tomto článku
- Jak Plan Mode mění paradigma vývoje s pomocí AI
- Kompletní pracovní postup: od rychlého generování po schválení plánu
- Co je agent na pozadí a jak fungují pracovní stromy git v Cursoru
- Jak spustit až 8 paralelních agentů pomocí Cursor 2.0
- Řízení misí: Monitorujte a spravujte běžící agenty
- Praktické případy použití: lešení funkcí, paralelní opravy chyb, projekty migrace
- Dlouhodobí agenti: limity, osvědčené postupy a řízení nákladů
- Jak pravidla kurzoru vedou generovaný plán
- Skutečné limity a řešení testované ve výrobě
Pozice v řadě: Cursor IDE a AI-Native Development
| # | Položka | Úroveň |
|---|---|---|
| 1 | Cursor IDE: Kompletní průvodce pro vývojáře | Začátečník |
| 2 | Pravidla kurzoru: Konfigurace AI pro váš projekt | Střední |
| 3 | Režim agenta: Upravte kódovou základnu pomocí příkazu | Střední |
| 4 | Režim plánu a agenti na pozadí (jste zde) | Moderní |
| 5 | Háčky kurzoru: Automatizujte pracovní postup | Střední |
| 6 | MCP a kurzor: Připojte IDE k databázi a API | Moderní |
| 7 | Ladění pomocí kurzoru AI: 3x rychlejší | Střední |
| 8 | Cursor vs Windsurf vs Copilot v roce 2026 | Začátečník |
| 9 | Profesionální pracovní postup: Úhlový projekt s kurzorem | Moderní |
Co je plánovací režim a jak se liší od režimu agenta
Abyste pochopili režim plánu, musíte nejprve porozumět problému, který řeší. V Režim agenta standardní, tok je přímý: zadáte pokyn, agent si přečte příslušné soubory a spustí se okamžitě realizovat. Tento přístup je účinný pro omezené a dobře definované úkoly, ale systematicky selhává ve složitých nebo nejednoznačných problémech.
Představte si, že se zeptáte agenta: "Refaktorujte ověřovací modul tak, aby podporoval OAuth2 s Google a GitHub". Agent v normálním režimu může začít upravovat existující autentizační soubory, aniž byste věděli, že používáte JWT, že máte vlastní middleware, nebo že architektura zahrnuje správu relací na straně serveru. Výsledkem je správný kód abstraktně, ale špatně v kontextu vašeho projektu.
Filozofie „Přemýšlejte, než začnete kódovat“.
Režim plánu zavádí a deliberační vrstva před popravou. Kdy aktivujete režim plánu, agent nepíše kód: klade otázky, prohledává kódovou základnu, identifikuje závislosti a omezení, pak vytvoří strukturovaný dokument, který přesně popisuje co hodlá dělat, soubor po souboru, krok za krokem.
Plán je upravitelný soubor Markdown. Můžete jej upravit, odstranit kroky, se kterými nesouhlasíte, přidat omezení, která agent nezohlednil, opravit nesprávné předpoklady. Jen když jste spokojeni, klikněte na "Vytvořit" a realizace začne podle schváleného plánu.
Kdy použít režim plánu vs režim agenta
Volba mezi těmito dvěma režimy závisí především na složitosti a nejednoznačnosti úkolu:
Průvodce výběrem režimu
| Charakteristika úkolu | Doporučený režim |
|---|---|
| Jednoduchý, dobře definovaný úkol (oprava chyby, přidána funkce) | Režim přímého agenta |
| Komplexní funkce, která ovlivňuje více modulů | Režim plánu |
| Architektonický refaktoring | Režim plánu je povinný |
| Migrace (rámce, databáze, knihovny) | Režim plánu + agenti na pozadí |
| Úkoly, které dobře znáte a které jste již udělali | Režim agenta se specifickými pravidly |
| Neznámá nebo zděděná kódová základna | Režim plánu vždy |
| Strukturovaná typická generace | Režim plánu nebo agent se šablonou |
Jak režim plánu funguje: Od výzvy k spustitelnému plánu
Režim plánu se aktivuje stisknutím Shift + Tab ve vstupním poli agenta, popř je automaticky navrženo kurzorem, když detekuje složitý požadavek. Jednou aktivovaný, je proudění rozděleno do čtyř odlišných fází.
Fáze 1: Výzkum a analýza Codebase
Agent nezačíná z výzvy: začíná z kódové základny. Použití stejných nástrojů jako v režimu agenta (sémantické vyhledávání, čtení souborů, grep), prozkoumejte projekt, abyste pochopili kontext. Identifikovat relevantní soubory, čte existující dokumentaci, analyzuje závislosti a vztahy mezi moduly.
Během této fáze může agent dělat upřesňující otázky. Pokud je vaše požadavek a nejednoznačný v kritickém bodě vás požádá o upřesnění, než budete pokračovat. Tyto otázky jsou cenné: často odhalují implicitní předpoklady, o kterých jste neuvažovali.
Fáze 2: Vytváření plánu
Jakmile je analýza dokončena, agent vygeneruje strukturovaný dokument Markdown. Plán obsahuje: shrnutí cíle, analýzu příslušných souborů, seznam očíslovaných kroků s podrobným popisem, cestou k souborům, které budou vytvořeny nebo upraveny, a potenciálem rizika nebo závislosti, které je třeba řídit.
S Cursor 2.2 mohou plány také zahrnovat Schémata mořské panny vytvořené automaticky vizualizovat toky, architektury a vztahy mezi komponentami.
Zde je příklad vygenerovaného plánu pro refaktoring ověřování:
# 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)
Fáze 3: Kontrola a úprava plánu
Plán se otevře jako soubor Markdown v editoru. Můžete jej upravit přímo: odstranit zbytečné kroky, přidat omezení, opravit názvy souborů, určit přístupy alternativy. Toto je nejdůležitější fáze: váš zásah určuje kvalitu příštího provedení.
Častá chyba, které je třeba se vyhnout
Bez přečtení plán neschvalujte. Pokušení okamžitě kliknout na „Vytvořit“ je silné, ale to je přesně to, kde se režim plánu liší od režimu agenta: vaše recenze a část integrální součástí procesu. Plán schválený bez kontroly je horší než režim agenta přímý, protože vám dává falešný pocit kontroly.
Fáze 4: Plánem řízené provedení
Kliknutím na "Build" přejde kurzor do režimu agenta, ale s plánem jako strukturovaným průvodcem. Agent provádí kroky v definovaném pořadí a používá plán jako „specifikaci“. odkaz. Můžete sledovat pokrok v reálném čase: každý dokončený krok je označené a agent hlásí jakékoli odchylky od původního plánu.
Pokud se během provádění objeví neočekávaný problém, agent se zastaví a zeptá se vás pokyny namísto samostatného postupu směrem k potenciálně nesprávnému řešení.
Agenti na pozadí: Architektura a provoz
Zatímco plánovací režim řeší problém s kvalitou provedení, tj Pozadí agenti řeší problém rychlosti a paralelismu. Představeno s Cursor 2.0 v listopadu 2025, vám umožní spouštět až osm agentů současně, každého v jednom prostředí git zcela izolovaný.
Git Worktrees: Základní technologie
Pozadí Agenti jsou založeni na pracovní stromy git, nativní funkce git, který vám umožňuje mít více pracovních adresářů spojených se stejným úložištěm, každý z nich na jiné větvi. Na rozdíl od tradičního klonu (který duplikuje celé úložiště na disku), pracovní strom a lehký: sdílí úložiště objektů git a vyžaduje pouze místo pro soubory, které se ve skutečnosti mezi větvemi liší.
Pro kurzor to znamená, že každý agent na pozadí má:
- Un vyhrazená větev git na kterém pracuje izolovaně
- Una samostatný pracovní adresář na místním souborovém systému
- Un samostatný index kódové báze pro sémantické vyhledávání
- Žádné rušení s vaší prací nebo s jinými agenty
Výsledkem je, že můžete pracovat na větvi main zatímco tři agenti upravují
funkce/autorizace, funkce/panel a oprava/výkon současně, aniž byste museli vstoupit
v konfliktu.
Spouštění agentů na pozadí pomocí kurzoru 2.0
Pro spuštění paralelních agentů existují dva hlavní přístupy. První a nejčastější: z panelu Skladatel otevřete novou kartu agenta a přiřaďte jí konkrétní úkol. Každá karta představuje nezávislého agenta, který může pracovat na pozadí.
Druhý přístup, představený s Cursor 2.0, umožňuje spouštět více agentů ze stejné výzvy: hlavní agent obdrží pokyn, rozloží jej na dílčí úkoly a vytvoří podřízené agenty, kteří na každém pracují paralelně dílčí úkoly. Podřízení agenti nyní mohou být asynchronní, což umožňuje rodičům pokračovat, zatímco děti vystupují.
# 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
Asynchronní agenti a rekurzivní spawn
Jednou z nejvýznamnějších inovací Cursoru 2.2 je schopnost agentů pracovat svým způsobem zcela asynchronní. V předchozích verzích, když agent hlavní spawnovaní podagenti museli čekat, než se každý dokončí pokračovat. Nyní může rodič pokračovat, zatímco děti pracují paralelně.
Ještě silnější je schopnost sub-agentů zplodit své vlastní sub-agenty, vytvoření a koordinovaný pracovní strom. Hlavní agent může delegovat funkci A na dítě, které zase rozdělí práci mezi vnouče na testování a vnuka na realizaci. Kurzor se stará o synchronizaci stromu a předkládá vám výsledky koherentním způsobem.
Řízení mise: Monitorujte paralelní agenty
Vzhledem k tomu, že více agentů pracuje současně, je důležité mít přehled o tom, co děje se to. Cursor 2.0 přepracoval rozhraní s paradigmatem zaměřený na agenta: Místo správy souborů řídíte procesy.
Panel agentů
Na postranním panelu kurzoru najdete panel aktivních agentů. Pro každého agenta přijdou ukaž se:
- Jméno a úkol přiřazeno (odvozeno z úvodní výzvy)
- Větev git na kterém pracuje
- Stát: běží, čeká na vstup, dokončeno, došlo k chybě
- Proveden poslední krok s podrobným logem
- Soubory upraveny v aktuální relaci
- Spotřebované tokeny a odhad nákladů
Komunikujte s výkonnými agenty
Kliknutím na kteréhokoli agenta otevřete jeho historii chatu, zobrazíte soubory které upravil, dát nové pokyny nebo přerušit provádění. Pokud agent zasekne nebo jde špatným směrem, můžete jej zastavit kliknutím a přesměrovat jej novou zprávou.
Užitečné zkratky pro Mission Control
| Akce | Zkratka / Metoda |
|---|---|
| Nový agent pozadí | Cmd+Shift+N na panelu Skladatel |
| Přepíná mezi agenty | Klikněte na panel agentů nebo Cmd+Shift+Tab |
| Povolit režim plánu pro agenta | Shift+Tab ve vstupu agenta |
| Zastavit běh agenta | Klikněte na tlačítko stop v záhlaví agenta |
| Zkontrolovat rozdílový agent | Klikněte na "Změněné soubory" na panelu agenta |
| Povolit zobrazení pracovního stromu SCM | Nastavení git.showCursorWorktrees: true |
Praktické případy použití
Případ 1: Funkce lešení s režimem Plán
Typický scénář: Ke stávající aplikaci potřebujete přidat kompletní modul. Bez režimu plánu může agent generovat formulář s různými konvencemi od zbytku projektu nebo ignorovat konsolidované architektonické vzory.
V režimu Plán je tok:
- Otevřete Composer a stiskněte Shift+Tab aktivovat režim plánu
- Popište funkci: "Přidat modul oznámení v reálném čase přes WebSocket, uživatelské předvolby a správu historie"
- Agent analyzuje projekt: identifikuje existující vzory, konvence pojmenování, architekturu modulu
- Klade vám otázky: "Používá projekt Redux nebo kontextové API pro správu stavu?", "Mám zahrnout testy, nebo je zpracujete samostatně?"
- Vytvořte plán s přesnou strukturou souborů, respektujte konvence projektu
- Zkontrolujete, případně odstraníte kroky (např.: "nepřidávejte příběhy z Pohádkové knihy, nepoužíváme je")
- Klepněte na tlačítko Sestavit a formulář je od prvního pokusu správně vytvořen
Případ 2: Oprava chyb Parallels s agenty na pozadí
Máte seznam 4 izolovaných chyb, každá v jiných modulech aplikace. Místo toho opravte je postupně, můžete paralelizovat:
# 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
Výhoda není jen dočasná. S opravami izolovanými na samostatných větvích, recenze a mnohem jednodušší: každé PR se dotýká pouze jednoho problému, rozdíl je minimální a pochopitelný.
Případ 3: Projekt migrace s plánem + agenty na pozadí
Nejsilnější případ použití: komplexní migrace, která vyžaduje plánování přesnost a rovnoběžnost. Například migrujte aplikaci z JavaScriptu na TypeScript.
Optimální pracovní postup:
- Pomocí režimu plánu vygenerujte kompletní strategii migrace
- Plán identifikuje 30 souborů seskupených do 4 klastrů závislostí
- Spusťte 4 agenty na pozadí, jednoho na každý cluster
- Každý agent má jako kontext hlavní plán plus jeho podmnožinu souborů
- Zatímco agenti pracují, vy monitorujete z řízení misí a řídíte konflikty
- Po dokončení zkontrolujte 4 větve a sloučte je ve správném pořadí
Dlouhotrvající agenti: Jak fungují a co očekávat
Agenti pozadí kurzoru mohou pracovat pro prodloužené relace, i když zavřeli jste IDE. Tato funkce je užitečná zejména pro úkoly, které vyžadují desítky minut i více, např. migrace, rozsáhlé generování testů popř hloubková analýza kódové základny.
Kontinuita relace
Na rozdíl od jednoduchého chatovacího okna si agent na pozadí udržuje své vlastní stav mezi relacemi. Můžete spustit agenta, zavřít notebook a až se vrátíte agent pokračoval v práci (pokud je nakonfigurován ke spuštění na vzdálených počítačích). Kurzor podporuje obě provedení místní (proces se zastaví, když buď zavřete IDE). vzdálený (agent pokračuje v cloudu infrastruktury).
Token a limity nákladů
Dlouhotrvající agenti spotřebují mnoho žetonů. Důležité je sledovat spotřebu abyste se vyhnuli překvapením při účtování. Kurzor zobrazuje žetony v reálném čase spotřebované pro každého agenta v ovládacím panelu mise.
Věnujte pozornost nákladům na paralelní agenty
Každý agent pozadí spotřebovává tokeny nezávisle. Spusťte 8 agentů paralelně může spotřebovat 8násobek tokenů jednoho agenta v tomtéž období. U plánu Pro (20 $/měsíc) máte měsíční limit: spravujte paralelismus opatrně. Používejte paralelní agenty pro úkoly, které z nich skutečně těží paralelizace, ne jako výchozí pro každou operaci.
Režim plánu a pravidla kurzoru: Výkonná synergie
Režim plánu nefunguje izolovaně: je silně ovlivněn Pravidla kurzoru nakonfigurované v projektu. Když agent generuje pravidla fungují jako omezení a vodítka, která utvářejí jeho obsah.
Jak pravidla vedou plán
Pokud máte definovaná pravidla jako "vždy používejte 3vrstvou čistou architekturu" o "každá nová funkce musí zahrnovat testy jednotek s Jest", vytvořený plán automaticky zohlední tato omezení. Agent nenavrhne vložit logiku činnosti správce, pokud pravidla specifikují oddělení obav.
# 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
Pravidla pro optimalizaci plánů
Můžete také vytvořit pravidla specifická pro režim plánu, která vedou strukturu samotného plánu, nejen jeho realizace:
# 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
Skutečné limity a řešení
Režim plánu a agenti na pozadí jsou výkonné funkce, ale nejsou bez omezení. Znát limity je stejně důležité jako znát schopnosti.
Režim plánu: Halucinace v rovině
Plán může obsahovat chyby: neexistující cesty k souborům, nesprávné předpoklady na architektuře, nadbytečné nebo chybějící kroky. Agent dělá maximum pochopit projekt, ale pokud je kódová základna velká nebo špatně zdokumentovaná, můžete se mýlit.
zástupná řešení: Přinutit agenta, aby během analýzy uváděl přesné cesty. Přidat do výzvy: „Před vygenerováním plánu uveďte seznam souborů, které jste našli ve vašem výzkumu a potvrďte, že jsou správné“. Tento "kontrolní bod" výrazně snižuje chyby v konečném plánu.
Agenti na pozadí: Konflikty sloučení
Pokud dva agenti upraví stejný soubor na různých větvích, v době sloučení budete mít konflikty. Kurzor automaticky nezpracovává sémantické sladění: sloučení je vaše práce.
zástupná řešení: Před spuštěním paralelních agentů plán analyzujte a ujistěte se, že úkoly jsou skutečně nezávislé. Pokud se dva agenti musí dotýkat stejný soubor (např. centrální směrovací soubor), sekvence, které konkrétní úkol a zbytek paralelizovat.
Dlouhý kontext v dlouhých plánech
U velmi velkých projektů může být vygenerovaný plán tak dlouhý, že během provádění nevstoupí do kontextového okna agenta. Výsledek and that the final steps of the plan are executed with less context and can být méně přesný.
zástupná řešení: Rozbít velké plány. Ke generování použijte režim plánu „metaplán“, který identifikuje hlavní fáze, a poté znovu použije režim plánu vytvořit podrobné plány pro každou fázi. Tento vodopádový přístup udržuje kontext spravovatelný pro každý krok.
Blokování agentů na externích závislostech
Agent, který potřebuje například dotazovat databázi nebo volat externí API k dokončení úkolu zablokuje, pokud tyto zdroje nejsou přístupné v místním nebo vzdáleném vývojovém prostředí, ve kterém běží.
zástupná řešení: Pomocí pravidel kurzoru určete, jak zacházet vnější závislosti: „Pokud potřebujete reálná data z DB, použijte soubor příslušenství/sample-data.json jako maketa". To agentům umožňuje postupovat i bez přímého přístupu k externím zdrojům.
Osvědčené postupy pro režim plánu a agenty na pozadí
1. Systematické přezkoumání plánu
Stanovte proces kontroly plánu před jeho provedením. Neomezujte se pro rychlé posouvání: zkontrolujte, zda je každý krok přiměřený, zda soubory skutečně existují, že exekuční příkaz je správný. Dobře zkontrolovaný plán má za následek téměř vždy úspěšné provedení.
2. Před spuštěním agentů se zavázat
Před spuštěním jakéhokoli agenta (v režimu plánu nebo na pozadí) vždy udělejte potvrzení vaší aktuální práce. Git worktrees fork z vaší HEAD current: čistý pracovní adresář zajišťuje, že se agent větví začít od známého a stabilního stavu.
3. Granulární úkoly pro paralelní agenty
Agent nejlépe pracuje s dobře definovaným a omezeným úkolem. Odolávejte pokušení dát agentovi velké úkoly ("Implementace všech modulů elektronického obchodu"): rozdělte je na menší úkoly, které můžete paralelizovat. Paralelnost dobře granulovaný a spolehlivější než paralelní monolitismus.
4. Poprvé použijte plánovací režim na kódové základně
Když pracujete na kódové základně, kterou dobře neznáte (zděděný projekt, open source, do kterého přispíváte, nový zákazník), vždy používejte režim plánu na první úkoly. Vygenerovaný plán vám poskytne rychlý pohled na vzory architektonické aspekty projektu, a to i v případě, že se poté rozhodnete jej nerealizovat.
5. Optimalizace nákladů
Ne všechny úkoly vyžadují režim plánu. Používejte plánovací režim selektivně pro i složité úkoly. Pro jednoduché úkoly (přejmenování proměnné, přidání importu, opravit překlep v dokumentu), režim agenta přímý, efektivnější a levnější. Náklady na režim plánu zahrnují analýzu i provádění.
6. Přehled rozdílů před sloučením
Jakmile agent na pozadí dokončí svůj úkol, neslučujte se automaticky.
USA git diff main...feature/agent-branch přezkoumat každého
upravit. Rozdíly agentů jsou obecně čisté a dobře organizované,
ale lidská kontrola zůstává před integrací zásadní.
Režim plánu vs. jiné přístupy plánování AI
Plánovací režim není jediným přístupem k plánování s pomocí AI, ale přináší některé charakteristické rysy ve srovnání s alternativami.
Nejběžnějším alternativním přístupem je ruční zápis technické specifikace v dokumentu a poté jej předejte agentovi jako kontext. Tohle funguje, ale trvá to mnohem déle a nevyužívá schopnosti agenta analyzovat kódovou základnu nezávisle identifikovat relevantní soubory.
GitHub Copilot Workspace, spuštěný v roce 2024, nabízí podobné funkce jako Režim plánu integrovaný do problémů GitHubu. Kopilot analyzuje problém, generuje plán a může PR otevřít automaticky. Výhoda a integrace kurzoru přímo s editorem: plán je generován a prováděn ve stejném prostředí, s plnou viditelností do místního kódu a struktury projektu.
Závěry
Režim plánu a agenti na pozadí představují kvalitativní skok v cestě kde mohou vývojáři spolupracovat s AI. Není to jen o urychlit práci: jde o změnu typu práce, kterou můžete delegovat.
S režimem plánu, komplexními funkcemi, které dříve vyžadovaly iterativní režim agenta a mnoho dozoru se stává strukturovanými procesy s plánem schváleným jako první exekuce. Kvalita generovaného kódu se zlepšuje, protože agent se spustí z hlubokého pochopení problému, nikoli z obecné výzvy.
S agenty na pozadí již není paralelismus výsadou těch velkých společnosti s velkými týmy. Jeden vývojář může organizovat osm agentů kteří pracují ve stejnou dobu a svým způsobem znásobují svou produktivitu což by bylo při tradičním sekvenčním vývoji nemyslitelné.
Kombinace těchto dvou vlastností - přesný plán prováděný paralelními agenty koordinovaný – a pravděpodobně nejpokročilejší pracovní postup, který je dnes v IDE k dispozici komerční. Vyžaduje to praxi a křivku učení, ale pro vývojáře kteří investují do jeho zvládnutí, návratnost je značná.
Další kroky v sérii
- Další: Háčky kurzoru: Automatizujte pracovní postup - Jak automatizovat akce agentů před a po provedení
- Předchozí článek: Režim agenta: Upravte kódovou základnu pomocí příkazu - Kompletní průvodce režimem agenta a jeho možnostmi
- Související článek: Pravidla kurzoru: Konfigurace AI pro váš projekt - Jak pravidla řídí režim plánu a agenty
Spojení s jinými řadami
- MCP a kurzor: Agenti na pozadí mohou používat nástroje MCP přistupovat k externím databázím a rozhraním API za běhu. Viz Řada MCP (ID 64-77) pro podrobnosti.
- Vibe kódování: Režim plánu a přístup „specifikace na prvním místě“ jsou propojeny přímo na principy vibračního kódování. Viz Řada Vibe Coding pro doplňkovou perspektivu.
- Moderní hranaté: V Angular workflow s kurzorem, plánovacím režimem a ideálem na lešení kompletních modulů. Vidíš Angular Workflow with Cursor (ID 297).