AI összekapcsolása a szerverrel: így telepít és adminisztrál egy AI-ügynök a szerverén

A legtöbben eddig úgy használják az AI-t, mint egy nagyon olvasott kollégát a telefon túloldalán: az ember leír egy szerverproblémát, kap egy javasolt parancsot, bemásolja a konzolba, visszamásolja a hibaüzenetet, és addig ismétli a kört, amíg minden működni nem kezd. Amint összekapcsolja az AI-t a szerverével, ez a kerülőút megszűnik. Egy AI-ügynök, például a Claude Code, az OpenAI Codex CLI vagy a Gemini CLI, maga jelentkezik be SSH-n a szerverre, elolvassa a naplókat, ellenőrzi a konfigurációt, élesíti a változtatásokat, teszteli az eredményt, és leírja, mit csinált. Ön adja meg a feladatot, és ön hagyja jóvá azokat a lépéseket, amelyek nem vonhatók vissza.

Ez a cikk gyakorlati beszámoló. A KernelHostnál hónapok óta nap mint nap egy AI-ügynök is dolgozik a saját infrastruktúránkon: ügyfélportál, monitorozás, fizetési csatornák, dokumentáció. Megmutatjuk, hogyan épül fel a kapcsolat az ügynök és a szerver között, milyen folyamat szerint telepít az ügynök éles rendszerekre, mely szabályok akadályozzák meg, hogy közben valami elromoljon vagy kiszivárogjon, és mit kell egy szervernek tudnia ahhoz, hogy mindez működjön. Az eszközök és az architektúrák alapjait az AI-menedzselt szerver: AI-ügynökök biztonságos összekapcsolása című cikk tárgyalja, a szerverre történő telepítést pedig a Claude Code-hoz és a Codex CLI-hez készült útmutató írja le.

AI összekapcsolása a szerverrel: mit jelent ez

Egy AI összekapcsolása a szerverrel azt jelenti, hogy egy AI-ügynök saját, ellenőrzött hozzáférést kap a szerver parancssorához, többnyire egy SSH-kulcson keresztül. Ettől a pillanattól kezdve az ügynök a parancsokat nemcsak javasolja, hanem maga futtatja is, elolvassa a kimenetet, és ebből vezeti le a következő lépést. Maga a nyelvi modell továbbra is a szolgáltatónál fut (Anthropic, OpenAI vagy Google), az ön gépén vagy szerverén csak egy könnyű parancssori eszköz dolgozik, amely kiadja a parancsokat.

A döntő szó az „ellenőrzött”. Egy szerverhozzáféréssel rendelkező ügynök nem robotpilóta, hanem egy nagyon gyors munkatárs, aki minden beavatkozó művelet előtt rákérdez. Hogy mennyit tehet meg visszakérdezés nélkül, azt ön határozza meg: a puszta olvasási hozzáféréstől egészen a frissítések rögzített folyamat szerinti, önálló telepítéséig.

Chatbot vagy ügynök: a különbség egy táblázatban

Így a félórányi oda-vissza gyakran néhány percre rövidül, az „elgépeltem” mint hibaforrás pedig teljesen megszűnik.

Mit végez el egy AI-ügynök a szerveren: példák a saját üzemeltetésünkből

Az alábbi példák a mindennapjainkból származnak. A neveket, címeket és hozzáférési adatokat kihagyjuk, a folyamatok valósak.

Élesítés mentéssel és visszaúttal

Ha az ügyfélportálon vagy egy szerverszkriptben módosítunk valamit, az élesítést az ügynök végzi. Először összeveti a szerveren lévő fájlt az utolsó ismert állapottal, hogy ne írjon felül valaki más által végzett változtatást. Ezután dátummal ellátott mentést készít a webkönyvtáron kívül, megír egy visszaállító szkriptet, ellenőrzi az új fájl szintaxisát, ugyanazzal a tulajdonossal és ugyanazokkal a jogosultságokkal élesíti, mint korábban, majd teszteli az érintett funkciót. Csak ha minden zöld, akkor jelenti, hogy elkészült. A pontos folyamatot lentebb, az élesítésről szóló részben találja.

