Conectarea AI la server: cum face un agent AI implementări și cum vă administrează serverul

Deocamdată, cei mai mulți oameni folosesc AI-ul ca pe un coleg foarte citit, aflat la celălalt capăt al firului: îi descriu o problemă de server, primesc o comandă sugerată, o copiază în consolă, copiază mesajul de eroare înapoi în chat și reiau jocul până când totul funcționează. De îndată ce conectați AI-ul la serverul dumneavoastră, acest ocol dispare. Un agent AI precum Claude Code, OpenAI Codex CLI sau Gemini CLI se autentifică singur pe server prin SSH, citește jurnalele, verifică configurația, aplică modificările, testează rezultatul și notează ce a făcut. Dumneavoastră stabiliți sarcina și aprobați pașii care nu mai pot fi anulați.

Acest articol este o relatare din practică. La KernelHost, un agent AI lucrează de luni de zile, zilnic, la propria noastră infrastructură: portalul de clienți, monitorizarea, fluxurile de plată, documentația. Arătăm cum este construită conexiunea dintre agent și server, după ce procedură face agentul implementări pe sistemele de producție, ce reguli împiedică erorile sau scurgerea de date în exterior și ce trebuie să ofere un server pentru ca totul să funcționeze. Bazele despre instrumente și arhitecturi se găsesc în articolul Server gestionat de AI: conectarea sigură a agenților AI, iar instalarea pe server, în ghidul pentru Claude Code și Codex CLI.

Conectarea AI la server: ce înseamnă

Conectarea AI la server înseamnă a-i oferi unui agent AI un acces propriu și controlat la linia de comandă a serverului, de obicei printr-o cheie SSH. Din acel moment, agentul poate nu doar să propună comenzi, ci și să le execute singur, să citească rezultatul și să deducă din el pasul următor. Modelul lingvistic propriu-zis rulează în continuare la furnizor (Anthropic, OpenAI sau Google), iar pe calculatorul sau serverul dumneavoastră rulează doar un instrument ușor de linie de comandă, care trimite comenzile.

Cuvântul decisiv este „controlat”. Un agent cu acces la server nu este un pilot automat, ci un colaborator foarte rapid, care întreabă înaintea fiecărei intervenții. Cât are voie să facă fără să întrebe stabiliți chiar dumneavoastră: de la simplul acces de citire până la aplicarea independentă a actualizărilor, după o procedură fixă.

Chatbot sau agent: diferența într-un tabel

Astfel, o jumătate de oră de du-te-vino devine adesea doar câteva minute, iar sursa de erori „tastat greșit” dispare complet.

Ce face un agent AI pe server: exemple din activitatea noastră

Exemplele de mai jos provin din activitatea noastră de zi cu zi. Omitem numele, adresele și datele de acces, dar procedurile sunt reale.

Implementări cu backup și cale de revenire

Când modificăm ceva în portalul de clienți sau într-un script de server, agentul se ocupă de aplicarea modificării. Mai întâi compară fișierul de pe server cu ultima versiune cunoscută, ca să nu suprascrie modificarea altcuiva. Apoi creează un backup datat în afara directorului web, scrie un script de revenire, verifică sintaxa fișierului nou, îl aplică cu aceiași proprietari și aceleași drepturi ca înainte, iar după aceea testează funcția afectată. Abia când totul este verde raportează că a terminat. Procedura exactă este descrisă mai jos, în secțiunea despre implementări.

Depanare: de la simptom la cauză în câteva minute

„Site-ul nu este accesibil din biroul nostru, dar din afara lui, da.” Altădată, asta ar fi însemnat o căutare mai lungă. Agentul verifică regulile firewallului, caută adresa biroului în jurnalele software-ului de protecție, găsește regula care a intrat în acțiune și explică ce cerere a declanșat-o. Decizia despre ce trebuie făcut rămâne la noi, munca de detectiv nu. La erorile tipice de server web, precum 502 Bad Gateway sau discurile pline, procedează la fel: citește jurnalele cu journalctl, precum și pe cele ale aplicației, formulează o ipoteză și o susține cu dovezi înainte de a modifica ceva.

Monitorizare construită chiar de agent

