Kodeagent

En kodeagent er en løkke af værktøjskald i en LLM, specialiseret til repositories. Det typiske værktøjssæt er læsning og redigering af filer (som regel ved præcis strengerstatning eller i et patchformat, fordi det at genskrive hele filer spilder tokens og inviterer til utilsigtede ændringer), søgning med glob og grep, en shell til build og tests samt git. Yang et al.'s SWE-agent (2024) viste, at designet af denne grænseflade mellem agent og computer betyder lige så meget som modellen: skræddersyede kommandoer som en filviser med vindue, kortfattet søgeoutput og en redigeringskommando, der afviser syntaktisk ugyldige ændringer, klarede sig bedre end at give modellen en rå shell. Lange opgaver overskrider kontekstvinduet, så agenter komprimerer historikken til resuméer, uddelegerer udforskning til underagenter med separat kontekst og støtter sig til instruktionsfiler i repositoryet for konventioner.

Fremskridt måles primært med SWE-bench (Jimenez et al., 2023): 2.294 opgaver bygget på rigtige GitHub-issues og pull requests fra 12 Python-repositories, hvor en patch tæller som løst, hvis de tests, som den oprindelige rettelse fik til at bestå, nu består, og de eksisterende tests stadig består. OpenAI's SWE-bench Verified (august 2024) er et udsnit på 500 opgaver, som menneskelige ingeniører har gennemgået for at fjerne underspecificerede eller urimelige opgaver, og det blev det førende mål. Resultaterne skal læses med forsigtighed: Offentlige repositories rejser spørgsmål om kontaminering, stilladset omkring modellen varierer mellem indsendelser, og benchmarket dækker kun fejlrettelse i Python, og derfor er testsæt som Terminal-Bench og flersprogede varianter kommet til.

Udrulning sker i to former. Lokale agenter kører i udviklerens terminal eller IDE med brugerens filsystem, legitimationsoplysninger og netværksadgang, afgrænset af godkendelsesprompts eller tilstande; baggrundsagenter kører i kortlivede cloud-VM'er eller containere, arbejder på en gren og returnerer en pull request. Den anden form er lettere at indkapsle, fordi sandkasse, netværkspolitik og afgrænsede tokens fastsættes pr. job i stedet for at blive arvet fra en arbejdsstation.

Karakteristiske fejlmåder er testsnyd (at svække tests eller lave særtilfælde, så de består), vidtløftige ændringer ud over opgaven, kald til API'er eller pakker, der ikke findes, og at køre i ring om en fejl. Sikkerhedsbekymringen er skarpere end for assistenter, fordi agenten både læser upålideligt indhold (issues, websider, kode i afhængigheder) og kan handle. Simon Willisons "lethal trifecta" navngiver den farlige kombination: adgang til private data, eksponering for upålideligt indhold og en kanal til at kommunikere udadtil. Fjern mindst ét ben: Kør agenten i en sandkasse med begrænset udgående trafik, giv den kortlivede legitimationsoplysninger efter mindste privilegium, hold den væk fra beskyttede grene, og send hver ændring gennem CI og menneskelig gennemgang.