Tool calling: sådan kalder en AI-agent eksterne værktøjer

Uden tool calling kan en sprogmodel kun én ting: producere tekst ud fra tekst. Den kan hverken slå op i en opdateret database, sende en besked eller udløse en handling i et tredjepartsprogram. Tool calling er broen, der forbinder en model til et eksternt system. Det er det, der forvandler en model, der fører en samtale, til en AI-agent, der kan handle, selve grundstenen bag enhver autonom agent.

Detaljeret definition

Tool calling, også kaldet function calling, betegner en sprogmodels evne til at besvare en forespørgsel ikke kun med tekst, men med en struktureret anmodning om at udføre en præcis funktion, med argumenter udfyldt efter et forudfastlagt skema. Anthropics dokumentation beskriver princippet sådan: modellen afgør, om den skal kalde et værktøj, ud fra forespørgslen og værktøjets beskrivelse, og returnerer derefter et struktureret kald, som applikationen udfører (klientsiden) eller som udbyderen selv udfører (serversiden, for visse indbyggede værktøjer). OpenAI's dokumentation, som populariserede udtrykket function calling i 2023, beskriver en identisk mekanisme: modellen svarer med et maskinlæsbart funktionskald i stedet for fri tekst, og det er op til applikationen at udføre det.

De to referenceudbydere er enige om selve definitionen: en funktion beskrives af et navn, en beskrivelse i naturligt sprog og et JSON-skema, der lister de forventede parametre. Modellen bruger udelukkende disse tre elementer til at afgøre, om den skal kalde værktøjet, og hvordan den skal udfylde dets argumenter. Der findes ingen væsentlig uenighed mellem de to tilgange om dette grundlæggende princip; forskellene ligger i implementeringsdetaljer (formater for parallelle kald, værktøjer leveret nativt af udbyderen, fejlhåndtering).

Tool calling er det, der adskiller en simpel chatbot fra et system, der kan handle på den virkelige verden: slå op i en database, søge på nettet, skrive i en fil, sende en besked, udløse en betaling. Det er også grundstenen, der gør protokollen MCP mulig, skabt til at standardisere den måde, værktøjer beskrives og eksponeres for en model på.

Sådan fungerer det

Forløbet af et værktøjskald følger altid samme mønster i flere trin. Først definerer applikationen en liste af værktøjer, der er tilgængelige for modellen, hver med sit navn, sin beskrivelse og sit argumentskema. Dernæst modtager modellen brugerens forespørgsel sammen med denne værktøjsliste og afgør, ud fra konteksten, om den skal svare direkte i tekst eller anmode om udførelsen af et værktøj.

Vælger den at kalde et værktøj, returnerer modellen et struktureret svar, der indeholder værktøjets navn og værdierne af dets argumenter, uden selv at udføre noget som helst. Det er applikationen, der modtager denne anmodning, reelt udfører handlingen (kalder en API, læser en database, skriver en fil) og derefter sender resultatet tilbage til modellen i en form, den kan læse. Modellen fortsætter derefter sit svar ud fra dette resultat og kan kæde flere værktøjskald sammen efter hinanden, hvis opgaven kræver det.

Denne opdeling er vigtig for sikkerheden: modellen kører aldrig selv kode, den foreslår blot et kald. Det er applikationen, der bevarer kontrollen over, hvad der reelt udføres, og som kan afvise et kald, hvis betingelserne ikke er opfyldt.

Konkret eksempel fra Atako

Hos Atako er tool calling kernen i en agents virkemåde. Hver forbundet integration (Slack, Notion, GitHub, HubSpot og omkring fyrre andre) eksponerer et sæt præcise handlinger, som post_message på Slack eller create_issue på GitHub, som agenten kan kalde, når den vurderer, at opgaven kræver det.

Men hos Atako udføres et værktøjskald aldrig direkte. Det går først gennem en tilladelseskontrol: platformen tjekker, at der findes et "grant" for netop denne agent og denne forbindelse, at den anmodede handling faktisk står på listen over tilladte handlinger i dette grant, og at det tildelte omfang (kun læsning eller læsning-skrivning) reelt dækker den pågældende handling. Er en af disse betingelser ikke opfyldt, afvises kaldet, og fejlen logges. Denne beslutningsvej, hvor agenten foreslår et kald og platformen derefter kontrollerer, før den udfører det, er præcis den sikkerhedslogik, tool calling gør det muligt at indføre: modellen foreslår, infrastrukturen beslutter.

Almindelige fejl

En almindelig fejl er at tro, at modellen selv udfører det værktøj, den kalder. Det er aldrig tilfældet: modellen producerer en struktureret anmodning, det er altid en applikation eller platform, der reelt udfører handlingen og til enhver tid kan afvise den.

Anden fejl: at tro, at det at give en model adgang til et værktøj svarer til at give den fuld og ubegrænset adgang til denne tjeneste. Et velkonstrueret tool calling-system begrænser præcist de tilgængelige handlinger, med tilladelser pr. handling og pr. omfang, i stedet for en generisk alt-eller-intet-adgang.

Tredje fejl: at undervurdere betydningen af værktøjsbeskrivelsen. Modellen har kun navnet, beskrivelsen og argumentskemaet til at afgøre, hvornår og hvordan et værktøj skal kaldes. En vag eller tvetydig beskrivelse giver dårligt valgte kald eller forkerte argumenter, selv med en velfungerende model.

Endelig forveksler nogle tool calling med MCP. Tool calling er grundmekanismen, der har eksisteret siden 2023 hos de store modeludbydere. MCP er en nyere protokol, der standardiserer den måde, værktøjer beskrives og forbindes til en model på, for at undgå at skulle udvikle en ny integration for hvert værktøj og hver udbyder.