O mare parte din monitorizarea noastră a luat naștere în colaborare cu agentul: mici scripturi de verificare care, printr-un job cron, testează la fiecare câteva minute un serviciu de la un capăt la altul și, în caz de eroare, trimit un mesaj pe telefon, de exemplu printr-un bot Telegram. Agentul scrie scriptul, îl testează provocând intenționat o eroare, configurează jobul cron și documentează cum se pune alarma pe silențios. Cum construiți în principiu așa ceva descrie articolul Configurarea monitorizării serverului.

Rapoarte de ansamblu și curățenie

Ce servere mai rulează, deși contractul aferent a fost reziliat? Ce servicii suplimentare sunt plătite, dar nu mai sunt folosite? La astfel de întrebări agentul răspunde interogând bazele de date și interfețele doar în mod citire și prezentând rezultatul sub formă de tabel. Are voie să facă curățenie abia după aprobare, iar înainte de asta verifică dacă mașina este cu adevărat nefolosită, de exemplu după traficul de date din ultimele zile.

Documentație care crește de la sine

Fiecare modificare se încheie cu o intrare în registrul de modificări și, dacă este nevoie, cu o completare în manualul de operare. Pe agent asta îl costă câteva secunde, iar nouă ne economisește mai târziu ore întregi, pentru că întrebarea „De fapt, de ce este așa?” are un răspuns scris.

Avantajele atunci când AI-ul lucrează direct pe server

• Viteză: Agentul citește în câteva secunde ceea ce unui om îi ia minute și testează imediat o ipoteză, în loc să o descrie mai întâi.
• Temeinicie: Citește întreaga configurație, împreună cu fișierele incluse, precum și liniile din jurnal din jurul erorii, nu doar fragmentul pe care cineva l-a considerat relevant.
• Procedură constantă: Backupul, verificarea sintaxei și controlul final au loc de fiecare dată, și vineri seara, și la a douăzecea modificare mică.
• Documentație fără efort suplimentar: Fiecare modificare este descrisă, cu motivul, locul backupului și calea de revenire.
• Automatizare fără să învățați scripting: Scripturile de verificare, joburile cron și rapoartele iau naștere dintr-o descriere în limbaj obișnuit și sunt testate înainte de utilizare.
• Învățare pe parcurs: Agentul explică ce face și de ce. Cine urmărește explicațiile își înțelege serverul mult mai bine după câteva săptămâni.

Trei arhitecturi și pe care o folosim noi

Există trei căi verificate în practică pentru a conecta un agent la un server. Ele diferă prin locul în care rulează instrumentul și prin locul în care se află datele de acces.

Alegerea noastră: agentul pe stația de lucru, serverele prin SSH

Noi lucrăm cu prima variantă. Agentul rulează pe calculatorul de lucru, fiecare server are o intrare în configurația SSH, iar agentul se conectează cu o cheie proprie. Motivul principal: administrăm multe sisteme și tocmai astfel un singur agent poate urmări, într-o singură sesiune, o cauză pe mai multe servere, de exemplu de la serverul web, prin baza de date, până la firewall. În plus, autentificarea la furnizorul AI și cheile se află într-un loc pe care oricum îl protejăm. Cine are un singur server și dorește rapoarte automate noaptea se descurcă bine cu a doua variantă. Mai multe despre avantaje și dezavantaje găsiți în articolul despre serverul gestionat de AI.

Ghid: conectarea unui agent AI la server prin SSH

Cei șapte pași de mai jos funcționează la fel cu Claude Code, Codex CLI și Gemini CLI. Exemplele folosesc adresa de documentație 203.0.113.10 și numele de utilizator deploy, pe care le înlocuiți cu valorile dumneavoastră. Condiția prealabilă este un server cu autentificare prin cheie SSH, așa cum este descris în articolul Securizarea SSH și configurarea autentificării cu cheie.

Pasul 1: generați o cheie SSH proprie, doar pentru agent

Agentul nu primește niciodată cheia dumneavoastră personală, ci una proprie. Astfel îi puteți retrage accesul oricând, fără să îl pierdeți pe al dumneavoastră, iar în jurnale se vede ce autentificare a venit de la agent.

ssh-keygen -t ed25519 -C "ki-agent" -f ~/.ssh/ki_agent_ed25519

