Agenți AI și utilizarea instrumentelor — Agenți RAG și AI

Câștiguri:

Definirea unui agent ca „model + instrumente + buclă” și deciderea când este necesar
Scrierea definiției instrumentului cu nume, descriere și schemă de intrare
Monitorizarea fluxului și gestionarea erorilor a buclei tool_use și tool_result

Până acum, modelul a făcut întotdeauna o singură treabă: primește introducerea textului, produce răspunsuri text. Dar munca reală necesită adesea mai mult decât text; efectuarea unui calcul, interogarea unei baze de date, apelarea unui API, aflarea unui curs de schimb curent. Modelul nu poate face ea însăși aceste lucruri, dar poate decide când trebuie făcute și poate cere cuiva să le facă. Acesta este ceea ce utilizarea instrumentului oferă modelului și aceasta este baza agenților AI. În această unitate, vom afla ce este un agent, cum este definit instrumentul și cum funcționează bucla tool_use.

Ce este un agent? Model + Instrumente + Buclă

Un agent AI este format din trei părți: modelul (creierul care ia decizia), instrumentele (funcțiile pe care modelul le poate apela: vremea, interogarea bazei de date, trimiterea de e-mail) și bucla (bucla; modelul apelează instrumentul, obține rezultatul, decide din nou ce să facă și așa mai departe).

Distincție critică: un singur model de apel nu este un agent. Agentul este un proces în care modelul decurge pas cu pas, la fiecare pas alegând următoarea mișcare în funcție de rezultatul instrumentului. „Gândește ca un om, folosește-ți mâinile, privește rezultatul, gândește-te din nou.”

Un fapt important: modelul în sine nu operează vehiculul. Modelul spune doar „Vreau să apelez acest instrument cu aceste intrări”. Aplicația dvs. (numită ham) rulează instrumentul și returnează rezultatul modelului. Acest lucru este vital pentru securitate: modelul nu atinge direct sistemul dvs.; Fiecare acțiune este sub controlul tău.

Sfat: Nu încercați să rezolvați fiecare problemă cu agentul. Agent; crește riscul de întârzieri, costuri și erori. Întrebați mai întâi: „Va fi rezolvat acest lucru cu un singur apel sau un flux de lucru fix?” Dacă răspunsul este da, nu este nevoie de un agent. Agentul este pentru sarcini deschise în care pașii nu pot fi cunoscuți în prealabil.

Definiție instrument: nume, descriere, schemă_input

Pentru a introduce un instrument în model, dați trei lucruri:

nume: identitatea vehiculului, de ex. get_weather.
descriere: ce face instrumentul și când să-l numească. Aceasta este cea mai importantă zonă care permite modelului să aleagă instrumentul potrivit la momentul potrivit. Scrieți nu doar „ce face”, ci și „sunați când”.
input_schema (schema de intrare): schema JSON care definește ce parametri se așteaptă instrumentul, în ce tip.

# Definiția vehiculului (conceptual — schema JSON){ "name": "get_order_status", "description": "Preluează starea curentă de livrare a unei comenzi. Apelați când utilizatorul întreabă unde este un număr de comandă sau când va sosi.", "input_schema": { "type": "object", "properties": { "order_noscription,": { "order_noscription,": {"order_noscription,": de ex. SP-1024"} }, "obligatoriu": ["nr._comanda"] }}

Reguli pentru o descriere bună a instrumentului: denumire clară și concisă, descriere cu „când să se folosească”, descriere pentru fiecare parametru, introducerea celor cu adevărat obligatorii în necesar. Menține concentrat numărul de vehicule; Zeci de modele de vehicule similare sunt surprinzătoare.

zona

Ce face?

bun exemplu

exemplu prost

nume

ID vehicul

order_status_getir

aduce

descriere

Ce face + când să suni

„Întoarce starea încărcăturii; sunați când utilizatorul întreabă unde este comanda”

„preluează datele”

schema_de_intrare

Tipul de parametru și cerințele

{order_no: șir, adnotat}

fără diagramă / fără descriere

tool_use → tool_result Buclă

Ciclul funcționează astfel, pas cu pas:

Trimiteți întrebarea utilizatorului + descrierile instrumentului către model.
Modelul fie răspunde direct, fie generează un bloc tool_use: „call order_durumu_geir with order_no=SP-1024”.
Aplicația dvs. rulează de fapt instrumentul (interogează baza de date).
Trimiteți rezultatul înapoi la model ca tool_result.
Cu acest rezultat, modelul fie produce răspunsul final, fie apelează un alt instrument. Ciclul continuă până când modelul spune „Am terminat”.

# Mesaje în buclă (conceptuală) agent = [întrebare_utilizator]while Adevărat: răspuns = model.uret(mesaje, instrumente = definiții_unelte) if response.tur == "utilizare_unelte": rezultat = harness.run(nume_instrument_răspuns, răspuns.entrii) # APLICAȚIA rulează mesaje += [răspuns, instrument_result)]: # întrerupe rezultatul final; capetele buclei

