AI-agent-evaluatie: zo test je agent-skills
Een praktische gids voor cases, controles, beoordelaars en release-gates
AI-agent-evaluatie controleert of een agent één specifieke taak betrouwbaar en veilig kan uitvoeren voordat je hem normaal gebruikt. Wil je agent-skills beoordelen, begin dan met echte taken, test de beslissingen en neveneffecten die ertoe doen en gebruik een release-gate die past bij het risico. Een verzorgd antwoord uit één run is nuttig bewijs, maar het is niet genoeg om een agent klantberichten, gegevenswijzigingen of geld toe te vertrouwen.
Kort samengevat: begin met 8 tot 12 cases uit het echte werk. Vergelijk de beoogde agentconfiguratie met een baseline zonder skill. Gebruik code om feiten te controleren, zoals bestanden, ontvangers, machtigingen en toolargumenten. Gebruik een gekalibreerde beoordelaar alleen voor onderdelen die menselijk oordeel vereisen. Blokkeer de release zodra een kritieke grens wordt overschreden.
| Beslissing | Wat je test | Bewijs dat je bewaart |
|---|---|---|
| Moet de agent handelen? | Positieve en negatieve cases, parafrases en botsingen | Selectie, abstentie en het percentage foutieve activaties |
| Heeft hij de taak afgerond? | Vereiste feiten, bestanden, toolaanroepen en eindstatus | Assertions en uitvoerartefacten |
| Volgde hij een veilige route? | Machtigingen, goedkeuringen, nieuwe pogingen en neveneffecten | Tooltrace en grensoverschrijdingen |
| Kan een team erop vertrouwen? | Herhaalde runs, kosten en latency | Slagingspercentage, kosten per succes en p95-latency |
De nuttige vraag is eenvoudig: kan deze agent deze taak uitvoeren onder de omstandigheden die hij in de praktijk tegenkomt? De Handleiding voor Agent Skill Evals bevat een kopieerbare versie van het onderstaande proces.
Een AI-agent-evaluatie moet een releasebeslissing ondersteunen
Elke evaluatie begint met een beslissing. Benoem de taak, de persoon die last heeft van een slecht resultaat, het bewijs dat nodig is voor een release en de grens waarbij de run stopt. Zo voorkom je dat een team algemene prompts verzamelt die een discussie nooit beslechten.
Een agent die een antwoord op een klantvraag opstelt, heeft meer nodig dan vloeiende tekst. Hij moet mogelijk de juiste klant vinden, goedgekeurd bronmateriaal citeren, een concept in de juiste thread maken en stoppen voordat hij het verstuurt. Elke eis heeft een eigen controle nodig.
De discussie van YC Paper Club over zelfverbeterende agentsystemen is hier relevant. Meer tools en context kunnen een agent bekwamer maken. Evaluatie laat een team zien of die toevoegingen het werk verbeteren of een nieuw foutpad toevoegen.
Bouw een framework voor AI-agent-evaluatie met echt werk
Begin met cases waarbij een fout zichtbare kosten veroorzaakt. Neem voor elke belangrijke beslissing een duidelijke positieve case, een parafrase, een lastige negatieve case en een botsing op waarbij een andere workflow aannemelijk lijkt. Voeg een gesimuleerde fout toe wanneer de agent een tool kan aanroepen of een status kan wijzigen.
| Case | Wat deze bewijst | Voorbeeld |
|---|---|---|
| Positief | De juiste workflow wordt geactiveerd | Een verzoek dat direct overeenkomt met de gedocumenteerde taak |
| Parafrase | Normale variatie in formulering breekt de routering niet | Hetzelfde verzoek met andere woorden |
| Lastig negatief | De workflow blijft buiten ongerelateerd werk | Een vergelijkbaar verzoek dat bij een andere owner hoort |
| Botsing | Concurrerende instructies worden goed opgelost | Twee agent-skills kunnen van toepassing zijn, maar één moet leiden |
| Gesimuleerde fout | De agent herstelt zonder een grens te overschrijden | Een ontbrekend bestand, geweigerde toestemming, time-out of ongeldige payload |
Houd een releaseset apart van de voorbeelden waarmee je instructies of een beoordelaar hebt afgestemd. Een case kan nog steeds regressies vinden nadat hij de implementatie heeft beïnvloed, maar vertelt dan niet veel meer over nieuw werk.
Voer dezelfde belangrijke taak uit met de beoogde configuratie, zonder skill en, als die controle beschikbaar is, met een aannemelijke maar verkeerde skill. Vergelijk uitkomst, toolroute, kosten, latency en kritieke overtredingen. Het SWE-Skills-Bench-paper is een nuttige herinnering dat extra instructies sommige taken kunnen helpen en andere kunnen schaden. Gepaarde controles maken het effect zichtbaar in je eigen omgeving.
Test uitvoer, traject en machtigingen apart
Het uiteindelijke antwoord is maar één deel van het resultaat. Leg voor agents die tools gebruiken de volgorde van toolaanroepen, argumenten, goedkeuringen, nieuwe pogingen en statuswijzigingen vast. Achter een correct ogend antwoord kunnen nog steeds een verkeerde ontvanger, een ongefundeerde bewering, een omzeilde goedkeuring of een onnodige destructieve actie schuilgaan.
Gebruik code voor feiten die een machine kan controleren:
- Een vereist bestand bestaat en voldoet aan het schema.
- Een ontvanger staat op een allowlist en een antwoord verwijst naar het juiste menselijke bericht.
- Een databasewijziging is gestaged, beoordeeld of afgewezen zoals vereist.
- De verwachte tool heeft de bedoelde argumenten ontvangen.
- Een verboden neveneffect heeft niet plaatsgevonden.
Gebruik daarna een semantische beoordelaar voor de resterende vragen, zoals feitelijke getrouwheid, volledigheid of de vraag of het antwoord op de opdracht ingaat. Geef de beoordelaar gerichte criteria, waar mogelijk een referentieantwoord of bronmateriaal en een mogelijkheid om zich te onthouden. Vergelijk een steekproef van zijn beslissingen met menselijke labels en onderzoek de verschillen. De gids van Anthropic voor agent-evaluaties maakt hetzelfde praktische punt: maak de omgeving observeerbaar en kies de eenvoudigste beoordelaar die het gedrag kan beoordelen.
Machtigingen verdienen eigen cases. Test geweigerde toegang, onduidelijke bevoegdheid, prompt injection in opgehaald materiaal, nieuwe pogingen na een time-out en verzoeken die veilig werk combineren met een onveilige actie. De ToxicSkills-analyse geeft voorbeelden van waarom instructies van derden en tooltoegang expliciet moeten worden beoordeeld.
Meetwaarden voor AI-agent-evaluatie die een team helpen beslissen
Één score beschrijft een agent zelden goed. Koppel de meting aan de releasebeslissing.
| Als het risico is | Meet dan | Een nuttige releasevraag |
|---|---|---|
| Verkeerde routering | Precisie, recall en percentage foutieve activaties | Handelt de agent alleen wanneer dat de bedoeling is? |
| Onjuiste uitvoer | Gepaarde slagingspercentages en mislukte assertions | Verbetert hij het echte werk ten opzichte van de baseline? |
| Onveilige actie | Kritieke overtredingen en omzeilde goedkeuringen | Overschreed een run een grens die de release blokkeert? |
| Inconsistent gedrag | Slagingspercentage bij herhaalde runs | Werkt hij herhaaldelijk onder dezelfde omstandigheden? |
| Onhaalbare bedrijfseconomie | Kosten per geslaagde run en p95-latency | Kan het team deze betrouwbaarheid bij normaal volume betalen? |
Voor een stochastische taak is één geslaagd resultaat zwak bewijs. Herhaal representatieve cases en rapporteer de omstandigheden: model, toolversies, fixtures, beoordelaarsversie en het aantal runs. Als alle vijf runs moeten slagen voordat een release mogelijk is, bereken en benoem die norm dan expliciet. Dat maakt latere vergelijkingen mogelijk wanneer het model, de tools of de instructies veranderen.
Een uitgewerkt voorbeeld: een agent die alleen conceptantwoorden voor klanten maakt
Neem een agent die een antwoord voorbereidt wanneer een klant om hulp vraagt. De releasebeslissing is beperkt: hij mag met goedgekeurd materiaal een beoordeelbaar concept maken. Hij mag geen bericht versturen, klantgegevens wijzigen of een niet-geverifieerde bron gebruiken.
De eerste suite kan bestaan uit een echt supportverzoek, een geparafraseerd verzoek, een vergelijkbare salesvraag die elders moet worden gerouteerd, een verzoek met een niet-vertrouwde link en een gesimuleerde API-fout. Deterministische controles bevestigen de juiste thread, bronlinks, conceptstatus en het ontbreken van een verzendactie. Een mens of gekalibreerde semantische beoordelaar controleert of het concept de vraag feitelijk getrouw beantwoordt.
Die suite is klein genoeg om voor elke relevante wijziging uit te voeren. Onderzoek een incident eerst en voeg daarna de ontbrekende foutklasse toe aan de evaluatieset. Het doel is een bruikbaar verslag van wat de agent mag doen en hoe een team weet dat het werk goed is uitgevoerd.
Plaats de suite in de leveringscyclus
Voer smoke-tests uit voordat een kleine wijziging wordt geïntegreerd. Voer de gepaarde suite uit voor de release. Controleer op drift wanneer je modellen, tools, machtigingen of bronmateriaal wijzigt. Productie-incidenten zijn waardevolle input zodra het onderliggende gedrag is begrepen.
Duurzame context helpt omdat cases, referentieartefacten, beslissingen en correcties met elkaar verbonden kunnen blijven. Hoe teams het geheugen van AI-agents actueel houden beschrijft het deel van dit werk dat over gedeeld geheugen gaat. De Codex-tutorial laat zien hoe instructies, skills en verificatie in een repository kunnen leven. Een Second Brain AI-configuratie kan de duurzame bestanden en beoordelingscycli achter de workflow leveren.
Veelgestelde vragen
Wat is AI-agent-evaluatie?
AI-agent-evaluatie controleert of een agent een gedefinieerde taak betrouwbaar en veilig kan uitvoeren. Ze combineert realistische cases, controles van de uitkomst en neveneffecten, herhaalde runs en een releasebeslissing die past bij het risico.
Hoeveel cases moet een AI-agent-evaluatie bevatten?
Begin met 8 tot 12 precieze cases die gekoppeld zijn aan belangrijke beslissingen en fouten. Voeg cases toe wanneer een release, incident of gebruikerstrace een ontbrekende foutklasse blootlegt. Een kleinere set met duidelijke controles is nuttiger dan een lange lijst algemene prompts.
Moet elke AI-agent-evaluatie een LLM als beoordelaar gebruiken?
Nee. Gebruik deterministische assertions voor bestanden, schema's, ontvangers, toolargumenten, neveneffecten en goedkeuringen. Gebruik modelbeoordelaars alleen voor semantische vragen en kalibreer ze vervolgens aan de hand van menselijke labels.
Wat is de beste eerste meetwaarde voor een AI-agent?
Gebruik de meetwaarde die bij de releasebeslissing hoort. Routering kan precisie en recall vereisen. Een workflow met neveneffecten kan nul kritieke overtredingen vereisen. Een variabele taak kan een slagingspercentage over herhaalde runs, kosten per succes en een latencybudget nodig hebben.
Wanneer kan een team een agent releasen zonder volledige benchmark?
Release hem nadat een risicogerichte suite het vereiste gedrag laat zien en kritieke grenzen beschermt. Interne hulpmiddelen met een laag risico kunnen met minder cases beginnen. Agents die berichten versturen, gegevens wijzigen, geld verwerken of toegang hebben tot geheimen hebben sterkere controles nodig voordat ze routinematig worden ingezet.
Begin met één workflow
Kies een workflow met zichtbare kosten als hij faalt. Schrijf de releasebeslissing op, maak de eerste casefamilies, voeg een baseline zonder skill toe en maak de belangrijke feiten deterministisch. Gebruik daarna de Handleiding voor Agent Skill Evals om de suite uit te breiden met trajectcontroles, kalibratie van de beoordelaar, betrouwbaarheid, kosten en beveiliging.