Hibakeresés: a tünettől az okig percek alatt

„A weboldal az irodánkból nem érhető el, útközben viszont igen.” Korábban ez hosszabb keresgélést jelentett volna. Az ügynök ellenőrzi a tűzfalszabályokat, átnézi a védőszoftver naplóit az iroda IP-címét keresve, megtalálja a szabályt, amely aktiválódott, és elmagyarázza, melyik kérés váltotta ki. A döntés arról, mi a teendő, nálunk marad, a nyomozómunka viszont nem. Az olyan tipikus webszerverhibáknál, mint az 502 Bad Gateway vagy a megtelt lemez, ugyanígy dolgozik: a journalctl kimenetét és az alkalmazásnaplókat olvassa, hipotézist állít fel, és bizonyítékkal alátámasztja, mielőtt bármit módosítana.

Monitorozás, amelyet az ügynök maga épít

Monitorozásunk nagy része az ügynökkel együttműködésben készült: kis ellenőrző szkriptek, amelyek néhány percenként cronfeladatként végponttól végpontig tesztelnek egy szolgáltatást, és hiba esetén üzenetet küldenek a mobiltelefonra, például egy Telegram-boton keresztül. Az ügynök megírja a szkriptet, szándékosan előidézett hibával teszteli, beállítja a cronfeladatot, és dokumentálja, hogyan lehet elnémítani a riasztást. Hogy ilyen rendszert általánosságban hogyan építhet fel, azt a Szervermonitorozás beállítása című cikk mutatja be.

Áttekintések és takarítás

Mely szerverek futnak még, bár a hozzájuk tartozó szerződést már felmondták? Mely kiegészítő szolgáltatásokért fizetnek még, holott már nem használják őket? Az ilyen kérdésekre az ügynök úgy válaszol, hogy az adatbázisokat és interfészeket csak olvasási módban kérdezi le, és az eredményt táblázatba rendezi. Takarítani csak jóváhagyás után szabad neki, és előtte ellenőrzi, hogy a gép valóban kihasználatlan-e, például az elmúlt napok adatforgalma alapján.

Dokumentáció, amely magától bővül

Minden változtatás egy változásnapló-bejegyzéssel és szükség esetén az üzemeltetési kézikönyv kiegészítésével zárul. Ez az ügynöknek másodpercekbe kerül, nekünk pedig később órákat takarít meg, mert a „Tulajdonképpen miért van ez így?” kérdésre írásos válasz van.

Az előnyök, ha az AI közvetlenül a szerveren dolgozik

• Tempó: az ügynök másodpercek alatt elolvassa azt, amihez egy embernek percek kellenek, és egy hipotézist azonnal kipróbál, ahelyett hogy előbb leírná.
• Alaposság: a teljes konfigurációt elolvassa a beemelt fájlokkal együtt, és a hiba körüli naplósorokat is, nem csak azt a részletet, amelyet valaki fontosnak tartott.
• Mindig ugyanaz a folyamat: a mentés, a szintaxis ellenőrzése és az utólagos ellenőrzés minden alkalommal lefut, péntek este is, és a huszadik apró változtatásnál is.
• Dokumentáció többletmunka nélkül: minden változtatás le van írva, az okkal, a mentés helyével és a visszaúttal együtt.
• Automatizálás szkriptírási ismeretek nélkül: az ellenőrző szkriptek, a cronfeladatok és a jelentések hétköznapi nyelvű leírásból készülnek, és használatba vétel előtt tesztelésen esnek át.
• Tanulás menet közben: az ügynök elmagyarázza, mit csinál és miért, így aki követi a munkáját, néhány hét után sokkal jobban érti a saját szerverét.

Három architektúra, és melyiket használjuk mi

Három bevált módja van annak, hogy egy ügynököt összekapcsoljunk egy szerverrel. Abban különböznek, hol fut az eszköz, és hol vannak a hozzáférési adatok.

A mi választásunk: ügynök a munkaállomáson, szerverek SSH-n

