Cuprins
Un agent AI care lucrează într-un proiect software are nevoie de instrucțiuni pe care să le poată aplica și de o imagine clară a lucrului rămas. Pentru echipele care îi încredințează modificări de cod, o întrebare practică este ce merită păstrat permanent în conversație și ce poate fi adus doar când devine relevant.
Două lucrări recente oferă indicii: Agent Skill Evolution examinează schimbările din fișierele de instrucțiuni, iar AutoCompact studiază gestionarea istoricului de lucru. Împreună, ele sugerează o direcție de experimentare: reguli esențiale ușor de găsit și puncte de reluare precise. Rezultatele sunt însă limitate la condițiile evaluate de autori.
Ce arată studiul despre Skills
Un fișier SKILL.md descrie proceduri pentru un agent. Preprintul Agent Skill Evolution: How Revisions Affect Coding Agents, depus pe arXiv la 4 octombrie 2026, analizează 3.159 de Skills, inclusiv 2.608 perechi de versiuni inițiale și finale.
În experimentele cu patru agenți, regulile adăugate au crescut rata efectuării acțiunii cerute cu 23 de puncte procentuale, în medie. Corectitudinea finală, evaluată uman fără dezvăluirea modelului și versiunii, a crescut cu aproximativ 10 puncte procentuale pentru trei agenți. Comenzile și căile de fișiere absente anterior au contribuit în special la câștig. Pentru Sonnet, estimarea individuală a corectitudinii rămâne neconcludentă statistic.
Încărcarea la cerere a păstrat, în medie, 51% din câștigul privind acțiunea. Separat, includerea corpului unui skill vechi a consumat aproximativ 50% mai mulți tokeni per episod decât absența corpului. Acest procent nu izolează costul încărcării dinamice. Revizuirea skill-ului nu a produs un cost suplimentar detectabil per episod. Acțiunea cerută și corectitudinea soluției sunt măsuri distincte. Sursa: studiul original, secțiunile 5 și 6.
Ce schimbă AutoCompact
AutoCompact: Learning When to Compact Context in Long-Horizon Coding Agents, depus la 1 octombrie 2026, antrenează agentul să aleagă când comprimă istoricul, ce stare păstrează și cum continuă. Rezumatul trebuie să consemneze corect situația și să propună o acțiune compatibilă cu ea.
Cu aceeași bază Qwen3-Coder-30B-A3B-Instruct și același mediu de execuție, tabelul 1 raportează următoarele rezultate pe SWE-bench Verified:
| Variantă | Sarcini rezolvate |
|---|---|
| Modelul de bază cu istoricul complet | 30,4% |
| AutoCompact cu antrenare supravegheată | 32,2% |
| AutoCompact cu antrenare supravegheată și prin recompensă | 39,6% |
Diferența finală este de 9,2 puncte procentuale. Valorile sunt medii din trei rulări. Avantaje apar și la 256K tokeni, unde istoricul nu atinge pragul de comprimare forțată. „Aceeași bază” nu înseamnă aceiași parametri după antrenare: rezultatul de 39,6% nu poate fi atribuit exclusiv unui rezumat sau unei instrucțiuni adăugate în prompt. Sursa: AutoCompact, secțiunea 3.
Cum citim corect aceste rezultate
Cele două lucrări sunt disponibile ca preprinturi; paginile arXiv consultate nu indică o publicare evaluată într-o revistă sau conferință. Rezultatele trebuie tratate ca dovezi preliminare. Agent Skill Evolution pe arXiv, AutoCompact pe arXiv.
Pentru a interpreta procentele, să luăm un exemplu ipotetic: o rată care urcă de la 40% la 63% câștigă 23 de puncte procentuale, dar crește relativ cu 57,5%. Folosirea corectă a unității evită promisiuni ambigue despre „un agent cu 23% mai bun”.
De asemenea, îndeplinirea unei instrucțiuni este doar o parte a muncii. Un agent poate porni comanda de verificare corectă și totuși să livreze o modificare greșită. În evaluarea unui proiect real, merită consemnate separat respectarea procedurii și funcționarea rezultatului.
Un exemplu practic într-un magazin online
Să presupunem că un agent trebuie să corecteze calculul reducerilor într-un magazin online. Uneori, două promoții se aplică simultan, deși regulile magazinului permit una singură. Exemplul este ipotetic și arată cum pot fi formulate instrucțiunile și rezumatul de lucru.
O cerință precum „repară reducerile și verifică atent” lasă agentului multe lucruri de descoperit. O instrucțiune mai precisă ar putea arăta astfel:
Calculul reducerilor se află în src/pricing/discounts.py.
Regulile comerciale sunt descrise în docs/discount-policy.md.
După modificare, rulează python -m pytest tests/test_discounts.py.
Verifică separat: fără reducere, o singură reducere și două promoții concurente.
Când două promoții sunt eligibile, aplică doar reducerea cea mai avantajoasă.
Raportează comanda executată și rezultatul verificării.
Căile și comanda aparțin acestui exemplu; într-un proiect real trebuie înlocuite cu cele existente. Regula privind promoțiile exprimă comportamentul dorit, iar verificarea stabilește cum va fi controlat. Agentul poate astfel distinge între o modificare care doar rulează fără erori și una care respectă cerința comercială.
Pentru organizarea instrucțiunilor, o echipă poate încerca trei pași:
- Păstrează permanent regulile esențiale. Include comportamentul cerut, locul principal din cod și verificarea obligatorie.
- Separă explicațiile ample. Istoricul promoțiilor și exemplele comerciale rare pot rămâne într-un document consultat când este relevant.
- Evaluează efectul schimbărilor. Compară rezultatele agentului înainte și după revizuirea instrucțiunilor, pe aceleași sarcini.
Această organizare este o aplicare posibilă a ideilor discutate, iar eficiența ei trebuie măsurată în proiectul concret.
Cum arată un rezumat din care agentul poate continua
După identificarea cauzei erorii, agentul poate înlocui explorarea de până atunci cu o stare de lucru concisă. În exemplul magazinului, aceasta ar putea fi:
Obiectiv: două promoții eligibile nu trebuie cumulate.
Cauză confirmată: funcția aplică succesiv ambele reduceri.
Dovadă: cazul cu două promoții reproduce totalul incorect.
Fișier relevant: src/pricing/discounts.py.
Starea modificărilor: cauza este localizată; codul nu a fost schimbat.
Verificări executate: cazul cu două promoții eșuează.
Lucru rămas: corectarea selecției promoției și verificarea celorlalte cazuri.
Următoarea acțiune: modifică selecția pentru a păstra reducerea cea mai avantajoasă.
Un asemenea rezumat spune ce s-a aflat și ce urmează. La reluare, agentul are un punct concret de pornire. Dacă există deja modificări în fișiere, rezumatul trebuie să le menționeze, inclusiv pe cele realizate de altcineva. O verificare neexecutată trebuie să rămână în lista de lucru rămas.
Redactarea acestor puncte de reluare poate fi încercată după etape precum identificarea cauzei sau finalizarea implementării. Este un experiment inspirat de AutoCompact, care nu reproduce antrenarea din studiu și nu garantează același câștig.
Cum aflăm dacă schimbarea ajută proiectul
Reviziile regulilor și ale mecanismului de reluare pot fi evaluate pe un set fix de sarcini reprezentative. Pentru ca rezultatele să fie comparabile:
- Păstrează condițiile constante. Folosește aceeași versiune a modelului, același punct de pornire al codului, aceleași instrumente și același buget.
- Schimbă un singur element odată. Compară mai întâi regulile vechi cu cele noi. Într-un experiment separat, compară istoricul complet cu reluarea dintr-o stare structurată.
- Măsoară rezultatul și costul. Urmărește sarcinile rezolvate, verificările obligatorii efectuate, consumul de tokeni, durata și apelurile de instrumente repetate fără informații noi.
- Repetă rulările. O reușită izolată nu arată cât de stabil este comportamentul. Include și sarcini pe care nu le-ai folosit pentru a redacta regulile.
Acest protocol oferă un criteriu practic pentru păstrarea unei modificări: îmbunătățește în mod repetat rezultatul, la un cost acceptabil pentru proiect. Un fișier de instrucțiuni mai lung sau un rezumat mai elegant nu sunt, singure, o măsură a progresului.
