Hos Cursor har et team bygget en agent, der læser hver eneste pull request og sammenholder den med en database over erfaringer fra tidligere fejl. Står ændringen i modsætning til noget, holdet allerede har lært, siger agenten det og henviser til den note, der gælder. Ifølge Cursor tog den agent, kb-reviewer, omkring en dag at bygge. Den er lavet med Agent SDK, som Cursor lancerede som færdigt produkt 20. oktober.
Agent SDK er en ramme til at bygge agenter, der kører automatisk og defineres i kode. Prompten er en Markdown-fil, hvert værktøj er en TypeScript-funktion, og det hele ligger i versionsstyring ved siden af resten af koden. Det er det samme værktøj, Cursor selv bruger til sine egne agenter som Bugbot, Security Reviewer og Rollouts. Søger du på Cursor SDK eller Cursor-agenter, er det her den nyeste brik.
Cursor Agent SDK er værktøjet bag Bugbot
De fleste værktøjer til AI-agenter har hidtil fået dig til at vælge mellem to ting. Enten konfigurerer du en agent i et dashboard med nogle få klik, eller også bygger du hele maskinrummet selv med sessions, hemmeligheder, logning og deployment. Cursors svar ligger midt imellem: du skriver selve agenten, og Cursor leverer resten. Forskellen på et fast workflow og hvad en AI-agent er ligger i, hvem der vælger trinene, og her vælger modellen selv inden for de værktøjer, du har skrevet.
Agenterne reagerer på hændelser i de systemer, et udviklingshold allerede bruger. En pull request på GitHub, GitLab eller Bitbucket kan sætte dem i gang, og det kan en kommentar eller et CI-resultat også. Det samme gælder en omtale eller en direkte besked i Slack, et webhook fra et vilkårligt system eller et fast tidspunkt via cron. GitHub-hændelser kommer ind via Cursor-kontoen, så du behøver ikke åbne en offentlig webhook-adresse.
Agenterne kan også træffe beslutninger efter regler. En agent kan vurdere, hvor risikabel en ændring er, sende den til det rigtige team eller godkende den, hvis den opfylder holdets politik. Større opgaver kan den give videre til en specialiseret agent med egne værktøjer eller dele ud på flere underagenter, der arbejder parallelt.
En agent er en mappe i dit repo
Det, der adskiller Agent SDK fra en automation i et dashboard, er formen. En agent er en mappe med en fast struktur:
instructions.mder agentens prompttools/indeholder én typet handling per fil, som modellen kan kaldeskills/rummer procedurer, som modellen henter ind, når der er brug for demmcp-connections/kobler værktøjer fra MCP-servere påchannels/bestemmer, hvor agenten modtager og besvarer beskeder
Fordi det hele er filer, gælder de samme regler som for anden kode. En ændring i agentens prompt går gennem code review, før den bliver aktiv. Du kan se i historikken, hvem der gjorde agenten strengere i sidste måned, og rulle det tilbage, hvis den begyndte at afvise for meget. For en agent, der må godkende ændringer på egen hånd, er netop det sporbare spor sjældent en luksus.
Du behøver heller ikke starte fra bunden. Cursor leverer skabeloner til en sikkerhedsreviewer, en agent der godkender efter en ejerskabspolitik, en agent der selv retter fejl i pull requests og en, der sorterer sager i Linear eller Jira. SDK'en har også skills med, som guider en kodeagent gennem at bygge en ny agent, så du kan pege din egen kodeagent på dokumentationen og lade den gøre grovarbejdet.
Test agenten på gårsdagens pull requests
Det sværeste ved agenter i drift er ikke at få dem til at virke én gang. Det er at vide, om de stadig opfører sig ordentligt, efter at nogen har rettet i prompten. Her har Agent SDK to ting med fra start.
Den ene er evals. Et eval sender en fast besked til agenten og kontrollerer, hvilke værktøjer den kalder, med hvilke input, og hvilken form svaret har. Det minder om en almindelig test, bare for en agent, hvis svar aldrig er helt ens to gange. Den anden er replay. Kommandoen agent-sdk github replay tager en rigtig pull request og laver den om til signerede webhook-data, som du kan afspille mod agenten lokalt eller gemme som testdata.
I praksis betyder det, at du kan tage de ti pull requests fra sidste uge, hvor agenten traf en forkert beslutning, og bruge dem som testsæt. Retter du prompten, kører du dem igen og ser, om rettelsen holder, før agenten møder nye ændringer. Hver samtale gemmer også sin egen session med fuld log over beskeder og værktøjskald, og et opfølgende svar i samme pull request eller Slack-tråd fortsætter den session.
I Cursors sky eller i din egen container
Når agenten er klar, bygger agent-sdk deploy den, giver den en adresse og starter den på Cursors infrastruktur. Hemmeligheder og integrationer styres fra Cursors dashboard, og logs, evals og en legeplads til afprøvning virker på samme måde lokalt og efter deployment. Vil du hellere selv drive den, er hver agent én Node-proces, som kan pakkes i en container og køre på egne servere.
Den mulighed er relevant for alle, der har krav om, hvor data og logs må ligge. Men selvhosting gør ikke agenten uafhængig af Cursor. Eksemplet i lanceringen bruger Cursors egen model, Composer 2.5, og den model findes kun hos Cursor. Ifølge Cursors prisside koster den omkring 3 kr. per million input-tokens og 16 kr. per million output-tokens i standardudgaven, mens den hurtige udgave, som eksemplet slår til, koster seks gange så meget. Hvad selve SDK'en og hostingen koster, står der ikke noget om i lanceringen.
Regn på det, før du slipper agenten løs. En agent, der vågner ved hver pull request og hver Slack-besked, kører mange flere gange end en udvikler, der åbner en chat. Store eval-sæt, der køres ved hver ændring af prompten, tæller også med. Prisen per kørsel er lille, men det er antallet af kørsler, der afgør regningen.
Hvornår er en automation nok?
Cursor har allerede Automations, hvor man i dashboardet sætter en agent op til at køre efter skema eller hændelse. Cursors egen dokumentation trækker grænsen ret præcist: Automations passer til opgaver, der kan beskrives som en udløser og en instruks, mens Agent SDK er til hold, der vil have agentkode, som kan versioneres, reviewes og testes.
Tommelfingerreglen er derfor enkel. Opsummerer agenten bare noget og poster det i en kanal, er et dashboard nok. Må agenten godkende, afvise eller ændre noget, som andre bygger videre på, bør den behandles som kode med review, test og historik. Det er samme logik, som gør AI-agenter i skyen uden egen infrastruktur interessante hos Anthropic, men Cursor går et skridt længere og lægger hele agenten ind i repoet.
En af de første kunder er golforganisationen PGA, der ifølge Cursor har bygget hele sin softwarefabrik, altså kæden af agenter rundt om udviklingsarbejdet, på SDK'en. Det er et stort ord for et værktøj, der har været ude som færdigt produkt i godt en uge. Det tydeligste tegn er alligevel, at Cursor har bygget sine egne betalte produkter med det, og at kb-reviewer kun tog en dag. En agent, der kan bygges på en dag og testes på sidste uges pull requests, er ikke længere et forskningsprojekt. Den er bare endnu en mappe i repoet.
Kilde: Cursor
