Veiledning til å forstå, bygge og optimalisere API-kallende agenter

Rollen til kunstig intelligens i teknologiselskaper utvikler seg raskt; AI-bruksområder har utviklet seg fra passiv informasjonsbehandling til proaktive agenter som kan utføre oppgaver. Ifølge en undersøkelse om global AI-tilpasning gjennomført av Georgian og NewtonX i mars 2025, bruker eller planlegger 91% av tekniske ledere i vekstfase- og bedriftsselskaper å bruke eller planlegge å bruke agenter med AI.

API-kallende agenter er et primært eksempel på denne overgangen til agenter. API-kallende agenter utnytter store språkmodeller (LLM) til å samhandle med programvaresystemer via deres programmeringsgrensesnitt (API-er).

For eksempel kan agenter, ved å oversette naturlige språkkommandoer til presise API-kall, hente sanntidsdata, automatisere rutineoppgaver eller til og med kontrollere andre programvaresystemer. Denne funksjonaliteten transformerer AI-agenter til nyttige mellomledd mellom menneskelig intensjon og programvarefunksjonalitet.

Selskaper bruker for tiden API-kallende agenter i ulike domener, inkludert:

• Forbrukerapplikasjoner: Assistentene som Apples Siri eller Amazons Alexa er designet for å forenkle daglige oppgaver, som å kontrollere smarte hjemmeenheter og gjøre reservasjoner.
• Bedriftsprosesser: Bedrifter har deployert API-agenter for å automatisere repetitive oppgaver som å hente data fra CRM, generere rapporter eller konsolidere informasjon fra interne systemer.
• Datahenting og analyse: Bedrifter bruker API-agenter for å forenkle tilgangen til proprietære datasett, abonnementsbaserte ressurser og offentlige API-er for å generere innsikt.

I denne artikkelen vil jeg bruke en ingeniør-sentrert tilnærming til å forstå, bygge og optimalisere API-kallende agenter. Materialet i denne artikkelen er basert delvis på praktisk forskning og utvikling utført av Georgians AI-laboratorium. Den motiverte spørsmålet for mye av AI-laboratoriets forskning i området API-kallende agenter har vært: “Hvis en organisasjon har en API, hva er den mest effektive måten å bygge en agent som kan samhandle med denne API-en ved hjelp av naturlig språk?”

Jeg vil forklare hvordan API-kallende agenter fungerer og hvordan man kan vellykket arkitektonisk og ingeniørmessig disse agentene for ytelse. Til slutt vil jeg gi en systematisk arbeidsflyt som ingeniørteam kan bruke til å implementere API-kallende agenter.

I. Nøkkeldefinisjoner:

• API eller Programmeringsgrensesnitt: En samling regler og protokoller som muliggjør kommunikasjon og informasjonsutveksling mellom ulike programvareapplikasjoner.
• Agent: Et AI-system designet for å oppfatte sin omverden, ta beslutninger og utføre handlinger for å oppnå bestemte mål.
• API-kallende Agent: En spesialisert AI-agent som oversetter naturlige språkinstruksjoner til presise API-kall.
• Kodegenererende Agent: Et AI-system som hjelper med programvareutvikling ved å skrive, modifisere og feilsøke kode. Selv om dette er relatert, fokuserer jeg her hovedsakelig på agenter som kaller API-er, selv om AI også kan hjelpe med å bygge disse agentene.
• MCP (Modellkontekstprotokoll): Et protokoll, særlig utviklet av Anthropic, som definerer hvordan LLM-er kan koble til og bruke eksterne verktøy og datakilder.

II. Kjerneoppgave: Oversettelse av Naturlig Språk til API-handlinger

Den grunnleggende funksjonen til en API-kallende agent er å tolke en brukers naturlige språkforespørsel og konvertere den til ett eller flere presise API-kall. Denne prosessen innebærer vanligvis:

1. Intentgjenkjenning: Å forstå brukerens mål, selv om det uttrykkes tvetydig.
2. Verktøyvalg: Å identifisere det passende API-endepunktet (eller “verktøyet”) fra en samling tilgjengelige alternativer som kan oppfylle intensjonen.
3. Parameteruttrekk: Å identifisere og uttrekke de nødvendige parameterne for det valgte API-kallet fra brukerens forespørsel.
4. Eksekvering og svarsgenerering: Å gjøre API-kallet, motta svaret og deretter syntetisere denne informasjonen til et sammenhengende svar eller utføre en påfølgende handling.

Vurdér en forespørsel som “Hei Siri, hva er været som i dag?” Agenten må identifisere behovet for å kalle en vær-API, bestemme brukerens nåværende lokasjon (eller tillate spesifisering av en lokasjon) og deretter formulere API-kallet for å hente værinformasjonen.

