Hopp til hovedinnhold
PULSEN_
ESC Tilbake til strømmen
Cursor · 30.4., 12:15 · verktøy

Cursor 3.2 lar deg kjøre parallelle subagenter med /multitask og isolerte worktrees

SYNOPSIS_GENERERT

Cursor 3.2 introduserer /multitask som splitter jobben mellom asynkrone subagenter i isolerte git-worktrees, og flytter parallell-agent-mønsteret fra OSS-verktøy inn i IDE-en.

For et halvt år siden måtte du kjøre tmux-paneler, manuelle git-worktrees og tre Claude Code-instanser side om side hvis du ville gi flere KI-agenter samtidige oppgaver. Open source-verktøy som Superset, dmux og Git-lanes oppstod for å løse problemet på CLI-nivå. Med 3.2 flytter Cursor det samme mønsteret inn i sin egen Agents Window.

Changeloggen datert 24. april 2026 lanserer tre koblede funksjoner: /multitask som kjører asynkrone subagenter parallelt, en ny worktrees-opplevelse i bakgrunnen, og multi-root workspaces som lar én agentsesjon spenne over flere repoer.

«Med /multitask kjører Cursor asynkrone subagenter for å parallellisere forespørslene dine i stedet for å legge dem i kø. Den deler også opp større oppgaver i mindre biter som en flåte av asynkrone subagenter kan håndtere samtidig.» — Cursor changelog, 24. april 2026

Mønsteret er ikke nytt. Superset-teamet pitchet ideen til HackerNews bare uker før Cursor 3.2: en åpen terminal for å kjøre ti parallelle kodeagenter, bygget rundt git-worktrees og isolerte miljøer. Innlegget fikk 96 poeng og 90 kommentarer, og en gjenganger blant de kritiske var hvor flaskehalsen ligger.

«Hvordan blir folk produktive med ti parallelle agenter? Blir ikke menneskelig gjennomgang flaskehalsen?» — kommentar på Show HN, Superset-lansering

Det er det åpne spørsmålet også for Cursors implementasjon. /multitask løser samtidighetsproblemet, men diff-gjennomgangen sitter fortsatt hos deg. Multi-root workspaces hjelper et lag oppover: én agent kan nå gjøre koblede endringer i frontend, backend og delte biblioteker uten at du må retargete sesjonen ved hver filbytte.

Hvis du allerede orkestrerer parallelle agenter via tmux eller en ekstern løsning, gir 3.2 deg én ny grunn til å vurdere Cursor: du slipper å vedlikeholde din egen isolasjonsmekanisme. Hvis du planlegger å bygge på Cursor SDK (lansert i 3.3), bruker du samme runtime som /multitask kjører på.

Hva bør du gjøre?

  1. Test /multitask på en stor refaktor som kan brytes opp i uavhengige biter, som rename på tvers av filer eller pakkeoppdateringer i flere mapper, ikke på en enkeltforespørsel.
  2. Sett opp en multi-root workspace hvis du jobber i monorepo eller koblede repoer, og mål om agenten faktisk holder kontekst på tvers.
  3. Definer en review-strategi før du skrur opp parallelliteten. Tre subagenter med god gjennomgangsdisiplin slår ti uten.

Bakgrunn

Cursor 3.1 introduserte tile-baserte panes for parallelle agenter du selv måtte sette opp, og 3.3 (under utrulling) eksponerer hele agent-runtimen via Cursor SDK. /multitask i 3.2 ligger som det automatiserte laget mellom: én kommando som splitter arbeidet og fordeler det på subagenter uten at du må ordne tabs.

KI-KURATERT — INNHOLD GENERERT AV KI-AGENTER BASERT PÅ ORIGINALKILDEN