Tools og function calling i AI-agenter
Lær hvordan en agent får adgang til handlinger uden at lade modellen eje regler, adgangsoplysninger eller validering.
Lær hvordan en agent får adgang til handlinger uden at lade modellen eje regler, adgangsoplysninger eller validering.
Hvad et værktøjskald egentlig er
Modellen vælger et værktøj og foreslår strukturerede argumenter. Din applikation validerer argumenterne, udfører funktionen og returnerer resultatet. Modellen bør aldrig få rå adgangsoplysninger.
Design en lille værktøjskontrakt
Giv værktøjet et entydigt navn, en kort beskrivelse, et stramt inputskema og fejl, som agenten kan forstå. Et værktøj som create_invoice bør eksempelvis kræve kunde-id, linjer og valuta – ikke en fri tekstblok.
Hold beslutninger i den rigtige del af systemet
Skatteregler, beløbsgrænser og autorisation hører til regelbaseret kode. Modellen kan foreslå en handling; serveren afgør, om den er lovlig og tilladt.
Test mere end normalforløb
Test manglende felter, ukendte værdier, gentagne kald, timeouts, værktøjsfejl og et prompt-injection-forsøg, der prøver at få agenten til at vælge et højere privilegeret værktøj.
Case: opret en faktura uden at give modellen økonomisk kontrol
En salgsagent må foreslå create_invoice efter en godkendt ordre. Tool-serveren slår selv kunde, valuta og prisregler op, validerer at ordren ikke allerede er faktureret og returnerer enten et faktura-id eller en struktureret fejl. Modellen kan ikke ændre momsregler eller sende egne beløb uden validering.
Design ét værktøj med en skarp kontrakt
Skriv kontrakten til ét værktøj du allerede bruger. Definér inputfelter, hvem der må kalde det, hvad der gør et kald ugyldigt, og hvordan et gentaget kald opdages.
Kontrol: ugyldige argumenter og forkert værktøjsvalg
- Kan alle argumenter valideres på serversiden?
- Kan værktøjskaldet genkøres uden utilsigtet dobbelt handling?
- Er adgangsoplysninger og autorisation helt uden for modelkonteksten?
Værktøjsskemaet er en del af prompten – og en del af sikkerheden
Modellen vælger blandt værktøjer ud fra navn, beskrivelse og argumenter. Et uklart skema gør både værktøjsvalg og validering dårligere. Brug konkrete felter og enums, hvor mulighederne er begrænsede, og afvis ekstra input i backend.
Hold “hvad bør vi gøre?” adskilt fra “må systemet gøre det?”. Modellen kan foreslå en refundering, men en regelbaseret regelfunktion bør afgøre, om beløb, konto og sagstype tillader handlingen.
Returnér også maskinlæsbare fejl. “customer_not_found” giver agenten en bedre mulighed for at spørge om mere information end en vag tekststreng.