Agent-EvalKit: struktureret

Den grundlæggende idé i Agent-EvalKit er, at evaluering af en AI-agent ikke er én opgave, men en proces med flere adskilte trin, der hver løser et specifikt problem. Værktøjet strukturerer processen i seks faser: definition af testscenarier, generering af syntetiske brugerinteraktioner, eksekvering af agenten mod disse scenarier, automatisk scoring af svarene, aggregering af resultater på tværs af kørsler og til sidst rapportering, der gør resultaterne læsbare for et menneske, der skal træffe en beslutning.

Det, jeg selv hæfter mig ved, er systematikken. Almindelig praksis, som jeg har set gentaget mange gange, er at teste en agent manuelt på en håndfuld cases, man selv finder plausible, og så stole på, at resten går godt. Agent-EvalKit vender processen om: den genererer et bredere sæt af scenarier ud fra en definition af, hvad agenten skal kunne, kører agenten igennem dem alle, og scorer resultaterne konsekvent i stedet for ud fra en subjektiv vurdering fra sag til sag. Det gør det muligt at sammenligne to versioner af den samme agent objektivt, og det er præcis den slags sammenligning, jeg selv har manglet, hver gang jeg har ændret en prompt, skiftet model eller tilføjet et nyt værktøj til en agents rækkevidde.

For at gøre de seks faser konkrete arbejder Agent-EvalKit med en rejseagent som gennemgående eksempel, altså en agent, der skal hjælpe brugere med at planlægge og booke rejser. Scenariefasen definerer, hvad en typisk bruger kan finde på at spørge om: alt fra simple flysøgninger til komplekse forespørgsler med flere destinationer, budgetbegrænsninger og ændrede datoer undervejs i samtalen.

Genereringsfasen bygger derefter realistiske brugerinteraktioner ud fra disse scenarier, ikke bare ét spørgsmål, men hele samtaleforløb, hvor brugeren kan skifte mening, stille opfølgende spørgsmål eller give ufuldstændige informationer, som agenten skal håndtere. Det er en detalje, jeg selv har set gå igen i mine egne agent-driftsforløb: fejlene opstår sjældent i det første svar, de opstår efter tre eller fire samtaletrin, når konteksten er skiftet under agenten. Eksekveringsfasen sender disse samtaler igennem selve rejseagenten og logger, hvad den svarer, hvilke værktøjer den kalder, og om den rent faktisk løser opgaven.

Scoring og aggregering samler så resultaterne op: fandt agenten den rigtige rejse, holdt den sig inden for budgettet, undgik den at hallucinere en flyafgang, der ikke findes? Rapporteringsfasen gør det hele læsbart, så et menneske kan se mønstre, for eksempel at agenten klarer sig fint på simple søgninger, men fejler systematisk, når brugeren ændrer destination midt i samtalen. Den slags mønstre er svære at opdage med manuel testning, men bliver tydelige, når man kører agenten igennem hundredvis af varianter på en gang, og det er også den slags mønster, jeg selv leder efter, når jeg gennemgår logs fra en agent, der har kørt en hel nat.

Agent-EvalKit er bygget til at fungere sammen med de værktøjer, mange agentudviklere allerede bruger. Det har native integration til Claude Code, Anthropics kommandolinjeværktøj til agentbaseret kodning, samt til Kiro CLI og Kilo Code, som begge er udviklermiljøer rettet mod at bygge og styre AI-agenter. Den integration betyder, at evaluering ikke er et separat trin, man skal huske at udføre bagefter, men noget, der kan køres direkte som en del af udviklingsflowet, mens man arbejder på agenten.

Det lyder som en lille detalje, men jeg har set den have reel betydning i praksis. Evaluering, der kræver et separat værktøj med sit eget setup, bliver ofte nedprioriteret, når deadline nærmer sig, det har jeg selv været skyldig i. Evaluering, der kører i samme terminal og samme arbejdsgang som selve udviklingen, bliver derimod en naturlig del af processen, på samme måde som automatiserede tests er blevet en selvfølge i almindelig softwareudvikling.

Vi arbejder med større AI-projekter for danske virksomheder, fra problemafklaring og planlægning til implementering og drift, og det billede, Agent-EvalKit tegner, matcher en udvikling, vi ser tydeligt: agenter, der tidligere blev sat i produktion efter et par ugers manuel testning, bliver nu mødt med krav om dokumenteret, gentagelig evaluering, før de bliver til agenter der reelt er i drift med rigtige kunder eller rigtige data.

For en dansk virksomhed, der overvejer at sætte en AI-agent i produktion, er pointen ikke nødvendigvis at bruge præcis dette værktøj, men at anerkende det problem, det løser. En agent, der ser ud til at virke i demoen, kan stadig fejle systematisk i situationer, ingen har tænkt på at teste. Struktureret evaluering i faser, med syntetiske scenarier, der dækker bredere end det oplagte, er en af de mest direkte måder at reducere den risiko på, før agenten møder virkelige brugere og virkelige konsekvenser.

Den tendens rimer også på, hvad vi ser i det bredere agent-økosystem lige nu, hvor både evalueringsrammer og driftsplatforme som Amazon Bedrock AgentCore modnes hurtigt. Det tyder på, at systematisk kvalitetssikring af agenter er ved at blive en forudsætning for produktionssætning, ikke et ekstra trin, man kan springe over, hvis tiden er knap.