Esettanulmány: így építettük a saját agentünket

A probléma, amiből indult

A kiindulópont nem technológiai ambíció volt, hanem egy napi bosszúság. A projekt dokumentációja így írja le:

„Közel húsz AI-eszközt futtattam egyszerre a saját munkámhoz. Amit az egyik megtanult rólam, arról a következő soha nem hallott. A memóriám szét volt szórva, a biztonságról minden eszközben máshol döntöttek, és a kontextus minden váltásnál elveszett."

Ez nem eszközhiány. Ez integrációs probléma — és ez a különbség dönti el, hogy érdemes-e egyáltalán belevágni. Ha a gond az, hogy nincs jó eszközöd, vegyél jobbat. Ha a gond az, hogy hat jó eszközöd van, és egyik sem tud a másikról, akkor a hiányzó darab nem egy hetedik eszköz.

Az eredmény egy saját üzemeltetésű keretrendszer lett, amely 2026 szeptemberében nyilvános bétában jár: közel hatvan modul, több mint kétszáz skill, harmincnégy MCP-szerver és tizenkét futtatható motor, hat nyelven. Ezek a számok hetente változnak, és nem is ezek a lényegesek. A döntések igen.

Hogy egyáltalán mit csinál egy agent lépésről lépésre, arról az agent működésecímű írás szól bővebben.

Az első döntés: nem chatbot, hanem keretrendszer

A dokumentáció nyitómondata egyértelmű: „Nem chatbot. Valódi asszisztens." A gyakorlati következménye viszont nem a felület, hanem a motorkérdés.

A rendszer bármelyik modellszolgáltatót tudja használni, és ebben van egy olyan döntés, ami ritkán kerül elő: az előfizetéses parancssori eszközök is motorként szolgálnak, külön API-kulcs nélkül. Ha már fizetsz egy kódoló asszisztensért, azt a rendszer motorként hívja, nem másodszor is megveszed API-n.

Ez költségdöntés, nem funkció. És meg is van a párja a kompromisszumok oldalán: a nagy, felügyelt szolgáltatásoknál a modell benne van az előfizetésben. Itt nincs. A dokumentáció ezt ki is mondja — a modell továbbra is a te kulcsod vagy a te előfizetésed.

Hogy mikor éri meg egyáltalán saját megoldást építeni a kész helyett, azt a megvenni vagy megépíteni kérdést járja körül egy külön poszt.

A routing: az első lépés nem is AI

Ez a leghasznosabb átvihető döntés az egész rendszerből. A hívás útja:

1. OLCSÓ JELEK                  -> öt jel, fizetős hívás nélkül
2. MODELLES BESOROLÁS           -> csak ha az első bizonytalan
3. SZINTVÁLASZTÁS
4. KÖLTSÉGKERET-ELLENŐRZÉS
5. TARTALÉKLÁNC                 -> ha a szolgáltató nem elérhető

A lényeg az első sorban van: a besorolás első köre nem kerül pénzbe. Öt olcsó jel dönt — mire van az eszköz bekötve, milyen kulcsszavak vannak benne, mit mond az üzenet metaadata, mi volt eddig a beszélgetésben, és mit mond egy helyben futó kis osztályozó —, és csak akkor kérdez meg egy fizetős modellt, ha ezek után is bizonytalan. A legolcsóbb optimalizáció egy agentben nem az, hogy olcsóbb modellt hívsz, hanem hogy egyáltalán nem hívsz modellt.

A szintek, amelyekbe a hívás besorolódik:

A költségkeretnek három küszöbe van: 80 százaléknál figyelmeztet, 100 százaléknál automatikusan olcsóbb szintre vált, 120 százaléknál megáll. Ez azért érdekes, mert a harmadik küszöb a fontos: figyelmeztetést mindenki ír, kemény megállást kevesen.

A memória: öt réteg, és egy hiba, ami miatt el kellett szigetelni

A memória öt rétegre oszlik, és a rétegeket az élettartamuk különbözteti meg:

A visszakeresés kulcsdöntése az, hogy a modellnek nem kell kérnie a memóriát. Minden fordulóban bekerül két blokk: egy egysoros mutató az összes jegyzetről, és a kapcsolódó korábbi munka. A mutatónak fix kerete van, nyolcezer karakter — ez a korlát azért van benne a rendszerben, mert enélkül a memória észrevétlenül megeszi a context window-t.