Mi az első változattal dolgozunk. Az ügynök a munkaállomáson fut, minden szervernek van egy bejegyzése az SSH-konfigurációban, és az ügynök saját kulccsal csatlakozik. A legfontosabb ok: sok rendszert üzemeltetünk, és így egyetlen ügynök egy munkamenetben több szerveren át követheti egy hiba okát, például a webszervertől az adatbázison át egészen a tűzfalig. Emellett az AI-szolgáltatónál használt bejelentkezés és a kulcsok egy olyan helyen vannak, amelyet amúgy is védünk. Akinek csak egy szervere van, és éjszakánként automatikus jelentéseket szeretne, annak a második változat jó választás. Az előnyökről és hátrányokról bővebben az AI-menedzselt szerverről szóló cikkben olvashat.

Útmutató: AI-ügynök összekapcsolása a szerverrel SSH-n keresztül

Az alábbi hét lépés a Claude Code, a Codex CLI és a Gemini CLI esetében egyformán működik. A példák a dokumentációs célú 203.0.113.10 címet és a deploy felhasználónevet használják, mindkettőt cserélje le a saját értékeire. Előfeltétel egy SSH-kulcsos bejelentkezéssel rendelkező szerver, ahogyan azt az SSH biztonságossá tétele és a kulcsos bejelentkezés beállítása című cikk leírja.

1. lépés: saját SSH-kulcs létrehozása csak az ügynök számára

Az ügynök soha nem az ön személyes kulcsát kapja meg, hanem egy sajátot. Így bármikor visszavonhatja a hozzáférését anélkül, hogy a sajátját elveszítené, a naplókból pedig kiderül, melyik bejelentkezés érkezett az ügynöktől.

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

Az Ed25519 rövid, gyors, és biztonságosnak számít. A ki-agent megjegyzés később megjelenik a szerver authorized_keys fájljában, és első pillantásra felismerhetővé teszi a kulcsot.

2. lépés: a nyilvános kulcs elhelyezése a szerveren

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

Aki tovább szeretné szűkíteni a hozzáférést, a szerveren a ~/.ssh/authorized_keys fájlban opciókat ír a kulcs elé. A from= csak egy adott címről engedi a bejelentkezést, a no-agent-forwarding és a no-port-forwarding pedig megakadályozza, hogy a kapcsolat ugródeszkaként szolgáljon:

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

Ha a szerver ezután Permission denied (publickey) üzenettel válaszol, az SSH Permission denied (publickey) hiba elhárítása című cikk segít.

3. lépés: hosztalias létrehozása az SSH-konfigurációban

Egy alias gondoskodik arról, hogy az ügynöknek csak egy rövid nevet kelljen ismernie, és mindig a megfelelő kulcsot használja:

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

Ezután elég ennyi: ssh web-prod "systemctl status nginx". Az IdentitiesOnly yes megakadályozza, hogy az SSH végigpróbálja a kulcstartójában lévő többi kulcsot. Minden további szerverhez hozzon létre külön blokkot, a teszt- és az éles rendszerekhez lehetőleg eltérő nevekkel, például web-test és web-prod, hogy egy esetleges összekeverés már a névből kiderüljön.

4. lépés: az ügynök telepítése és bejelentkezés

A Claude Code, a Codex CLI és a Gemini CLI Linuxon, macOS-en és Windowson fut, a bejelentkezés pedig a szolgáltatónál létrehozott fiókkal vagy API-kulccsal történik. A telepítést és a böngésző nélküli bejelentkezést a lépésről lépésre haladó útmutató ismerteti. A munkaállomásos változathoz az eszközt a saját gépére telepítse, ne a szerverre.

5. lépés: az ügynök által betartandó szabályok rögzítése

Mindhárom eszköz induláskor beolvas egy szabályfájlt a munkakönyvtárból: a Claude Code a CLAUDE.md, a Codex CLI az AGENTS.md, a Gemini CLI a GEMINI.md fájlt. Ebben áll, hogyan kell dolgozni az ön szerverein. Egy bevált kiindulópont:

# Szabályok a szervereken végzett munkához

