Tankeledere
Guide til at forstå, opbygge og optimere API-kaldende agenter To-Do List API version: 1.0.0 paths: /tasks: post: summary: Tilføj en ny opgave requestBody: required: true

Rollen for 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-adopteringsgrad, gennemført af Georgian og NewtonX, er 91% af tekniske direktører i virksomheder i vækst- og enterprise-fasen angiveligt ved at bruge eller planlægge 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 styre andre software-systemer. Denne funktion transformerer AI-agenter til nyttige mellemled mellem menneskers intentioner og software-funktionalitet.
Virksomheder bruger i øjeblikket API-kaldende agenter i forskellige domæner, herunder:
- Forbrugerapplikationer: Assistenter som Apples Siri eller Amazons Alexa er designet til at simplificere daglige opgaver, såsom at styre smarte hjemmeenheder og foretage reservationer.
- Enterprise-workflows: Virksomheder har udrullet API-agenter til at automatisere repetitive opgaver som at hente data fra CRM’er, generere rapporter eller konsolidere information fra interne systemer.
- Datahenting 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å, opbygge og optimere API-kaldende agenter. Materialet i denne artikel er baseret delvist på den praktiske forskning og udvikling, der er gennemført af Georgians AI Lab. Det motiverende spørgsmål for meget af AI Labs forskning på området for API-kaldende agenter har været: “Hvis en organisation har en API, hvad er den mest effektive måde at opbygge en agent, der kan interface med denne API ved hjælp af naturligt sprog?”
Jeg vil forklare, hvordan API-kaldende agenter fungerer, og hvordan man kan arkitekturere og ingeniøre disse agenter for ydelse. Endelig vil jeg give en systematisk arbejdsproces, som ingeniørteams 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å specifikke mål.
- API-kaldende agent: En specialiseret AI-agent, der oversætter naturlige sprogkommandoer til præcise API-kald.
- Code-genererende agent: Et AI-system, der assisterer i software-udvikling ved at skrive, modificere og fejlfinde kode. Selvom det er relateret, er mit fokus 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 for en API-kaldende agent er at fortolke en brugers naturlige sprogforespørgsel og konvertere den til en eller flere præcise API-kald. Denne proces involverer typisk:
- Intent-genkendelse: At forstå brugernes mål, selv hvis det udtrykkes tvetydigt.
- Værktøjvalg: At identificere det passende API-endpoint (eller “værktøj”) fra en samling af tilgængelige muligheder, der kan opfylde intentionen.
- Parameter-ekstraktion: At identificere og ekstrahere de nødvendige parametre for det valgte API-kald (eller kald) fra brugers forespørgsel.
- Udførelse og respons-generering: At udføre API-kaldet (eller kald), modtage responsen (eller respons) og derefter syntetisere denne information til en samlet besked eller udføre en efterfølgende handling.
Overvej en forespørgsel som “Hej Siri, hvordan er vejret i dag?” Agenten må identificere behovet for at kalde en vejrappi, bestemme brugernes aktuelle placering (eller tillade specifikation af en placering) og derefter formulere API-kaldet til at hente vejrinformation.
For forespørgslen “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øjt niveau udfordringer er indbygget i denne oversættelsesproces, herunder tvetydigheden af naturligt sprog og behovet for, at agenten opretholder kontekst på tværs af multi-trins interaktioner.
For eksempel skal agenten ofte “huske” tidligere dele af en samtale eller tidligere API-kaldresultater for at informere nuværende handlinger. Konteksttab er en almindelig fejltilstand, hvis ikke det håndteres eksplizit.
III. Arkitektur for løsningen: Nøglekomponenter og protokoller
Opbygning 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 inputparametre (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 for Model Context Protocol (MCP)
MCP er en kritisk aktiver for mere standardiseret og robust værktøjsbrug af LLM’er. Den giver en struktureret format for at definere, hvordan modeller kan tilslutte og udnytte eksterne værktøjer og datakilder.
MCP-standardisering er fordelagtigt, da 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ørteams, der starter 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-klar”.
3. Agent-rammer & implementeringsvalg
Der er flere rammer, der kan hjælpe med at opbygge agenten selv. Disse omfatter:
- Pydantic: Selvom det ikke udelukkende er en agent-ramme, er Pydantic nyttigt til at definere datastrukturer og sikre typesikkerhed for værktøjers input og output, hvilket er vigtigt for pålidelighed. Mange brugerdefinerede agentimplementeringer udnytter Pydantic til denne strukturintegritet.
- LastMiles mcp_agent: Denne ramme er specifikt designet til at arbejde med MCP’er, og tilbyder en mere opiniot struktur, der er i overensstemmelse med bedste praksis for opbygning 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 (ved hjælp af 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 AI Labs erfaring med at arbejde med virksomheder på agentic-implementeringer viser, at dette kan være fantastisk til at opbygge meget minimale, brugerdefinerede rammer.
IV. Ingeniørarbejde for pålidelighed og ydelse
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 & 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 Labs forskning fandt, at sikring af korrektheden og den realistiske 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 agentydelse. Omhyggelig validering af syntetisk data er absolut kritisk.
For 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 & optimering
LLM-baseret agents ydelse påvirkes kraftigt af de prompts, der bruges til at guide dets resonnering og værktøjsvalg.
- Effektivt prompt-ingeniørarbejde involverer at definere agentens opgave tydeligt, 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 ydelsen. DSPy tillader dig at definere agentens komponenter (f.eks. moduler for tankegenerering, værktøjsvalg, parameterformatering) og derefter bruger en compiler-lignende tilgang med få-shot-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ørdisciplin. Baseret på resultaterne af Georgian AI Labs forskning kan resultaterne betydeligt forbedres ved hjælp af en systematisk arbejdsproces som følger:
- Start med klare API-definitioner: Begynd med velstrukturerede OpenAPI-specifikationer for de API’er, din agent vil interagere med.
- 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å.
- Implementer agenten: Vælg en passende ramme eller tilgang. Dette kan involvere brug af Pydantic til data-modellering inden for en brugerdefineret agent-struktur eller udnyttelse af en ramme som LastMiles mcp_agent, der er bygget op omkring MCP.
- Før du gør dette, overvej at tilslutte MCP til et værktøj som Claude Desktop eller Cline og manuelt bruge dette interface 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 eventuelle andre detaljer, der kan spare dig tid under implementeringen.
- 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.
- Optimer agent-prompts og logik: Anvend rammer som DSPy til at forfine agentens prompts og interne logik, ved hjælp af dit datasæt til at drive forbedringer i nøjagtighed og pålidelighed.
VI. Et illustrativt eksempel på arbejdsprocessen
Her er et simplificeret eksempel, der illustrerer den anbefalede arbejdsproces for at opbygge 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:
application/json:
schema:
type: object
properties:
description:
type: string
responses:
‘201’:
description: Opgave oprettet med succes
get:
summary: Få alle opgaver
responses:
‘200’:
description: Liste over 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:
| Værktøjsnavn | Beskrivelse | Inputparametre | Outputbeskrivelse |
| Tilføj opgave | Tilføjer en ny opgave til To-Do-listen. | `description` (string, påkrævet): Opgavens beskrivelse. | Bekræftelse af opgaveoprettelse. |
| Få opgaver | Henter alle opgaver fra To-Do-listen. | Ingen | En liste over opgaver med deres beskrivelser. |
Trin 3: Implementer agenten
Ved hjælp af Pydantic til data-modellering 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:
| Forespørgsel | Forventet API-kald | Forventet resultat |
| “Tilføj ‘Køb ind’ til min liste.” | `Tilføj opgave` med `description` = “Køb ind” | Bekræftelse af opgaveoprettelse |
| “Hvad er på min liste?” | `Få opgaver` | Liste over opgaver, herunder “Køb ind” |
Trin 5: Optimer agent-prompts og logik
Ved hjælp af DSPy kan du forfine promptene, fokusere 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ørteams bygge mere kapable, pålidelige og vedligeholdelige API-kaldende AI-agenter.