SDK-urile moderne oferă instrumente care rulează această buclă pentru tine; doar scrieți funcțiile instrumentului. Dar exact asta se întâmplă în culise.

Gestionarea erorilor

Instrumentele pot eșua: comanda nu a fost găsită, API-ul expiră, intrarea este nevalidă. Dacă nu puteți rula instrumentul, returnați eroarea la model ca un tool_result descriptiv („eroare: Numărul de comandă SP-9999 nu a fost găsit”) și indicatorul de eroare. Modelul poate vedea acest lucru și îl poate explica ușor utilizatorului sau poate încerca un alt mod. Nu înghițiți eroarea și returnați rezultate goale; Modelul trebuie să știe ce a mers prost.

Descrierea vehiculului slab/puternic

Slab (substantiv nedefinit, fără „când”):

nume: „date”, descriere: „preluează date”# Modelul nu știe când și cum să sune; Fie nu sună deloc, fie sună incorect.

Puternic (nume net + când + descriere parametru):

name: "musteri_bakiyesi_getir"description: "Returează soldul contului curent al unui client. Sună când utilizatorul solicită debit, credit sau sold. NU face plata."input_schema: {custeri_id: string ("Customer ID")}# Modelul sună la momentul potrivit, cu parametrii potriviți, cunoscându-și limita.

Trei mini carcase

Cazul 1 – Agent inutil. O echipă a construit afacerea „rezumat text” cu un agent cu instrumente multiple; Fiecare recapitulare durează 4 apeluri de model și 9 secunde. Lucrarea a fost de fapt o slujbă cu un singur apel. Când am eliminat agentul și l-am redus la un singur apel, timpul a scăzut la 1,5 secunde, iar costul a scăzut la un sfert. Lecție: utilizați agentul atunci când este cu adevărat necesar.

Cazul 2 — Explicație slabă, apel greșit. Într-un agent de asistență, un instrument obscur numit fetch a fost apelat aleatoriu de către model atât în întrebarea de echilibru, cât și în cea de expediere. Când vehiculele au fost împărțite în balance_getir și cargo_durumu_getir și s-au adăugat explicații „apel când”, selecția greșită a vehiculului a scăzut de la 18 la 1 din 50 de exemple.

Cazul 3 — Eroare înghițită. Un agent returna rezultate goale când comanda nu a fost găsită; Modelul a interpretat acest lucru ca „comanda a fost livrată” și a indus în eroare clientul. Când mesajul de eroare este scris în mod explicit în tool_result ("comanda nu a fost găsită"), modelul spune corect "Nu am putut găsi acest număr, îl puteți verifica?" începu să spună.

Greșeli comune

Transformarea totul către un agent: deși un singur apel este suficient, agentul adaugă costuri și întârzieri.
Descriere vagă a vehiculului: Modelul nu știe când să sune; alege greșit.
Gândindu-vă că modelul conduce vehiculul: Hamul conduce vehiculul; modelul vrea doar.
Înghițirea erorii: modelul trebuie să știe ce a mers prost; Dați eroarea ca open tool_result.
Prea multe vehicule similare: Modelul devine confuz; Păstrați setul de instrumente concentrat și minim.

Atenție: Doar pentru că modelul spune „sunați acel vehicul” nu înseamnă că trebuie luate măsuri. Pe instrumentele distructive (ștergere, finalizare, e-mail) aplicația dvs. nu ar trebui să execute orbește apelul - acesta este nucleul subiectului de securitate din următoarea unitate.

Pe scurt

Agent = model (decizie) + instrumente (funcții) + buclă (apel instrument, obține rezultat, decide din nou).
Un singur model de apel nu este un agent; agentul este un proces pas cu pas.
Modelul nu rulează vehiculul; Aplicația dumneavoastră rulează (harness) și returnează rezultatul ca tool_result.
Instrumentul este identificat prin nume, descriere (în special „apel când”) și input_schema.
Bucla continuă pe măsură ce instrument_use → cablaj rulează → tool_result → modelul continuă până când modelul spune „terminat”; erorile sunt raportate în mod explicit modelului.

Sarcina de aplicare

Proiectați 3 instrumente din propria afacere care pot fi date agentului. (1) Scrieți numele, descrierea cu „call when” și input_schema pentru fiecare; Să fie cel puțin unul un instrument de citire nedistructiv și unul un calcul. (2) Alegeți o întrebare realistă a utilizatorului și scrieți manual pas cu pas (în buclă) care dintre aceste instrumente va apela modelul cu ce intrări și ce va face după ce sosește tool_result. (3) Configurați un scenariu în care unul dintre instrumente eșuează și arată cum mesajul de eroare va reveni la model.

lista de verificare

[ ] Pot defini agentul ca „model + instrumente + buclă” și pot decide când este necesar.
[ ] Știu că hamul conduce vehiculul, modelul îl dorește doar.
Pot scrie o descriere solidă a vehiculului cu [ ] nume, descriere („apel când”) și schemă de intrare.
Pot urmări ciclul [ ] tool_use → tool_result pas cu pas.
[ ] Raportez erorile de instrument la model ca open tool_result.