Deep Agents

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 1 din 16. Să construiești un coding agent de la zero e distractiv cam o oră. Apoi, modelul tău atinge context limit-ul, uită complet task-ul inițial și suprascrie un fișier critic cu garbage. Ca să-ți oprești asistentul din a-și distruge propriul workspace, ai nevoie de ceea ce se numește pattern-ul de agent harness. Lumea întâlnește des acest pattern printr-un library numit Deep Agents. Mai întâi, o scurtă clarificare. Deep Agents nu este LangChain și nu este nici LangGraph. Este un library Python standalone care stă deasupra acestor tool-uri, împachetându-le într-un coding assistant gata de utilizare. Dacă încerci să construiești tu singur un coding assistant, de obicei începi cu un script de bază. Iei un user prompt, îl trimiți către un Large Language Model și dai print la codul pe care îl returnează. Asta e doar un simplu chat loop. Funcționează bine pentru a răspunde la o singură întrebare. Dar în curând, vrei ca modelul să implementeze pe bune un feature în mai multe fișiere de pe mașina ta. Aici se destramă iluzia. Îți dai seama că trebuie să scrii manual tool-uri ca să citești fișiere, să cauți prin directoare și să aplici code diffs în siguranță. Ai nevoie de un sistem care să țină evidența contextului pe parcursul a zeci de pași, fără să atingă token limit-ul. Trebuie să construiești un task list persistent, astfel încât modelul să țină minte pe bune ce tocmai a făcut și ce trebuie să facă în continuare. Ajungi să-ți petreci tot timpul scriind file system boilerplate și state management, în loc să te concentrezi pe agent behavior. Asta este exact ceea ce rezolvă pattern-ul de agent harness. Un harness este layer-ul de infrastructură care înconjoară raw language model-ul. Transformă un chat loop fragil și stateless într-un agent durabil, long-running. În Deep Agents, acest harness oferă memory management, file system operations și logica de planificare pas cu pas, direct out of the box. Îi dai un high-level goal și îl îndrepți spre un director local. Harness-ul preia munca repetitivă de a-i oferi modelului un mediu sigur în care să planifice, să editeze și să verifice cod. Iată ideea cheie. Principalul avantaj al folosirii unui harness independent precum Deep Agents este că e complet model-agnostic. Soluțiile tightly integrated, precum Claude Agent SDK sau ecosistemele mai vechi precum OpenAI Codex, sunt puternic optimizate, dar te blochează la un singur provider. Dacă mâine se lansează un model mai ieftin sau mai deștept, migrarea agentului tău tightly coupled va fi o mare bătaie de cap. Pentru că Deep Agents abstractizează mediul separându-l de reasoning engine, language model-ul devine o componentă complet înlocuibilă. Harness-ul gestionează task list-urile, citește file system-ul și se ocupă de error recovery. Această logică rămâne identică indiferent dacă folosești Anthropic, OpenAI sau un model local open-weight. Harness-ul este șasiul mașinii, iar language model-ul este doar motorul. Adevărata valoare a acestui pattern este fiabilitatea. Un agent este la fel de capabil ca mediul în care operează, iar fără un harness care să-l ancoreze de un file system real și de un plan concret, chiar și cel mai inteligent model este doar un text generator care merge în gol. Dacă vrei să ajuți ca show-ul să meargă mai departe, poți căuta DevStoriesEU pe Patreon, orice sprijin acolo contează enorm și este mereu apreciat. Asta e tot pentru acest episod. Mersi că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 2 din 16. Nu ai nevoie de o diagramă de arhitectură masivă sau de sute de linii de boilerplate pentru ca un model de limbaj să își planifice autonom munca. Ai nevoie doar de un singur apel de funcție pentru a declanșa Core Loop-ul. Punctul de intrare pentru acest comportament este o funcție numită create deep agent. Această funcție este locul unde definești creierul aplicației tale. În loc să imporți librării client separate și să scrii wrapper-uri custom, îi spui funcției ce model să folosească printr-un simplu string separat prin două puncte. Pasezi provider-ul, două puncte și numele exact al modelului. Ai putea folosi anthropic colon claude-sonnet-4-6 sau openai colon gpt-5.4. Framework-ul citește acest string și gestionează inițializarea specifică under the hood. Un agent are nevoie de o modalitate de a interacționa cu lumea, pe care i-o oferi prin intermediul tool-urilor. Un tool este doar o funcție standard Python care execută o acțiune specifică. Să zicem că dezvolți un agent de research pe internet. Ai scrie o funcție care primește un query, apelează un search API și returnează text. Pasezi această funcție de search direct în apelul tău create deep agent, ca parte a unei liste. Agentul tău este acum gata. Pentru a începe procesul, apelezi metoda run pe noul tău agent și îi pasezi un prompt, cum ar fi să-i ceri să facă research și să sintetizeze știri recente despre quantum computing. Acum Core Loop-ul preia controlul. Iată ideea cheie. Dezvoltatorii presupun adesea că trebuie să scrie system prompts complexe pentru a forța modelul să împartă task-urile, sau să construiască custom parsers pentru a-i urmări progresul. Nu trebuie să faci nimic din toate astea. Când apelezi create deep agent, harness-ul injectează automat un built-in tool numit write todos. Nu scrii și nu gestionezi niciodată acest tool tu însuți. Face parte din core engine. Înainte ca agentul să atingă vreodată tool-ul tău de search, Core Loop-ul forțează modelul să folosească tool-ul write todos. Agentul evaluează promptul tău și generează o listă structurată de pași. Abia după finalizarea acestui plan începe faza de execuție. Loop-ul iterează prin plan pas cu pas. Agentul se uită la primul său task, recunoaște că are nevoie de informații și apelează tool-ul tău de căutare pe internet. Citește raw text-ul returnat de motorul de căutare și își actualizează memoria internă. Loop-ul verifică apoi dacă obiectivul principal este îndeplinit. Dacă rezultatele căutării au fost incomplete, agentul trece la următorul element de pe todo list-ul său, eventual formulând un nou search query pentru a găsi detaliile lipsă. Acest ciclu de selectare a unui tool, observare a rezultatului și verificare a planului continuă autonom. Când loop-ul confirmă că toate task-urile necesare sunt finalizate, se oprește din a apela tool-uri. Agentul analizează datele colectate, generează un răspuns final sintetizat și ți-l returnează. Caracteristica definitorie a Core Loop-ului este că transformă un generator de text static într-un problem solver activ, forțându-l structural să planifice înainte de a acționa. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 3 din 16. Să-i dai unui agent autonom acces raw la computerul tău este o modalitate excelentă de a-ți șterge accidental home directory-ul. Dacă un agent decide să-ți reorganizeze fișierele sau să testeze un script, trebuie să te asiguri că este limitat la o zonă sigură. De aceea folosim The Pluggable Filesystem. Când îi dai unui Deep Agent tools pentru a citi sau edita un fișier, acele tools nu se conectează direct la sistemul tău de operare. În schimb, ele se mapează la un backend. Un backend este un mediu de stocare care dictează unde și cum există de fapt fișierele. Mediul default este StateBackend. Acesta este un ghost drive efemer ținut în întregime în memorie. Să presupunem că îi ceri unui agent să scrie un draft rapid de e-mail sau să manipuleze niște date text. Agentul creează fișierul, îl citește și îl editează, totul în interiorul StateBackend. Când scriptul tău termină de rulat, acea memorie este ștearsă, iar fișierele dispar. Este complet izolat și perfect sigur. Dar ce se întâmplă când vrei ca agentul să genereze un proiect Python real pe disk-ul tău local? Memoria nu mai este de ajuns. Faci upgrade la permisiunile agentului atașând un FilesystemBackend. Asta conectează acele file tools ale agentului la hard drive-ul tău real. Ca să păstrezi totul sigur, inițializezi backend-ul cu un parametru numit virtual mode setat pe true. Iată ideea cheie. Virtual mode creează un path boundary strict. Definești un base directory, iar agentul operează în interiorul lui. Dacă agentul încearcă să citească un system file sensibil din afara acelui folder, backend-ul blochează request-ul. Îl blochează pe agent într-un workspace desemnat. Totuși, există o concepție greșită periculoasă aici. Mulți developeri presupun că activarea virtual mode creează un sandbox complet securizat. Nu este așa. Filesystem backend-ul controlează doar operațiunile pe fișiere. Dacă vrei ca agentul tău să ruleze și comenzi de terminal, trebuie să atașezi un al treilea tip de backend, numit LocalShellBackend. LocalShellBackend îi dă agentului un tool nou, numit execute. Asta îi permite agentului să ruleze comenzi de shell pe host machine-ul tău. Dacă atașezi un LocalShellBackend, acel virtual mode al filesystem backend-ului tău nu te va proteja de comenzi de terminal distructive. Agentul ar putea executa un script de ștergere system-wide, iar shell-ul l-ar rula, făcând bypass complet la restricțiile tale de file path. Accesul la fișiere și execuția de shell sunt capabilități distincte, mapate la backend-uri distincte. Dacă agentul tău trebuie doar să scrie cod, rămâi la FilesystemBackend. Atașează LocalShellBackend doar dacă agentul trebuie neapărat să compileze sau să ruleze acel cod local. Cel mai sigur agent autonom nu este cel cu cele mai inteligente prompt-uri, ci cel care primește deploy cu un state backend efemer, care fizic nu poate atinge host operating system-ul tău. Asta e tot pentru azi. Mersi că m-ai ascultat — du-te și construiește ceva cool.

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 4 din 16. Cea mai frecventă greșeală în designul agenților este scrierea unui system prompt masiv, de patru mii de cuvinte, care detaliază exact cum funcționează fiecare tool în parte și face hardcoding cu datele specifice sesiunii. Te alegi cu un prompt fragil, context windows epuizate și un coșmar atunci când gestionezi mai mulți utilizatori. System prompt-urile dinamice rezolvă acest lucru prin asamblarea din mers a instrucțiunilor exacte de care are nevoie language model-ul. Gândește-te la context engineering în Deep Agents ca la o linie de asamblare dinamică. În loc să scrii un bloc static de text, prompt-ul final trimis language model-ului este construit din trei straturi distincte. Aceste straturi sunt system prompt-ul static, tool prompt-urile și runtime context-ul. Acestea se îmbină în momentul exact al execuției pentru a forma input context-ul complet. Primul strat este system prompt-ul static. Aceasta este partea pe care o scrii manual. Definește persona-ul agentului, regulile sale de bază și scopul său final. Este deliberat simplu. Îi poți spune agentului că este un asistent de interogare a bazei de date, dar nu îi spui cum să se conecteze la baza de date, ce formatare așteaptă tool-ul sau care este session ID-ul utilizatorului. Păstrezi acest strat strict concentrat pe high-level business logic. Al doilea strat este format din tool prompt-uri, iar aici intervine framework-ul. Deep Agents injectează automat instrucțiunile de utilizare necesare pentru tool-urile specifice pe care le atașezi agentului. Dacă oferi agentului un tool pentru a citi un fișier, framework-ul adaugă dinamic schema exactă pentru acel tool. Împreună cu schemele, injectează un planning prompt built-in. Acest planning prompt instruiește modelul cu privire la modul de secvențiere eficientă a tool-urilor disponibile pentru a rezolva o problemă. Nu scrii niciodată manual instrucțiunile despre cum ar trebui modelul să formateze un tool call sau să își planifice pașii de execuție. Framework-ul gestionează automat aceste mecanisme. Când adaugi sau elimini un tool din agent, tool prompt-urile din spate se actualizează instantaneu fără ca tu să atingi core system prompt-ul. Acum, trebuie să clarificăm o sursă comună de confuzie între system prompt-ul static și runtime context. Prompt-ul static este definit atunci când inițializezi agentul. Runtime context-ul, însă, este injectat exact atunci când invoci agentul pentru a face treabă. Ia în considerare un scenariu în care construiești o aplicație multi-tenant. Când un anumit utilizator pune o întrebare, agentul are nevoie de ID-ul unic de conexiune la baza de date al acelui utilizator pentru a-i prelua datele. Dacă pui acel identificator în system prompt-ul static, ar trebui să recreezi întregul agent de la zero pentru fiecare solicitare a utilizatorului. În schimb, folosești runtime context-ul. Iată ideea cheie. Pasezi un context object printr-un feature numit ToolRuntime chiar la pasul de invocare. Îi oferi framework-ului un dicționar care conține ID-ul specific de conexiune la baza de date pentru acea sesiune. Framework-ul preia acest runtime context, îl îmbină cu prompt-ul tău static și cu instrucțiunile tool-ului generate automat, și îl conectează direct la tool-urile care îl necesită. Tool-ul se execută folosind ID-ul de conexiune corect, furnizat dinamic. System prompt-ul tău static rămâne complet curat de identificatori temporari, API keys sau session tokens. La milisecunda de execuție, linia de asamblare dinamică își termină treaba. Deep Agents concatenează instrucțiunile tale de bază, tool schemas generate dinamic, planning prompt-urile și datele specifice de invocare într-un singur input context coerent. Modelul primește un set complet, perfect formatat, de instrucțiuni adaptate utilizatorului specific și sarcinii specifice. Cei mai scalabili agenți nu știu nimic despre mediul lor până în momentul exact în care li se cere să acționeze. Asta e tot pentru acest episod. Pe data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 5 din 16. Majoritatea agenților AI dau crash sau eșuează silențios în momentul în care citesc un system log sau un data dump care depășește dimensiunea maximă a promptului. Deep Agents previne acest lucru tratând limitele de context așa cum un sistem de operare gestionează memoria virtuală. Asta se numește Context Compression and Offloading. Large language models au o limită strictă pentru cantitatea de text pe care o pot procesa simultan. Dacă un agent încearcă să țină prea multe date în promptul activ, modelul dă o eroare și se oprește. Deep Agents gestionează acest token overflow monitorizând constant dimensiunea datelor din conversație. Funcționează exact ca un computer care face paging din RAM pe un hard disk atunci când memoria se umple. Spațiul de lucru activ este menținut curat, în timp ce datele bulk sunt mutate în siguranță din cale. Acest mecanism funcționează în două faze distincte. Prima fază gestionează acele data spikes imediate și masive de la tools externe. Framework-ul urmărește token count-ul pentru fiecare tool input și tool result în parte. Pragul strict pentru această verificare este de douăzeci de mii de tokeni. Dacă o operațiune depășește această limită, sistemul interceptează payload-ul înainte să ajungă vreodată la language model. Gândește-te la un agent care execută un query ce extrage un database dump masiv, de treizeci de mii de tokeni. Un agent standard încearcă să insereze tot acel payload direct în istoricul conversației, ceea ce declanșează imediat un token overflow. Deep Agents alege o rută diferită. Interceptează acel răspuns masiv, face offload la textul complet într-un fișier nou pe filesystem-ul din backend și înlocuiește payload-ul din conversație cu un simplu preview de zece linii. Agentul citește preview-ul și primește un file path care indică spre datele complete. Agentul știe exact ce a găsit, dar promptul activ rămâne complet neîncărcat. Asta rezolvă acele data spikes bruște. A doua fază gestionează acumularea lentă dintr-o conversație standard. Pe măsură ce un agent rulează un proces lung, multi-step, istoricul continuu de tip back-and-forth consumă încet tokenii disponibili. Deep Agents monitorizează utilizarea totală a context window-ului în raport cu limitele modelului. Când promptul activ atinge optzeci și cinci la sută din totalul context window-ului disponibil, un proces de sumarizare în background se declanșează automat. Sistemul ia cel mai vechi bloc de mesaje din istoricul curent și folosește un language model pentru a genera un rezumat dens și factual al acelor evenimente. Apoi înlocuiește acel bloc mai vechi de mesaje din promptul activ cu rezumatul nou generat, scăzând instantaneu token count-ul înapoi la un nivel de lucru sigur. Iată ideea cheie. Developerii presupun adesea că sumarizarea conversației distruge definitiv istoricul original. Asta nu este adevărat. Înainte să aibă loc orice sumarizare, mesajele originale sunt scrise pe filesystem ca o înregistrare permanentă, canonică. Datele brute nu se pierd. Dacă agentul determină ulterior că are nevoie de un detaliu foarte specific dintr-un pas anterior, care nu a ajuns în rezumat, poate folosi tool-urile sale de search pentru a face un query pe acel filesystem și a recupera exact textul original. Prin combinarea offload-urilor imediate pe filesystem pentru tool results masive, cu sumarizarea dinamică pentru istoricuri lungi, un agent poate funcționa la nesfârșit fără să se sufoce în propriul context. Mulțumesc că m-ați ascultat, happy coding tuturor!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 6 din 16. Dacă agentul tău principal de AI citește zece pagini web pentru a răspunde la o singură întrebare, în cele din urmă va uita care a fost prompt-ul inițial. Tot acel zgomot intermediar acoperă instrucțiunile. Soluția pentru asta este Context Isolation cu subagenți sincroni. Gândește-te la asta ca la un pattern de clean architecture pentru modelele tale de limbaj. Când un singur agent are acces la zeci de tools și rulează prin loops iterative lungi, context window-ul său se umple rapid cu date brute, mesaje de eroare și tool outputs. Acest context bloat degradează capacitatea modelului de a raționa. În loc ca un agent masiv să încerce să facă totul, ai nevoie de un supervizor. Agentul principal acționează ca un manager. Deleagă munca dezordonată, care consumă mulți tokens, către specialiști și primește doar un raport final curat și formatat. Oamenii confundă adesea subagenții cu un chat room multi-agent continuu, unde diferite modele stau și dezbat idei între ele. Nu este cazul aici. Subagenții sincroni sunt strict efemeri. Sunt instanțiați pentru a executa un anumit job, rulează complet autonom în propriul lor spațiu de memorie izolat până când jobul este gata și returnează un singur rezultat final supervizorului. Odată ce predau acel rezultat, dispar. Ia în considerare un scenariu specific. Agentul tău principal are sarcina de a scrie un market briefing și are nevoie de date despre tendințele economice recente. În loc ca supervizorul să invoce direct un tool de web search de cinci ori și să-și polueze propriul context window cu text brut de pe website-uri, el deleagă problema. Pornește un subagent de tip researcher. Acest researcher efemer intră în propriul său loop izolat. Efectuează cele cinci căutări pe Google, citește rezultatele dezordonate, sintetizează concluziile și scrie un singur paragraf de rezumat. Transmite doar acel paragraf înapoi supervizorului. Supervizorul primește exact ceea ce are nevoie, iar contextul său rămâne intact. Pentru a configura asta, îți definești specialiștii folosind dicționare simple. Le pasezi parametrului subagents atunci când îți construiești agentul principal. Fiecare dicționar este o specificație a subagentului care necesită patru informații. În primul rând, îi dai un nume, cum ar fi researcher sau calculator. În al doilea rând, oferi o descriere. Asta este partea care contează. Supervizorul citește această descriere pentru a decide ce specialist să angajeze pentru o anumită problemă. În al treilea rând, oferi tools-urile, dându-i acestui subagent specific acces izolat la lucruri precum un web scraper sau un database client. În cele din urmă, oferi un system prompt, care guvernează modul în care se comportă subagentul. Odată ce îi pasezi această listă de configurări agentului principal, acesta obține automat acces la un built-in tool numit task. Supervizorul nu trebuie să știe cum să instanțieze subagenții. Când întâlnește o problemă care se potrivește cu descrierea unui specialist, apelează pur și simplu tool-ul task. Pasează două argumente: numele subagentului pe care să-l folosească și o instrucțiune plain text despre ceea ce trebuie făcut. Execuția supervizorului se pune pe pauză. Subagentul pornește, lucrează cu tools-urile sale și, în cele din urmă, termină. Pentru supervizor, tool-ul task returnează pur și simplu răspunsul text final ca și cum ar fi un function call standard. Chiar dacă nu definești explicit niciun dicționar, framework-ul îți oferă un fallback. Există un subagent default de uz general, built-in. Agentul principal poate folosi acest specialist default pentru a face offload la pași complecși de raționament. Acesta acționează ca o pagină goală, oferind modelului un context window proaspăt pentru a rezolva un puzzle logic dens, fără a polua memoria supervizorului. Iată ideea cheie. Prin impunerea unor limite stricte între task-urile izolate, împiedici munca intermediară de tip scratchpad să degradeze calitatea raționamentului din fluxul principal al aplicației tale. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 7 din 16. Să lași un sistem autonom să ruleze orbește query-uri SQL este o modalitate excelentă de a da drop accidental la o bază de date de producție. Dacă vrei ca agentul tău să funcționeze în lumea reală, ai nevoie de un mecanism care să-l intercepteze înainte să facă ceva distructiv. Aici intervin intervențiile Human-in-the-Loop. Ideea de bază e simplă. Pui agentul pe pauză fix înainte să execute o operațiune sensibilă, ceri instrucțiuni de la un om, și apoi dai resume la execuție pe baza acelui feedback. Înainte să ne uităm la mecanică, există o capcană comună pe care trebuie să o eviți. LangGraph are nevoie de memorie pentru a pune pe pauză și a da resume la state. Dacă încerci să configurezi o intervenție human-in-the-loop fără să setezi un checkpointer, intervenția va eșua. Sistemul are nevoie de un persistence layer, cum ar fi un memory saver, ca să înghețe execution graph-ul și să stocheze variabilele curente în timp ce așteaptă ca un om să răspundă. Atașează mereu un checkpointer mai întâi. Nu toate tool-urile au nevoie de human review. Să verifici vremea sau să citești un log file este în general sigur. Ștergerea fișierelor sau modificarea înregistrărilor din baza de date necesită un control strict. Gestionezi această clasificare a riscului folosind parametrul de configurare interrupt on. Când îți inițializezi agentul sau definești tool node-ul, pasezi o listă de nume de tool-uri acestui parametru. Dacă agentul încearcă să facă un tool call către un tool care nu e pe listă, rulează imediat. Dacă încearcă să apeleze un tool care este pe listă, execuția se pune pe pauză. Hai să trecem printr-un scenariu concret. Ai un agent cu un database tool numit execute. Adaugi execute la lista ta de interrupt on. Agentul decide că trebuie să curețe niște date vechi și încearcă să ruleze o comandă drop pe baza de date. Sistemul interceptează call-ul și pune pe pauză execution graph-ul. Când rulezi agentul, monitorizezi result object-ul returnat de framework. Mai exact, verifici o proprietate numită interrupts. Dacă lista interrupts din rezultat conține date, agentul a lovit un safety gate și așteaptă input-ul tău. În acest punct, operatorul uman evaluează acțiunea în așteptare. Ai trei decizii permise pe care le poți pasa înapoi agentului. Acestea sunt approve, reject sau edit. Dacă dai approve, agentul execută tool-ul cu argumentele originale. Dacă dai reject, tool call-ul eșuează gracefully, iar agentul primește un mesaj de eroare care îi dă prompt să încerce o abordare diferită. Aici devine interesant. Decizia de edit îți permite să modifici acțiunea intenționată a agentului înainte să se întâmple. În scenariul nostru cu baza de date, agentul încearcă o comandă drop periculoasă. Poți intercepta acel request, poți rescrie argumentele tool-ului ca să rulezi un query select sigur în schimb, și poți trimite acel payload modificat înapoi către sistem. Ca să scoți agentul de pe pauză, îl invoci din nou, dar de data asta pasezi un command object folosind parametrul resume. În interiorul acelui parametru resume, oferi string-ul tău de decizie împreună cu orice argumente modificate. Checkpointer-ul preia state-ul înghețat, injectează decizia ta umană direct în graph ca și cum agentul ar fi planificat-o inițial în acest fel, iar execuția continuă. Cel mai important lucru de reținut e că intervențiile human-in-the-loop îți oferă mai mult decât un simplu buton de emergency stop. Abilitatea de a da edit la argumentele tool-ului mid-flight îți permite să ghidezi în siguranță un agent prin workflow-uri complexe, fără să o iei de la capăt. Dacă vrei să ajuți la susținerea emisiunii, caută DevStoriesEU pe Patreon. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și keep building!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 8 din 16. S-ar putea să te uiți la un agent care citește un fișier local și să presupui că acea capabilitate este hardcoded adânc în core execution loop. Nu este așa. Magia din spatele sistemului de fișiere al unui agent este susținută în întregime de un middleware composable pe care îl poți extinde chiar tu. Astăzi vorbim despre extinderea acestui harness cu middleware. Deep Agents nu este o cutie neagră. Harness-ul care controlează execution pipeline-ul este extrem de extensibil. Când echipezi un agent cu un sistem de fișiere sau un todo list, pur și simplu atașezi un middleware pre-packaged la acel harness. Middleware-ul stă exact la granița dintre momentul în care agentul decide să invoce un tool și execuția efectivă a acelui tool. Este un interceptor. Îți oferă control absolut asupra a ceea ce intră, a ceea ce iese și a ceea ce se înregistrează în timpul schimbului. Pentru a scrie propriul tău middleware custom, creezi o funcție interceptor și aplici un decorator specific numit wrap tool call. Acest decorator îți înregistrează funcția în harness. Când agentul declanșează un tool, harness-ul pune pe pauză flow-ul default și predă controlul funcției tale wrapped. În interiorul acestui interceptor, primești argumentele de input raw generate de agent, o referință către tool-ul apelat și graph state-ul curent. Execuți manual tool-ul original din interiorul funcției tale, îi capturezi output-ul, iar apoi returnezi acel output înapoi către harness. Gândește-te la un middleware custom construit pentru a monitoriza un API extern. Vrei să interceptezi fiecare tool call către API, să loghezi argumentele exacte folosite de agent și să urmărești metricile de utilizare pentru a evita rate limit-urile. Funcția ta wrap tool call prinde request-ul înainte să ajungă în rețea. Extrage payload-ul, îl scrie în log-urile aplicației tale, și apoi execută request-ul API propriu-zis. Odată ce request-ul se termină, middleware-ul primește datele de răspuns. Acum trebuie să înregistreze faptul că a fost făcut un apel. Fii atent la partea asta. Când urmăresc metricile de utilizare, developerii încearcă adesea să folosească variabile standard de instanță ale clasei. Pur și simplu scriu ceva de genul self dot api call count plus equals one. Asta este o greșeală fatală. Deep Agents execută în mod curent tool-uri și subagenți în paralel. Dacă mai multe tool-uri se rezolvă în același moment și încearcă să modifice direct aceeași proprietate a instanței, vei provoca race conditions. Contoarele tale se vor suprascrie reciproc, update-urile se vor pierde, iar metricile tale vor fi complet greșite. Pentru a gestiona datele în siguranță, trebuie să actualizezi în schimb graph state-ul. Graph state-ul este conceput explicit pentru a gestiona execuția paralelă. În loc să modifice o variabilă locală, middleware-ul tău citește metrica curentă din graph state, calculează noua valoare și face yield la un obiect de state actualizat alături de rezultatul tool-ului. Execution harness-ul preia controlul de acolo. Procesează toate state update-urile primite din execuțiile paralele ale tool-urilor și le face merge curat, fără coliziuni. Prin rutarea tuturor side effect-urilor și a urmăririi metricilor prin graph state, middleware-ul tău rămâne complet thread-safe. Înțelegerea acestui pattern deblochează întregul framework. Încetezi să mai tratezi agentul ca pe un sistem închis și începi să îl privești ca pe un pipeline transparent, unde fiecare acțiune poate fi interceptată și măsurată în siguranță. Asta e tot pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 9 din 16. Să ai un AI coding assistant este super, până când trebuie să-i reamintești pentru a cincizecea oară că proiectul tău necesită strict typing și variabile snake case. Soluția o reprezintă Project Conventions prin memory files. Ergonomia de developer cere ca tool-urile tale să se adapteze la codebase-ul tău, nu invers. Nu ar trebui să fii nevoit să dai paste la un style guide în fiecare prompt. Deep Agents rezolvă asta oferindu-i agentului memorie persistentă printr-un fișier specific numit AGENTS dot md. Oamenii confundă uneori memoria cu skills-urile. Memoria îți oferă un baseline universal. Este mereu încărcată la startup, ceea ce o face perfectă pentru convenții globale și reguli de arhitectură. Skills-urile sunt tool-uri funcționale pe care agentul le încarcă dinamic doar atunci când un task specific le cere. Astăzi, ne uităm strict la memorie. Când inițializezi un agent și îi pasezi parametrul memory, framework-ul injectează automat conținutul fișierului AGENTS dot md direct în agent context, înainte ca acesta să facă vreo treabă. Această operațiune se bazează pe protocolul memory-first, care dictează trei faze distincte pentru agent: Research, Response și Learning. În faza de Research, agentul citește memory file-ul pentru a înțelege environment-ul. În faza de Response, generează codul sau răspunde la prompt. Apoi urmează faza de Learning. Iată ideea cheie. Nu trebuie să scrii manual fișierul AGENTS dot md. Agentul actualizează acest fișier în mod autonom, pe baza feedback-ului tău. Ia un scenariu concret. Îi ceri agentului să genereze un nou API endpoint. El scrie cod funcțional, dar formatează variabilele în CamelCase. Respingi pull request-ul și îi răspunzi că acest proiect folosește strict snake case. Agentul corectează codul, dar nu se oprește aici. Intră în faza de Learning, deschide fișierul local AGENTS dot md și adaugă o nouă regulă care cere snake case pentru toate variabilele viitoare. Data viitoare când ceri un endpoint, agentul citește acel memory file în timpul fazei de Research și scrie nativ snake case încă de la început. Acest sistem de memorie persistentă funcționează pe două scope-uri diferite. Primul este global scope. Acest fișier se află în home directory-ul tău, într-un folder dot deepagents. Îl folosești pentru preferințele tale personale de developer. Dacă preferi mereu Python asincron în loc de cod sincron în toate proiectele tale, agentul învață asta aici. Al doilea este project scope. Acest fișier se află direct în folderul repository-ului tău local. Aici intră regulile specifice repository-ului. Când un agent rulează, acesta încarcă ambele fișiere. Aplică mai întâi preferințele tale globale, apoi suprapune convențiile specifice proiectului. Pentru că memory file-ul cu project scope se află în repository-ul tău, îi dai commit în version control. Când un nou developer se alătură echipei și rulează agentul, instanța sa locală moștenește instantaneu toate deciziile de stil pe care agentul le-a învățat deja. Fiecare greșeală corectată îmbunătățește permanent înțelegerea agentului asupra repository-ului tău, transformându-l dintr-un code generator generic într-un maintainer extrem de contextualizat. Cam atât pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 10 din 16. Dacă arunci cincizeci de ghiduri diferite de documentație API în system prompt-ul tău, agentul tău nu va deveni mai inteligent. Va fi doar distras și va da greș la task-uri de bază. Ai nevoie de o metodă prin care să-i oferi unui agent expertiză profundă fără să dai peste cap context window-ul. Progressive Disclosure cu Skills rezolvă exact această problemă. Un skill în Deep Agents acționează ca un upgrade modular de creier. Îți permite să împachetezi logică complexă, cum ar fi reguli de deploy AWS sau workflow-uri custom de data science, într-un directory izolat. Ca să construiești unul, pur și simplu creezi un folder nou, îi dai numele skill-ului tău și pui în el un fișier numit exact skill dot md. O concepție greșită comună este că framework-ul pur și simplu face append la tot conținutul acestui fișier în system prompt. Nu face asta. Dacă ar face asta, ne-am întoarce direct la problema unui context window supraîncărcat, degradând performanța și crescând costurile. În schimb, framework-ul se bazează pe un pattern numit progressive disclosure, care are loc în trei pași: Match, Read și Execute. Chiar în partea de sus a fișierului tău skill dot md, scrii un bloc de frontmatter. Acesta este formatat ca un YAML de bază și conține doar un nume și o scurtă descriere. Aici e ideea cheie. Framework-ul încarcă doar acea scurtă descriere în system prompt-ul inițial. Agentul citește descrierea și decide dacă face match cu request-ul curent al utilizatorului. Aceasta este faza de Match. Dacă agentul decide că skill-ul este relevant, nu ghicește ce să facă mai departe. Folosește activ un tool intern pentru a face fetch la restul fișierului skill dot md. Aceasta este faza de Read. Acum, agentul are instrucțiunile complete și detaliate încărcate temporar în memoria sa de lucru pentru acest turn specific. În cele din urmă, trece la faza de Execute, unde urmează acele instrucțiuni detaliate pentru a finaliza task-ul. Când conversația trece la un alt subiect, acel payload greu este eliminat, iar agentul revine la starea sa de baseline. Ia în considerare un scenariu în care vrei să construiești un skill numit langgraph-docs. Frontmatter-ul din skill dot md are o descriere care precizează că acest skill oferă instrucțiuni și URL-uri interne pentru căutarea în documentația LangGraph. Corpul fișierului conține acele URL-uri interne reale și metodologia specifică de search. Când un utilizator întreabă ce este LangGraph, agentul își verifică skill-urile active. Vede descrierea scurtă, își dă seama că are nevoie de mai multe informații pentru a răspunde la întrebare și cere documentul complet. Citește URL-urile, face search-ul și formulează un răspuns precis. Fără progressive disclosure, ar trebui să dai paste la toate acele URL-uri în prompt-ul principal pentru absolut fiecare conversație. Când construiești o librărie de skill-uri, s-ar putea să te lovești de conflicte în care două skill-uri încearcă să definească instrucțiuni pentru task-uri similare. Deep Agents rezolvă asta folosind source precedence. Regula e simplă: ultimul câștigă. Orice skill care este încărcat ultimul va face override la instrucțiunile conflictuale din cele anterioare. Asta îți permite să pui primele skill-urile generale, generice, și apoi să adaugi override-uri foarte specifice mai târziu în configurația ta. Execuția întregului tău workflow agentic depinde de cât de bine scrii acel frontmatter. Păstrează-ți descrierile precise și corpurile skill-urilor foarte detaliate, pentru că agentul va citi fișierul complet doar dacă îl convingi mai întâi din descriere. Asta e tot pentru acest episod. Mulțumesc pentru ascultare și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 11 din 16. Un asistent inteligent nu ar trebui să te întrebe ce bază de date folosești de fiecare dată când începi o conversație nouă. Totuși, out of the box, majoritatea agenților suferă de amnezie totală în momentul în care un thread se termină. Pentru a rezolva asta, ai nevoie de Long-term Memory Stores. Când rulezi un agent, acesta generează fișiere. Ascultătorii presupun adesea că, dacă un agent scrie un fișier, acesta rămâne pentru totdeauna. Nu e așa. By default, totul este efemer. Deep Agents folosesc un StateBackend, care stochează fișierele în state-ul thread-ului curent de conversație. Când acel thread se încheie, fișierele respective dispar. Dacă vrei o personalizare reală, în care agentul construiește o bază de date permanentă cu preferințele userului și cunoștințele despre proiect, ai nevoie de o abordare diferită. Ai nevoie de StoreBackend. Acesta se conectează direct la un LangGraph Store persistent, păstrând datele în siguranță pe parcursul mai multor thread-uri. Dar nu vrei să persiști absolut fiecare fișier temporar pe care îl creează agentul tău. Ai nevoie de un mecanism care să separe munca efemeră de tip scratchpad de memoriile durabile. Aici intervine CompositeBackend. Gândește-te la el ca la un router de trafic pentru file system-ul agentului tău. Configurezi CompositeBackend cu un fallback default, de obicei StateBackend-ul efemer. Apoi, înregistrezi explicit o rută pentru stocarea pe termen lung. Îi spui routerului că orice file path care începe cu prefixul de director slash memories slash trebuie să fie gestionat de StoreBackend. Fii atent la partea asta. Această persistență nu este automată. Trebuie să rutezi specific path-ul slash memories slash către Store. Dacă sari peste acest pas de rutare, agentul va scrie pur și simplu fișierele de memorie în state-ul efemer, iar ele vor fi șterse când se termină thread-ul. Odată ce introduci o bază de date persistentă, te confrunți cu o nouă problemă. Nu poți lăsa un user să citească preferințele stocate ale altui user. Pentru a preveni asta, StoreBackend folosește namespace factories. Un namespace factory este pur și simplu o funcție care injectează un layer de izolare bazat pe contextul curent. În loc să salveze un fișier global, factory-ul generează un array de prefixe, cum ar fi cuvântul users urmat de ID-ul unic al userului. De fiecare dată când agentul interacționează cu StoreBackend, baza de date face automat scope operațiunii la acel namespace exact al userului. Hai să vedem cum funcționează asta în practică. Începi conversația unu. Menționezi că construiești o aplicație React. Agentul notează asta și scrie un rezumat într-un fișier numit project notes dot txt, plasându-l specific în directorul slash memories slash. CompositeBackend vede acel prefix de director, interceptează comanda de scriere și o rutează către StoreBackend-ul durabil, sub namespace-ul tău izolat de user. Mâine, începi conversația doi. Acesta este un thread complet nou, cu zero context imediat. Pui o întrebare despre framework-urile de state management. Înainte să răspundă, agentul își verifică directorul slash memories slash. CompositeBackend rutează request-ul de citire către store-ul persistent. Agentul citește notițele tale de proiect, vede detaliile despre React și oferă un răspuns extrem de relevant, adaptat stack-ului tău specific. Contextul se transferă perfect, chiar dacă thread-urile sunt separate. Persistența cross-thread necesită un design deliberat, prin rutarea unor directoare specifice către un store persistent și protejarea lor cu namespace-uri specifice userului. Mulțumesc că ai petrecut câteva minute cu mine. Până data viitoare, numai bine.

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 12 din 16. Să lași un AI să scrie cod este impresionant. Să lași acel AI să ruleze orbește codul pe care tocmai l-a scris direct pe laptopul tău este o idee groaznică. Pentru a remedia acest lucru, ai nevoie de un loc sigur în care agentul să își verifice logica fără a risca mașina ta host. Exact despre asta discutăm astăzi, Executarea codului în sandbox-uri. Dacă un agent nu poate executa cod, nu poate verifica dacă acesta chiar funcționează. Se bazează exclusiv pe datele de training pentru a ghici dacă un script este corect. Sandbox-urile oferă agentului un playground sigur pentru a itera, a eșua și a repara erorile pe baza output-ului real de execuție. Înainte de a analiza mecanismele, trebuie să clarificăm o concepție greșită des întâlnită. Ai putea presupune că agentul în sine trebuie deployat și rulat în interiorul sandbox-ului. Nu este cazul. Deep Agents se bazează pe pattern-ul Sandbox as tool. Logica, memoria și prompt-urile agentului trăiesc în siguranță pe serverul tău. Agentul pur și simplu trimite comenzi shell și cod printr-un API către un mediu remote, izolat. Această interacțiune are loc prin intermediul tool-ului execute. Când agentul decide că trebuie să ruleze un script, apelează tool-ul execute și îi pasează blocul de cod generat. Acest tool trimite payload-ul către un sandbox backend. Provideri precum Modal, Daytona și Runloop oferă aceste medii. Ei fac provision pentru un container securizat, rulează codul și returnează standard output-ul sau error log-urile înapoi către agent. Sandbox-ul creează o graniță strictă de izolare între spațiul de execuție și sistemul tău. Gândește-te la un agent desemnat să creeze un mic pachet Python și să ruleze un test suite folosind pytest. Agentul stă pe serverul tău. Folosește tool-ul execute pentru a contacta un server efemer remote. Mai întâi, trimite o comandă pentru a instala librăriile necesare. Apoi, scrie fișierele Python în directorul sandbox-ului. În cele din urmă, trimite o comandă pentru a rula pytest. Sandbox-ul execută acești pași și returnează output-ul din terminal. Dacă un test pică, agentul citește eroarea din răspunsul API-ului, actualizează codul și apelează din nou tool-ul execute. Agentul poate să facă build, să testeze și să șteargă totul, în timp ce mașina ta host rămâne complet neatinsă. Când configurezi un sandbox backend, trebuie să îi definești lifecycle-ul. Există două abordări principale. Prima este thread-scoped. Aici, sandbox-ul este legat de un thread de conversație specific. Când începe conversația, un sandbox nou face spin up. Când sesiunea utilizatorului se termină, sandbox-ul este distrus. Acest lucru asigură un clean slate pentru fiecare interacțiune și este ideal pentru operațiuni single-task în care datele nu trebuie să persiste. A doua abordare este assistant-scoped. În acest model, sandbox-ul este legat de agentul în sine, indiferent de conversația activă. Fiecare thread care interacționează cu acel agent partajează exact același sandbox state. Dacă un thread instalează o versiune specifică a unei librării sau descarcă un dataset mare, acele fișiere rămân disponibile pentru următorul thread. Aceasta este alegerea potrivită atunci când agentul tău acționează ca un persistent worker care necesită un workspace stabil și continuu. Iată ideea cheie. Mediul de execuție dictează capacitatea agentului. Prin controlul lifecycle-ului sandbox-ului și impunerea unor granițe stricte de API, îi oferi agentului libertatea de a face greșeli fără a-ți compromite infrastructura. Adevărata putere a unui agent nu constă doar în generarea de cod, ci și în iterarea în caz de eșec, iar sandbox-urile remote oferă singura modalitate sigură de a lăsa această iterație să se întâmple automat. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 13 din 16. Lansezi un query complex, agentul tău supervizor delegă către trei subagenți paraleli, iar utilizatorul tău stă și se uită la un loading spinner generic două minute în șir. Asta înseamnă un user experience groaznic și, ca să îl repari, trebuie să expui exact ce se întâmplă sub capotă. Răspunsul este Subgraph Streaming UX. Workflow-urile multi-agent sunt în mod inerent asincrone și lente. Când un agent principal delegă task-uri, creează un black box. Dacă aștepți doar rezultatul final combinat, utilizatorul presupune că aplicația s-a blocat. Trebuie să faci stream la activitatea subagentului direct către frontend. O greșeală frecventă pe care o fac developerii aici este să presupună că atunci când subagenții fac stream la tokeni, acei tokeni sunt pur și simplu adăugați orbește la output stream-ul agentului principal. Dacă asta ar fi adevărat, output-urile paralele s-ar intercala într-o harababură de text. În schimb, framework-ul gestionează asta izolând fiecare eveniment în propriul său namespace. Ca să faci asta să funcționeze, folosești formatul de streaming versiunea doi și pasezi un flag care setează subgraphs la true atunci când apelezi stream-ul. Când faci asta, stream-ul nu mai generează chunk-uri raw de text. Generează dicționare. Fiecare dicționar conține trei chei specifice: type, ns și data. Type îți spune la ce fel de eveniment te uiți. Data conține payload-ul propriu-zis sau token-ul de text. Iar ns vine de la namespace. Asta e partea care contează. Namespace-ul este un tuple care definește calea exactă a node-ului care a generat evenimentul. Dacă un chunk provine de la agentul principal, tuple-ul de namespace este gol. Dacă provine de la un subagent, namespace-ul conține calea. Arată ca un tuple care conține cuvântul tools urmat de un ID unic de subagent. Să zicem că construiești un dashboard de frontend. Un utilizator cere sistemului să planifice o vacanță. Agentul supervizor pornește trei subagenți separați: unul pentru zboruri, unul pentru hoteluri și unul pentru activități. În codul tău de frontend, iterezi prin stream-ul care vine. Verificând cheia namespace pe fiecare chunk de tip dicționar, știi exact ce subagent a generat acel token specific. Apoi poți ruta acele date către componente UI separate. În loc de un singur spinner blocat, utilizatorul tău vede trei loading bar-uri individuale sau ferestre de text care se umplu cu output-uri în timp real, una lângă alta. Uneori trebuie să faci stream la informații care nu sunt doar un token de language model. Poate vrei să faci push la un status update custom, cum ar fi să notifici UI-ul că este apelat un API extern. Poți face asta din interiorul unui node folosind funcția get stream writer. Preiei writer-ul, îi pasezi dicționarul tău custom, iar el injectează acele date direct în stream-ul general sub namespace-ul curent al subagentului. Frontend-ul îl primește exact ca pe orice alt eveniment și actualizează loading bar-ul specific corect. Dacă vrei să ajuți la continuarea emisiunii, ne poți sprijini căutând DevStoriesEU pe Patreon. Transparența multi-agent este fundamental o problemă de rutare; maparea tuple-urilor de namespace la componente UI independente este ceea ce transformă un black box frustrant într-un user experience premium. Asta e tot pentru acest episod. Mulțumesc că m-ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 14 din 16. Ce-ar fi dacă ai putea conecta agentul tău local din terminal la baza de date proprietară a companiei tale fără să scrii o singură linie de cod Python? Exact această capacitate este motivul pentru care discutăm despre Deep Agents CLI și tools-urile MCP externe. Deep Agents SDK oferă un command line interface built-in, gata de utilizare. Pornești procesul și primești un prompt în terminal unde poți discuta cu agentul tău. Poți gestiona creierul central al agentului direct din acest prompt. Dacă ai nevoie de un reasoning engine mai capabil, trebuie doar să tastezi slash model urmat de noul identificator de model. CLI-ul face hot-swap la provider instant, și îți continui sesiunea. Dar un agent în terminal care doar discută nu este foarte util. Are nevoie de acces la munca ta reală. În mod normal, ca să-i dai unui agent acces la un repository GitHub sau la o bază de date locală, trebuie să scrii cod de wrapper Python custom pentru a gestiona acele API calls. CLI-ul evită complet acest lucru folosind Model Context Protocol, cunoscut pe larg sub numele de MCP. Există adesea confuzie legată de ce este, de fapt, MCP. Nu este un library Python pe care îl imporți în codul agentului tău. Un server MCP este un proces complet separat sau un remote URL. Acționează ca un wrapper standardizat în jurul unui sistem extern. Când CLI-ul pornește, comunică cu acest proces separat, întrebând ce tools oferă, și le încarcă dinamic. Configurezi această conexiune folosind un simplu fișier text numit dot mcp dot json. Acest fișier este nucleul integrărilor zero-code. Când lansezi Deep Agents CLI, acesta face auto-discovery. Caută în directorul tău curent această configurare json. Dacă găsește una, se conectează la serverele listate înăuntru, le înregistrează tools-urile și le predă agentului tău. Acest fișier de configurare acceptă două mecanisme de transport. Primul este standard input și output, sau stdio. Acesta este pentru serverele locale. CLI-ul pornește serverul ca un background process pe mașina ta și comunică cu el prin standard terminal streams. Al doilea tip de transport se bazează pe HTTP și Server-Sent Events. Folosești asta atunci când serverul tău MCP este găzduit remote, probabil aflat într-o rețea privată de companie. Deoarece serverele stdio rulează comenzi locale, securitatea este o prioritate. CLI-ul menține un trust store local pentru serverele la nivel de proiect. Prima dată când CLI-ul detectează o nouă comandă de server local în fișierul tău dot mcp dot json, se oprește și îți cere permisiunea explicită. După ce o aprobi, hash-ul acelei comenzi este salvat în trust store-ul tău, iar rulările viitoare se conectează automat. Hai să ne uităm la un scenariu specific. Vrei ca agentul tău să citească fișiere de pe discul tău local. Creezi un fișier dot mcp dot json. Înăuntru, definești un server block și îl numești local-filesystem. Setezi tipul de transport la stdio. Pentru command line, îi spui să ruleze tool-ul node package manager, npx, pointându-l către un community server pre-built numit server-filesystem, împreună cu calea directorului pe care vrei să o expui. Salvezi fișierul și lansezi Deep Agents CLI. Aici este partea esențială. CLI-ul face automat spawn la acea comandă npx în background. Serverul de filesystem face boot și dă broadcast că are tools pentru citirea fișierelor și listarea directoarelor. CLI-ul prinde acel broadcast și îți echipează agentul. Poți tasta imediat în terminal, cerându-i agentului să citească fișierul tău de system log. Agentul înțelege că are tool-ul, apelează background process-ul, preia conținutul fișierului și îți răspunde la întrebare. Tocmai i-ai oferit unui sistem AI acces securizat la discul tău local folosind câteva linii de text de configurare. Prin decuplarea logicii de tool de aplicația ta Python, MCP îți transformă terminalul dintr-o interfață de chat de bază într-un control center extensibil. Asta e tot pentru acest episod. Ne auzim data viitoare!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 15 din 16. De ce să te mulțumești cu un asistent de programare generic când poți injecta propriul tău agent LangGraph puternic personalizat direct în editorul tău de cod? Protocolul care îți scoate agentul personalizat din terminal și îl aduce în fluxul tău zilnic de lucru este Editor Integrations via ACP. Înainte să mergem mai departe, trebuie să clarificăm o coliziune de acronime. Probabil ai auzit de MCP, sau Model Context Protocol. MCP îți conectează agentul la tools externe, permițându-i să caute într-o bază de date sau să citească un file system. ACP, adică Agent Client Protocol, este complet diferit. ACP îți conectează agentul la IDE-uri externe, cum ar fi Zed sau VSCode. Unul conectează agentul la date externe, celălalt conectează agentul la workspace-ul tău. ACP este un layer de comunicare standardizat. Acesta definește exact cum un Integrated Development Environment trimite text selections, structuri de fișiere și user prompts către un agent AI. De asemenea, dictează cum acel agent trimite înapoi code insertions, file diffs și chat responses. Implementând acest protocol, agentul tău deep personalizat se comportă exact ca un asistent standard direct în editorul tău. Diferența este că are toate structurile specifice de memorie, custom prompt templates și internal tools specializate pe care i le-ai adăugat. Pentru a face această legătură, instalezi pachetul deepagents-acp. Integrarea necesită un script Python foarte scurt care să acționeze ca entry point. În acest script, îți instanțiezi agentul deep preconfigurat. Apoi, în loc să pornești un web server sau un command-line loop, îi faci wrap agentului tău într-o interfață de server ACP. Realizezi asta apelând o funcție run dedicată și pasând un obiect AgentServerACP, care la rândul lui face wrap la logica agentului tău. Iată ideea cheie. Când configurezi acest server, îl setezi să folosească standard input și output, cunoscute în general ca modul stdio. Asta este crucial, deoarece înseamnă că nu ai network ports de gestionat, reguli de firewall de ocolit și web sockets de făcut debug. Procesul agentului pur și simplu ascultă după text strings primite pe standard input și își printează răspunsurile structurate pe standard output. Apoi, trebuie să îți conectezi editorul la acest script. Ia ca exemplu concret editorul Zed. În Zed, deschizi fișierul tău JSON de user settings. Adaugi un configuration block care instruiește editorul să folosească un agent personalizat. În loc să direcționezi Zed către un REST API endpoint remote, îl direcționezi direct către executabilul tău Python local, oferind calea către noul tău script ACP ca argument principal. Când pornești o sesiune, editorul lansează scriptul tău Python ca un background process ascuns. De fiecare dată când ceri un inline edit sau selectezi o funcție pentru refactoring, editorul trimite un mesaj ACP structurat prin standard input direct către scriptul tău care rulează. Agentul tău personalizat procesează request-ul, traversează node graph-ul său intern, își interoghează memoria și printează răspunsul formatat ACP înapoi pe standard output. Editorul capturează acel output și aplică modificările de cod nativ în fereastra aplicației tale. Cea mai valoroasă idee de reținut aici este controlul. Rutând agentul tău personalizat prin ACP over stdio, nu te mai bazezi pe un asistent generic și începi să colaborezi cu o entitate care înțelege nativ convențiile specifice din codebase-ul tău. Asta e tot pentru acest episod. Îți mulțumesc că ai ascultat și continuă să construiești!

