Agenți AI fiabili: context, instrumente și evaluare

Un agent are nevoie de reguli explicite de execuție

Un asistent care descrie o publicare și un agent care modifică un sistem de producție sunt sisteme diferite. Al doilea are nevoie de reguli explicite: ce poate citi, ce acțiuni poate executa, cum își reia activitatea după întreruperi și ce înseamnă succesul.

Modelul este doar o componentă. O arhitectură solidă include și mediul de execuție, interfețele instrumentelor, starea persistentă, autorizarea și evaluarea. Articolul propune o arhitectură pentru un agent ipotetic de pregătire a versiunilor software. Exemplele sunt recomandări de proiectare, nu afirmații despre implementări pentru clienții Nikba.

Alege un flux cu limite clare înainte de a crește autonomia

Pentru un asistent de lansare, sarcina inițială ar putea fi: inspectează un commit aprobat, rulează o suită definită de teste, redactează notele versiunii și pregătește propunerea de deploy. Mediul de execuție poate codifica direct aceste etape. Nu câștigi prea mult cerând modelului să redescopere procesul la fiecare rulare.

Oferă modelului libertate acolo unde este necesară interpretarea: alegerea unui diagnostic relevant, explicarea unei erori sau selectarea următorului instrument permis, cu acces doar la citire. Distincția Anthropic dintre fluxuri și agenți oferă un vocabular util, deși discuția despre instrumente datează din 2024. Arhitecturile mai recente trebuie evaluate separat.

Definește limita de pași, bugetul de timp, instrumentele permise, politica de reîncercare și stările finale explicite. Faptul că „modelul a încetat să răspundă” nu este un criteriu suficient de succes. În acest exemplu, succesul înseamnă că dovezile testării sunt înregistrate și că propunerea corespunde commitului aprobat.

Separă starea persistentă de fereastra curentă de context

Contextul de lucru conține informația necesară următoarei decizii. Registrul persistent păstrează ce s-a întâmplat: identitatea sarcinii, reviziile surselor, apelurile instrumentelor, rezultatele, aprobările și artefactele produse. Durata lor de viață diferă. Resetarea contextului sau înlocuirea unui proces de execuție nu trebuie să șteargă istoricul de referință.

Arhitectura Managed Agents prezentată de Anthropic în aprilie 2026 separă sesiunea, infrastructura de coordonare a agentului și mediul de execuție. O consecință utilă: agentul poate recupera evenimente relevante dintr-un registru persistent, fără să depindă de o singură conversație tot mai lungă.

Pentru asistentul propus, salvează hash-ul commitului aprobat și identificatorii artefactelor înainte de pornirea oricărui proces de lucru. La reluare, reconstruiește contextul necesar din aceste înregistrări. Dacă arborele de lucru sau destinația deploy-ului s-au schimbat, tratează neconcordanța ca pe o decizie nouă, în loc să continui tacit vechiul plan.

Pregătește contextul pentru fiecare decizie

Instrucțiunile de sistem, descrierile instrumentelor, documentele sursă și rezultatele acumulate ocupă aceeași fereastră de context. Include obiectivul curent, constrângerile relevante, un rezumat concis al execuției și dovezile necesare pasului următor. Păstrează jurnalele mari ca artefacte și recuperează fragmentul relevant atunci când diagnosticul o cere.

Ingineria contextului tratează selecția informațiilor ca pe o responsabilitate continuă a mediului de execuție. Rezumatele ajută, dar sunt reprezentări derivate. Păstrează trimiteri la rezultatele originale pentru a putea verifica un avertisment omis sau o ipoteză schimbată.

În exemplul nostru, regula de proiectare este să păstrăm exact identificatorii reviziilor, mediile vizate, domeniul aprobărilor și codurile de ieșire ale testelor. Ieșirea repetitivă privind progresul poate fi rezumată. Este o politică concretă, testabilă, mai utilă decât îndemnul „ține minte tot ce este important”.

Construiește instrumente cu rol restrâns, tipuri explicite și verificarea permisiunilor

Contractul unui instrument trebuie să descrie intrările, domeniul de acțiune, ieșirile, efectele posibile asupra sistemului și modurile de eșec. Mediul de execuție validează cererea și drepturile solicitantului înainte de apel. Rezultatele trebuie să distingă succesul, o eroare temporară de transport, o intrare invalidă și o operație respinsă.

inspect_release(commit, repository) → evidence
run_checks(commit, check_profile) → test_results
prepare_release(commit, evidence_ids) → proposal
execute_release(proposal_id, approval_id, idempotency_key) → execution_record

