Gevinster:
- At definere en agent som 'model + værktøjer + loop' og beslutte, hvornår det er nødvendigt
- Skrivning af værktøjsdefinitionen med navn, beskrivelse og input_schema
- Overvågning af flow og fejlhåndtering af tool_use og tool_result loop
Indtil nu har modellen altid udført ét job: modtage tekstinput, producere tekstsvar. Men rigtigt arbejde kræver ofte mere end tekst; udføre en beregning, forespørge i en database, kalde en API, finde ud af en aktuel valutakurs. Modellen kan ikke gøre disse ting selv - men hun kan bestemme, hvornår de skal gøres, og bede nogen om at gøre dem. Det er, hvad værktøjsbrug giver modellen, og det er grundlaget for AI-agenter. I denne enhed lærer vi, hvad en agent er, hvordan værktøjet er defineret, og hvordan tool_use-løkken fungerer.
Hvad er en agent? Model + Værktøj + Løkke
En AI-agent består af tre dele: modellen (hjernen, der træffer beslutningen), værktøjerne (de funktioner, som modellen kan kalde: vejr, databaseforespørgsel, send e-mail), og løkken (løkken; modellen kalder værktøjet, får resultatet, beslutter igen, hvad der skal gøres, og så videre).
Kritisk skelnen: Et enkelt mønsteropkald er ikke en agent. Agent er en proces, hvor modellen fortsætter trin for trin, ved hvert trin at vælge det næste træk baseret på værktøjets resultat. "Tænk som et menneske, brug dine hænder, se på resultatet, tænk om igen."
En vigtig kendsgerning: Modellen selv betjener ikke køretøjet. Modellen siger bare "Jeg vil kalde dette værktøj med disse input". Din applikation (kaldet en sele) kører værktøjet og returnerer resultatet til modellen. Dette er afgørende for sikkerheden: modellen berører ikke dit system direkte; Hver handling er under din kontrol.
Tip: Forsøg ikke at løse alle problemer med agenten. Agent; øger risikoen for forsinkelser, omkostninger og fejl. Spørg først: "Vil dette blive løst med et enkelt opkald eller en fast arbejdsgang?" Hvis svaret er ja, er der ikke behov for en agent. Agent er til åbne opgaver, hvor trinene ikke kan kendes på forhånd.
Værktøjsdefinition: navn, beskrivelse, input_skema
For at introducere et værktøj i modellen giver du tre ting:
- navn: Køretøjets identitet, f.eks. få_vejr.
- beskrivelse: Hvad værktøjet gør, og hvornår det skal kaldes. Dette er det vigtigste område, der gør det muligt for modellen at vælge det rigtige værktøj på det rigtige tidspunkt. Skriv ikke bare "hvad gør", men også "ring hvornår".
- input_schema (input skema): JSON skema, der definerer hvilke parametre værktøjet forventer, i hvilken type.
# Køretøjsdefinition (konceptuelt — JSON-skema){ "name": "get_order_status", "description": "Henter den aktuelle forsendelsesstatus for en ordre. Ring, når brugeren spørger, hvor et ordrenummer er, eller hvornår det vil ankomme.", "input_schema": { "type": "object", "properties": { "order_no": string, "order_no": {"order_no": {"Order_nr. f.eks. SP-1024"} }, "påkrævet": ["ordre_no"] }}
Regler for en god værktøjsbeskrivelse: klart og kortfattet navn, beskrivelse med "hvornår skal bruges", beskrivelse for hver parameter, indsættelse af de virkelig obligatoriske. Hold fokus på antallet af køretøjer; Dusinvis af lignende bilmodeller er overraskende.
område
Hvad gør det?
godt eksempel
dårligt eksempel
navn
Køretøjs-id
order_status_getir
bringe
beskrivelse
Hvad den gør + hvornår man skal ringe
"Returnerer fragtstatus; ring, når brugeren spørger, hvor ordren er"
"henter data"
input_skema
Parametertype og krav
{ordre_nr: streng, kommenteret}
intet diagram / ingen beskrivelse
tool_use → tool_result Loop
Cyklussen fungerer sådan, trin for trin:
- Du sender brugerspørgsmålet + værktøjsbeskrivelser til modellen.
- Modellen reagerer enten direkte eller genererer en tool_use blok: "kald order_durumu_getir med order_no=SP-1024."
- Din applikation kører faktisk værktøjet (forespørger databasen).
- Du sender resultatet tilbage til modellen som tool_result.
- Med dette resultat producerer modellen enten det endelige svar eller kalder et andet værktøj. Cyklussen fortsætter, indtil modellen siger "Jeg er færdig."
# Agent loop (konceptuelle) meddelelser = [brugerspørgsmål] mens True: respons = model.uret(meddelelser, værktøjer=værktøjsdefinitioner) if response.tur == "værktøj_brug": resultat = harness.run(respons.værktøj_navn, svar.indtastninger) # APPLIKATION kører meddelelser værktøj +_= [retur # resultat, resultat pause svar; sløjfe ender
Moderne SDK'er tilbyder værktøjsløbere, der kører denne løkke for dig; du skriver bare værktøjets funktioner. Men det er præcis, hvad der sker bag kulisserne.
Fejlhåndtering
Værktøjer kan mislykkes: ordre ikke fundet, API timeout, input er ugyldigt. Hvis du ikke kan køre værktøjet, skal du returnere fejlen til modellen som et beskrivende tool_result ("fejl: Ordrenummer SP-9999 ikke fundet") og fejlflaget. Modellen kan se dette og forsigtigt forklare det for brugeren, eller prøve en anden måde. Slug ikke fejlen og returner tomme resultater; Modellen skal vide, hvad der gik galt.
Svag/stærk køretøjsbeskrivelse
Svag (ubestemt navneord, intet "hvornår"):
navn: "data", beskrivelse: "henter data"# Modellen ved ikke hvornår og hvordan man ringer; Enten ringer den slet ikke eller ringer forkert.
Stærk (nettonavn + når + parameterbeskrivelse):
navn: "musteri_bakiyesi_getir"description: "Returnerer en kundes løbende kontosaldo. Ring, når brugeren beder om debet, kredit eller saldo. FORETAR IKKE betaling."input_schema: {custeri_id: string ("Kunde-id")}# Modellen ringer på det rigtige tidspunkt, med de rigtige parametre, og kender sin grænse.
Tre mini etuier
Sag 1 — Unødvendig agent. Et team byggede "opsummer tekst"-forretningen med en multiværktøjsagent; Hver opsummering tager 4 modelopkald og 9 sekunder. Jobbet var faktisk et one-call job. Da vi fjernede agenten og reducerede det til et enkelt opkald, faldt tiden til 1,5 sekunder, og prisen faldt til et kvartal. Lektion: Brug midlet, når det virkelig er nødvendigt.
Case 2 — Svag forklaring, forkert opkald. I en supportagent blev et obskurt værktøj kaldet apport tilfældigt kaldt af modellen i både balancespørgsmålet og forsendelsesspørgsmålet. Da køretøjerne blev opdelt i balance_getir og cargo_durumu_getir og "ring når"-forklaringer blev tilføjet, faldt forkert valg af køretøjer fra 18 til 1 ud af 50 eksempler.
Tilfælde 3 — Fejl slugt. En agent returnerede tomme resultater, da ordren ikke blev fundet; Modellen tolkede dette som "ordren blev leveret" og vildledte kunden. Når fejlmeddelelsen er skrevet eksplicit til tool_result ("ordre ikke fundet"), siger modellen korrekt "Jeg kunne ikke finde dette nummer, kan du tjekke det?" begyndte han at sige.
Almindelige fejl
- At vende alt til en agent: Mens et opkald er nok, tilføjer agenten omkostninger og forsinkelse.
- Uklar køretøjsbeskrivelse: Modellen ved ikke, hvornår den skal ringe; vælger forkert.
- Tænker, at modellen kører køretøjet: Selen kører køretøjet; modellen vil bare have.
- At sluge fejlen: Modellen skal vide, hvad der gik galt; Giv fejlen som open tool_result.
- For mange lignende køretøjer: Model bliver forvirret; Hold værktøjssættet fokuseret og minimalt.
Bemærk: Bare fordi modellen siger "ring til det køretøj", betyder det ikke, at der skal tages handling. På destruktive værktøjer (slet, checkout, e-mail) bør din applikation ikke blindt udføre opkaldet - dette er kernen i sikkerhedsemnet i den næste enhed.
Sammenfattende
- Agent = model (beslutning) + værktøjer (funktioner) + loop (kald værktøj, få resultat, beslut igen).
- Et enkelt mønsterkald er ikke en agent; agent er en trin-for-trin proces.
- Modellen kører ikke køretøjet; Din applikation kører (harness) og returnerer resultatet som tool_result.
- Værktøjet identificeres ved navn, beskrivelse (specifikt "ring når") og input_schema.
- Sløjfen fortsætter som tool_use → selen kører → tool_result → modellen fortsætter indtil modellen siger "færdig"; fejl rapporteres eksplicit til modellen.
Ansøgningsopgave
Design 3 værktøjer fra din egen virksomhed, som kan gives til agenten. (1) Skriv navn, beskrivelse med "kald når" og input_schema for hver; Lad mindst én være et ikke-destruktiv læseværktøj og én en beregning. (2) Vælg et realistisk brugerspørgsmål og skriv manuelt trin for trin (i en løkke), hvilke af disse værktøjer modellen vil kalde med hvilke input og hvad den vil gøre efter tool_result ankommer. (3) Opsæt et scenarie, hvor et af værktøjerne fejler, og vis, hvordan fejlmeddelelsen vender tilbage til modellen.
tjekliste
- [ ] Jeg kan definere agenten som "model + værktøjer + loop" og bestemme, hvornår det er nødvendigt.
- [ ] Jeg ved, at selen kører køretøjet, modellen vil bare have det.
- Jeg kan skrive en solid køretøjsbeskrivelse med [ ] navn, beskrivelse ("ring når") og input_schema.
- Jeg kan følge cyklussen [ ] tool_use → tool_result trin for trin.
- [ ] Jeg rapporterer værktøjsfejl til modellen som open tool_result.