AI-agenter og verktøybruk

Gevinster:

• Definere en agent som 'modell + verktøy + loop' og bestemme når det er nødvendig
• Skrive verktøydefinisjonen med navn, beskrivelse og input_schema
• Overvåking av flyt og feilhåndtering av verktøy_bruk og verktøy_resultat-løkken

Til nå har modellen alltid gjort én jobb: motta tekstinndata, produsere tekstsvar. Men ekte arbeid krever ofte mer enn tekst; utføre en beregning, spørre en database, kalle et API, finne ut en gjeldende valutakurs. Modellen kan ikke gjøre disse tingene selv - men hun kan bestemme når de må gjøres og be noen om å gjøre dem. Det er dette verktøybruken gir modellen, og dette er grunnlaget for AI-agenter. I denne enheten vil vi lære hva en agent er, hvordan verktøyet er definert og hvordan tool_use-løkken fungerer.

Hva er en agent? Modell + Verktøy + Løkke

En AI-agent består av tre deler: modellen (hjernen som tar avgjørelsen), verktøyene (funksjonene modellen kan kalle: vær, databasespørring, send e-post), og loopen (løkken; modellen kaller verktøyet, får resultatet, bestemmer igjen hva som skal gjøres, og så videre).

Kritisk distinksjon: Et enkelt mønsteranrop er ikke en agent. Agent er en prosess der modellen fortsetter trinnvis, ved hvert trinn velges neste trekk basert på verktøyets resultat. "Tenk som et menneske, bruk hendene, se på resultatet, tenk om igjen."

Et viktig faktum: Selve modellen betjener ikke kjøretøyet. Modellen sier bare "Jeg vil kalle dette verktøyet med disse inngangene". Applikasjonen din (kalt en sele) kjører verktøyet og returnerer resultatet til modellen. Dette er avgjørende for sikkerheten: modellen berører ikke systemet ditt direkte; Hver handling er under din kontroll.

Tips: Ikke prøv å løse alle problemer med agenten. Agent; øker risikoen for forsinkelser, kostnader og feil. Spør først: «Vil dette løses med en enkelt samtale eller en fast arbeidsflyt?» Hvis svaret er ja, er det ikke behov for en agent. Agent er for åpne oppgaver der trinnene ikke kan kjennes på forhånd.

Verktøydefinisjon: navn, beskrivelse, input_schema

For å introdusere et verktøy i modellen, gir du tre ting:

• navn: Identiteten til kjøretøyet, f.eks. få_vær.
• beskrivelse: Hva verktøyet gjør og når det skal kalles det. Dette er det viktigste området som gjør at modellen kan velge riktig verktøy til rett tid. Skriv ikke bare "hva gjør", men også "ring når."
• input_schema (input schema): JSON-skjema som definerer hvilke parametere verktøyet forventer, i hvilken type.

# Kjøretøydefinisjon (konseptuell — JSON-skjema){ "name": "get_order_status", "description": "Henter gjeldende fraktstatus for en ordre. Ring når brukeren spør hvor et ordrenummer er eller når det vil ankomme.", "input_schema": { "type": "object", "properties": { "order_no":string", "order_no": {:"Order_no":string f.eks. SP-1024"} }, "required": ["order_no"] }}

Regler for en god verktøybeskrivelse: klart og kortfattet navn, beskrivelse med "når den skal brukes", beskrivelse for hver parameter, angi de virkelig obligatoriske. Hold fokus på antall kjøretøy; Dusinvis av lignende kjøretøymodeller er overraskende.

område

Hva gjør det?

godt eksempel

dårlig eksempel

navn

Kjøretøy-ID

order_status_getir

bringe

beskrivelse

Hva den gjør + når du skal ringe

"Returnerer laststatus; ring når brukeren spør hvor bestillingen er"

"henter data"

input_schema

Parametertype og krav

{ordre_no: streng, kommentert}

ingen diagram / ingen beskrivelse

tool_use → tool_result Løkke

Syklusen fungerer slik, trinn for trinn:

1. Du sender brukerspørsmålet + verktøybeskrivelser til modellen.
2. Modellen svarer enten direkte eller genererer en tool_use-blokk: "ring order_durumu_getir med order_no=SP-1024."
3. Applikasjonen din kjører faktisk verktøyet (spør databasen).
4. Du sender resultatet tilbake til modellen som tool_result.
5. Med dette resultatet produserer modellen enten det endelige svaret eller kaller et annet verktøy. Syklusen fortsetter til modellen sier "Jeg er ferdig."

# Agent loop (konseptuelle) meldinger = [brukerspørsmål] mens True: respons = model.uret(meldinger, verktøy=verktøy_definisjoner) if response.tur == "verktøy_bruk": resultat = harness.run(respons.verktøy_navn, respons.oppføringer) # APPLIKASJON kjører meldinger +_= [respons # resultat, brudd svar; løkke ender

Moderne SDK-er tilbyr verktøyløpere som kjører denne løkken for deg; du skriver bare verktøyfunksjonene. Men det er akkurat det som skjer bak kulissene.

Feilhåndtering

