Astăzi am citit un articol lung despre Harness Engineering — zeci de mii de cuvinte, aproape sigur scris de AI. Prima mea reacție nu a fost "wow, ce concept puternic." Era "au acești oameni vreo idee dincolo de a inventa termeni noi pentru cei vechi?" Întotdeauna m-a deranjat acest tipar din lumea AI — reinventarea constantă a conceptelor existente. De la ingineria prompturilor la ingineria contextului, acum să valorificăm ingineria. La fiecare câteva luni, cineva inventează un termen nou, scrie un eseu de 10.000 de cuvinte, adaugă câteva studii de caz ale unor companii mari și întreaga comunitate începe să fie în forță. Dar dacă te uiți efectiv la conținut, este același lucru de fiecare dată: Proiectează mediul în care rulează modelul tău — ce informații primește, ce unelte poate folosi, cum sunt interceptate erorile, cum este gestionată memoria între sesiuni. Acest lucru există încă din ziua lansării ChatGPT. Nu devine o disciplină nouă doar pentru că cineva — dintr-un motiv sau altul — a decis să-i dea un nume nou. Totuși, lăsând la o parte plângerile, cercetările și studiile de caz citate în articol au valoare — mai ales că se suprapun puternic cu ceea ce am construit cu modul de sglang. Așadar, permiteți-mi să folosesc această ocazie să vorbesc despre greșelile pe care le-am făcut de fapt. Mai întâi, puțin context. Cele mai frecvente cereri în comunitatea SGLang sunt Întrebările How-to — cum să implementezi DeepSeek-V3 pe 8 plăci grafice, ce să faci când gateway-ul nu poate ajunge la adresa muncii, dacă diferența dintre GLM-5 INT4 și FP8 oficial este semnificativă. Aceste întrebări acoperă o suprafață tehnică extrem de largă, iar pe măsură ce comunitatea crește tot mai repede, tot mai mult nu putem ține pasul cu răspunsurile. Așa că am început să construiesc un sistem multi-agent pentru a răspunde automat. Prima idee a fost, desigur, cea mai naivă — să construiască un singur Agent omniscient, să încorporeze toată documentația, codul și cărțile de bucate ale SGLang în el și să-l lase să răspundă la tot. Asta nu a funcționat. Nu ai nevoie de teoria de tip harness engineering pentru a explica de ce — fereastra de context nu este RAM. Cu cât bagi mai mult în ea, cu atât atenția modelului se dispersează mai mult și răspunsurile devin mai proaste. Un agent care încearcă să înțeleagă simultan cuantizarea, dezagregarea PD, difuzarea și compatibilitatea hardware ajunge să nu înțeleagă în profunzime niciuna dintre ele. Designul pe care am ajuns în cele din urmă este o arhitectură expertă în subdomenii cu mai multe straturi. Documentația SGLang are deja limite funcționale naturale — funcționalități avansate, platforme, modele suportate — cu cărți de bucate organizate pe modele. Am transformat fiecare subdomeniu într-un agent expert independent, cu un Manager de Dezbateri Experți responsabil de primirea întrebărilor, descompunerea lor în sub-întrebări, consultarea Tabelului de Rutare pentru Experți pentru a activa agenții potriviți, rezolvarea în paralel și apoi sintetizarea răspunsurilor. Privind înapoi, acest design se potrivește aproape perfect cu modelele promovate de comunitatea ingineriei hamurilor. Dar când îl construiam, nu aveam idee că aceste modele aveau nume. Și nici nu aveam nevoie. 1. Dezvăluire progresivă — nu am transferat toată documentația niciunui agent individual. Fiecare expert de domeniu încarcă doar cunoștințele sale de domeniu, iar Managerul decide pe cine să activeze în funcție de tipul de întrebare. Intuiția mea spune că acest design a adus mult mai multe îmbunătățiri decât înlocuirea cu un model mai puternic. Nu trebuie să știi că acest lucru se numește "dezvăluire progresivă" pentru a lua această decizie. Trebuie doar să fi încercat o dată abordarea "să bagi totul înăuntru" și să fi văzut cum a eșuat. 2. Depozitul ca sursă de adevăr — întregul flux de lucru se află în depozitul how-to-sglang. Toți agenții experți își extrag cunoștințele din fișierele de reducere din depozit, fără a depinde de documente externe sau acorduri verbale. La început, am avut dorința să scriem un sglang-maintain.md uriaș care să acopere totul. Am învățat rapid că asta nu funcționează. Echipa Codex a OpenAI a făcut aceeași greșeală — au încercat un singur AGENTS.md supradimensionat și l-au văzut putrezind în moduri previzibile. Nu trebuie să fi citit blogul lor ca să calci tu însuți pe această mină. Este problema clasică a ingineriei software, "documentația monolitică se închide mereu", doar că în contextul unui agent consecințele sunt mai grave — documentația învechită nu rămâne doar necitită, ci induce activ în eroare agentul. 3. Rutarea structurată — Tabelul de Rutare al Experților mapează explicit tipurile de întrebări către agenți. O întrebare despre GLM-5 INT4 activează simultan atât Expertul Domeniului din Cărți de Bucate, cât și Expertul în Domeniu de Cuantificare. Managerul nu ghicește; Urmează un indice structurat. Cei din domeniul ingineriei hamurilor numesc acest lucru "constrângeri mecanizate". Eu îi spun inginerie normală. Nu spun că ideile din spatele ingineriei hamurilor sunt proaste. Cercetarea citată este solidă, conceptul ACI de la SWE-agent merită cu adevărat cunoscut, iar arhitectura dual-agent a Anthropic (agent inițializator + agent de programare) este material de referință valoros pentru oricine face sarcini pe termen lung. Ceea ce găsesc obositor este inventarea constantă a unor termeni noi — ambalarea bunului simț ingineresc stabilit ca o disciplină nouă, apoi fabricarea anxietății legate de "ești în urmă dacă nu cunoști acest cuvânt." Ingineria promptului, ingineria contextului, ingineria de harness — sunt fațete diferite ale aceluiași lucru. Luna viitoare probabil cineva va inventa ingineria schelelor sau ingineria orchestrării, va scrie un alt eseu lung citând aceeași lucrare de agent SWE, iar comunitatea va începe un nou ciclu de amplificare. Ce am învățat de fapt din how-to-sglang poate fi spus fără vocabular nou:...