- Minden változtatás előtt készíts dátummal ellátott mentést, a webkönyvtáron kívül.
- Élesítés előtt ellenőrizd a szintaxist (nginx -t, php -l, apachectl configtest).
- Élesítés után ellenőrizd a szolgáltatást, a naplót és a funkciót, és jelentsd az eredményt.
- Jelszavakat, API-kulcsokat és tokeneket soha ne írj ki, és soha ne másold őket fájlokba.
- Törlés, adatbázis-módosítás és bármi visszafordíthatatlan csak kifejezett jóváhagyás után.
- A vezérlőpult által kezelt fájlokat ne módosítsd közvetlenül.
- A teszt után távolítsd el a tesztfájlokat.

A szabályok idővel bővülnek. Valahányszor az ügynök másként csinál valamit, mint ahogy ön szeretné, a javítás szabályként ebbe a fájlba kerül. Néhány hét után úgy dolgozik, ahogy ön maga dolgozna.

6. lépés: jóváhagyások és engedélylista beállítása

Alapértelmezés szerint az eszközök minden olyan parancs előtt kérdeznek, amely változtat valamin. Kezdetben ez így helyes. Azokat az olvasó parancsokat, amelyeket folyton jóváhagy, előre engedélyezheti. A Claude Code-ban ez a .claude/settings.json fájlban történik:

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

Minden, ami nincs ezen a listán, továbbra is az ön jóváhagyását igényli. Az olyan kapcsolók, amelyek minden visszakérdezést kikapcsolnak, legfeljebb egy eldobható tesztgépre valók.

7. lépés: az első feladat: csak olvasás

Kezdjen olyan feladatokkal, amelyek semmin sem változtathatnak, és figyelje meg, hogyan jár el az ügynök:

Ellenőrizd a web-prod szerveren az elmúlt 24 óra nginx-hibáit, és nevezd meg a három
leggyakoribb okot, mindegyikhez egy bizonyítékkal a naplóból. Ne változtass semmin.

Csak ha az elemzések helytállóak, jöhetnek a kisebb változtatások, például egy új naplórotáció vagy egy systemd-szolgáltatás, és csak ezután a telepítések az éles rendszerre.

Így élesít az ügynök: a folyamatunk az éles rendszer minden változtatásához

Egy AI-ügynök éles rendszeren csak rögzített folyamat szerint élesíthet, amely mentést, előkészített visszautat, valamint az élesítés előtti és utáni ellenőrzést tartalmaz. Nálunk ez a folyamat így néz ki:

1. Az aktuális állapot ellenőrzése. Az ügynök összeveti a szerveren lévő fájlt az utolsó ismert állapottal. Ha közben valaki más módosította, az ügynök leáll és visszakérdez, ahelyett hogy felülírná a más által végzett változtatást.
2. Mentés készítése. Az érintett fájlok dátummal ellátva egy mentési mappába kerülnek a webkönyvtáron kívül. A webkönyvtárban tárolt mentés adott esetben nyilvánosan letölthető lenne.
3. A visszaút előkészítése. Egy kis szkript, amely egyetlen paranccsal visszaállítja a korábbi állapotot, még a változtatás előtt elkészül, nem pedig csak akkor, amikor már baj van.
4. A szintaxis ellenőrzése. Az új fájl élesítés előtt ellenőrzésen megy át, PHP esetén a php -l, nginx esetén az nginx -t paranccsal. Így egy szintaxishiba el sem jut az éles rendszerig.
5. Élesítés a megfelelő jogosultságokkal. A tulajdonost, a csoportot és a fájljogosultságokat az ügynök a korábbi állapotból veszi át. A szintaxishibák után a hibás jogosultságok a leggyakoribb okai a frissítés utáni kieséseknek.
6. Tesztelés mellékhatások nélkül. A tesztelés csak olvasó műveletekkel, kitalált tesztadatokkal vagy elszigetelt környezetben történik, soha nem valódi megrendelésekkel vagy valódi ügyféladatokkal.
7. Ellenőrzés élesben. Élesítés után az ügynök ellenőrzi a HTTP-állapotkódot, a hibanaplót és a módosított funkciót.
8. Dokumentálás. A változásnapló és az üzemeltetési kézikönyv kiegészül, a mentés helyével és a visszaállítás parancsával együtt.

