Vejledning til at forstå, bygge og optimere API-kaldende agenter

Rollen af kunstig intelligens i teknologivirksomheder udvikler sig hurtigt; AI-brugs eksempler er gået fra passiv informationsbehandling til proaktive agenter, der kan udføre opgaver. Ifølge en undersøgelse fra marts 2025 om global AI-adopteringsfrekvens, gennemført af Georgian og NewtonX, rapporterer 91% af tekniske direktører i vækstfaser og virksomheder, at de bruger eller planlægger at bruge agentic AI.

API-kaldende agenter er et primært eksempel på denne skift til agenter. API-kaldende agenter udnytter Large Language Models (LLM’er) til at interagere med software-systemer via deres Application Programming Interfaces (API’er).

For eksempel kan agenter ved at oversætte naturlige sprogkommandoer til præcise API-kald hente realtidsdata, automatisere rutineopgaver eller endda kontrollere andre software-systemer. Denne funktion transformerer AI-agenter til nyttige mellemled mellem menneskelig hensigt og software-funktionalitet.

Virksomheder bruger i øjeblikket API-kaldende agenter i forskellige domæner, herunder:

• Forbrugerapplikationer: Assistenter som Apple’s Siri eller Amazon’s Alexa er designet til at simplificere daglige opgaver, såsom kontrol af smarte hjemmeenheder og reservationer.
• Enterprise-workflows: Virksomheder har udrullet API-agenter til at automatisere gentagne opgaver som hentning af data fra CRM’er, generering af rapporter eller konsolidering af information fra interne systemer.
• Data-hentning og analyse: Virksomheder bruger API-agenter til at simplificere adgangen til proprietære datasæt, abonnementsbaserede ressourcer og offentlige API’er for at generere indsigt.

I denne artikel vil jeg bruge en ingeniørcentreret tilgang til at forstå, bygge og optimere API-kaldende agenter. Materialet i denne artikel er baseret delvist på den praktiske forskning og udvikling, der er udført af Georgian’s AI Lab. Den motiverende spørgsmål for meget af AI Lab’s forskning i området API-kaldende agenter har været: “Hvis en organisation har en API, hvad er den mest effektive måde at bygge en agent, der kan kommunikere med denne API ved hjælp af naturligt sprog?”

Jeg vil forklare, hvordan API-kaldende agenter fungerer, og hvordan man kan arkitektonisk og ingeniørmæssigt bygge disse agenter for ydeevne. Endelig vil jeg give en systematisk arbejdsgang, som ingeniørhold kan bruge til at implementere API-kaldende agenter.

I. Nøgledefinitioner:

• API eller Application Programming Interface: En samling regler og protokoller, der muliggør kommunikation og informationsudveksling mellem forskellige software-applikationer.
• Agent: Et AI-system designet til at percipere sin omverden, træffe beslutninger og udføre handlinger for at opnå bestemte mål.
• API-kaldende agent: En specialiseret AI-agent, der oversætter naturlige sprogkommandoer til præcise API-kald.
• Kode-genererende agent: Et AI-system, der hjælper med software-udvikling ved at skrive, ændre og fejlfinde kode. Selvom dette er relateret, fokuserer jeg her primært på agenter, der kald API’er, selvom AI også kan hjælpe med at bygge disse agenter.
• MCP (Model Context Protocol): En protokol, udviklet af Anthropic, der definerer, hvordan LLM’er kan tilslutte og udnytte eksterne værktøjer og datakilder.

II. Kerneopgave: Oversættelse af naturligt sprog til API-handlinger

Den fundamentale funktion af en API-kaldende agent er at fortolke en brugers naturlige sprog-anmodning og konvertere den til en eller flere præcise API-kald. Dette proces indebærer typisk:

1. Intent-genkendelse: At forstå brugerens mål, selv hvis det udtrykkes tvetydigt.
2. Værktøjsvalg: At identificere det passende API-endpoint (eller “værktøj”) fra en samling tilgængelige muligheder, der kan opfylde intentionen.
3. Parameter-ekstraktion: At identificere og ekstrahere de nødvendige parametre for det valgte API-kald fra brugerens forespørgsel.
4. Udførelse og respons-generering: At udføre API-kaldet, modtage responsen og derefter syntetisere denne information til en sammenhængende besked eller udføre en efterfølgende handling.

Overvej en anmodning som “Hej Siri, hvordan er vejret i dag?” Agenten må identificere behovet for at kalde en vejrservice-API, bestemme brugerens aktuelle placering (eller tillade specifikation af en placering) og derefter formulere API-kaldet til at hente vejrinformation.

