Så sätter du upp en kvalitetsloop för kodagenter

Efter guiden kan du mäta om en kodagent faktiskt blir bättre mellan iterationer i stället för att bara kännas bättre i några handplockade exempel.

• Målgrupp: utvecklare och team som redan testar kodagenter i vardagen.
• Förkunskaper: du kan köra terminalkommandon, läsa JSONL och vet vad en prompt eller agenttrace är.
• Du behöver: Node.js, ett repo eller en agentmiljö att utvärdera, samt ett sätt att exportera testfall eller traces.
• Slutkontroll: du vet att det fungerar när du har en baslinje, en körbar uppsättning testfall och en ny mätning som går att jämföra mot förra körningen.

Det här behöver du

• En kodagent som redan gör någon konkret uppgift, till exempel kodgranskning, felsökning eller planering.
• Ett litet testset med riktiga fall från ditt team.
• Ett separat eval-konto eller projekt om du vill köra Googles flywheel-paket från källan.

Steg 1: Välj en enda uppgift att mäta

**Mål:** begränsa scope så att första loopen blir begriplig.

**Gör så här:** välj en uppgift där agenten ofta används och där fel går att upptäcka. Bra första kandidater är “föreslå fix på ett felmeddelande”, “planera en ändring i ett repo” eller “svara på en kodfråga med rätt filreferenser”. Skriv också vad som räknas som godkänt.

```text

Uppgift: föreslå en fix för ett byggfel i ett TypeScript-projekt

Godkänt när:

• agenten identifierar rätt fil eller modul
• agenten föreslår en relevant ändring
• agenten hittar inte på beroenden eller kommandon

```

**Kontrollera att det fungerar:** någon i teamet ska kunna läsa definitionen och hålla med om vad som är “bra” respektive “dåligt”.

**Vanligt fel:** ni försöker mäta “hela agenten” direkt. Börja med en enda uppgift, annars blir signalen för brusig.

Steg 2: Bygg ett litet eval-set från verkliga fall

**Mål:** skapa en första baslinje med riktiga exempel.

**Gör så här:** samla 10 till 25 fall från supporttrådar, interna buggar eller tidigare agentkörningar. Lägg dem i JSONL så att varje rad motsvarar ett scenario.

```json

{"id":"case-001","prompt":"Bygget kraschar med module not found i src/api/client.ts","expected":"Peka ut importen eller sökvägen som är fel"}

{"id":"case-002","prompt":"Testerna faller efter en schemaändring i databasen","expected":"Föreslå att fixtures eller migration uppdateras"}

```

Om du redan har produktionsspår kan du använda dem som start, precis som Googles kvalitetsloop beskriver.

**Kontrollera att det fungerar:** du ska kunna öppna filen och förstå vad agenten ska göra i varje fall utan extra förklaring.

**Vanligt fel:** alla testfall blir nästan identiska. Blanda enkla, normala och besvärliga fall.

Steg 3: Installera eval-verktyget och skapa en graderingskonfiguration

**Mål:** få ett återanvändbart sätt att bedöma resultaten.

**Gör så här:** enligt Googles officiella blogg finns två paket för samma eval-tjänst. Välj det som passar din miljö.

```bash

npx skills add https://github.com/google/agents-cli --skill google-agents-cli-eval

npx skills add https://github.com/google/skills --skill agent-platform-eval-flywheel

```

Skapa sedan en enkel konfigurationsfil för vad du vill bedöma.

```yaml

metrics:

• name: task_success

description: Agenten löser uppgiften utan att missa huvudfelet

• name: trajectory_quality

description: Agenten tar rimliga steg och hallucinerar inte filer eller verktyg

```

**Kontrollera att det fungerar:** du ska ha både ett testset och en rubricering som går att återanvända i nästa körning.

**Vanligt fel:** teamet ändrar bedömningsregler mellan varje körning. Frys första rubriken och justera först efter några iterationer.

Steg 4: Kör en första mätning och läs varför fallen fallerar

**Mål:** få en baslinje i stället för magkänsla.

**Gör så här:** kör agenten mot ditt eval-set och spara traces i en egen mapp. Om du redan har traces kan du hoppa direkt till grading-steget.

```bash

mkdir -p eval

agents-cli eval grade --traces eval/traces.jsonl --config eval/eval_config.yaml

```

Läs sedan igenom de fall som fick låga betyg. Fokusera först på återkommande fel, inte på enstaka märkliga avvikelser.

**Kontrollera att det fungerar:** du ska kunna peka på minst två konkreta feltyper, till exempel fel filreferenser eller att agenten ignorerar en ändrad användarinstruktion.

**Vanligt fel:** ni hoppar direkt till promptändringar utan att först läsa de svaga körningarna.

Steg 5: Gör en liten ändring och jämför mot baslinjen

**Mål:** förbättra agenten utan att råka förstöra annat.

**Gör så här:** ändra en sak i taget, till exempel systemprompt, verktygsval eller hur kontext hämtas. Kör sedan samma eval-set igen.

```text

Ändra en sak:

• prompt
• verktygsordning
• retrieval
• statehantering

Kör sedan om exakt samma eval-set.

```

Jämför nya resultat mot baslinjen. Om bara tre exempel ser bättre ut men helheten står still, har du inte bevis på förbättring ännu.

**Kontrollera att det fungerar:** du vet att loopen fungerar när du kan säga “version B förbättrade task_success men försämrade trajectory_quality” i stället för “den här kändes smartare”.

**Vanligt fel:** samma modell eller agent får bedöma sin egen förbättring. Källan varnar uttryckligen för att optimizer och evaluator ska vara separerade.

Felsökning

• Problem: resultaten hoppar kraftigt mellan körningar. Lösning: använd samma testset och samma rubrik i minst två till tre rundor innan du drar slutsatser.
• Problem: teamet får för få misslyckanden för att lära sig något. Lösning: blanda in svårare produktionsfall och inte bara “rena” demofall.
• Problem: alla diskussioner fastnar i promptord. Lösning: gruppera först feltyperna och välj sedan en enda ändring att testa.

Källa: Google Developers Blog – Driving the Agent Quality Flywheel from Your Coding Agent