Parancssorozatként, valódi elérési utak helyett helyőrzőkkel, ez nagyjából így néz ki:

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/

Miért készül el a visszaút a változtatás előtt

Hiba esetén senki sincs a legjobb formájában ahhoz, hogy kigondoljon egy tiszta visszautat. Ha a szkript már készen áll, a visszaállítás másodpercek kérdése, és az ügynök maga is végrehajthatja, ha az élesítés utáni ellenőrzés sikertelen. Ez a legnagyobb különbség aközött az ügynök között, amely „csak úgy gyorsan” módosít valamit, és aközött, amelyre éles rendszert bízunk.

Tesztek, amelyek semmit sem tehetnek tönkre

Sok funkciót nem lehet úgy tesztelni, hogy közben ne történjen valami: egy megrendelés, egy fizetés, egy e-mail. Itt három technika segít. Először is a próbafuttatások, amelyeket maga az eszköz kínál. Másodszor a kitalált azonosítók, amelyek garantáltan sehol sem léteznek. Harmadszor egy elszigetelt környezet: egy folyamat, amely saját hálózati névtérben, hálózat nélkül fut (unshare -n), sem külső interfészt nem érhet el, sem véletlenül nem vásárolhat semmit, a helyi adatbázist viszont a Unix-socketen keresztül továbbra is látja. A teszt után az összes tesztfájlt eltávolítjuk.

A pénzbe kerülő műveletekhez zárolás kell

Ha egy folyamat megrendel, kiszámláz vagy töröl valamit, nem futhat kétszer egyszerre, akkor sem, ha valaki duplán kattint, vagy az ügynök megismétel egy parancsot. Linuxon a legegyszerűbb megoldás a flock:

flock -n /run/lock/bestellung.lock ./bestellung-ausfuehren.sh || echo "már fut"

Adatbázis-alkalmazásoknál egy elnevezett zár (GET_LOCK a MySQL-ben és a MariaDB-ben) tölti be ugyanezt a szerepet, API-knál pedig egy Idempotency-Key, erről bővebben lentebb, a KernelHost API-nál olvashat.

Biztonság: hozzáférés az ügynöknek anélkül, hogy bármi kiszivárogna

A leggyakrabban hallott aggodalom így hangzik: „És mi lesz az adataimmal?” Az őszinte válasz: mindent, amit az ügynök elolvas, feldolgozásra elküld a szolgáltató nyelvi modelljének. Ezért a következő szabályokkal ön dönti el, mit láthat egyáltalán.

A titkok nem valók a chatbe

Jelszavakat, API-kulcsokat és tokeneket soha nem írunk bele egy feladatba, és az ügynök sem írja ki őket soha. A szkriptek 600 jogosultságú fájlokból olvassák be őket, amelyeket az ügynöknek nem kell megjelenítenie ahhoz, hogy a szkriptet használja. Ha mégis chatbe kerül egy kulcs, azonnal letiltjuk a szolgáltatónál, és újat generálunk. A töredékek sem valók a chatbe: egy kulcs első karakterei senkinek sem segítenek a hibakeresésben, a támadó munkáját viszont megrövidítik.

Saját kulcs, saját jogosultságok, bármikor visszavonható

Minden ügynök saját SSH-kulcsot kap, és minden kulcs felismerhető a megjegyzéséről az authorized_keys fájlban. Aki vissza akarja vonni a hozzáférést, törli azt az egy sort. Ahol ez elegendő, az ügynök saját felhasználóval és egy olyan sudo-szabállyal dolgozik, amely csak a szükséges parancsokat engedélyezi. Az API-khoz saját kulcsok tartoznak a lehető legszűkebb jogosultságokkal, tisztán elemzési célra csak olvasási joggal.

Jóváhagyások: ami ember nélkül soha nem történik meg