For forespørselen “Hei Siri, hva er været som i dag?”, kan et eksempel på et API-kall se slik ut:

GET /v1/vær?lokasjon=New%20York&enheter=metric

Initielle høynivåutfordringer er innebygget i denne oversettelsesprosessen, inkludert tvetydighet i naturlig språk og behovet for at agenten skal opprettholde kontekst over flere trinn.

For eksempel må agenten ofte “huske” tidligere deler av en samtale eller tidligere API-kallresultater for å informere nåværende handlinger. Konteksttap er en vanlig feilmodus hvis ikke dette håndteres eksplisitt.

III. Arkitektur for Løsningen: Nøkkelkomponenter og Protokoller

Bygging av effektive API-kallende agenter krever en strukturert arkitektonisk tilnærming.

1. Definering av “Verktøy” for Agenten

For at en LLM skal kunne bruke en API, må API-ens funksjonalitet beskrives for den på en måte den kan forstå. Hvert API-endepunkt eller funksjon representeres ofte som et “verktøy”. En robust verktøysdefinisjon inkluderer:

• En klar, naturlig språkbeskrivelse av verktøys formål og funksjonalitet.
• En presis spesifikasjon av innparameterne (navn, type, om det er påkrevd eller valgfritt, og en beskrivelse).
• En beskrivelse av utdata eller data verktøyet returnerer.

2. Rollen til Modellkontekstprotokoll (MCP)

MCP er en kritisk faktor for mer standardisert og robust verktøybruk av LLM-er. Den gir en strukturert format for å definere hvordan modeller kan koble til eksterne verktøy og datakilder.

MCP-standardisering er gunstig fordi den muliggjør enklere integrering av ulike verktøy, fremmer gjenbruk av verktøysdefinisjoner over ulike agenter eller modeller. Dessuten er det en best praksis for ingeniørteam, startende med godt definerte API-spesifikasjoner, som en OpenAPI-spec. Verktøy som Stainless.ai er designet for å hjelpe med å konvertere disse OpenAPI-spesifikasjonene til MCP-konfigurasjoner, og strømlinje prosessen med å gjøre API-er “agentklare”.

3. Agentrammeverk og Implementeringsvalg

Flere rammeverk kan hjelpe med å bygge agenten selv. Disse inkluderer:

• Pydantic: Selv om ikke eksklusivt et agentrammeverk, er Pydantic nyttig for å definere datastrukturer og sikre typesikkerhet for verktøyinndata og -utdata, noe som er viktig for pålitelighet. Mange tilpassede agentimplementeringer utnytter Pydantic for denne strukturelle integriteten.
• LastMiles mcp_agent: Dette rammeverket er spesifikt designet for å fungere med MCP-er, og tilbyr en mer bestemt struktur som samsvare med praksis for bygging effektive agenter, som beskrevet i forskning fra steder som Anthropic.
• Intern Rammeverk: Det er også stadig mer vanlig å bruke AI-kodegenereringsagenter (med verktøy som Cursor eller Cline) for å hjelpe med å skrive boilerplate-koden for agenten, dens verktøy og den omgivende logikken. Georgians AI-laboratoriums erfaring med å arbeide med selskaper på agenterimplementeringer viser at dette kan være bra for å skape svært minimalistiske, tilpassede rammeverk.

IV. Ingeniørarbeid for Pålitelighet og Ytelse

Sikring av at en agent gjør API-kall pålitelig og fungerer godt, krever fokusert ingeniørarbeid. To måter å gjøre dette på er (1) datasett opprettelse og validering og (2) promptingeniørarbeid og optimalisering.

1. Datasett Opprettelse og Validering

Trening (hvis aktuelt), testing og optimalisering av en agent krever et høykvalitetsdataset. Dette datasettet bør bestå av representative naturlige språkforespørsler og deres tilhørende ønskede API-kallsekvenser eller resultater.

• Manuell Opprettelse: Manuell kurering av et datasett sikrer høy presisjon og relevans, men kan være arbeidskrevende.
• Syntetisk Generering: Generering av data programmatisk eller ved hjelp av LLM-er kan skalerer datasett opprettelse, men denne tilnærmingen presenterer betydelige utfordringer. Georgians AI-laboratoriums forskning fant at sikring av korrekthet og realistisk kompleksitet av syntetisk genererte API-kall og forespørsler er svært vanskelig. Ofte var de genererte spørsmålene enten for enkle eller umulig komplekse, noe som gjorde det vanskelig å måle nyansert agentytelse. Omhyggelig validering av syntetisk data er absolutt kritisk.