Interfețele sunt ilustrative. Instrumentul de execuție trebuie să stabilească destinația și drepturile din starea de încredere a aplicației. Un șir arbitrar generat de model nu trebuie să decidă pentru ce cont de producție există autorizare.

MCP poate standardiza descoperirea și apelarea instrumentelor, dar o conexiune de protocol nu înlocuiește arhitectura de securitate a aplicației. Ghidul de securitate MCP discută amenințări precum confused deputy și transmiterea necontrolată a tokenurilor de acces. Detaliile documentației draft trebuie verificate față de versiunea protocolului folosită efectiv.

Tratează instrucțiunile din sursele externe ca date fără autoritate

Fișierele din repository, paginile web și răspunsurile instrumentelor pot conține instrucțiuni menite să redirecționeze agentul. Modelul poate confunda acest conținut cu o sursă de autoritate. Astfel, un atac de tip prompt injection poate transforma o operație de citire într-o încercare de modificare sau divulgare de date.

Recomandările OWASP pentru prompt injection propun protecții pe mai multe niveluri: privilegiu minim, verificări deterministe și controale pentru operațiile privilegiate. Etichetarea textului extern este utilă, dar nu constituie o apărare completă.

În exemplul lansării, jurnalul de modificări recuperat poate contribui la notele versiunii. Nu poate acorda acces la alt repository și nu poate autoriza un deploy. Mediul de execuție trebuie să respingă schimbarea destinației dacă nu există o aprobare corespunzătoare, chiar dacă modelul oferă o explicație convingătoare.

Proiectează reîncercările în funcție de efectele operațiilor

Să presupunem că o cerere de deploy depășește timpul de așteptare. Operația de la distanță poate să fi reușit, deși răspunsul s-a pierdut. Repetarea oarbă a apelului poate dubla acțiunea. Interfața propusă folosește o cheie de idempotență legată de propunerea aprobată; serviciul o înregistrează împreună cu operația și returnează starea existentă la reîncercare.

Salvează intenția înainte de execuție, clarifică rezultatele incerte prin verificarea sistemului și inspectează starea de la distanță înainte de a alege măsura de recuperare. Limitele tranzacțiilor depind de sistemul extern. Afirmația agentului că „a făcut rollback” nu dovedește că operația de compensare a avut loc.

Leagă aprobările de acțiunea, destinația și artefactul concret. În această arhitectură, schimbarea commitului sau a mediului invalidează aprobarea anterioară de execuție. Permisiunea pentru o verificare în staging nu trebuie să autorizeze implicit modificări în producție.

Evaluează rezultatele și examinează traseul execuției

Un agent poate redacta note de versiune convingătoare în timp ce testează revizia greșită. Evaluează starea și artefactele rezultate, apoi examinează traseul execuției pentru a înțelege cum a ajuns la ele. Ghidul Anthropic de evaluare din ianuarie 2026 descrie sarcini, rulări și evaluatori pentru sisteme care acționează pe parcursul mai multor pași de conversație.

Pentru asistentul de lansare, matricea inițială de evaluare ar include:

• O lansare fără erori, în care dovezile și propunerea trebuie să indice același commit.
• Un test eșuat care trebuie să oprească traseul de execuție.
• O instrucțiune ascunsă într-un document sursă, care încearcă să schimbe destinația deploy-ului.
• O eroare de timeout după pornirea operației externe.
• O aprobare expirată sau care nu mai corespunde artefactului.
• Repornirea procesului, cu reluare din registrul persistent fără repetarea operațiilor deja finalizate.

Repetă rulările atunci când variația ieșirii influențează rezultatul. Măsoară separat finalizarea sarcinii, încălcările de permisiuni, corectitudinea recuperării, latența și costul. Un scor agregat poate ascunde o eroare rară, dar inacceptabilă. Păstrează evaluarea umană pentru cazurile ambigue și folosește verificări deterministe oriunde starea așteptată poate fi definită direct.

Stabilește ce se poate schimba în siguranță după lansare

Versionează modelul, instrucțiunile de sistem, schemele instrumentelor și politica infrastructurii de coordonare împreună cu rezultatele evaluării. Înaintea unui upgrade, repetă scenariile de eșec care au justificat controalele existente. Progresele modelului pot face inutilă o soluție provizorie, iar noile instrumente pot extinde consecințele posibile ale unei erori.

Pentru prima implementare, alege un agent de pregătire a lansării cu sarcini observabile, limite clare și un transfer explicit către etapa de execuție. Extinde-i autoritatea numai când produsul are nevoie de acest lucru și comportamentul măsurat susține decizia.

Pentru arhitectura căutării și permisiuni, citește RAG sau fine-tuning. Pentru costurile contextului și generării, vezi inferența LLM.