For anmodningen “Hej Siri, hvordan er vejret i dag?”, kan et eksempel på et API-kald se således ud:

GET /v1/weather?location=New%20York&units=metric

Initielle højniveaufordringer er indbyggede i denne oversættelsesproces, herunder tvetydigheden af naturligt sprog og behovet for, at agenten skal opretholde kontekst over multi-trins-interaktioner.

For eksempel skal agenten ofte “huske” tidligere dele af en samtale eller tidligere API-kald-resultater for at informere nuværende handlinger. Konteksttab er en almindelig fejltilstand, hvis det ikke håndteres eksplicit.

III. Arkitektur-løsning: Nøglekomponenter og protokoller

Bygning af effektive API-kaldende agenter kræver en struktureret arkitektonisk tilgang.

1. Definering af “værktøjer” for agenten

For at en LLM kan bruge en API, skal API’ens funktioner beskrives for den på en måde, den kan forstå. Hvert API-endpoint eller funktion repræsenteres ofte som et “værktøj”. En robust værktøjsdefinition omfatter:

• En klar, naturlig sprogbeskrivelse af værktøjets formål og funktionalitet.
• En præcis specifikation af dens input-parametre (navn, type, om det er påkrævet eller valgfrit, og en beskrivelse).
• En beskrivelse af output eller data, værktøjet returnerer.

2. Rollen af Model Context Protocol (MCP)

MCP er en kritisk faktor for mere standardiseret og robust værktøjsbrug af LLM’er. Det giver en struktureret format for at definere, hvordan modeller kan tilslutte og udnytte eksterne værktøjer og datakilder.

MCP-standardisering er nyttig, fordi det muliggør en nemmere integration af forskellige værktøjer, det fremmer genbrug af værktøjsdefinitioner på tværs af forskellige agenter eller modeller. Yderligere er det en bedste praksis for ingeniørhold at starte med veldefinerede API-specifikationer, såsom en OpenAPI-specifikation. Værktøjer som Stainless.ai er designet til at hjælpe med at konvertere disse OpenAPI-specifikationer til MCP-konfigurationer, hvilket strømliner processen med at gøre API’er “agent-klare”.

3. Agent-rammer og implementeringsvalg

Der er flere rammer, der kan hjælpe med at bygge agenten selv. Disse omfatter:

• Pydantic: Selvom det ikke udelukkende er et agent-ramme, er Pydantic nyttigt til at definere datastrukturer og sikre typesikkerhed for værktøjsinput og -output, hvilket er vigtigt for pålidelighed. Mange brugerdefinerede agent-implementationer udnytter Pydantic til denne strukturelle integritet.
• LastMile’s mcp_agent: Dette ramme er specifikt designet til at arbejde med MCP’er og tilbyder en mere opioneret struktur, der er i overensstemmelse med bedste praksis for bygning af effektive agenter, som beskrevet i forskning fra steder som Anthropic.
• Intern ramme: Det er også mere og mere almindeligt at bruge AI-kode-genererende agenter (med værktøjer som Cursor eller Cline) til at hjælpe med at skrive boilerplate-koden for agenten, dens værktøjer og den omgivende logik. Georgian’s AI Lab-erfaring med at arbejde med virksomheder på agentic-implementationer viser, at dette kan være fantastisk til at oprette meget minimalistiske, brugerdefinerede rammer.

IV. Ingeniørarbejde for pålidelighed og ydeevne

At sikre, at en agent udfører API-kald pålideligt og yder godt, kræver fokuseret ingeniørarbejde. To måder at gøre dette på er (1) datasætsoprettelse og validering og (2) prompt-ingeniørarbejde og optimering.

1. Datasætsoprettelse og validering

Træning (hvis anvendeligt), test og optimering af en agent kræver et højkvalitetsdatasæt. Dette datasæt skal bestå af repræsentative naturlige sprogforespørgsler og deres tilhørende ønskede API-kaldsekvenser eller resultater.

• Manuel oprettelse: Manuelt at kuraterer et datasæt sikrer høj præcision og relevans, men kan være arbejdskrævende.
• Syntetisk generering: At generere data programmeringsmæssigt eller ved hjælp af LLM’er kan skala datasætsoprettelse, men denne tilgang præsenterer betydelige udfordringer. Georgian AI Lab’s forskning fandt, at sikring af korrekthed og realistisk kompleksitet af syntetisk genererede API-kald og forespørgsler er meget svært. Ofte var de genererede spørgsmål enten for trivielle eller umuligt komplekse, hvilket gjorde det svært at måle nuanceret agent-ydeevne. Omhyggelig validering af syntetisk data er absolut kritisk.

