Agenți AI și subagenți: când ajută și când complică arhitectura

Anthropic a publicat pe 22 octombrie 2026 o analiză despre situațiile în care unele subcomponente ale unui sistem cu mai mulți agenți AI pot fi reunite într-un singur agent. Ideea importantă pentru dezvoltatori: adăugarea unui nou „specialist” AI nu garantează automat un rezultat mai bun.

În analiza despre integrarea subagenților în agentul principal, Anthropic descrie implementări în care simplificarea a ajutat calitatea, costul și timpul de răspuns. Compania păstrează însă rolul subagenților pentru lucrul paralel, izolarea contextului și situațiile în care un singur agent întâmpină limite măsurabile.

Documentare: 22 octombrie 2026. Articolul separă observațiile publicate de Anthropic de exemplele și recomandările noastre. Nu am executat un benchmark comparativ pentru acest material și nu prezentăm rezultate numerice inventate.

Ce este un subagent și cu ce diferă de un instrument

Un instrument execută o operațiune definită: caută o comandă, citește un fișier sau verifică un rezultat. Un agent poate decide ce operațiune să facă în continuare, folosind obiectivul și răspunsurile primite. Un subagent preia o parte din sarcină și returnează un rezultat agentului care îl coordonează.

Nu orice etapă a aplicației trebuie să fie un agent. Dacă trebuie doar să verifici dacă o dată are formatul corect, o funcție deterministă poate fi mai potrivită. Dacă ai nevoie să explorezi documente și să alegi următoarea sursă în funcție de ce ai găsit, autonomia poate avea un rol.

Distincția dintre fluxuri prestabilite și agenți care își aleg dinamic pașii este explicată în Building effective agents. Este o sursă de context publicată inițial în 2024, nu anunțul din această zi. Principiul util este evaluarea complexității în raport cu sarcina, nu alegerea arhitecturii după numărul de componente din diagramă.

De ce o echipă de agenți pare o idee bună

Împărțirea pe roluri este intuitivă: unul cercetează, unul scrie, unul verifică și altul coordonează. Poți avea instrucțiuni mai scurte pentru fiecare rol, surse diferite și acces separat la anumite instrumente. Unele sarcini independente pot fi executate în același timp.

Problema apare când organigrama înlocuiește analiza tehnică. Un agent pentru fiecare departament nu este obligatoriu soluția potrivită dacă toate etapele citesc aceleași date și așteaptă una după alta. Denumirea de „expert” nu îi oferă automat unui model dovezi mai bune sau acces la informații pe care nu le primește.

Înainte să adaugi un rol, scrie ce primește, ce livrează și de ce nu poate fi o instrucțiune sau un instrument al agentului existent. Dacă răspunsul este doar „arată mai bine organizat”, nu ai încă un motiv măsurabil pentru complexitatea suplimentară.

Limita 1: contextul se poate pierde la predarea sarcinii

Scenariu demonstrativ: un utilizator cere modificarea unei pagini, precizând să nu fie schimbate URL-urile. Agentul coordonator trimite designerului doar „propune o structură mai bună”, iar implementatorului doar schița rezultată. Dacă restricția nu ajunge la fiecare etapă relevantă, soluția poate încălca cerința inițială.

Un rezumat este util pentru reducerea volumului de informații, dar poate omite excepții. Pentru sarcinile delegate, păstrează explicit obiectivul, restricțiile, sursele și formatul rezultatului. Nu presupune că subagentul cunoaște automat întregul istoric al conversației.

În Claude Code, documentația despre subagenți descrie contexte separate și configurarea instrumentelor. Aceste proprietăți trebuie înțelese pentru implementarea respectivă; nu toate platformele de agenți folosesc exact aceleași mecanisme de moștenire a contextului.

Limita 2: coordonarea consumă timp și resurse

Fiecare delegare poate necesita pregătirea instrucțiunilor, transmiterea contextului, execuția și interpretarea răspunsului. Dacă două componente trebuie să își ceară repetat clarificări, o parte din muncă devine administrarea conversației dintre ele.

Lucrul paralel poate reduce durata, dar numai pentru activități care pot avansa independent. Un agent care așteaptă rezultatul altuia nu produce un avantaj doar fiindcă procesul său există separat. Măsoară timpul până la rezultatul acceptat de utilizator, inclusiv reluările și corecturile.

Analiza Anthropic despre propriul sistem de cercetare cu mai mulți agenți, publicată în 2025, descrie atât utilitatea explorării paralele, cât și costurile și dificultățile coordonării. Rezultatele acelui sistem nu trebuie transformate într-o regulă numerică pentru orice aplicație din 2026.

