Tool calling: hur en AI-agent anropar externa verktyg

Utan tool calling kan en språkmodell bara göra en sak: producera text utifrån text. Den kan varken konsultera en aktuell databas, skicka ett meddelande eller utlösa en åtgärd i en tredjepartsmjukvara. Tool calling är bron som förbinder en modell med ett yttre system. Det är det som förvandlar en modell som pratar till en AI-agent som kan agera, grundbyggstenen bakom varje autonom agent.

Detaljerad definition

Tool calling, även kallat function calling, beskriver en språkmodells förmåga att svara på en förfrågan inte bara med text, utan med en strukturerad begäran om att köra en specifik funktion, med argument ifyllda enligt ett i förväg definierat schema. Anthropics dokumentation beskriver principen så här: modellen avgör om den ska anropa ett verktyg utifrån förfrågan och verktygets beskrivning, och skickar sedan tillbaka ett strukturerat anrop som applikationen utför (klientsidan) eller som leverantören utför själv (serversidan, för vissa inbyggda verktyg). OpenAI:s dokumentation, som populariserade termen function calling 2023, beskriver en identisk mekanism: modellen svarar med ett maskinläsbart funktionsanrop i stället för fri text, och det är applikationens ansvar att utföra det.

De två referensleverantörerna är eniga om grunddefinitionen: en funktion beskrivs av ett namn, en beskrivning på naturligt språk, och ett JSON-schema som listar dess förväntade parametrar. Modellen förlitar sig enbart på de här tre elementen för att avgöra om den ska anropa verktyget och hur den ska fylla i dess argument. Det finns ingen betydande skillnad mellan de två ansatserna kring den här grundprincipen; skillnaderna ligger i implementationsdetaljerna (format för parallella anrop, verktyg som levereras nativt av leverantören, felhantering).

Tool calling är det som skiljer en enkel chattbot från ett system som kan agera i den verkliga världen: konsultera en databas, söka på webben, skriva i en fil, skicka ett meddelande, utlösa en betalning. Det är också grundbyggstenen som gör protokollet MCP möjligt, tänkt för att standardisera hur verktyg beskrivs och exponeras för en modell.

Så fungerar det

Förloppet för ett verktygsanrop följer alltid samma mönster i flera steg. Först definierar applikationen en lista över tillgängliga verktyg för modellen, var och en med sitt namn, sin beskrivning och sitt argumentschema. Sedan tar modellen emot användarens förfrågan tillsammans med den här verktygslistan, och avgör, utifrån kontexten, om den ska svara direkt i text eller begära att ett verktyg körs.

Om den väljer att anropa ett verktyg skickar modellen tillbaka ett strukturerat svar som innehåller verktygets namn och värdena för dess argument, utan att själv utföra något. Det är applikationen som tar emot den här begäran, faktiskt utför åtgärden (anropar ett API, läser en databas, skriver en fil), och sedan skickar tillbaka resultatet till modellen i en form den kan läsa. Modellen fortsätter sedan sitt svar utifrån det här resultatet, och kan kedja samman flera verktygsanrop i rad om uppgiften kräver det.

Den här uppdelningen är viktig för säkerheten: modellen kör aldrig kod själv, den bara föreslår ett anrop. Det är applikationen som behåller kontrollen över vad som faktiskt utförs, och som kan neka ett anrop om villkoren inte är uppfyllda.

Konkret exempel med Atako

Hos Atako är tool calling kärnan i hur en agent fungerar. Varje ansluten integration (Slack, Notion, GitHub, HubSpot, och ett fyrtiotal andra) exponerar en uppsättning specifika åtgärder, som post_message på Slack eller create_issue på GitHub, som agenten kan anropa när den bedömer att uppgiften kräver det.

Men hos Atako utförs ett verktygsanrop aldrig direkt. Det går först genom en tillståndskontroll: plattformen kontrollerar att ett "grant" finns för just den agenten och den kopplingen, att den begärda åtgärden verkligen finns med i det tillståndets lista över godkända åtgärder, och att det beviljade omfånget (skrivskyddat eller läs- och skrivbehörighet) verkligen täcker åtgärden i fråga. Om något av de här villkoren inte är uppfyllt nekas anropet och felet loggas. Den här beslutsvägen, en agent som föreslår ett anrop och sedan en plattform som kontrollerar innan det utförs, är exakt den säkerhetslogik som tool calling gör det möjligt att bygga upp: modellen föreslår, infrastrukturen beslutar.

Vanliga misstag

Ett vanligt misstag är att tro att modellen själv utför verktyget den anropar. Så är det aldrig: modellen producerar en strukturerad begäran, det är alltid en applikation eller plattform som faktiskt utför åtgärden och som när som helst kan neka den.

Andra misstaget: tro att ge en modell tillgång till ett verktyg motsvarar att ge den total och obegränsad åtkomst till den tjänsten. Ett väl utformat tool calling-system begränsar precist de tillgängliga åtgärderna, med tillstånd per åtgärd och per omfång, snarare än en generisk allt-eller-inget-åtkomst.

Tredje misstaget: underskatta betydelsen av verktygets beskrivning. Modellen har bara tillgång till namnet, beskrivningen och argumentschemat för att avgöra när och hur ett verktyg ska anropas. En vag eller tvetydig beskrivning ger felaktigt valda anrop eller felaktiga argument, även med en välpresterande modell.

Slutligen blandar vissa ihop tool calling och MCP. Tool calling är grundmekanismen, som funnits sedan 2023 hos de stora modellleverantörerna. MCP är ett nyare protokoll som standardiserar hur verktyg beskrivs och kopplas till en modell, för att slippa utveckla en ny integration för varje verktyg och varje leverantör.