Ed25519 este scurt, rapid și considerat sigur. Comentariul ki-agent apare mai târziu în fișierul authorized_keys al serverului și face cheia ușor de recunoscut dintr-o privire.

Pasul 2: adăugați cheia publică pe server

ssh-copy-id -i ~/.ssh/ki_agent_ed25519.pub deploy@203.0.113.10

Dacă doriți să restrângeți și mai mult accesul, adăugați opțiuni înaintea cheii în fișierul ~/.ssh/authorized_keys de pe server. from= permite autentificarea doar de la o anumită adresă, iar no-agent-forwarding și no-port-forwarding împiedică folosirea conexiunii ca trambulină:

from="198.51.100.7",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... ki-agent

Dacă serverul răspunde apoi cu Permission denied (publickey), vă ajută articolul Rezolvarea erorii SSH Permission denied (publickey).

Pasul 3: creați un alias de host în configurația SSH

Datorită unui alias, agentul trebuie să cunoască doar un nume scurt și folosește mereu cheia corectă:

Host web-prod
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/ki_agent_ed25519
    IdentitiesOnly yes
    ServerAliveInterval 30

După aceea este suficient ssh web-prod "systemctl status nginx". IdentitiesOnly yes împiedică SSH să încerce pe rând alte chei din colecția dumneavoastră de chei. Pentru fiecare server suplimentar creați un bloc separat, iar pentru sistemele de test și de producție, de preferință, cu nume diferite, precum web-test și web-prod, astfel încât o confuzie să iasă în evidență încă de la nume.

Pasul 4: instalați agentul și autentificați-vă

Claude Code, Codex CLI și Gemini CLI rulează pe Linux, macOS și Windows, iar autentificarea se face cu un cont la furnizor sau cu o cheie API. Instalarea și autentificarea fără browser sunt descrise în ghidul pas cu pas. Pentru varianta cu stație de lucru, instalați instrumentul pe calculatorul dumneavoastră, nu pe server.

Pasul 5: stabiliți regulile pe care le respectă agentul

Toate cele trei instrumente citesc la pornire un fișier de reguli din directorul de lucru: Claude Code citește CLAUDE.md, Codex CLI AGENTS.md, iar Gemini CLI GEMINI.md. Acolo este descris modul de lucru pe serverele dumneavoastră. Un punct de plecare verificat în practică:

# Reguli pentru lucrul pe servere

- Înaintea fiecărei modificări creează un backup datat, în afara directorului web.
- Înainte de aplicare verifică sintaxa (nginx -t, php -l, apachectl configtest).
- După aplicare verifică serviciul, jurnalul și funcționalitatea, apoi raportează rezultatul.
- Nu afișa niciodată parole, chei API sau tokenuri și nu le copia niciodată în fișiere.
- Execută ștergeri, modificări în baze de date și orice acțiune ireversibilă doar după aprobare explicită.
- Nu modifica direct fișierele gestionate de panoul de control.
- După test, șterge fișierele de test.

Regulile evoluează odată cu activitatea. De fiecare dată când agentul face ceva altfel decât doriți, corectura trebuie trecută ca regulă în acest fișier. După câteva săptămâni, lucrează așa cum ați lucra chiar dumneavoastră.

Pasul 6: configurați aprobările și lista albă

Implicit, instrumentele întreabă înaintea fiecărei comenzi care modifică ceva. La început, așa și trebuie. Comenzile de citire pe care le confirmați în mod repetat le puteți aproba permanent. În Claude Code, acest lucru se face în fișierul .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(ssh web-prod journalctl:*)",
      "Bash(ssh web-prod systemctl status:*)",
      "Bash(ssh web-prod df -h)"
    ]
  }
}

Tot ce nu se află pe această listă are nevoie în continuare de acordul dumneavoastră. Opțiunile care dezactivează toate confirmările își au locul cel mult pe o mașină de test de unică folosință.

Pasul 7: prima sarcină: doar citire

Începeți cu sarcini care nu pot modifica nimic și observați cum procedează agentul:

Verifică pe web-prod erorile nginx din ultimele 24 de ore și numește cele trei
cauze cele mai frecvente, fiecare cu o dovadă din jurnal. Nu modifica nimic.