Limita 3: erorile se pot propaga între specialiști

Dacă agentul de cercetare inventează o informație, iar redactorul o primește ca fapt confirmat, textul final poate deveni foarte convingător și totuși greșit. Un al treilea agent care verifică numai stilul nu corectează neapărat problema. Numărul verificatorilor contează mai puțin decât criteriile și dovezile la care au acces.

Pentru un flux editorial, solicită URL-ul sursei, data evenimentului și pasajul care susține afirmația. Verificatorul trebuie să poată consulta sursa, nu doar rezumatul primului agent. Pentru cod, atașează rezultatele testelor și fișierele modificate, nu o declarație generală că „totul funcționează”.

Acordul dintre două răspunsuri nu dovedește automat corectitudinea. Dacă ambele pornesc de la aceeași premisă greșită, pot repeta aceeași eroare. Introdu verificări care se sprijină pe mediul real: răspunsuri API, teste executate, documente și criterii de acceptare observabile.

Limita 4: prea multe instrumente și permisiuni

Separarea pe agenți poate ajuta la delimitarea accesului, dar numai dacă permisiunile sunt aplicate tehnic. Instrucțiunea „nu modifica producția” nu înlocuiește un cont fără drepturi de scriere în producție. Evaluează ce poate face efectiv fiecare componentă.

Documentația despre permisiunile Claude Code oferă mecanisme specifice produsului. Într-o aplicație proprie, păstrează aceeași întrebare de proiectare: ce acces este necesar pentru sarcină și unde se verifică aprobarea unei acțiuni?

Recomandare: separă citirea datelor de publicare, plată sau deployment. Un agent de cercetare poate avea nevoie să citească documente, fără să poată trimite mesaje în numele utilizatorului. Nu acorda drepturi globale tuturor agenților doar pentru a evita configurarea individuală.

Când merită păstrați mai mulți subagenți

Tabelul este un cadru editorial de decizie, nu o promisiune de performanță. Nu există un număr universal de agenți potrivit pentru toate proiectele. Pentru unele fluxuri, un singur agent și câteva instrumente sunt suficiente; pentru altele, explorarea paralelă produce un avantaj verificabil.

Exemplu: un asistent pentru un magazin online

Imaginează-ți un asistent care răspunde la întrebări despre comenzi. O arhitectură complicată ar putea avea agenți pentru clasificare, client, livrare, retur, ton și răspuns final. Dacă fiecare întrebare trece prin toate aceste etape, chiar și o solicitare simplă poate acumula întârzieri.

O variantă de test mai simplă ar folosi un agent principal cu instrumente pentru citirea comenzii și a politicii aplicabile. El cere datele necesare, verifică răspunsurile și explică situația. Operațiunea de rambursare rămâne controlată prin regulile aplicației și aprobările stabilite, indiferent câți agenți participă.

Ai putea păstra un subagent separat pentru o investigație complexă, care citește mai multe documente și întoarce un raport. Alegerea trebuie testată pe solicitări reale anonimizate sau pe cazuri sintetice reprezentative. Acest exemplu nu este un benchmark și nu afirmă că o anumită variantă va câștiga în toate magazinele.

Cum compari două arhitecturi fără să te păcălești

1. Definește rezultatul corect. Ce trebuie să primească utilizatorul și ce acțiuni sunt interzise?
2. Pregătește cazuri reprezentative. Include sarcini simple, complexe, ambigue și erori ale instrumentelor.
3. Păstrează condițiile comparabile. Documentează modelele, instrumentele, datele și bugetele folosite.
4. Măsoară întregul flux. Include costul total, durata, reluările și verificarea umană.
5. Examinează eșecurile. Un scor mediu bun poate ascunde o eroare gravă de permisiuni.
6. Repetă evaluarea. O singură execuție reușită nu demonstrează stabilitatea.

Nu compara o arhitectură cu acces la toate sursele cu alta care primește doar un rezumat incomplet. Dacă schimbi simultan modelul, promptul și structura agenților, notează că nu poți atribui întregul rezultat unei singure modificări.

Pentru fiecare caz, păstrează traseul operațiunilor și dovada rezultatului. O evaluare care notează numai calitatea formulării poate favoriza un răspuns elegant, dar incorect. Într-un flux de cod, verifică comportamentul; într-un flux editorial, verifică sursele; într-un flux comercial, verifică și respectarea autorizării.