For kritisk evaluering tilbyr et mindre, høykvalitets, manuelt verifisert datasett ofte mer pålitelige innsikter enn et stort, støyende syntetisk datasett.

2. Promptingeniørarbeid og Optimalisering

Ytelsen til en LLM-basert agent påvirkes sterkt av promptene som brukes til å guide dens resonnering og verktøyvalg.

• Effektiv prompting innebærer å klart definere agentens oppgave, å gi beskrivelser av tilgjengelige verktøy og å strukturere prompten for å oppmuntre nøyaktig parameteruttrekk.
• Systematisk optimalisering ved hjelp av rammeverk som DSPy kan betydelig forbedre ytelsen. DSPy lar deg definere agentens komponenter (f.eks. moduler for tankegenerering, verktøyvalg, parameterformatering) og deretter bruke en kompilator-lignende tilnærming med få eksempler fra datasettet for å finne optimerte prompter eller konfigurasjoner for disse komponentene.

V. En Anbefalt Veide til Effektive API-Agenter

Utvikling av robuste API-kallende AI-agenter er en iterativ ingeniørdisiplin. Basert på funnene fra Georgians AI-laboratoriums forskning, kan resultater betydelig forbedres ved å bruke en systematisk arbeidsflyt som følger:

1. Start med Klare API-Definisjoner: Begynn med godt strukturerte OpenAPI-Spesifikasjoner for API-ene agenten skal samhandle med.
2. Standardisere Verktøytilgang: Konverter OpenAPI-spesifikasjonene til MCP-verktøy. Verktøy som Stainless.ai kan fasilitere dette, og skape en standardisert måte for agenten å forstå og bruke API-ene.
3. Implementer Agenten: Velg et passende rammeverk eller tilnærming. Dette kan innebære å bruke Pydantic for datamodellering innenfor en tilpasset agentstruktur eller å utnytte et rammeverk som LastMiles mcp_agent som er bygget rundt MCP.
   • Før du gjør dette, vurdér å koble MCP til et verktøy som Claude Desktop eller Cline, og manuelt bruke dette grensesnittet for å få en følelse av hvor godt en generisk agent kan bruke det, hvor mange iterasjoner det vanligvis tar å bruke MCP korrekt og andre detaljer som kan spare tid under implementering.
4. Kurér et Kvalitetsvurderingsdatasett: Opprett manuelt eller valider nøye et datasett av forespørsler og ønskede API-interaksjoner. Dette er kritisk for pålitelig testing og optimalisering.
5. Optimaliser Agentprompter og Logikk: Anvend rammeverk som DSPy for å finjustere agentens prompter og indre logikk, ved å bruke datasettet til å drive forbedringer i nøyaktighet og pålitelighet.

VI. Et Illustrerende Eksempel på Arbeidsflyten

Her er et forenklet eksempel som illustrerer den anbefalte arbeidsflyten for å bygge en API-kallende agent:

Trinn 1: Start med Klare API-Definisjoner

Forestall en API for å håndtere en enkel gjøremåliste, definert i OpenAPI:

openapi: 3.0.0

info:

tittel: Gjøremåliste-API

versjon: 1.0.0

stier:

/oppdrag:

post:

oppsummering: Legg til et nytt oppdrag

forespørselsbody:

påkrevd: true

innhold:

application/json:

skjema:

type: objekt

egenskaper:

beskrivelse:

type: streng

responser:

‘201’:

beskrivelse: Oppdrag opprettet

get:

oppsummering: Hent alle oppdrag

responser:

‘200’:

beskrivelse: Liste over oppdrag

Trinn 2: Standardisere Verktøytilgang

Konverter OpenAPI-spesifikasjonen til Modellkontekstprotokoll (MCP)-konfigurasjoner. Ved hjelp av et verktøy som Stainless.ai kan dette muligens føre til:

Trinn 3: Implementer Agenten

Ved hjelp av Pydantic for datamodellering, opprett funksjoner som svarer til MCP-verktøyene. Deretter kan en LLM brukes til å tolke naturlige språkforespørsler og velge det passende verktøyet og parameterne.

Trinn 4: Kurér et Kvalitetsvurderingsdatasett

Opprett et datasett:

Trinn 5: Optimaliser Agentprompter og Logikk

Bruk DSPy til å finjustere promptene, med fokus på klare instruksjoner, verktøyvalg og parameteruttrekk ved hjelp av det kurerte datasettet for evaluering og forbedring.

Ved å integrere disse byggeklossene – fra strukturerte API-definisjoner og standardiserte verktøyprotokoller til strenge datapraksiser og systematisk optimalisering – kan ingeniørteam bygge mer kapable, pålitelige og vedlikeholdbare API-kallende AI-agenter.