A rögzítésnek is vannak kapui: negyven karakternél rövidebb üzenetből nem lesz jegyzet, egy beszélgetésre legfeljebb húsz rögzítő modellhívás jut, és fordulónként nulla és kettő között születik jegyzet. Kulcsszólista nincs, egyetlen nyelven sem. A rögzítés pedig a válasz kiküldése után fut: ha elhasal, egy jegyzetbe kerül, nem a válaszba.

És itt jön az a hiba, ami egy egész alrendszert indokolt. Az egyik motor saját memóriát vezet a gazdagépen. Elszigetelés nélkül a kinyerő egyszer beolvasta ezt a gazdagép-memóriát, visszajelezte, hogy a tény „már rögzítve van" — és a saját tár közben üresen maradt. Csendes hiba: semmi nem hasalt el, csak nem került be semmi.

A javítás két részből áll: elszigetelt modellkontextus, és egy nem modellalapú kapu, amely minden fájlíró eszköznek megtiltja az idegen memóriaútvonalakat. A becsületes korlát viszont ott maradt: két motor protokollja nem ismer elszigetelési paramétert, tehát ott ez nem megoldható — és a felület ezt ki is írja ahelyett, hogy úgy tenne, mintha menne.

Hogy általában mit érdemes egy agentnek megjegyeznie és mit elfelejtenie, azt az agent memorycímű poszt részletezi.

A biztonság: három kapu, és az első nem modell

Nem minden hívás megy végig mindhármon, és ez a rendszer lelke:

• zöld művelet (olvasás, keresés) → csak az első kapu
• sárga (írás, beállításmódosítás) → első és második
• piros (törlés, pénzügyi művelet, éles telepítés) → mind a három, plusz emberi jóváhagyás

A determinisztikus kapu része egy egyszerű szabály: a „megbízhatatlan bemenet", az „érzékeny adat" és a „külső művelet" közül egyszerre legfeljebb kettő teljesülhet. Ha mindhárom kell, kötelező az emberi jóváhagyás. Ez egyetlen mondatban több védelmet ad, mint a legtöbb házirend három oldalon.

Minden módosítás előtt pillanatfelvétel készül — fájl, adatbázis, beállítás, git —, visszaállítható állapottal. A megfogalmazás, amiért ezt megépítettük: „»az AI elrontotta« nem érv, hanem egyetlen parancs".

És a mondat, ami nélkül ez a szakasz hiteltelen lenne: a prompt injection nincs megoldva. A dokumentáció szó szerint ezt írja, és hozzáteszi, hogy aki mást állít, azt érdemes alaposabban megnézni. A rétegek csökkentik a kockázatot, nem szüntetik meg.

Hogy hova tedd a jóváhagyást egy folyamatban, azt az ember a folyamatbantémájú poszt bontja ki.

A jogosultságok szűkítéséről, vagyis arról, hogy az agent a lehető legkevesebbet kapja meg, a least privilege elvéről szóló írás szól.

És a prompt injection üzleti következményeit egy másik poszt nézi meg.

A zsákutca, amit meg lehetett mérni

Egyetlen döntés van a projektben, amit szám állít meg, nem érvelés — és pont ez a legtanulságosabb.

A keresés több forrásból dolgozik: teljes szöveges keresés, vektoros keresés és gráf. A találatokat össze kell fésülni, és erre van egy tankönyvi módszer: a rangsorok reciprok összefésülése, szűrés nélkül. Kézenfekvő, mindenki ezt csinálja.

Megmérve: a szűretlen összefésülés a találati arányt 85 százalékról 65 százalékra vitte le az első öt találaton. Az első öt találat közül tehát minden ötödik jó találat eltűnt — egy olyan lépéstől, amit a legtöbb rendszer be sem tesz a mérésbe. A kódban azóta tiltva van.

Amit ebből érdemes elvinni, az nem a konkrét szám. Hanem az, hogy ezt csak akkor veszed észre, ha a találati arányt méred, nem a benyomást. Egy ilyen hiba után a rendszer nem lassabb és nem ad hibaüzenetet. Csak kevesebbet talál meg, és emiatt többet hallucinál — amit aztán a modell számlájára írsz.

Őszintén hozzá kell tenni: a projektben ez az egyetlen ilyen, nyilvánosan dokumentált mérés. A többi döntés indoklása végig gondolatmenet, nem A/B-teszt. Ez normális egy egyszemélyes projektnél, de ismerni kell a különbséget.

Amit szándékosan nem építettünk meg

