Majoritatea echipelor de IA care urmăresc performanțe mai bune ale agenților apelează la aceleași pârghii: ferestre contextuale mai mari, mai multe documente, solicitări mai inteligente. Acest articol susține că instinctul este complet greșit. Ingredientul lipsă nu este un volum mai mare de informații. Este controlul. Un nivel de control bine proiectat face diferența dintre un agent care funcționează într-o demonstrație și unul care funcționează în producție.
Dacă îi oferi unui agent IA o memorie mai mare, mai multe documente sau o fereastră contextuală mai lungă, nu devine mai inteligent, ci doar mai lent și mai costisitor. Progresele reale apar când agentul învață să aleagă de ce are nevoie și când, în loc să consume totul deodată.
Fiabilitatea vine din buclă, nu din model. Diferența dintre un agent impresionant într-o demonstrație și unul robust în producție nu constă în calitatea IA, ci în faptul că sistemul își verifică sau nu propria activitate. Agenții care planifică, acționează, observă și verifică la fiecare pas își descoperă propriile greșeli, în loc să ofere cu încredere rezultate eronate.
Majoritatea agenților IA de astăzi sunt, în esență, chatboți cu pași suplimentari: nu au niciun mecanism prin care să știe dacă sunt pe drumul cel bun, când să se oprească sau când să încerce altă abordare. Adăugarea unui nivel de control adecvat — criterii clare de succes, stare structurată și verificări de validare — transformă un obiect cu formă de agent în ceva în care chiar poți avea încredere.
Ce ai mâncat ieri la prânz?
Probabil că nu ți-ai reluat fiecare amintire până când ai ajuns la „ieri + prânz”. Ai mers direct la partea experienței tale în care se află acele concepte. Aceasta este o analogie utilă pentru construirea agenților:
O fereastră contextuală uriașă nu este memorie.
O grămadă de documente preluate nu înseamnă înțelegere.
Un lanț de gândire lung nu înseamnă fiabilitate.
Acestea sunt doar ingrediente. Dar ceea ce face ca un agent să pară cu adevărat un agent este același lucru care împiedică creierul să parcurgă exhaustiv întreaga ta viață: controlul.
Un studiu recent — Agentic Reasoning for Large Language Models — a sintetizat și a denumit foarte bine schimbarea pe care mulți dintre noi am simțit-o în timp ce construiam: de la raţionamentul din interiorul modelului la raţionamentul prin interacțiune. Această postare nu este un rezumat al lucrării respective. Este o încercare de a transpune schimbarea în proiectarea practică a sistemelor:
Dacă vei construi agenți ca pe niște chatboți cu instrumente, vei avea în continuare probleme specifice chatboților, doar că greșelile vor costa mai mult.
O vreme, metoda noastră implicită pentru „a face modelul mai inteligent” a fost, în esență: solicitări mai bune, lanț de gândire, consecvență internă sau îmbunătățiri bazate pe eșantionare și, eventual, căutare.
ReAct a reprezentat un moment de cotitură, deoarece a făcut ca secvența „gând → acțiune → observație” să pară firească. Dar observă constrângerea implicită: o mare parte se reduce tot la „inferență cu un exemplu, dar cu mai mulți tokeni”. Perspectiva studiului este mai precisă: raţionamentul agentic pune accentul pe extinderea interacțiunii în timpul testării, transformând inferența într-un proces iterativ în care modelul, memoria și mediul rămân permanent în buclă.
Dacă ai construit sau ai folosit agenți care par impresionanți în demonstrații, dar sunt fragili în fluxurile de lucru reale, acest articol este pentru tine.
Permite-mi să descriu un tipar pe care l-am întâlnit frecvent (și ale cărui versiuni le-am construit cu siguranță și eu):
Ia un model de chat bun
Adaugă câteva instrumente (căutare, interogarea bazei de date, poate și execuție de cod)
Adaugă RAG
Adaugă o solicitare de sistem de tipul „ești un agent autonom”
Încapsulează totul într-o buclă while până când se oprește sau expiră timpul
Felicitări, ai un obiect cu formă de agent. Dar acesta tinde să eșueze în moduri previzibile:
Context supradimensionat: fiecare observație este adăugată, iar solicitările devin straturi arheologice.
Folosirea haotică a instrumentelor: „instrumentul greșit, dar folosit cu încredere” devine modul implicit de eșec.
Fără condiții de oprire: continuă fiindcă poate, nu fiindcă ar trebui.
Fără disciplină privind temeiul: nu își dă seama că greșește decât dacă îl obligi.
Memorie = istoric de chat: practic, scrii jurnale și numești asta învățare.
De aceea, „agenții” par adesea magici în demonstrații și haotici în producție. Experiența noastră cu implementarea sistemelor agentice în producție confirmă acest lucru: când nu mai evaluezi un model, ci un sistem, modurile de eșec includ navigarea, utilizarea corectă a instrumentelor, restrângerea contextului și proiectarea evaluării, nu doar întrebarea „a răspuns corect modelul?”.
Așadar, întrebarea devine: cum arată agentul proiectat corect?
Pentru un exemplu mai puțin abstract, iată un flux de lucru simplificat, ușor de imaginat: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
O implementare obișnuită, „cu formă de agent”, arată astfel:
Preia imediat o mulțime de documente despre companii aeriene și politici de călătorie (chiar dacă încă nu este necesar niciunul).
Apelează un instrument de căutare, inserează în solicitare o listă lungă de rezultate și „alege unul”.
Rezervă prematur, fără să verifice constrângerile (ora sosirii/bagajul/locul/politica).
Dacă eșuează, încearcă din nou într-un mod puțin diferit, dar fără o idee clară despre ce s-a schimbat sau ce a învățat.
Problema nu este că modelul nu poate raționa, ci că sistemul nu controlează fluxul de lucru.
O versiune mai agentică tratează sarcina ca pe un proces interactiv, cu stare și verificări explicite:
PLANIFICĂ: reformulează constrângerile și enumeră informațiile lipsă (de ex., “which airport preference?” / “is 1 stop ok?”).
ACȚIONEAZĂ: apelează căutarea de zboruri cu o interogare structurată (intervalul de date, constrângerea privind sosirea, bugetul).
OBSERVĂ: stochează rezultatele într-un obiect de stare compact (primii 5 candidați, cu preț/sosire/escale), nu într-un bloc uriaș de text inserat.
ACTUALIZEAZĂ: rafinează interogarea dacă nu sunt respectate constrângerile (de ex., “arrival before 6pm is too strict—widen time window or raise budget?”).
VERIFICĂ: rulează validatori („sosire < 18:00”, „preț ≤ 900 GBP”, „respectă politica”, „este disponibilă alegerea locului”).
OPREȘTE: numai după ce API-ul de rezervări returnează o confirmare și toate verificările validatorilor reușesc.
Schimbarea este subtilă, dar decisivă. Preluarea este condiționată (nu un reflex), contextul este gestionat (starea este structurată, nu acumulată), iar verificarea face parte din buclă (nu este lăsată utilizatorului). Înlocuiește „rezervarea unui zbor” cu „crearea unei comenzi de achiziție”, „emiterea unei rambursări”, „modificarea unei configurații de producție” sau „livrarea unui PR” și situația rămâne aceeași: odată ce agentul poate acționa, bucla contează mai mult decât solicitarea.
Studiul menționat anterior organizează raţionamentul agentic pe trei niveluri: fundamental (planificare/utilizarea instrumentelor/căutare), autoevolutiv (feedback și memorie) și colectiv (coordonare între mai mulți agenți).
Dar ideea mai profundă este că raţionamentul devine principiul organizator al planificării, luării deciziilor și verificării, nu doar al generării unui lanț de gândire plauzibil. Pare abstract până când transpui ideea în schimbările necesare arhitecturii tale. Există trei idei esențiale de reținut:
Un agent bun nu ar trebui să trateze preluarea drept ceva ce „trebuie făcut mereu”. Preluarea este o decizie, nu un reflex.
Iată o euristică practică:
Dacă sistemul preia informații la fiecare interacțiune, nu ai construit un mecanism de preluare, ci o taxă pe context.
Acest lucru apare mereu în activitatea reală. Când depanezi un incident din producție, nu introduci toate jurnalele în context; decizi ce indicatori sau jurnale să preiei în continuare, pe baza ipotezei actuale. Aceasta este „preluarea agentică”. Iată un tipar mai concret:
Decide dacă ai nevoie să preiei informații
Dacă da: formulează o interogare, preia, parcurge rapid, extrage
Dacă dovezile se contrazic: preia din nou
Abia apoi sintetizează
Tot aici începe „RAG agentic” să difere de RAG tradițional: preluarea devine un pas deliberat de raţionament, nu o etapă implicită a fluxului de procesare.
Din clipa în care nu mai evaluezi „un model”, ci „un sistem”, urmărirea stării și trasarea devin importante.
Un aspect pe care industria a început să-l trateze mai explicit este observabilitatea fluxurilor de lucru ale agenților. De exemplu, SDK-ul Agents de la OpenAI include trasare integrată și un tablou de bord Traces care înregistrează execuțiile agenților (generări, apeluri de instrumente, transferuri, mecanisme de protecție, evenimente personalizate), tocmai pentru a putea depana și audita pas cu pas ce s-a întâmplat.
Nu este doar ceva „util de avut”. Este diferența dintre un sistem pe care îl poți depana și unul pe care îl poți evalua doar intuitiv.
În opinia mea, partea cea mai ușor de pus în practică a studiului este modul direct în care abordează feedbackul. Acesta împarte feedbackul în trei regimuri: feedback reflexiv (generează → critică → revizuiește), adaptare parametrică (învățare prin ajustare fină/RL) și feedback bazat pe validatori (reîncearcă până când verificarea unui validator reușește).
Majoritatea echipelor ar trebui să înceapă cu feedbackul bazat pe validatori, deoarece este banal și eficient. Dacă poți scrie orice validator care execută teste unitare, verifică schema, impune reguli sau constrângeri de afaceri („nicio rambursare peste X fără escaladare”) ori confirmă corectitudinea faptelor („sunt obligatorii citările”), poți transforma rezultatele nedeterministe ale modelului în ceva în care chiar poți avea încredere.
Una dintre schimbările de tip „necunoscut necunoscut” este simplă: în lumea agenților, fiabilitatea vine adesea mai mult din buclă decât din model.
Iată cea mai simplă disciplină de lucru în buclă pe care am găsit-o și care îmbunătățește fiabil comportamentul fără antrenare:
Lucrează în pași: Planifică → Acționează → Observă → Actualizează,
După fiecare acțiune, rezumă observația în 1–3 puncte,
Oprește-te când sunt îndeplinite criteriile de succes sau când se atinge bugetul; returnează cel mai bun rezultat cunoscut și incertitudinile rămase.
Scopul nu este ca modelul să devină prolix. Scopul este ca sistemul să fie ușor de înțeles și să fie obligat să „verifice realitatea” la fiecare pas. Un exemplu foarte familiar inginerilor este stabilirea temeiului în buclă închisă, în stil CI:
Planifică: propune lista de modificări
Acționează: rulează testele/verificarea lint
Observă: interpretează erorile
Actualizează: aplică remedieri și reîncearcă
Câteva întrebări care tind să scoată la iveală proiectele de agenți creați din greșeală:
„Agentul meu decide ce să preia sau preiau eu întotdeauna informațiile?”
Dacă preluarea este necondiționată, vei plăti prin latență, costuri, diluarea contextului și un risc mai mare ca datele slabe de intrare să producă rezultate slabe.
„Agentul meu își poate da seama că greșește?”
Dacă singurul semnal de feedback al agentului tău este „utilizatorul se enervează”, faci RL prin suferință umană. O buclă de reîncercare bazată pe un validator este cea mai simplă cale de a-l pune în contact cu realitatea.
„Memoria poate fi actualizată și se îmbunătățește în timp?”
Dacă „memoria” ta doar adaugă istoricul conversației, practic scrii jurnale. Perspectiva studiului asupra memoriei este importantă: memoria devine un context care crește dinamic și pe care agenții îl rafinează în timp, nu doar o transcriere.
Jurnalele îți spun ce s-a întâmplat, iar memoria îți spune ce să faci data viitoare. Istoricul conversației este o transcriere. Memoria este o politică în continuă evoluție despre ceea ce merită păstrat pentru viitor.
Un punct de pornire practic este un mic tabel cu „lecții învățate”, organizat după o cheie formată din tipul sarcinii, instrument și modul de eșec, cu valori care descriu ce a funcționat și ce trebuie evitat. Scopul nu este să construiești un graf perfect de cunoștințe. Scopul este să creezi un comportament cu efect cumulativ: memoria și feedbackul transformă agenții din „asistenți fără stare” în sisteme care se îmbunătățesc în timp.
Tentația este să aloci mai mulți agenți problemei, dar acest lucru multiplică adesea efortul de coordonare. Un tipar bun de „echipă minimă viabilă”:
Coordonator: descompune și atribuie
Executor: apelează instrumentele și efectuează modificările
Critic/evaluator: verifică exactitatea și riscurile
Responsabil cu memoria: consemnează și selectează lecțiile
Dacă nu poți explica responsabilitatea fiecărui agent, probabil că încă nu ai nevoie de mai mulți agenți.
Dacă acceptăm cu adevărat schimbarea de paradigmă, probabil că vom înceta să înghesuim totul în solicitări, să tratăm eșecurile drept rezultate finale și să evaluăm agenții ca pe niște chatboți. Și vom începe să tratăm agenții așa cum sunt: sisteme software în care limbajul este planul de control, iar fiabilitatea vine din buclă.
Înainte să adaugi alt model, adaugă încă o buclă de evaluare. Înainte să preiei totul, condiționează preluarea. Livrează un validator înainte să livrezi zece. Tratează memoria ca pe un set de decizii de politică, nu ca pe o bază de date. Iar când treci la un sistem multi-agent, începe cu doi agenți, nu cu douăzeci. Acestea nu sunt reguli, ci tiparele care au rezistat în producție.