În episodul trecut am înțeles teoria, logica fuzzy și cum arată scheletul unui Agent AI. Acum lăsăm pliantele tehnice deoparte și începem să demontăm piesă cu piesă motorul intern al unui agent: legătura dintre raționamentul modelului și execuția rigidă.

„Destul cu teoria generală din Matrix. Este timpul să înțelegem cum o unealtă reală ajunge în mâna modelului și cum poate acesta să decidă când și cum să o folosească. Cum transformi un simplu text într-o comandă software capabilă să ruleze pe mașina ta.”

Bun venit la al doilea capitol al ghidului nostru de inginerie AI aplicată. Astăzi dăm jos bariera confuziilor tehnice. Există un mit răspândit că Agenții AI dețin în memorie baze uriașe de date sau că un model din Cloud poate rula direct cod pentru a-ți accesa infrastructura. Fals. Arhitectura din spatele autonomiei se bazează pe un mecanism de comunicare elegant și structurat, care delimitează clar teritoriul dintre gândire și execuție.

🔹Designul Uneltei și Mitul JSON-ului de Date

Amintește-ți ce am stabilit în primul capitol: un Agent AI este un model de limbaj căruia îi dăm unelte rigide (crisp). Dar cum știe un model text de la distanță ce unelte are la dispoziție în aplicația ta? Răspunsul este Function Calling (Apelarea de Funcții).

Aici apare marea confuzie de început: tendința de a asocia JSON-ul trimis către AI cu o bază de date masivă în care punem toate reperele, produsele sau prețurile pentru ca modelul să caute în ele. Complet fals. Dacă ai avea 10.000 de componente hardware în depozit, un astfel de JSON ar fi uriaș, ar ocupa inutil fereastra de context a modelului și te-ar costa o avere la fiecare interogare.

Noi nu îi dăm modelului datele sau codul executabil direct, ci îi transmitem o schemă (o descriere structurală în format JSON). Îi oferim doar manualul de utilizare al telecomenzii.

Să presupunem că vrem să-i dăm agentului nostru o unealtă prin care să poată verifica stocul real dintr-un depozit. În cod, noi vom defini unealta descriind doar mufa ei tehnică:

{
  "name": "verifica_stoc_hardware",
  "description": "Verifică stocul disponibil în depozit pentru o anumită componentă PC.",
  "parameters": {
    "type": "object",
    "properties": {
      "componenta": {
        "type": "string",
        "description": "Numele exact al componentei (ex: 'RAM DDR3L', 'Intel NUC')."
      }
    },
    "required": ["componenta"]
  }
}

Modelul din Cloud citește această structură scurtă și înțelege doar atât: „Aha! Am o unealtă disponibilă numită verifica_stoc_hardware. Ca să o pot folosi, va trebui să extrag din textul utilizatorului un singur parametru numit componenta.” Dacă vrei ca agentul tău să capete competențe noi (de exemplu, să verifice licențe software sau să trimită e-mailuri), nu modifici această schemă, ci adaugi unelte noi în listă, fiecare cu propria sa schemă de parametri.

🔹Schimbul de Ștafetă (Bucla ReAct în Acțiune)

Uită de chatboții clasici care primesc text și generează un răspuns. Când pornești un Agent AI, execuția se transformă într-un schimb strâns de informații între aplicația ta locală și Cloud, numit Bucla ReAct, împărțit în pași foarte clari:

Pasul 1: Cererea Fuzzy și Pasarea Contextului
Utilizatorul intră în chat și aruncă o întrebare în limbaj natural:

„Salut! Vreau să fac un upgrade de memorie și aș avea nevoie de un kit de RAM DDR3L de 1600MHz. Mai avem ceva pe stoc în depozit sau trebuie să dau comandă în altă parte?”

Aplicația ta preia textul. Deoarece codul tău nu înțelege nuanțele limbajului, pachetează întrebarea utilizatorului împreună cu schema uneltei de stoc (cea definită mai sus) și le trimite prin API în Cloud.