Ez a szakasz fontosabb, mint a funkciólista. A dokumentáció tizenkét kompromisszumot sorol fel kimondva; itt van hat közülük:

• Beágyazott adatbázis egy nagyobb helyett. A nagyobb tizenöt megabájtnyi natív függőséget hozott volna; az egyszerűbb megoldás a szükséglet nagyjából 95 százalékát lefedi.
• Nincs natív asztali és mobilalkalmazás. A dokumentáció ezt szó szerint „valódi hiánynak" nevezi, nem magyarázza el. A felület böngésző és üzenetküldő.
• A teljes képernyővezérlés csak egy operációs rendszeren működik. A másik kettőn nincs kész.
• Nincs egykattintásos helyreállítás üres gépre. A mentés teljes, a visszaállítás hat kézi lépés.
• Egytulajdonosú rendszer, nem vállalati. Nincs központi beléptetés, nincs tanúsítvány. A naplózás teljes, de egygépes és tanúsítatlan.
• A bővítmény-katalógus kicsi, szándékosan. Harmincnégy MCP-szerver és kilenc bővítmény. A 2026-os skill-regiszter incidensek után hozott döntés: a nyitott bővítménypiac bizonyított támadási felület.

Egy ilyen lista önmagában is információ. Ha egy termék dokumentációjában nincs „mit nem tudunk" szakasz, az nem azt jelenti, hogy mindent tud.

A saját üzemeltetés kockázatait egyébként a személyes agentek témájú írás szedi össze.

Mit vigyél el, ha te is ilyesmit építenél

1. ELŐBB A PROBLÉMÁT NEVEZD MEG, NE AZ ESZKÖZT
   "Nincs jó eszközöm" és "hat eszközöm van, és egyik
   sem tud a másikról" két különböző projekt.

2. A LEGOLCSÓBB HÍVÁS AZ, AMI EL SEM INDUL
   A besorolás első köre legyen determinisztikus.
   Modellt csak akkor kérdezz, ha bizonytalan vagy.

3. A KÖLTSÉGKERETHEZ KELL KEMÉNY MEGÁLLÁS
   A figyelmeztetés nem korlát. A visszaváltás sem.
   Kell egy szint, ahol tényleg leáll.

4. A BIZTONSÁG ELSŐ KAPUJA NE MODELL LEGYEN
   Amit prompttal át lehet verni, az nem kapu.
   A mintaillesztés unalmas, cserébe megbízható.

5. MÉRD A TALÁLATI ARÁNYT, NE A BENYOMÁST
   A keresés csendben romlik el. Egy rossz
   összefésülés a találatok ötödét elviheti.

6. ÍRD LE, MIT NEM TUDSZ
   A kompromisszumlista a későbbi önmagadnak szól,
   és annak, aki használni fogja.

Tipikus félreértések

• „Saját agenttel olcsóbb." A modellszámla marad. Csak az orkesztráció lesz a tiéd — és a karbantartás is.
• „Ha a saját gépemen fut, biztonságos." A kockázat nem tűnik el, hanem áthelyeződik: a modelltől a jogosultságokhoz.
• „Az agent majd eldönti, melyik modell kell." A jó rendszerben a döntés első köre determinisztikus, még modellhívás előtt.
• „A memória az a vektoradatbázis." A tárolás a könnyebbik fele. A nehezebb az, mikor és mennyi kerüljön be a kontextusba anélkül, hogy megenné.
• „Három biztonsági réteggel a prompt injection meg van oldva." Nincs. A rétegek a kockázatot csökkentik.

Amit érdemes elvinni

Egy saját agent-keretrendszer nem attól lesz jó, hogy sok modult tud. Attól, hogy a drága döntéseket olcsón hozza meg: a besorolást modellhívás nélkül, a blokkolást mintaillesztéssel, a visszaállítást pillanatfelvételből.

A három szám, amit ebből a projektből érdemes megjegyezni: öt ezredmásodperc a determinisztikus kapu, 120 százalék a kemény költségstop, és 85-ről 65 százalékra esett a találati arány egyetlen rosszul megválasztott összefésüléstől.

És a leghasznosabb, amit egy ilyen rendszer dokumentációjában találhatsz, nem a funkciólista, hanem a kompromisszumoké. Ha te építesz, írd meg a sajátodat még akkor, amikor még emlékszel rá, miért döntöttél úgy.

Az eszközök összekapcsolásának szabványáról, ami ennek a rendszernek is a gerince, az MCP működését bemutató magyarázat szól.