Til kritisk evaluering giver et mindre, højkvalitets-, manuelt verificeret datasæt ofte mere pålidelige indsigt end et stort, støjende syntetisk datasæt.

2. Prompt-ingeniørarbejde og optimering

Ydeevnen af en LLM-baseret agent påvirkes kraftigt af de prompts, der bruges til at guide dens tankegang og værktøjsvalg.

• Effektivt prompt-ingeniørarbejde indebærer klart at definere agentens opgave, give beskrivelser af tilgængelige værktøjer og strukturere prompten til at fremme præcis parameter-ekstraktion.
• Systematisk optimering ved hjælp af rammer som DSPy kan betydeligt forbedre ydeevnen. DSPy tillader dig at definere agentens komponenter (f.eks. moduler til tankegenerering, værktøjsvalg, parameterformatering) og derefter bruger en compiler-lignende tilgang med få-skud-eksempler fra dit datasæt til at finde optimerede prompts eller konfigurationer for disse komponenter.

V. En anbefalet vej til effektive API-agenter

Udvikling af robuste API-kaldende AI-agenter er en iterativ ingeniør-disciplin. Baseret på resultaterne af Georgian AI Lab’s forskning kan resultaterne forbedres væsentligt ved hjælp af en systematisk arbejdsgang som følger:

1. Start med klare API-definitioner: Begynd med velstrukturerede OpenAPI-specifikationer for de API’er, din agent vil interagere med.
2. Standardiser værktøjsadgang: Konverter dine OpenAPI-specifikationer til MCP. Værktøjer som Stainless.ai kan facilitere dette og skabe en standardiseret måde for din agent at forstå og bruge dine API’er på.
3. Implementer agenten: Vælg en passende ramme eller tilgang. Dette kan indebære brug af Pydantic til datamodellering inden for en brugerdefineret agent-struktur eller udnyttelse af en ramme som LastMile’s mcp_agent, der er bygget op omkring MCP.
   • Før du gør dette, overvej at tilslutte MCP’en til et værktøj som Claude Desktop eller Cline og manuelt bruge denne grænseflade til at få en fornemmelse af, hvor godt en generisk agent kan bruge det, hvor mange iterationer det normalt tager at bruge MCP korrekt og andre detaljer, der kan spare dig tid under implementeringen.
4. Kurater et kvalitets-evaluationsdatasæt: Opret manuelt eller valider omhyggeligt et datasæt af forespørgsler og forventede API-interaktioner. Dette er kritisk for pålidelig test og optimering.
5. Optimer agent-prompts og logik: Anvend rammer som DSPy til at finjustere agentens prompts og interne logik, ved hjælp af dit datasæt til at drive forbedringer i nøjagtighed og pålidelighed.

VI. Et illustrerende eksempel på arbejdsgangen

Her er et simplificeret eksempel, der illustrerer den anbefalede arbejdsgang for at bygge en API-kaldende agent:

Trin 1: Start med klare API-definitioner

Forestil dig en API til at administrere en simpel To-Do-liste, defineret i OpenAPI:
openapi: 3.0.0

info:
title: To-Do List API
version: 1.0.0

paths:
/tasks:
post:
summary: Tilføj en ny opgave
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
description:
type: string
responses:
‘201’:
description: Opgave oprettet succesfuldt

get:
summary: Hent alle opgaver
responses:
‘200’:
description: Liste af opgaver

Trin 2: Standardiser værktøjsadgang

Konverter OpenAPI-specifikationen til Model Context Protocol (MCP)-konfigurationer. Ved hjælp af et værktøj som Stainless.ai kan dette muligvis resultere i:

Trin 3: Implementer agenten

Ved hjælp af Pydantic til datamodellering kan du oprette funktioner, der svarer til MCP-værktøjerne. Derefter kan du bruge en LLM til at fortolke naturlige sprogforespørgsler og vælge det passende værktøj og parametre.

Trin 4: Kurater et kvalitets-evaluationsdatasæt

Opret et datasæt:

Trin 5: Optimer agent-prompts og logik

Brug DSPy til at finjustere prompts, fokus på klare instruktioner, værktøjsvalg og parameter-ekstraktion ved hjælp af det kuraterede datasæt til evaluering og forbedring.

Ved at integrere disse byggeklodser – fra strukturerede API-definitioner og standardiserede værktøjsprotokoller til strenge data-praksis og systematisk optimering – kan ingeniørhold bygge mere kapable, pålidelige og vedligeholdelige API-kaldende AI-agenter.