Pasul 2: Raționamentul în Cloud și Completarea de „Arguments”
Modelul din Cloud (Gemini, Llama 3 etc.) primește pachetul. Modelul interpretează dorința omului („Vrea RAM DDR3L”) și scanează meniul de unelte atașat. Pentru că are ponderile înghețate și este complet izolat pe serverele furnizorului de AI, LLM-ul nu poate accesa fizic depozitul tău real.

În schimb, el interpretează cererea în contextul uneltei disponibile și trimite înapoi către aplicația ta un ordin rigid în format JSON (un Tool Call). El completează cheia „arguments”, extrăgând valoarea relevantă din textul clientului:

{
  "tool_calls": [
    {
      "name": "verifica_stoc_hardware",
      "arguments": {
        "componenta": "RAM DDR3L"
      }
    }
  ]
}

Pasul 3: Execuția Rigidă Locală și Livrarea Rezultatului
Ordinul JSON aterizează înapoi în aplicația ta (scrisă în Python, C# sau Java). Codul tău preia comanda de la Cloud, deschide baza ta de date reală de 10.000 de piese și extrage datele reale: stocul este `0`, dar există o alternativă la `1333MHz`.

Aplicația ta pachetează acest rezultat brut din baza de date și îl trimite din nou în Cloud, ca răspuns al uneltei:

{
  "tool_name": "verifica_stoc_hardware",
  "output": {
    "stoc": 0,
    "alternativa": "DDR3 1333MHz"
  }
}

Pasul 4: Formularea Umană
LLM-ul din Cloud citește aceste date proaspete (`output`), folosește din nou flexibilitatea limbajului pentru a le transforma într-un răspuns politicos și de ajutor, livrând textul final pe ecranul utilizatorului:
„Din păcate, kitul specific de RAM DDR3L la 1600MHz lipsește. Am verificat baza de date și avem disponibil în depozit un kit la 1333MHz care s-ar putea să fie compatibil…”

Gândește-te la ce s-a întâmplat aici: AI-ul nu a generat doar un răspuns. El a analizat cererea, a solicitat rularea unui cod din lumea reală, a primit rezultatul rigid din aplicația ta, l-a interpretat și abia apoi a generat răspunsul final. Asta înseamnă arhitectură de Agent.

🔹De la un Query rigid, la Autonomie SF (Cele 3 Niveluri ale Agenților)

Dacă citești știrile din tehnologie, conceptul de „Agent AI” pare desprins din filmele SF — o entitate digitală independentă, cu personalitate, care „gândește de la sine”. Când deschizi capota, însă, marketingul din Silicon Valley dispare.

S-ar putea să spui: „Ok, dar până la urmă agentul doar a preluat un parametru și a căutat o piesă într-o bază de date locală, unde este marea autonomie?”.

Secretul stă în extrapolare. Ceea ce am construit noi în acest capitol este atomul de bază, cărămida fundamentală a inteligenței sistemice. Ca să înțelegi cum se trece de la o simplă interogare de stoc la agenții software care rezolvă sarcini complexe, trebuie să privim evoluția agenților pe 3 niveluri clare:

1. Agentul Operativ Single-Task (Nivelul Actual)

Este cel pe care l-am demontat astăzi. Are o singură unealtă (cum este o bază de date, un calculator sau un API de e-mail). Primește o comandă formulată în limbaj natural de la om, solicită prin Function Calling executarea unei acțiuni asupra unei resurse locale, interpretează rezultatul și îl livrează înapoi. Este echivalentul unui funcționar digital ultra-specializat.

2. Agentul Autonom Multi-Pas (Lumea Loop-urilor complexe)

Imaginează-ți că în loc de o singură unealtă, îi punem la dispoziție aplicației noastre o listă de 10 unelte diferite: `cauta_pe_web`, `scrie_fisier`, `ruleaza_terminal`, `trimite_mail` și `creeaza_alerta_slack`.

În acel moment, îi poți da o comandă abstractă și de anvergură: „Verifică sistemul și dacă găsești erori în loguri, repară-le și anunță-mă”. Agentul poate începe să ruleze bucla ReAct în mod repetat și autonom:
* **Pasul A:** Apelează unealta de citit loguri → Observă un port blocat.
* **Pasul B:** Evaluează următorul pas: „Portul este blocat, ceea ce poate împiedica funcționarea bazei de date. Voi folosi unealta de terminal.” → Apelează comanda Linux de deblocare.
* **Pasul C:** Verifică dacă reparația a funcționat → Apelează unealta de Slack ca să-ți trimită raportul final pe telefon.

3.Echipele de Agenți (Arhitecturi de tip Swarm)

Acesta este un nivel avansat de arhitectură software, folosit în anumite aplicații enterprise. În loc de un singur agent, pui mai mulți agenți software specializați să comunice între ei, pasându-și informații și rezultate de la unul la altul:
* Un agent are rolul de Manager (preia cererea clientului și împarte sarcinile).
* Un agent are rolul de Programator (are ca unealtă un mediu de scris cod).
* Un agent are rolul de Tester (are ca unealtă un terminal izolat de execuție).
Ei pot colabora autonom prin Function Calling, coordonând etape succesive de lucru și, în anumite scenarii, pot genera, testa și livra aplicații întregi cu intervenție umană minimă.

Din momentul în care ai înțeles cum un model din Cloud poate învăța să completeze corect cheia `{ “arguments”: { … } }` pentru o singură funcție banală de stoc, ai înțeles principiul de bază prin care pot fi construite sisteme cu mai multe unelte și agenți autonomi.

🧠 Iluzia Controlului: Creierul și Mâinile sunt la mii de kilometri distanță

În arhitectura modernă a agenților, „creierul” și „mâinile” pot fi în două locuri complet diferite, separate prin mii de kilometri, iar înțelegerea acestei topologii este crucială pentru a înțelege cum funcționează un astfel de sistem:

  • 1. Unde este LLM-ul (Creierul)? De multe ori este în Cloud (Google, OpenAI, Anthropic, Groq etc.). El primește cereri prin API și trimite înapoi răspunsuri sau ordine structurate în format JSON. Interpretează cererea, evaluează contextul și alege unealta potrivită din meniul pe care i l-ai pus la dispoziție, dar nu are, prin simplul fapt că este în Cloud, acces direct la rețeaua ta și nu poate rula cod direct pe mașina ta.
  • 2. Unde sunt „Mâinile” (Aplicația și Uneltele)? În infrastructura ta locală sau în mediul pe care îl controlezi. Aici rulează backend-ul tău (Python, C# sau Java). Aplicația ta este cea care deține accesul la baza de date cu piese, primește decizia trimisă din Cloud, execută funcția în condițiile stabilite de tine și trimite rezultatul înapoi în Cloud.

💡 Concluzia Hardware: Lăsăm infrastructura din Cloud să consume resursele necesare pentru rularea modelului și pentru interpretarea cererii, iar noi primim ordinul și executăm codul rigid (`output`) în mediul pe care îl controlăm. Datele tale private pot rămâne local, iar controlul efectiv al execuției rămâne în mâna aplicației tale.

🛠️ Ce urmează în Episodul 3?

Am văzut mecanica teoretică a modului în care un agent interpretează cererile, comunică prin structuri JSON și execută acțiuni prin bucla ReAct. Însă un sistem care are doar brațe executive, dar nu își poate planifica pașii, este doar un automat impulsiv.

În episodul următor, coborâm un nivel mai adânc în arhitectura sistemelor AI: Chain of Thought (CoT). Vom analiza de ce anumite modele moderne de raționament, precum seriile o1/o3 și alte sisteme cu mecanisme de thinking, alocă timp și resurse suplimentare pentru a analiza o problemă înainte de a formula răspunsul final.

Vom înțelege cum se pot combina cele două componente — raționamentul intern al modelului (CoT) și brațele executive din infrastructura ta (ReAct) — pentru a construi sisteme capabile să descompună obiective complexe, să execute pași succesivi și să verifice rezultatele pe parcurs.

Pregătește-te să înțelegi cum gândește mașina când vorbește singură. Trecem la nivelul următor!

Stay Free! Stay Hidden! Stay Autonomous!

⚙️ Appendix: Micro-Curs de Inginerie AI (Clarificări Tehnice)

  • JSON (JavaScript Object Notation): Format de text standardizat, ușor, utilizat pentru a schimba date între aplicații software. Nu conține cod executabil, ci doar structuri de date organizate în perechi de tip etichetă-valoare.
  • Function Calling (Apelarea de Funcții): Mecanismul prin care un LLM poate identifica faptul că utilizatorul are nevoie de o acțiune externă și poate returna o structură rigidă, de regulă în format JSON, care conține numele funcției și parametrii extrași din conversație.
  • Schema JSON: Schița structurală sau „mufa tehnică” a unei unelte, trimisă către LLM pentru a-i descrie ce face funcția, ce parametri acceptă și care dintre aceștia sunt obligatorii. Ea conține descrieri și reguli structurale, nu datele efective din aplicație.

    🧠 Marea Confuzie: Schema JSON nu este Baza ta de Date! Există o barieră mentală uriașă pentru cei care vin din zona clasică de software: Dacă îi dau Agentului o unealtă să verifice stocul de hardware, cum îi trimit baza mea de date în format JSON ca el să caute în ea?

    Răspunsul este simplu: Nu îi trimiți baza de date! Un JSON care conține toate produsele, prețurile sau datele logistice ar putea deveni enorm, ar ocupa inutil fereastra de context a modelului și ar crește semnificativ costul fiecărei interogări.

    În ingineria de agenți, noi trimitem către creierul din Cloud o schemă (un manual de utilizare al mufei). Cloud-ul folosește această schemă pentru a înțelege ce poate face unealta și pentru a extrage parametrul necesar din fraza utilizatorului (ex: “RAM DDR3L”).

    Baza ta de date reală, fie că are 10 repere sau 10 milioane, rămâne în infrastructura pe care o controlezi. Aplicația ta primește parametrul extras de Cloud, face interogarea local și poate trimite înapoi doar rezultatul necesar (ex: “Stoc: 0”). JSON-ul este doar plicul poștal, nu depozitul!

    ⏳ Stația Istorie: De ce JSON și nu protocoalele grele din anii 2000?

    Dacă ideea de a trimite comenzi structurate la distanță între sisteme diferite (Remote Procedure Call) exista încă de la începutul anilor 2000 și era folosită intens în marile sisteme bancare sau în arhitecturile enterprise, de ce a devenit JSON atât de important în arhitectura agenților AI de astăzi?

    Răspunsul ține de eficiență, simplitate și modul în care modelele de limbaj procesează textul:

    • 1. Coșmarul XML (SOAP / XML-RPC): În anii 2000, datele se împachetau frecvent în XML. Protocolul SOAP folosea documente cu numeroase taguri, headers complexe și reguli stricte de validare (XSD). Era un format greoi și foarte „guraliv” (verbose) în comparație cu JSON – consuma mult text pentru a descrie aceeași structură de date.
    • 2. JSON și explozia Web API-urilor: JSON a fost conceput ca un format de date simplu, ușor de folosit cu JavaScript și a devenit ulterior extrem de răspândit în aplicațiile web și API-uri. Structura sa bazată pe obiecte, liste și perechi cheie-valoare este simplă și compactă.
    • 3. Un format potrivit pentru LLM-uri: Rețelele neuronale care stau la baza LLM-urilor procesează text. O structură JSON este relativ compactă și are reguli clare, ceea ce o face potrivită pentru descrierea parametrilor și pentru generarea unor comenzi structurate de către modele.

    Pe scurt: în anii 2000 aveam deja tehnologia de a trimite comenzi și date la distanță, dar o făceam adesea prin protocoale și formate mult mai verbose, precum XML/SOAP. JSON a adus simplitate și compactitate și a devenit una dintre principalele forme de schimb de date în aplicațiile moderne, inclusiv în comunicarea dintre LLM-uri și aplicațiile care le folosesc.

  • Bucla ReAct (Reasoning and Acting): Paradigma de execuție în care un Agent AI alternează etapele de evaluare și planificare cu acțiuni concrete prin apeluri de unelte (Action), urmate de citirea rezultatelor din lumea reală (Observation), până la rezolvarea problemei.