Cum simplifici treptat o implementare existentă

Începe cu două componente care folosesc aceleași date și lucrează una după alta. Construiește o variantă de test în care sarcina lor este preluată de agentul principal, cu instrucțiuni clare. Compară rezultatele înainte să extinzi schimbarea.

Nu înlocui toată arhitectura într-o singură intervenție. Păstrează posibilitatea de revenire și urmărește cazurile care mergeau bine înainte. Dacă simplificarea reduce timpul, dar pierde o restricție importantă, rezultatul nu este acceptabil doar pentru că răspunsul sosește mai repede.

Instrucțiunile reutilizabile și instrumentele bine definite pot evita repetarea unor roluri întregi. Totuși, un fișier de instrucțiuni nu creează singur o limită de acces. Verifică separat contextul, permisiunile și executarea acțiunilor. Pentru lucrul practic cu AI în programare, vezi ghidul despre asistenții de cod.

Trei arhitecturi pe care merită să le compari înainte să alegi

Prima variantă este un flux determinist: aplicația știe ordinea etapelor, iar modelul ajută doar acolo unde este necesară interpretarea. De exemplu, citești un document, extragi câmpuri, validezi schema și trimiți rezultatul la revizuire. Nu ai nevoie de un coordonator autonom dacă ordinea operațiunilor este deja cunoscută și stabilă.

A doua variantă este un agent principal cu instrumente bine delimitate. Acesta decide ce informație mai trebuie citită și când are suficiente dovezi pentru răspuns. Avantajul posibil este continuitatea contextului; limita apare dacă sarcina adună prea multe informații sau dacă responsabilitățile devin greu de verificat împreună.

A treia variantă este coordonarea unor subagenți. Fiecare primește o problemă delimitată și întoarce un rezultat integrabil. Această structură poate fi utilă când explorările sunt independente, dar introduce contracte de comunicare, limite de resurse și reguli pentru rezolvarea contradicțiilor. Nu este suficient să desenezi săgețile dintre roluri.

În practică, poți combina variantele. Validarea unei cereri rămâne deterministă, cercetarea poate fi delegată, iar aprobarea unei acțiuni rămâne în aplicație. Un design hibrid este justificat dacă fiecare componentă are un motiv clar de existență, nu doar pentru a include toate modelele de arhitectură într-un singur proiect.

Contractul de delegare: ce trebuie să primească și să returneze un subagent

O cerere precum „ocupă-te de securitate” este prea largă pentru a putea evalua rezultatul. Înlocuiește-o cu o sarcină delimitată: verifică regulile de acces pentru un anumit flux, citește fișierele indicate, nu modifica nimic și raportează constatările susținute de dovezi. Formatul cererii reduce ambiguitatea, dar nu înlocuiește permisiunile tehnice.

Contractul ar trebui să conțină obiectivul, datele de intrare, restricțiile, bugetul, criteriul de oprire și forma răspunsului. Pentru fiecare constatare, solicită sursa și nivelul de certitudine. Dacă un fișier nu este disponibil, subagentul trebuie să raporteze limita, nu să completeze din memorie o implementare probabilă.

La întoarcere, coordonatorul verifică dacă rezultatul răspunde cererii și dacă dovezile pot fi consultate. Un rezumat fluent nu este suficient. Dacă subagentul trebuia să compare două configurații și a văzut doar una, raportul trebuie să păstreze explicit această lipsă. Altfel, incertitudinea dispare la predare și devine o concluzie aparent sigură.

Obiectiv: evaluează accesul la descărcarea facturilor.
Intrări: versiunea proiectului și fișierele autorizate.
Restricții: numai citire; fără date reale de client.
Rezultat: constatare, dovadă, limitări, verificare propusă.
Oprire: raport final sau explicația concretă a blocajului.

Acesta este un exemplu de structură editorială, nu o configurație executabilă pentru un anumit SDK. Adaptează câmpurile la platformă și la riscul sarcinii. Important este ca responsabilitatea să rămână verificabilă chiar dacă modelul sau infrastructura se schimbă.

Context comun, memorie și versiuni: cum previi lucrul pe informații vechi

Un subagent poate lucra corect cu informația primită și totuși să livreze un rezultat depășit. Imaginează-ți că citește versiunea inițială a unei politici, în timp ce coordonatorul primește o corecție de la utilizator. Dacă modificarea nu este transmisă sau sarcina nu este reluată, cele două componente rezolvă probleme diferite.