Abia când analizele sunt corecte urmează modificări mici, de exemplu o nouă rotație a jurnalelor sau un serviciu systemd, și abia după aceea implementări pe sistemul de producție.

Cum face agentul implementările: procedura noastră pentru fiecare modificare pe sistemul de producție

Un agent AI are voie să facă implementări pe un sistem de producție doar după o procedură fixă, care include un backup, o cale de revenire pregătită și o verificare înainte și după aplicare. La noi, această procedură arată așa:

1. Verificarea stării actuale. Fișierul de pe server este comparat cu ultima versiune cunoscută. Dacă între timp l-a modificat altcineva, agentul se oprește și întreabă, în loc să suprascrie acea modificare.
2. Crearea backupului. Fișierele afectate ajung, datate, într-un director de backup din afara directorului web. Un backup aflat în directorul web ar putea fi, în anumite condiții, accesibil public.
3. Pregătirea căii de revenire. Un mic script care restaurează starea veche cu o singură comandă este scris înaintea modificării, nu abia în caz de urgență.
4. Verificarea sintaxei. Fișierul nou este verificat înainte de aplicare, la PHP cu php -l, la nginx cu nginx -t. Astfel, o eroare de sintaxă nici nu mai ajunge pe sistemul de producție.
5. Aplicarea cu drepturile corecte. Proprietarul, grupul și drepturile fișierului sunt preluate de la versiunea veche. După erorile de sintaxă, drepturile greșite sunt cea mai frecventă cauză a căderilor după o actualizare.
6. Testarea fără efecte secundare. Se testează în mod citire, cu date de test inventate sau într-un mediu izolat, niciodată cu comenzi reale sau cu date reale ale clienților.
7. Verificarea live. După aplicare se controlează statusul HTTP, jurnalul de erori și funcția modificată.
8. Documentarea. Registrul de modificări și manualul de operare sunt completate, inclusiv cu locul backupului și comanda de revenire.

Ca secvență de comenzi, cu substituenți în locul căilor reale, arată cam așa:

ZIEL=/var/www/app/config.php
SICH=/var/backups/agent/$(date +%F-%H%M)
mkdir -p "$SICH" && chmod 700 "$SICH"
cp -a "$ZIEL" "$SICH/"
echo "cp -a $SICH/config.php $ZIEL" > "$SICH/rueckweg.sh"
php -l neu/config.php
install -o www-data -g www-data -m 640 neu/config.php "$ZIEL"
curl -fsS -o /dev/null -w "%{http_code}\n" https://example.com/

De ce calea de revenire se pregătește înaintea modificării

Când ceva a mers prost, nimeni nu este în cea mai bună formă să gândească o cale de revenire curată. Dacă scriptul este deja pregătit, anularea modificării este o chestiune de secunde, iar agentul o poate executa și singur dacă verificarea de după aplicare eșuează. Aceasta este cea mai mare diferență dintre un agent care modifică ceva „pe fugă” și unul căruia i se poate încredința un sistem de producție.

Teste care nu pot strica nimic

Multe funcții nu pot fi testate fără să se întâmple ceva: o comandă, o plată, un e-mail. Aici ajută trei tehnici. În primul rând, rulările de tip dry run oferite chiar de instrument. În al doilea rând, identificatori inventați, care cu siguranță nu există nicăieri. În al treilea rând, un mediu izolat: un proces care rulează într-un namespace de rețea propriu, fără nicio conexiune (unshare -n), nu poate nici să ajungă la o interfață externă, nici să cumpere ceva din greșeală, dar vede în continuare baza de date locală prin socketul Unix. După test, toate fișierele de test sunt eliminate.

Acțiunile care costă bani au nevoie de o blocare

Când o procedură comandă, facturează sau șterge ceva, nu are voie să ruleze de două ori în același timp, nici atunci când cineva dă dublu clic sau agentul repetă o comandă. Cea mai simplă soluție pe Linux este flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "rulează deja"

La aplicațiile cu baze de date, același rol îl îndeplinește o blocare cu nume (GET_LOCK în MySQL și MariaDB), iar la interfețe un Idempotency-Key, despre care găsiți mai multe mai jos, în secțiunea despre KernelHost API.

Securitate: acces pentru agent fără scurgeri de informații

