Arhitectura unui Agent AI Personal
O arhitectură de referință pentru a rula propriul agent AI mereu activ, pe infrastructură pe care o controlezi, extrasă din construirea uneia reale, nu doar din citit despre asta.
When to use
Folosește asta dacă vrei un agent care poate acționa pe infrastructură reală, CMS-ul tău, calendarul tău, repository-urile tale, nu doar o fereastră de chat care răspunde. Presupune confort în a rula un stack Docker mic și disponibilitatea de a începe restrâns și a extinde deliberat.
Pornește de la ce chiar ai nevoie, nu de la demo-ul unui framework
Înainte să scrii vreo infrastructură, numește singura sarcină care chiar îți consumă timp azi: publicat pe un CMS, gestionat calendar, deschis pull request-uri, răspuns la aceeași întrebare în trei locuri. Construiește întâi spre acea sarcină.
Framework-urile de agenți generaliste sunt utile de studiat, dar adoptarea unuia întreg înainte să-ți înțelegi propriul flux tinde să importe complexitate de care încă nu ai nevoie. O primă versiune mai restrânsă, făcută pe măsură, te învață mai mult despre ce chiar vrei decât un framework complet.
Stack-ul care chiar a rezistat
Un reverse proxy cu TLS automat în fața a tot, o rețea VPN doar pentru administrare ca nimic administrativ să nu fie expus pe internetul deschis, un datastore principal pentru stare, și o bază de cunoștințe partajată dacă mai mult de un dispozitiv sau persoană au nevoie de aceeași memorie.
Automatizarea de workflow-uri (ceva de genul n8n) gestionează sarcini programate și în mai mulți pași; un API central ușor gestionează direcționarea intenției și acțiunile reale. Observabilitatea (loguri plus câteva dashboard-uri) merită avută din prima zi, nu adăugată după primul eșec tăcut.
O singură interfață principală, o aplicație de mesagerie pe care operatorul o verifică deja constant, bate trei interfețe pe jumătate terminate. Adaugă o a doua interfață doar când prima e cu adevărat fiabilă.
Pragurile de încredere contează mai mult decât alegerea modelului
Direcționează modele ieftine și rapide către routing și clasificare simplă, și rezervă modelul mai capabil (și mai scump) pentru scris și decizii tehnice. Doar această împărțire controlează cea mai mare parte a costului de rulare.
Controlul mai important e un prag de încredere strict: sub o limită fixată, agentul întreabă înainte să acționeze, fără excepții. Asta nu e o instrucțiune în prompt, e o cale de cod, pentru că un model nesigur și un model sigur dar greșit produc exact același ton în răspuns. Nu le poți distinge citind răspunsul; poți prinde al doilea doar cerându-i să confirme înainte să acționeze.
Asta nu e singura formă validă
Un colaborator care rulează același stil de agent de pe un laptop personal, fără niciun server, sincronizând prin aceeași bază de cunoștințe partajată, e o configurație cu adevărat diferită, dar la fel de validă. Nu orice agent din acest stil are nevoie de propriul VPS; baza de cunoștințe partajată e cea care permite ca două desfășurări foarte diferite să rămână coordonate pe aceeași informație.
Potrivește infrastructura cu cât uptime și independență chiar ai nevoie, nu cu cel mai complet exemplu găsit online.
Sign-off checklist
- Alege o singură interfață principală înainte să construiești altceva
- Decide pragul de încredere și aplică-l în cod, nu doar în promptul de sistem
- Pune starea partajată într-un singur datastore durabil, nu împrăștiată prin istoricul de chat
- Calculează costul serviciilor mereu active înainte să te angajezi la o strategie de direcționare a modelelor
- Confirmă că asistentul chiar recunoaște orice produs sau unealtă existentă pe care o menționezi pe nume, înainte să înceapă să genereze arhitectură în jurul ei
Am nevoie de un VPS dedicat ca să rulez așa ceva?
Cum decizi ce model gestionează ce sarcină?
Dacă asistentul înțelege greșit o referință, așa cum e descris în articolul despre halucinația din vibe coding?
Map before you build
Workflow Mapping is how we start engagements where automation or custom software is on the table.