Asociază instrucțiunile și documentele relevante cu o versiune sau un identificator al reviziei. Când apare o schimbare importantă, decide explicit ce rezultate sunt invalidate. Nu este necesar să repornești întregul sistem la orice editare, însă o schimbare de obiectiv, permisiuni sau criterii de acceptare trebuie urmărită până la componentele afectate.

Memoria persistentă poate păstra informații utile între execuții, dar și presupuneri expirate. Definește ce poate fi memorat, sursa, data și condițiile de revalidare. O preferință de stil și o regulă de acces nu au aceeași durată de viață și nici același risc dacă sunt aplicate greșit.

Subagenții care modifică aceleași fișiere: de unde apar conflictele

Într-un proiect software, paralelismul nu este gratuit doar fiindcă fiecare agent primește un rol diferit. Un agent de interfață și unul de accesibilitate pot edita aceeași componentă. Dacă ambele schimbări pornesc de la versiunea veche, integrarea poate pierde o parte din corecții sau poate produce un comportament care nu a fost testat de niciunul.

Delimitează proprietatea fișierelor sau folosește spații de lucru separate, apoi integrează modificările controlat. Când separarea nu este posibilă, programează intervențiile secvențial. Eticheta de „lucru paralel” nu justifică două scrieri concurente asupra aceleiași surse de adevăr.

După integrare, rulează verificările pe rezultatul combinat. Testele trecute separat nu demonstrează compatibilitatea dintre patch-uri. Coordonatorul trebuie să poată identifica ce versiune a fost verificată și ce modificări au apărut ulterior. Un raport vechi de succes nu poate valida automat diferențele adăugate după test.

Bugete, timeouts și reluări: cum împiedici o sarcină să ruleze fără limită

Stabilește un buget pentru întreaga cerere, nu doar pentru fiecare agent. Dacă fiecare subagent poate delega din nou fără limită, costul total poate crește fără o legătură clară cu valoarea rezultatului. Limitează adâncimea delegării și numărul sarcinilor simultane în funcție de infrastructura și obiectivul aplicației.

Diferențiază eroarea temporară de problema logică. O conexiune întreruptă poate justifica o reluare controlată; o cerere invalidă repetată identic poate consuma buget fără progres. Înregistrează motivul reluării și stabilește când fluxul trebuie să ceară informații suplimentare sau să returneze un rezultat parțial declarat.

Pentru operațiunile cu efecte externe, verifică starea înainte să repeți acțiunea după un timeout. Lipsa răspunsului nu demonstrează că operațiunea nu s-a executat. Într-un magazin, repetarea necontrolată a unei cereri de rambursare este o problemă diferită de repetarea unei căutări într-un document. Designul trebuie să distingă aceste cazuri.

Oprește și sarcinile devenite inutile. Dacă utilizatorul anulează cererea sau schimbă obiectivul, agenții rămași activi nu trebuie să continue să consume resurse ori să execute acțiuni pentru vechea solicitare. Anularea trebuie transmisă și verificată de mecanismul de execuție, nu doar menționată în mesajul coordonatorului.

Costul real: de ce prețul unui răspuns nu spune toată povestea

Pentru planificare, poți folosi o descompunere simplă: costul total al sarcinii include apelurile modelelor, utilizarea instrumentelor, infrastructura și timpul de verificare umană. Nu este o formulă de tarifare a unui furnizor. Este o modalitate de a evita comparația dintre un apel ieftin, dar inutil, și un rezultat mai costisitor care poate fi acceptat.

Măsoară costul până la rezultat acceptat. Dacă o arhitectură livrează repede, dar necesită trei corecturi și o intervenție manuală, acestea fac parte din același flux. Separă sarcinile reușite, eșuate și abandonate; o medie calculată numai pe succese poate ascunde consumul produs de restul cererilor.

Pentru durată, urmărește traseul care determină finalizarea. Trei cercetări independente pot rula simultan, dar sinteza începe abia după rezultatele necesare. Cozile, limitele API și evaluarea finală pot domina timpul total. Nu deduce accelerarea doar din numărul de agenți porniți în paralel.

Un set de evaluare pentru asistentul magazinului online

Construiește cazurile pornind de la comportamentele care contează pentru utilizator. Include o întrebare simplă despre livrare, o comandă inexistentă, două comenzi asemănătoare și un utilizator fără acces la comanda cerută. Adaugă și situația în care instrumentul de citire este indisponibil. Răspunsul corect poate fi o limitare explicată, nu o informație completă.