Îngrijorarea pe care o auzim cel mai des este: „Și ce se întâmplă cu datele mele?” Răspunsul sincer: agentul trimite tot ce citește spre procesare la modelul lingvistic al furnizorului. De aceea, prin regulile de mai jos decideți ce ajunge el să vadă.

Secretele nu au ce căuta în chat

Parolele, cheile API și tokenurile nu se scriu niciodată într-o sarcină și nu sunt afișate niciodată de agent. Scripturile le citesc din fișiere cu drepturile 600, pe care agentul nu trebuie să le afișeze pentru a folosi scriptul. Dacă totuși o cheie ajunge vreodată în chat, este blocată imediat la furnizor și generată din nou. Nici fragmentele nu au ce căuta în chat: primele caractere ale unei chei nu ajută pe nimeni la depanare, dar scurtează munca unui atacator.

Chei proprii, drepturi proprii, revocabile oricând

Fiecare agent primește o cheie SSH proprie, iar fiecare cheie poate fi recunoscută în authorized_keys după comentariul ei. Cine vrea să retragă accesul șterge acea singură linie. Acolo unde este suficient, agentul lucrează cu un utilizator propriu și cu o regulă sudo care permite doar comenzile necesare. Interfețele de programare primesc chei proprii, cu cele mai mici drepturi posibile, iar pentru simple analize doar drepturi de citire.

Aprobări: ce nu se întâmplă niciodată fără un om

La noi, fără acord explicit, agentul nu are voie să șteargă, să scrie în baze de date, să relaxeze reguli de firewall sau de protecție, să oprească mașini sau să comande ceva. Instrumentele sprijină acest lucru: Claude Code întrerupe acțiunile care modifică sistemul și poate fi configurat în plus astfel încât un filtru de securitate să recunoască comenzile riscante și să le blocheze până la aprobare. Din experiența noastră de zi cu zi: acest filtru a oprit de mai multe ori o acțiune corectă din punct de vedere tehnic, dar ireversibilă. Ea a rulat abia după ce un om a aprobat-o explicit. Exact așa trebuie să fie.

Trasabilitate: jurnal, listă de modificări, backupuri

Fiecare sesiune lasă urme pe care un om le poate citi: backupurile datate, scriptul de revenire, intrarea din registrul de modificări și autentificările din jurnalul de sistem. Cine administrează în plus /etc în Git cu etckeeper vede fiecare modificare de configurație ca diff. Ce nu este trasabil nu poate fi nici anulat. Baza rămâne o strategie de backup funcțională, pentru că un agent nu înlocuiește un backup.

Ce server este potrivit pentru un agent AI?

Un server pentru administrare asistată de AI are nevoie de acces root complet, autentificare cu cheie SSH, conexiuni de ieșire nerestricționate, protecție DDoS permanentă și, ideal, o interfață de programare prin care serverele pot fi comandate și controlate automat. Nu are nevoie de GPU, pentru că modelul lingvistic rulează la furnizor.

De ce KernelHost pentru servere gestionate de AI

În principiu, un agent AI poate lucra cu orice server pe care primește un shell. În practică însă, mediul decide câtă muncă îi puteți încredința cu adevărat. Pe un server root KVM sau pe un server dedicat KernelHost nu există conturi restricționate, nici obstacole pentru conexiunile HTTPS către furnizorii AI și nici obligații contractuale care să facă testarea scumpă. Protecția DDoS permanentă este activă pe fiecare server fără cost suplimentar, iar pentru sarcinile care cer multă putere de calcul există servere root Professional cu nuclee dedicate. Facturarea se face PrePaid: fără contract, fără durată minimă, fără taxă de configurare. Dacă doriți să încercați mai întâi, începeți cu serverul de test gratuit.

KernelHost API: agentul dumneavoastră comandă și controlează singur servere

Cea mai mare pârghie se află cu un nivel deasupra serverului individual. Prin KernelHost API, un agent poate consulta produse și prețuri, comanda servere, citi starea serviciilor sale, porni, opri și reporni servere, precum și iniția și revoca rezilieri. Astfel, „Configurează-mi un server de test” devine o singură sarcină: agentul comandă mașina, așteaptă livrarea, se conectează prin SSH, instalează aplicația și comunică adresa.