Verktøy kan mislykkes: bestillingen ble ikke funnet, API-en tidsavbrutt, inndata er ugyldig. Hvis du ikke kan kjøre verktøyet, returner feilen til modellen som et beskrivende tool_result ("feil: Ordrenummer SP-9999 ikke funnet") og feilflagget. Modellen kan se dette og forsiktig forklare det til brukeren, eller prøve en annen måte. Ikke svelg feilen og returner tomme resultater; Modellen må vite hva som gikk galt.

Svak/sterk kjøretøybeskrivelse

Svak (ubestemt substantiv, ingen "når"):

navn: "data", beskrivelse: "henter data"# Modellen vet ikke når og hvordan den skal ringe; Enten ringer den ikke i det hele tatt eller ringer feil.

Sterk (nettnavn + når + parameterbeskrivelse):

navn: "musteri_bakiyesi_getir"description: "Returnerer gjeldende kontosaldo til en kunde. Ring når brukeren ber om debet, kreditt eller saldo. GJØR IKKE betaling."input_schema: {custeri_id: string ("Kunde-ID")}# Modellen ringer til rett tid, med riktige parametere, og kjenner sin grense.

Tre minivesker

Sak 1 - Unødvendig agent. Ett team bygde "sammendrag tekst"-virksomheten med en agent med flere verktøy; Hver oppsummering tar 4 modellanrop og 9 sekunder. Jobben var egentlig en engangsjobb. Da vi fjernet agenten og reduserte den til en enkelt samtale, ble tiden redusert til 1,5 sekunder og kostnadene redusert til ett kvartal. Leksjon: bruk agenten når det virkelig er nødvendig.

Case 2 — Svak forklaring, feil samtale. I en støtteagent ble et obskurt verktøy kalt henting tilfeldig kalt av modellen i både saldospørsmålet og fraktspørsmålet. Når kjøretøyene ble delt inn i balance_getir og cargo_durumu_getir og "ring når"-forklaringer ble lagt til, gikk feil kjøretøyvalg ned fra 18 til 1 av 50 eksempler.

Tilfelle 3 — Feil svelget. En agent returnerte tomme resultater da bestillingen ikke ble funnet. Modellen tolket dette som at "ordren ble levert" og villedet kunden. Når feilmeldingen er skrevet eksplisitt til tool_result ("ordre ikke funnet"), sier modellen riktig "Jeg kunne ikke finne dette nummeret, kan du sjekke det?" begynte han å si.

Vanlige feil

• Gir alt til en agent: Mens en samtale er nok, legger agenten til kostnader og forsinkelser.
• Uklar kjøretøybeskrivelse: Modellen vet ikke når den skal ringe; velger feil.
• Tenker at modellen kjører kjøretøyet: Selen kjører kjøretøyet; modellen bare vil ha.
• Svelger feilen: Modellen må vite hva som gikk galt; Gi feilen som open tool_result.
• For mange lignende kjøretøy: Modellen blir forvirret; Hold verktøysettet fokusert og minimalt.

Oppmerksomhet: Bare fordi modellen sier «ring det kjøretøyet», betyr det ikke at det bør iverksettes tiltak. På destruktive verktøy (sletting, utsjekking, e-post) skal ikke applikasjonen utføre anropet blindt – dette er kjernen i sikkerhetsemnet i neste enhet.

Oppsummert

• Agent = modell (beslutning) + verktøy (funksjoner) + loop (ringe verktøy, få resultat, bestemme på nytt).
• Et enkelt mønsteranrop er ikke en agent; agent er en trinnvis prosess.
• Modellen kjører ikke kjøretøyet; Applikasjonen din kjører (harness) og returnerer resultatet som tool_result.
• Verktøyet identifiseres ved navn, beskrivelse (spesifikt "ring når") og input_schema.
• Sløyfen fortsetter mens tool_use → sele kjører → tool_result → modellen fortsetter til modellen sier "ferdig"; feil rapporteres eksplisitt til modellen.

Søknadsoppgave

Design 3 verktøy fra din egen virksomhet som kan gis til agenten. (1) Skriv navn, beskrivelse med "ring når", og input_schema for hver; La minst ett være et ikke-destruktivt leseverktøy og ett regnestykke. (2) Velg et realistisk brukerspørsmål og skriv manuelt trinn for trinn (i en sløyfe) hvilke av disse verktøyene modellen vil ringe med hvilke innganger og hva den vil gjøre etter at tool_result kommer. (3) Sett opp et scenario der ett av verktøyene feiler og vis hvordan feilmeldingen kommer tilbake til modellen.

sjekkliste

• [ ] Jeg kan definere agenten som "modell + verktøy + loop" og bestemme når det er nødvendig.
• [ ] Jeg vet at selen kjører kjøretøyet, modellen vil bare ha det.
• Jeg kan skrive en solid kjøretøybeskrivelse med [ ] navn, beskrivelse ("ring når") og input_schema.
• Jeg kan følge syklusen [ ] tool_use → tool_result trinn for trinn.
• [ ] Jeg rapporterer verktøyfeil til modellen som open tool_result.