Cursor-bakgrundsagenter: kör fler av dem parallellt

Först namnet: Cursors dokumentation säger att "Cloud Agents tidigare kallades Background Agents." Samma produkt, nytt namn — vi använder båda i den här guiden. [3] En bakgrundsagent är en kodningsagent som körs under en lång stund borta från din laptop: uppgiften flyttas till molnet, och en agent för den från start till mål utan avbrott, och rapporterar sedan tillbaka med bevis på att arbetet är klart. [1]

Var och en körs på sin egen dedikerade virtuella maskin med en fullständig utvecklingsmiljö — ditt repo, dina beroenden, hemligheter och nätverksåtkomst. Agenten planerar uppgiften, redigerar kod, kör kommandon och testar sitt arbete under minuter eller timmar, och fortsätter oavsett om din dator är online eller inte. [1] VM:en är sandboxad och isolerad från din lokala dator, och du styr vilka repon, hemligheter och nätverksåtkomst en miljö får. [1]

När arbetet är klart öppnar agenten en pull request — och visar sitt arbete. Under tiden den körs bifogar den skärmdumpar, videor och loggreferenser till PR:en så att du kan validera ändringar utan att checka ut grenen. [1] Cloud Agents kan till och med styra sitt eget skrivbord och sin webbläsare, klicka sig igenom UI-flöden för att verifiera att det de byggt faktiskt fungerar innan de pushar. [2]

Du kan starta en Cursor Cloud Agent från var du redan arbetar: [3]

Automations dokumenteras separat. [4] Innan någon kan starta en agent från ett repo kopplar en Cursor-kontoadmin ihop källkodshantering: GitHub (Cloud och Enterprise Server), GitLab (Cloud och Self-Hosted), Bitbucket Cloud, eller Azure DevOps. [3]

Den centrala funktionen är lätt att missa: du kan köra så många agenter du vill parallellt, och ingen av dem behöver din lokala dator ansluten. [3] Parallellt är hela poängen. En enda bakgrundsagent är en trevlig bekvämlighet; fem som körs samtidigt är en kliv-förändring i hur mycket som levereras per vecka.

Men parallella agenter ändrar vad flaskhalsen är. Agenterna kan koda dygnet runt — vad de inte kan göra är att avgöra vad som är värt att göra, i vilken ordning, och om arbetet faktiskt är klart. Varje agent du lägger till tar av din uppmärksamhet precis när du är som mest upptagen: att skriva nästa uppgift, att granska en nyss avslutad PR, att upptäcka en agent som drivit i väg. Kör tillräckligt många ohanterade och du spenderar dagen med att pendla mellan dashboards istället för att driva produkten.

Det finns ett andra, tystare misslyckande: kvalitet. En agent som körs obevakad i en timme bygger gärna fel sak vackert om instruktionen var vag. Med en agent märker du det. Med tio blir vaga instruktioner i tysthet tio felaktiga pull requests.

Och dessa felaktiga pull requests kostar riktiga pengar. "Cloud Agents debiteras enligt API-prissättning för den valda modellen… ett större kontextfönster kan öka tokenanvändning och kostnader." [3] Parallellitet multiplicerar den notan — så en vag story är inte bara slösad granskningstid, det är tokens spenderade på att bygga fel sak, flera gånger om.

Så kompetensen som räknas med bakgrundsagenter är inte att starta dem — Cursor gjorde det till ett omnämnande bort. Det är att mata dem. De team som får ut mest av parallella agenter är de som kan skriva arbete som är skarpt nog att köras obevakat, och behålla överblick över varje körande agent utan att hänga över någon av dem. Hur många du faktiskt kan hänga med i handlar mest om en granskningskapacitets-fråga.

En anmärkning om den sista praxisen: multi-repo-miljöer låter en enda agent arbeta över separata frontend-, backend-, infrastruktur- eller delade biblioteksrepon och öppna pull requests i varje repo den ändrar. [3] Men även den bästa multi-repo-miljön fungerar en uppgift i taget — att bestämma vad arkitektur-storyn bör vara, över alla dessa repon, är fortfarande ditt jobb. För hur man skriver den, se vår guide till stories för kodningsagenter.

Rättvis fråga. Du kan tilldela ett Linear-ärende till @Cursor så tar en Cloud Agent upp det, [5] och Automations kan starta agenter från GitHub-, Linear- eller Slack-händelser. [4] Cursor är en mycket bra motor. Vad den inte gör är att avgöra vad som ska köras, eller i vilken ordning — den kör vilket ärende du än ger den, när du ger det.

Det är luckan Aerunit fyller. Tänk på Cursor som motorn och Aerunit som dispatchern: den gör ärendet värt att köra, skickar det när det är redo att köras, och skickar granskningsfynd tillbaka till samma agentsession för att fixas.

Ovanpå Cursors egen Linear-integration och Automations lägger Aerunit till fyra saker:

• Den skriver storyna. Du beskriver arbetet; Aerunit läser varje repo storyn berör och föreslår Linear-ärenden med omfång, acceptanskriterier och icke-mål — en huvudstory plus ett underärende per repo för arbete över flera repon.
• Den skickar i beroendeordning. Aerunit följer Linears blocks/blocked-by-relationer, så när en PR mergeas skickas ärendena den blockerade automatiskt till Cursor Cloud Agents — ingen manuell utskickning.
• Den granskar varje PR. När en agent öppnar en pull request kör Aerunit en kodgranskning och skickar fynden tillbaka till samma agentsession för att fixas — så att agenten som skrev koden är den som fixar den.
• Den visar hela flottan. En lista över varje pågående Cloud Agent-session, var och en länkad till sitt Linear-ärende — meddela flera samtidigt, arkivera avslutade.