Pentru utilizarea de către agenți, interfața este construită în mod deliberat prudent. Cheile API primesc doar drepturile de care au nevoie, iar o cheie pentru analize nu poate comanda absolut nimic. Un Idempotency-Key are grijă ca o comandă pe care agentul o repetă după o eroare de timeout să nu fie executată de două ori. Cererile sunt limitate per cheie, per cont și per adresă, astfel încât nici măcar un agent prins într-o buclă infinită să nu poată declanșa o avalanșă. Iar fiecare citire a datelor de acces generează o notificare prin e-mail, ca să vedeți când un agent a citit date de acces.

Cât costă un server gestionat de AI?

Există două categorii de costuri. Prima este serverul însuși: pentru un agent care lucrează prin SSH, acesta nu are nevoie de o dotare specială, fiind suficient orice server root pe care rulează oricum aplicația dumneavoastră. Dacă agentul rulează direct pe server, instrumentul are nevoie doar de câteva sute de megaocteți de memorie RAM, iar un server root cu 2 vCPU și 4 GB RAM este suficient dacă pe el nu mai rulează mare lucru. A doua este modelul lingvistic: fie un abonament la furnizor, care include utilizarea instrumentului de linie de comandă, fie o cheie API cu facturare în funcție de consum. La utilizare zilnică intensivă, abonamentul este de obicei mai avantajos, iar pentru sarcinile automatizate, fără un om în fața ecranului, cheia API este calea curată, pentru că poate fi plafonată cu un buget lunar. Prețurile actuale ale serverelor le găsiți pe pagina Închiriere server root.

Greșeli frecvente și cum le evitați

• Agentul lucrează cu cheia personală a administratorului. În acest caz, accesul lui nu poate fi retras separat și nu poate fi deosebit în jurnale. Soluția: o cheie proprie, cu un comentariu propriu.
• Toate confirmările sunt dezactivate. În prima zi, asta economisește clicuri, iar la un moment dat costă un server. Soluția: listă albă pentru comenzile de citire, aprobare pentru tot ce modifică sistemul.
• Niciun backup înaintea modificării. Soluția: backupul și scriptul de revenire ca regulă fixă în CLAUDE.md sau AGENTS.md.
• Backupuri în directorul web. Un fișier precum config.php.bak din webroot poate fi accesibil public, cu tot cu parola bazei de date. Soluția: un director de backup în afara directorului web, cu drepturile 700.
• Secrete în prompt. Soluția: datele de acces doar în fișiere cu drepturile 600, citite de scripturi, iar în caz de greșeală, regenerarea lor imediată.
• Execuție dublă. Un dublu clic sau o cerere repetată comandă de două ori. Soluția: blocare cu flock sau Idempotency-Key.
• Fișiere gestionate de panoul de control, modificate direct. Panoul le suprascrie la următoarea actualizare sau eșuează din cauza lor. Soluția: excludeți astfel de fișiere prin reguli și faceți modificările prin panou sau prin interfața acestuia.
• Rezultate preluate fără verificare. Un agent care nu înțelege un rezultat ghicește. Soluția: cereți dovezi („arată-mi linia din jurnal”) și puneți agentul să verifice rezultatele live.

Pe scurt

• Conectarea AI la server înseamnă a-i oferi unui agent precum Claude Code, Codex CLI sau Gemini CLI o cheie SSH proprie și reguli clare.
• Agentul citește jurnale, aplică modificări, verifică rezultatul și îl documentează, iar pașii care modifică sistemul rulează doar cu aprobare.
• Fiecare implementare urmează o procedură fixă: verificarea stării actuale, backup, pregătirea căii de revenire, verificarea sintaxei, aplicare, testare, verificare live, documentare.
• Secretele nu au ce căuta niciodată în chat, iar acțiunile care costă bani au nevoie de o blocare împotriva execuției duble.
• Serverul are nevoie de acces root, chei SSH, conexiuni de ieșire libere și protecție DDoS, dar nu de GPU.
• Serverele KernelHost îndeplinesc de la început toate cerințele, PrePaid și fără obligații contractuale, iar prin KernelHost API agentul poate chiar să comande și să controleze singur servere.