Vinster:
- Definiera en agent som 'modell + verktyg + loop' och bestämma när det behövs
- Skriva verktygsdefinitionen med namn, beskrivning och input_schema
- Övervaka flödet och felhanteringen av loopen tool_use och tool_result
Fram till nu har modellen alltid gjort ett jobb: ta emot textinmatning, producera textsvar. Men riktigt arbete kräver ofta mer än text; utföra en beräkning, fråga efter en databas, anropa ett API, ta reda på en aktuell växelkurs. Modellen kan inte göra dessa saker själv - men hon kan bestämma när de behöver göras och be någon att göra dem. Detta är vad verktygsanvändning ger modellen, och detta är grunden för AI-agenter. I den här enheten kommer vi att lära oss vad en agent är, hur verktyget definieras och hur slingan tool_use fungerar.
Vad är en agent? Modell + Verktyg + Slinga
En AI-agent består av tre delar: modellen (hjärnan som fattar beslutet), verktygen (funktionerna som modellen kan anropa: väder, databasfråga, skicka e-post), och slingan (slingan; modellen anropar verktyget, får resultatet, bestämmer igen vad som ska göras, och så vidare).
Kritisk skillnad: Ett enda mönsteranrop är inte en agent. Agent är en process där modellen fortsätter steg för steg, i varje steg väljer man nästa steg baserat på verktygets resultat. "Tänk som en människa, använd händerna, titta på resultatet, tänk om."
Ett viktigt faktum: Modellen själv styr inte fordonet. Modellen säger bara "Jag vill kalla det här verktyget med dessa ingångar". Din applikation (kallad sele) kör verktyget och returnerar resultatet till modellen. Detta är avgörande för säkerheten: modellen berör inte ditt system direkt; Varje åtgärd är under din kontroll.
Tips: Försök inte lösa alla problem med agenten. Ombud; ökar risken för förseningar, kostnader och fel. Fråga först: "Kommer detta att lösas med ett enda samtal eller ett fast arbetsflöde?" Om svaret är ja, behövs ingen agent. Agent är för öppna uppgifter där stegen inte kan vara kända i förväg.
Verktygsdefinition: namn, beskrivning, input_schema
För att introducera ett verktyg i modellen ger du tre saker:
- namn: Fordonets identitet, t.ex. få_väder.
- beskrivning: Vad verktyget gör och när det ska kallas. Detta är det viktigaste området som gör att modellen kan välja rätt verktyg vid rätt tidpunkt. Skriv inte bara "vad gör" utan också "ringa när."
- input_schema (input schema): JSON-schema som definierar vilka parametrar verktyget förväntar sig, i vilken typ.
# Fordonsdefinition (konceptuellt — JSON-schema){ "name": "get_order_status", "description": "Hämtar aktuell leveransstatus för en beställning. Ring när användaren frågar var ett beställningsnummer finns eller när det kommer fram.", "input_schema": { "type": "object", "properties": { "order_no": string, "order_no": {:Ordernummer: string t.ex. SP-1024"} }, "required": ["order_no"] }}
Regler för en bra verktygsbeskrivning: tydligt och kortfattat namn, beskrivning med "när den ska användas", beskrivning för varje parameter, sätta in de verkligt obligatoriska. Håll fokus på antalet fordon; Dussintals liknande fordonsmodeller är överraskande.
område
Vad gör det?
bra exempel
dåligt exempel
namn
Fordons-ID
order_status_getir
ta med
beskrivning
Vad den gör + när man ska ringa
"Returnerar laststatus; ring när användaren frågar var beställningen är"
"hämtar data"
input_schema
Parametertyp och krav
{order_nr: sträng, kommenterad}
inget diagram / ingen beskrivning
tool_use → tool_result Slinga
Cykeln fungerar så här, steg för steg:
- Du skickar användarfrågan + verktygsbeskrivningar till modellen.
- Modellen svarar antingen direkt eller genererar ett tool_use-block: "ring order_durumu_getir med order_no=SP-1024."
- Din applikation kör faktiskt verktyget (frågar databasen).
- Du skickar tillbaka resultatet till modellen som tool_result.
- Med detta resultat producerar modellen antingen det slutliga svaret eller anropar ett annat verktyg. Cykeln fortsätter tills modellen säger "Jag är klar."
# Agent loop (konceptuella) meddelanden = [user_question] medan True: response = model.uret(meddelanden, verktyg=tool_definitions) if response.tur == "tool_use": result = harness.run(response.tool_name, response.entries) # APPLICATION kör meddelanden +_= [retur # resultat, resultat paus svar; slinga slutar
Moderna SDK:er erbjuder verktygslöpare som kör den här slingan åt dig; du skriver bara verktygsfunktionerna. Men det är precis vad som händer bakom kulisserna.
Felhantering
Verktygen kan misslyckas: beställningen hittades inte, API-tiden går ut, inmatningen är ogiltig. Om du inte kan köra verktyget, returnera felet till modellen som ett beskrivande tool_result ("fel: Ordernummer SP-9999 hittades inte") och felflaggan. Modellen kan se detta och förklara det försiktigt för användaren, eller prova på ett annat sätt. Svälj inte felet och returnera tomma resultat; Modellen måste veta vad som gick fel.
Svag/stark fordonsbeskrivning
Svag (obestämt substantiv, inget "när"):
namn: "data", beskrivning: "hämtar data"# Modellen vet inte när och hur den ska ringa; Antingen ringer den inte alls eller så ringer den fel.
Stark (nätnamn + när + parameterbeskrivning):
namn: "musteri_bakiyesi_getir"description: "Returnerar det aktuella saldot för en kund. Ring när användaren ber om debet, kredit eller saldo. GÖR INTE betalning."input_schema: {custeri_id: string ("Kund-ID")}# Modellen ringer vid rätt tidpunkt, med rätt parametrar, med kunskap om dess gräns.
Tre minifodral
Fall 1 — Onödigt ombud. Ett team byggde upp "sammanfatta text"-verksamheten med en agent med flera verktyg; Varje sammanfattning tar 4 modellsamtal och 9 sekunder. Jobbet var egentligen ett ensamtalsjobb. När vi tog bort agenten och minskade det till ett enda samtal, minskade tiden till 1,5 sekunder och kostnaden minskade till ett kvartal. Lektion: använd agenten när det verkligen behövs.
Fall 2 — Svag förklaring, fel samtal. I en supportagent anropades ett obskyrt verktyg som heter hämta slumpmässigt av modellen i både balansfrågan och fraktfrågan. När fordonen delades upp i balance_getir och cargo_durumu_getir och "ring när" förklaringar tillkom, minskade fel fordonsval från 18 till 1 av 50 exempel.
Fall 3 — Fel svalt. En agent returnerade tomma resultat när beställningen inte hittades; Modellen tolkade detta som att "beställningen levererades" och vilseledde kunden. När felmeddelandet skrivs explicit till tool_result ("order ej hittad"), säger modellen korrekt "Jag kunde inte hitta det här numret, kan du kontrollera det?" började han säga.
Vanliga misstag
- Att vända allt till en agent: Medan ett samtal räcker, lägger agenten till kostnader och förseningar.
- Vaga fordonsbeskrivning: Modellen vet inte när den ska ringa; väljer fel.
- Tänker att modellen kör fordonet: Selen kör fordonet; modellen bara vill ha.
- Svälja felet: Modellen måste veta vad som gick fel; Ge felet som open tool_result.
- För många liknande fordon: Modellen blir förvirrad; Håll verktygsuppsättningen fokuserad och minimal.
Observera: Bara för att modellen säger "ring det fordonet" betyder det inte att åtgärder bör vidtas. På destruktiva verktyg (radera, kassa, e-post) ska din applikation inte blint utföra samtalet - detta är kärnan i säkerhetsämnet i nästa enhet.
Sammanfattningsvis
- Agent = modell (beslut) + verktyg (funktioner) + loop (ringa verktyg, få resultat, bestäm igen).
- Ett enda mönsteranrop är inte en agent; agent är en steg-för-steg-process.
- Modellen kör inte fordonet; Din applikation körs (harness) och returnerar resultatet som tool_result.
- Verktyget identifieras med namn, beskrivning (särskilt "ringa när") och input_schema.
- Slingan fortsätter som tool_use → selen körs → tool_result → modellen fortsätter tills modellen säger "klar"; fel rapporteras uttryckligen till modellen.
Applikationsuppgift
Designa 3 verktyg från ditt eget företag som kan ges till agenten. (1) Skriv namn, beskrivning med "ringa när" och input_schema för varje; Låt åtminstone en vara ett oförstörande läsverktyg och en uträkning. (2) Välj en realistisk användarfråga och skriv manuellt steg för steg (i en slinga) vilka av dessa verktyg som modellen kommer att anropa med vilka ingångar och vad den kommer att göra efter att tool_result anländer. (3) Ställ in ett scenario där ett av verktygen misslyckas och visa hur felmeddelandet kommer att återgå till modellen.
checklista
- [ ] Jag kan definiera agenten som "modell + verktyg + loop" och bestämma när den behövs.
- [ ] Jag vet att selen driver fordonet, modellen vill bara ha det.
- Jag kan skriva en solid fordonsbeskrivning med [ ] namn, beskrivning ("ringa när") och input_schema.
- Jag kan följa cykeln [ ] tool_use → tool_result steg för steg.
- [ ] Jag rapporterar verktygsfel till modellen som open tool_result.