Hovedpunkter fra AWS og hvorfor det har betydning
AWS gennemgår, hvordan Strands Evals SDK og Amazon Bedrock AgentCore Evaluations gør det muligt at vurdere agenters brug af skills med tre fokusområder: Skill Selection Accuracy, Skill Instruction Following og Skill Invoked. Ifølge AWS opstår der to fejltyper, som generelle output-metrics kan overse: en agent kan vælge en upassende skill til opgaven, eller vælge rigtigt men kun delvist følge instrukserne. AWS fremhæver, at en flydende sluttekst kan dække over procedurefejl, og at evaluering derfor må kigge på, hvad der faktisk skete undervejs – ikke kun på slutsvaret.
AWS beskriver samtidig, at evalueringerne kan trække på kørselsspor: trajectories i Strands Evals og OpenTelemetry-traces via AgentCore. Det gør det muligt at se, hvilke handlinger der blev udført, i hvilken rækkefølge, og med hvilke værktøjer.
Hvor klassiske metrics kommer til kort
AWS peger specifikt på de to nævnte failure modes: forkert skill-valg eller delvis instruktionsefterlevelse. Begge kan give pæne svar uden at bruge den ønskede domæneviden. Det er her de skill-fokuserede evalueringer har deres plads, ifølge AWS’ gennemgang.
En måling på skill-niveau kan tydeliggøre, om fejlen lå i routing (valg af skill) eller i eksekvering (efterlevelse af trin). Det er et andet indblik end et enkelt kvalitetsmål på slutteksten.
Hvad en skill er ifølge AWS
AWS definerer en skill som et genbrugeligt sæt instrukser, typisk lagret i en SKILL.md-fil, der lærer agenten en domænespecifik opgave, for eksempel kontraktredaktion, fakturaafstemning eller pull-request-konventioner. Fordi skills følger den åbne Agent Skills-standard, er de flytbare mellem kompatible rammer, og agenten indlæser kun den nødvendige skill ved runtime frem for at bære alle procedurer i grundinstruktionerne.
I AWS’ beskrivelse pakker en skill flere elementer: instrukser (domæneretning og begrænsninger), værktøjsbindinger (API’er, MCP-servere eller lokale kommandoer), viden (referencer og eksempler), workflow (flertrins procedurer) og guardrails (formatkrav, scope-grænser og valideringsregler). Formålet er at gøre adfærden mere konsistent og opdaterbar uden at finetune modellen eller omskrive agentens grundlogik.
Sådan måles skill-brug ifølge kilderne
I AWS’ materiale fremgår det, at Strands Evals SDK og AgentCore Evaluations introducerer skill-fokuserede målinger, herunder Skill Selection Accuracy, der vurderer, om en anvendt skill var passende. Skill Instruction Following vurderer efterlevelsen af en skills foreskrevne trin. Skill Invoked er et tjek, der bekræfter, at en navngiven skill blev indlæst. AWS beskriver, at evalueringerne kan kobles til trajectories og OpenTelemetry-traces, så vurderingen hviler på faktiske kørselsspor.
Pointen er, at evalueringen ikke alene ser på slutoutput, men på dokumenterede hændelser undervejs. Uden spor er vurderingen sværere; med spor kan man se rækkefølge, værktøjsopkald og kontekstindlæsning.
Operationalisering og sporbarhed
AWS’ gennemgang forudsætter, at agent-arbejdsgange kan instrumenteres, så det ses, hvilke skills og værktøjer der blev udløst hvornår, og hvilke trin der indgik i flowet. Materialet viser, at trajectories og OpenTelemetry-traces kan bruges som kørselsspor for evalueringerne.
Kilderne angiver ikke tal for compute, latenstid eller lagring i forbindelse med evaluering og sporing. Bemærkninger om driftsomkostninger kan derfor ikke dokumenteres ud over, at værktøjerne arbejder på kørselsspor.
Sikkerhedsimplikationer og FakeGit
En særskilt artikel beskriver FakeGit, en malwarekampagne gengivet som dokumenteret af Island, med omtrent 7.600 falske GitHub-repositories, 6.600 falske profiler og over 14 millioner downloads. Ifølge samme artikel udgav over 800 repositories sig for AI-skills og MCP-servere og distribuerede blandt andet SmartLoader og StealC. Artiklen anfører også, at Gemini og ChatGPT uafhængigt anbefalede det samme ondsindede repository.
Relevansen, som den sekundære kilde fremhæver, er impersonation: falske artefakter kan ligne legitime skills eller MCP-servere. Evalueringer af routing og instruksefterlevelse kan synliggøre adfærdsfejl, men materialet fra AWS beskriver ikke signering eller distributionskontrol for skills.
Åbne spørgsmål i det offentlige materiale
I de åbent tilgængelige kilder er der områder, der ikke er udfoldet: håndtering af versionskonflikter mellem skills; praksis for signering og verifikation af SKILL.md og tilhørende værktøjsbindinger; samt omkostningsprofilen ved skaleret evaluering. Kilderne giver ikke svar på disse punkter.
Et andet åbent punkt er scoring i flows med flere acceptable valg. Hvis to skills er acceptable, men én er foretrukken, er det ikke klart fra det offentlige materiale, hvordan falske fejlmarkeringer undgås, eller hvordan vægtning på tværs af skills bør ske.
Hvad kilderne eksplicit siger – og hvad der er analyse
Følgende udsagn er direkte beskrevet i AWS-kilden: at general-purpose agenter skal følge forretningsprocedurer; at det er svært at vedligeholde alt i én systemprompt eller i applikationslogik; at skills er modulære, typisk i en SKILL.md; at de følger den åbne Agent Skills-standard og er portérbare; at en skill samler instrukser, værktøjsbindinger, viden, workflow og guardrails; at to failure modes kan snyde generelle metrics; og at Strands Evals og AgentCore Evaluations tilføjer skill-fokuserede evalueringer, som kan kobles til trajectories og OpenTelemetry-traces.
Følgende udsagn er fra den sekundære sikkerhedskilde: omfanget af FakeGit, impersonation af skills og MCP-servere, og at to assistenter ifølge artiklen anbefalede et ondsindet repository. Konklusioner om signering og distributionskontrol er ikke beskrevet i AWS-kilden og er derfor ikke dokumenterede funktioner i Strands Evals eller AgentCore.
Praktiske implikationer, når man arbejder med evaluering
Når målingen sker på skill-niveau, bliver fejlårsager mere synlige: om det var valg af skill eller efterlevelse af trin. Kilderne viser, at dette kræver kørselssporing, der kan koble handlinger, værktøjsopkald og indlæste instrukser.
Hvor der ikke findes dokumenterede tal for omkostninger, peger materialet alene på, at vurderingen baseres på trajectories og OpenTelemetry-traces. Eventuelle antagelser om ressourceforbrug ligger uden for det, kilderne beskriver.
Terminologi og modenhed i materialet
Begreberne Skill Selection Accuracy, Skill Instruction Following og Skill Invoked bruges i AWS’ materiale om Strands Evals og AgentCore Evaluations. Skill Invoked omtales som et tjek for, om en bestemt skill blev indlæst; de øvrige målinger vurderer valg og efterlevelse. AWS beskriver, at vurderingen bygger på kørselsspor.
Kilderne går ikke i detaljer om scoringstyper eller afgrænsninger i multiskill-scenarier. Det betyder, at risikovurdering af falske positive og negative må bero på yderligere dokumentation eller erfaring, som ikke fremgår af de nævnte kilder.
Hvad der stadig mangler dokumentation
De offentlige kilder dækker ikke en standardiseret model for signering og verifikation af skills og tilknyttede artefakter. De dækker heller ikke, hvordan afhængigheder og versionsstyring håndteres på tværs af miljøer. Derudover er der ikke fremlagt offentlige målinger af langsigtede driftsomkostninger ved per-skill evaluering.
For sikkerhedsaspektet henviser den sekundære kilde til en rapport fra Island om FakeGit, men den primære rapport er ikke linket i materialet her. Tal og beskrivelser af kampagnen bør derfor læses som gengivet via den sekundære artikel.
Konklusion
Ifølge AWS tilfører Strands Evals og Amazon Bedrock AgentCore Evaluations tre skill-fokuserede målinger, som gør det muligt at identificere, om fejl opstår ved valg af skill eller ved mangelfuld efterlevelse. Evalueringerne hviler på kørselsspor som trajectories og OpenTelemetry-traces. En separat sikkerhedsdækning af FakeGit gengiver, at falske repos kan udgive sig for skills og MCP-servere og sprede malware. Samlet peger kilderne på, at adfærdsnær evaluering og kildekontrol er centrale hensyn, når agent-arkitekturer bringes i drift.
Flere spørgsmål er åbne i de offentlige kilder: versionering, signering, afhængigheder, skaleringsomkostninger og håndtering af multiskill-scenarier. Her vil yderligere dokumentation være nødvendig.