Pentru fiecare caz, scrie înainte ce răspunsuri și acțiuni sunt acceptabile. Dacă politica nu permite determinarea unei rambursări, agentul nu trebuie să inventeze o aprobare. Verifică separat corectitudinea informației, respectarea accesului, claritatea și operațiunile efectuate. O formulare politicoasă nu compensează o acțiune neautorizată.

Rulează variantele pe același set și păstrează configurațiile. Dacă modifici simultan modelul și arhitectura, poți compara sistemele complete, însă nu poți atribui diferența exclusiv subagenților. Repetă cazurile pentru a observa variația și rezervă exemple care nu au fost folosite la ajustarea instrucțiunilor.

Stabilește criterii eliminatorii pentru erorile grave. O variantă cu răspunsuri rapide poate fi respinsă dacă dezvăluie datele altui client. Pentru restul, compară compromisurile: calitate, cost, durată și efort de întreținere. Nu comprima toate diferențele într-un singur scor dacă astfel ascunzi problema care contează cel mai mult pentru aplicație.

Cum tratezi instrucțiunile găsite în documente sau răspunsuri externe

Un sistem de cercetare citește conținut pe care nu îl controlează. Unele pagini sau documente pot conține text care încearcă să schimbe sarcina, să ceară acces la informații sau să inducă acțiuni. Tratarea acelui text ca instrucțiune autorizată poate încălca obiectivul utilizatorului. Aceasta este o categorie de risc de proiectare, nu dovada unui incident în exemplele noastre.

Separă materialul citit de regulile sistemului și aplică permisiunile în afara răspunsului modelului. Un subagent care explorează documente nu ar trebui să poată modifica automat drepturile altui agent. În evaluare, include documente de test cu cereri contradictorii și verifică dacă fluxul păstrează obiectivul și limitele stabilite.

Plan de simplificare în patru etape

1. Inventar: listează agenții, intrările, instrumentele, drepturile și dependențele. Identifică rolurile care își transmit aceleași date.
2. Variantă de control: păstrează arhitectura actuală și rezultatele ei, pentru a avea un punct de comparație.
3. Experiment limitat: reunește o singură pereche de etape, rulează evaluările și inspectează eșecurile.
4. Decizie: păstrează schimbarea doar dacă respectă criteriile; altfel revino și documentează limita descoperită.

La final, echipa ar trebui să poată explica de ce fiecare subagent rămas are nevoie de context separat, de lucru paralel sau de o limită de acces distinctă. Dacă această explicație lipsește, componenta este un candidat pentru analiză, nu pentru ștergere automată. Arhitectura trebuie să reflecte dovezile din evaluare și constrângerile reale ale produsului.

Întrebări frecvente despre agenți și subagenți AI

Anthropic recomandă renunțarea la toți subagenții?

Nu. Analiza discută când merită reunite unele componente și păstrează cazuri în care separarea este utilă. Decizia trebuie susținută de evaluarea sarcinii concrete.

Mai mulți agenți înseamnă mai multă inteligență?

Nu automat. Pot crește capacitatea de explorare, dar și costurile, coordonarea și posibilitatea propagării erorilor. Contează rezultatul verificat, nu numărul de roluri.

Subagenții trebuie să folosească modele diferite?

Nu este o condiție generală. Modelele pot fi alese după sarcină, cost și evaluare. Schimbarea modelului trebuie documentată când compari arhitecturi.

Un singur agent este întotdeauna mai ieftin?

Nu. Poate consuma mult context sau repeta pași. Măsoară costul total până la rezultatul acceptat, inclusiv reluările și intervenția umană.

Pot înlocui testele cu un agent verificator?

Un evaluator AI poate ajuta, dar nu înlocuiește automat dovezile din teste, surse sau mediul de execuție. Verificările trebuie alese după riscul și natura rezultatului.

De unde încep dacă nu am încă un sistem de agenți?

Definește sarcina și un set mic de cazuri de evaluare. Construiește cea mai simplă variantă care le poate rezolva și adaugă complexitate atunci când ai o limită măsurată.

Arhitectura bună este cea pe care o poți explica și verifica

Un sistem util are responsabilități clare, acces controlat și rezultate verificabile. Păstrează subagenții acolo unde separarea rezolvă o problemă reală. Simplifică acolo unde componentele doar își transferă aceleași date fără un beneficiu demonstrat. Pentru formularea instrucțiunilor, consultă și ghidul de prompturi. Evaluarea arhitecturii rămâne specifică proiectului tău.