Salut, sunt Alex de la DEV STORIES DOT EU. Deep Agents, episodul 16 din 16. Îi ceri agentului tău un refactor masiv pe codebase, iar interfața de chat se blochează imediat. Rămâi blocat uitându-te la un spinner timp de douăzeci de minute, fără să poți pune întrebări sau să te răzgândești. Ca să rezolvi asta, ai nevoie de Background Workers cu Async Subagents. Subagenții standard sunt sincroni. Ei blochează main thread-ul. Supervisor-ul dă un task mai departe și pur și simplu așteaptă până se termină. Subagenții async schimbă complet dinamica asta, rulând ca background workers non-blocking. Când supervisor-ul asignează un task, nu așteaptă rezultatul. Primește imediat un job ID și returnează controlul user-ului. UI-ul rămâne responsive în timp ce heavy lifting-ul se întâmplă în altă parte. Configurezi acești background workers folosind specificația Async SubAgent. Când dai deploy la aplicație pe LangSmith Deployments, acești subagenți async sunt hostați independent. Supervisor-ul principal comunică cu ei prin transport protocols standard. Dacă dai deploy la worker pe exact același server cu supervisor-ul, ei comunică folosind ASGI, care este extrem de eficient pentru local routing. Dacă worker-ul stă pe un remote server separat, supervisor-ul se conectează la el prin HTTP. Ca să orchestreze acești remote workers, supervisor-ul este echipat cu o suită specifică de async tools. Adu-ți aminte de acel request de refactor pe codebase. User-ul cere rescrierea. Supervisor-ul decide că asta va lua mult timp și apelează tool-ul start async task. Acest tool pornește subagentul coder și îi dă supervisor-ului un job ID. Supervisor-ul îi răspunde user-ului, confirmând că background job-ul rulează. Pentru că main thread-ul este liber, user-ul poate continua conversația. Câteva minute mai târziu, user-ul ar putea întreba cum merge refactor-ul. Supervisor-ul apelează tool-ul check async task, pasând job ID-ul, și preia statusul curent de execuție de la worker. Aici e ideea principală. User-ul nu este blocat în afara procesului în timp ce worker-ul rulează. Dacă user-ul își dă seama brusc că are nevoie ca refactor-ul să impună strict type hinting, poate pur și simplu să-i spună supervisor-ului. Supervisor-ul apelează apoi tool-ul update async task. Asta trimite noi instrucțiuni de mid-flight steering direct către subagentul care rulează, fără să dea restart la job de la zero. Dacă user-ul decide că refactor-ul a fost o idee complet proastă, supervisor-ul folosește tool-ul cancel async task ca să închidă curat background process-ul. O confuzie comună e cum ține minte supervisor-ul aceste job-uri în timpul unei sesiuni lungi. În timp, chat history-ul este compactat pentru a salva context tokens. Dacă job ID-ul ar exista doar ca text în conversation history, supervisor-ul l-ar uita până la urmă și ar pierde urma worker-ului. Ca să prevină asta, task metadata nu este niciodată stocată doar în chat log. Este salvată într-un state channel dedicat, numit async tasks. Acest state channel funcționează independent de lista de mesaje, garantând că job ID-urile active supraviețuiesc oricărei compactări a conversației. Trecerea de la blocking calls la background workers îți schimbă arhitectura de la o simplă interfață de chat la un parallel orchestration engine capabil să gestioneze workloads masive. Pentru că asta încheie seria noastră curentă, te încurajez să citești documentația oficială, să încerci să dai deploy singur la un async worker, sau să vizitezi devstories dot eu ca să sugerezi subiecte pentru următoarea serie. Mersi că ai petrecut câteva minute cu mine. Până data viitoare, toate bune.