Kifejezett hozzájárulás nélkül az ügynök nálunk nem törölhet, nem írhat adatbázisokba, nem lazíthat tűzfal- vagy védelmi szabályokon, nem állíthat le gépeket, és nem rendelhet meg semmit. Az eszközök ezt támogatják: a Claude Code megállítja a beavatkozó műveleteket, és emellett úgy is beállítható, hogy egy biztonsági szűrő felismerje a kockázatos parancsokat, és a jóváhagyásig blokkolja őket. A mindennapjainkból: ez a szűrő nem egyszer megállított egy olyan műveletet, amely szakmailag helyes volt, csak éppen visszafordíthatatlan. Csak azután futott le, hogy egy ember kifejezetten jóváhagyta. Pontosan így kell lennie.

Nyomon követhetőség: napló, változáslista, mentések

Minden munkamenet ember által olvasható nyomokat hagy: a dátummal ellátott mentéseket, a visszaállító szkriptet, a változásnapló bejegyzését és a bejelentkezéseket a rendszernaplóban. Aki az /etc könyvtárat emellett etckeeperrel Gitben kezeli, minden konfigurációs változtatást diffként lát. Ami nem követhető nyomon, az vissza sem vonható. Az alap továbbra is egy működő mentési stratégia, mert egy ügynök nem helyettesíti a mentést.

Milyen szerver alkalmas egy AI-ügynökhöz?

Egy AI-támogatott üzemeltetésre szánt szervernek teljes root hozzáférésre, SSH-kulcsos bejelentkezésre, szabad kimenő kapcsolatokra, állandó DDoS-védelemre és ideális esetben egy olyan API-ra van szüksége, amelyen keresztül a szerverek automatizáltan megrendelhetők és vezérelhetők. GPU-ra nincs szüksége, mert a nyelvi modell a szolgáltatónál fut.

Miért a KernelHost az AI által kezelt szerverekhez

Elvileg egy AI-ügynök bármilyen szerverrel tud dolgozni, amelyen shellt kap. A gyakorlatban azonban a környezet dönti el, mennyi munkát adhat át neki valójában. Egy KernelHost KVM root szerveren vagy dedikált szerveren nincsenek korlátozott fiókok, nincsenek akadályok az AI-szolgáltatók felé irányuló HTTPS-kapcsolatok előtt, és nincs szerződéses kötöttség, amely drágává tenné a kipróbálást. Az állandó DDoS-védelem minden szerveren felár nélkül aktív, a számításigényes feladatokhoz pedig dedikált CPU-magokkal rendelkező Professzionális VDS-ek állnak rendelkezésre. Az elszámolás PrePaid alapon történik: nincs szerződés, nincs minimális futamidő, nincs beállítási díj. Aki előbb ki szeretné próbálni, kezdje az ingyenes tesztszerverrel.

A KernelHost API: az ön ügynöke maga rendel meg és vezérel szervereket

A legnagyobb lehetőség egy szinttel az egyes szerverek fölött rejlik. A KernelHost API segítségével egy ügynök lekérdezheti a termékeket és az árakat, szervereket rendelhet meg, kiolvashatja a szolgáltatásai állapotát, szervereket indíthat, állíthat le és indíthat újra, valamint felmondásokat kezdeményezhet és vonhat vissza. Így az „Állíts be nekem egy tesztszervert” kérésből egyetlen feladat lesz: az ügynök megrendeli a gépet, megvárja az üzembe helyezést, SSH-n csatlakozik, telepíti az alkalmazást, és visszajelzi a címet.

Az ügynökök általi használathoz az interfészt szándékosan óvatosra terveztük. Az API-kulcsok csak azokat a jogosultságokat kapják meg, amelyekre szükségük van, egy elemzésekhez használt kulcs egyáltalán semmit sem tud megrendelni. Egy Idempotency-Key gondoskodik arról, hogy az a megrendelés, amelyet az ügynök időtúllépési hiba után megismétel, ne fusson le kétszer. A kérések kulcsonként, fiókonként és IP-címenként korlátozottak, így még egy végtelen ciklusba került ügynök sem indít el lavinát. Továbbá a hozzáférési adatok minden lekérése e-mail-értesítést vált ki, így láthatja, mikor olvasott ki egy ügynök hozzáférési adatokat.

Mennyibe kerül egy AI által kezelt szerver?

Két költségtétel merül fel. Az első maga a szerver: egy SSH-n keresztül dolgozó ügynökhöz nem kell különleges felszereltség, bármelyik root szerver megfelel, amelyen az alkalmazása amúgy is fut. Ha az ügynök közvetlenül a szerveren fut, magának az eszköznek csak néhány száz megabájt memóriára van szüksége, egy 2 vCPU-s és 4 GB RAM-os root szerver elegendő, ha más alig fut rajta. A második a nyelvi modell: vagy a szolgáltató előfizetése, amely magában foglalja a parancssori eszköz használatát, vagy egy felhasználás alapján elszámolt API-kulcs. Napi intenzív használatnál az előfizetés többnyire olcsóbb, az ember nélküli automatizált feladatokhoz viszont az API-kulcs a tiszta megoldás, mert havi kerettel korlátozható. Az aktuális szerverárakat a Root szerver bérlése oldalon találja.

Gyakori hibák, és hogyan kerülheti el őket

• Az ügynök a rendszergazda személyes kulcsával dolgozik. Így a hozzáférése nem vonható vissza külön, és a naplókban sem különböztethető meg. Megoldás: saját kulcs saját megjegyzéssel.
• Minden visszakérdezés ki van kapcsolva. Ez az első napon kattintásokat spórol, előbb-utóbb pedig egy szerverbe kerül. Megoldás: engedélylista az olvasó parancsokhoz, jóváhagyás minden beavatkozó művelethez.
• Nincs mentés a változtatás előtt. Megoldás: a mentés és a visszaállító szkript legyen rögzített szabály a CLAUDE.md vagy az AGENTS.md fájlban.
• Mentések a webkönyvtárban. Egy olyan fájl, mint a config.php.bak a webrootban, nyilvánosan letölthető lehet, az adatbázisjelszóval együtt. Megoldás: mentési mappa a webkönyvtáron kívül, 700 jogosultsággal.
• Titkok a promptban. Megoldás: hozzáférési adatok csak 600 jogosultságú fájlokban, amelyeket a szkriptek olvasnak, tévedés esetén pedig azonnali újragenerálás.
• Kétszeri végrehajtás. Egy dupla kattintás vagy egy megismételt kérés kétszer ad le megrendelést. Megoldás: zárolás flock segítségével vagy Idempotency-Key.
• A vezérlőpult által kezelt fájlok közvetlen módosítása. A panel a következő frissítéskor felülírja őket, vagy hibára fut miattuk. Megoldás: az ilyen fájlokat zárja ki a szabályokban, a változtatásokat pedig a panelen vagy annak interfészén keresztül végezze.
• Ellenőrizetlenül elfogadott kimenetek. Egy ügynök, amely nem ért egy kimenetet, találgat. Megoldás: kérjen bizonyítékot („mutasd meg a naplósort”), és ellenőriztesse az eredményeket élesben.

Röviden összefoglalva

• Egy AI összekapcsolása a szerverrel azt jelenti, hogy egy ügynök, például a Claude Code, a Codex CLI vagy a Gemini CLI saját SSH-kulcsot és világos szabályokat kap.
• Az ügynök naplókat olvas, változtatásokat élesít, ellenőrzi és dokumentálja az eredményt, a beavatkozó lépések csak jóváhagyással futnak le.
• Minden élesítés rögzített folyamatot követ: az aktuális állapot ellenőrzése, mentés, a visszaút előkészítése, a szintaxis ellenőrzése, élesítés, tesztelés, ellenőrzés élesben, dokumentálás.
• A titkok soha nem valók a chatbe, a pénzbe kerülő műveletekhez pedig zárolás kell a kétszeri végrehajtás ellen.
• A szervernek root hozzáférésre, SSH-kulcsokra, szabad kimenő kapcsolatokra és DDoS-védelemre van szüksége, GPU-ra viszont nincs.
• A KernelHost-szerverek már alapból minden követelményt teljesítenek, PrePaid alapon, szerződéses kötöttség nélkül, a KernelHost API-n keresztül pedig az ügynök akár maga is megrendelhet és vezérelhet szervereket.