--- title: "AI-ügynökök biztonságosan: kódellenőrzés, tesztek, telepítés" description: "Gyakorlati útmutató AI-ügynökökhöz fejlesztési rutinfeladatokra: feladatválasztás, eszközkorlátok, előbb terv, naplózott hívások, átnézhető diffek, értékelés." canonical: https://sdk.enterprises/hu/insights/ai-agents-engineering-workflows language: hu --- # AI-ügynökök biztonságosan: kódellenőrzés, tesztek, telepítés Frissítve: 2026-09-25 > Az AI-ügynökök akkor segítik a fejlesztőcsapatokat, ha szűk, ismétlődő feladatokat vesznek át, például az első körös kódellenőrzést, a tesztek vázának megírását vagy a kiadással járó rutinmunkát, korlátozott eszközökkel, és minden módosítást ember hagy jóvá. Kérje, hogy cselekvés előtt mutassanak tervet, naplózzon minden eszközhívást, a munkát diffként kapja meg, és mielőtt bővítené a hatókörüket, tesztelje őket saját múltbeli eseteiből vett valódi példákon. ## Kezdje ismétlődő, ellenőrizhető és alacsony kockázatú feladatokkal Egy ügynöknek azok a legjobb első feladatok, amelyeket a csapata már most is hétről hétre ugyanúgy végez, és gyorsan ellenőrizni tud. Ha egy fejlesztő egy percen belül nem tudja megmondani, hogy jó-e az eredmény, az ügynök nem megspórolja, hanem gyártja az ellenőrzési munkát. Az éles adatok módosítását, az infrastruktúra változtatásait és minden visszafordíthatatlan lépést hagyja későbbre, amíg az ügynök biztonságosabb feladatokon nem bizonyított. - Első körös pull request-ellenőrzés: hiányzó tesztek, kockázatos minták, homályos elnevezések, stílushibák - Tesztek írása meglévő függvényekhez, különösen határesetekre, és regressziós tesztek a javított hibákhoz - Függőségfrissítő pull requestek, mindegyik változásnapló összefoglalásával - Kiadási jegyzetek piszkozata a beolvasztott pull requestek alapján - A sikertelen CI-futások osztályozása: a hibák csoportosítása és a valószínűleg felelős commit megjelölése ## Válassza a megfelelő szintet: modell-API, ügynökkeretrendszer vagy workflow-eszköz Egyetlen, jól körülhatárolt feladathoz elég az OpenAI vagy az Anthropic Claude API-jainak közvetlen hívása eszközhasználattal (tool use). A LangChain integrációkat és gyakori építőelemeket ad, a LangGraph pedig az ügynököt lépések explicit gráfjaként, közös állapottal modellezi, így könnyebb átlátni az elágazásokat, az újrapróbálkozásokat és az emberi jóváhagyási pontokat. Az n8n az ügynököt körülvevő összekötő munkára való: indítás GitHub- vagy GitLab-webhookra, a modell meghívása, ellenőrzési megjegyzés közzététele, értesítés egy csatornán. Gyakori munkamegosztás, hogy az orkesztrációt az n8n végzi, a következtetési lépés pedig kódban marad, ahol a szoftver többi részéhez hasonlóan verziózni és tesztelni lehet. A NorthStar Networknél mérnökeink AI-alapú belső eszközöket építettek, amelyek a platform eszközcsapatának ismétlődő fejlesztési feladatait automatizálták. ## Csak annyi eszközt adjon az ügynöknek, amennyire tényleg szüksége van Az ügynök csak az eszközein keresztül tud kárt okozni, ezért az eszközlista a legfontosabb biztonsági kontroll. Minden eszköznek legyen szűk célja és ellenőrzött bemenete, ahelyett hogy általános shellt vagy széles jogosultságú API-tokent adna az ügynök kezébe. Mindent, amit az ügynök olvas, a hibajegyek szövegét, a kódkommenteket és a weboldalakat is, kezeljen megbízhatatlan bemenetként. Egy fájlba rejtett utasítások megpróbálhatják eltéríteni az ügynököt (ezt a kockázatot promptinjektálásnak, angolul prompt injectionnek nevezik), és a szigorú eszközhatárok akadályozzák meg, hogy egy ilyen kísérlet kárt okozzon. - Alapértelmezetten csak olvasás: fájlok, diffek és CI-naplók olvasása - Írási jog csak egy munkaágra, soha nem a fő ágra vagy az éles környezetre - Ügynökönként külön, rövid életű hitelesítő adatok, minimális jogosultságokkal - Nincs közvetlen telepítés: az ügynök pull requestet nyit, és jóváhagyás után a szokásos pipeline telepít - Engedélyezett parancsok listája a tesztek futtatásához, elszigetelt konténerben végrehajtva ## Előbb terv, aztán cselekvés, és minden eszközhívás naplózva Kérje meg az ügynököt, hogy mielőtt bármit módosítana, készítsen tervet: mely fájlokat olvassa el, mit akar megváltoztatni, és hogyan ellenőrzi az eredményt. Az alacsony kockázatú tervek automatikusan futhatnak. Ami közös kódot érint, az megvárja, hogy egy ember jóváhagyja a tervet. Naplózzon minden eszközhívást a bemeneteivel, kimeneteivel, időbélyegével és azzal a feladattal együtt, amelyhez tartozik. Ebből a naplóból derítheti ki, miért lett rossz egy eredmény, ebből válaszolhat egy auditkérdésre, és ebből veheti észre, ha egy ügynök kilép a feladatából. Védje úgy, mint a többi fejlesztési naplót, mert forráskódot is tartalmazhat. Szabjon kemény korlátokat minden futásnak: legyen felső határa a lépések, a tokenek és a percek számának, és ismételt hibák után álljon le a futás, ne kezdjen végtelen újrapróbálkozásba. ## Minden változtatás diffként érkezzen, amelyet ember néz át Az ügynök munkája oda kerüljön, ahol a fejlesztők már most is ellenőrzik a munkát: pull requestbe, ellenőrzési megjegyzésbe, kiadási jegyzet piszkozatába. A diff pontosan megmutatja, mi változott, a CI lefut rajta, és a szokásos jóváhagyási szabályok érvényesek rá. Az ügynök diffjei legyenek kicsik és egyetlen célt szolgáljanak. Egy pull request, amely egy modulhoz ad teszteket, könnyen átnézhető, az viszont, amelyik általános javítás címén tíz fájlhoz nyúl, vagy érdemi átnézés nélkül megy át, vagy elutasítják. Jelölje meg az ügynök által írt változtatásokat, hogy az ellenőrzők a feltételezéseket is vizsgálják, ne csak a szintaxist. A generált tesztek különös figyelmet igényelnek. Győződjön meg róla, hogy a szándékolt viselkedést ellenőrzik, és elbuknának, ha a kód hibás lenne, nem pedig egyszerűen rögzítik azt, amit a jelenlegi kód visszaad. ## Értékelje saját múltbeli esetein, mielőtt bővítené a hatókört Állítson össze egy kis értékelő készletet saját repositoryjaiból: korábbi pull requestek ismert problémákkal, függvények ismert hibákkal, CI-hibák ismert okokkal. Futtassa rajta az ügynököt minden alkalommal, amikor a promptot, a modellt vagy az eszközöket módosítja, és vesse össze az eredményeket az előző futáséval. A napi használatban kövesse, milyen gyakran fogadják el az ellenőrzők az ügynök javaslatait, hány ügynöki pull request olvad be módosítás nélkül, és milyen gyakran utasítják el a terveket. Csak akkor adjon az ügynöknek új feladatot vagy több hozzáférést, ha ezek a jelzések stabilak. ## Az adatkezelési szabályokat az első futás előtt rögzítse Döntse el és írja le, milyen kódot és adatot, melyik modellszolgáltatónak és milyen szerződéses feltételekkel szabad elküldeni. Ellenőrizze minden szolgáltató adatmegőrzési és modelltanítási beállításait API-használat esetén, és tartsa távol a titkos kulcsokat, a hitelesítő adatokat és a személyes adatokat a promptoktól és a naplóktól. Ha egy ügynök több csapatot vagy ügyfelet szolgál ki, különítse el mindegyikük adatait, hitelesítő adatait és naplóit. Az SDK Pilot, a jelenleg ingyenes korai hozzáférésben elérhető AI-alapú fejlesztőügynökünk, ezeket a szabályokat követi: végrehajtás előtt megmutatja a tervét, naplóz minden eszközhívást, átnézhető diffeket készít, és elkülöníti az egyes szervezetek adatait. ## A legfontosabbak - Az ügynököket olyan ismétlődő feladatokkal indítsa, amelyek eredményét egy fejlesztő nagyjából egy perc alatt ellenőrizni tudja. - Az eszközlista a fő biztonsági kontroll: az eszközök legyenek szűkek, alapértelmezetten csak olvasásra jogosultak, íráskor egyetlen ágra korlátozva. - Követeljen meg tervet a cselekvés előtt, és naplózzon minden eszközhívást a bemeneteivel és kimeneteivel együtt. - Az ügynökök minden munkája kis diffekként, a szokásos ellenőrzési és CI-folyamaton keresztül érkezzen. - Mielőtt nagyobb hatókört adna nekik, értékelje az ügynököket saját múltjából vett valódi példákon. ## GYIK ### Kiválthatják az AI-ügynökök az emberi kódellenőrzést? Nem. Az ügynökök egy első körös átnézésre hasznosak, amely kiszűri a hiányzó teszteket, a kockázatos mintákat és a stílushibákat, így az emberi ellenőrzők a tervezésre és a szándékra koncentrálhatnak. Minden beolvasztott változtatást továbbra is embernek kell jóváhagynia. ### Biztonságos, ha egy AI-ügynök élesbe telepít? Közvetlenül nem. Az ügynök nyisson pull requestet vagy változtatási kérelmet, a telepítés pedig emberi jóváhagyás után a meglévő pipeline-on keresztül történjen. Így érintetlen marad az auditnyomvonal, a tesztek és a visszaállítási folyamat. ### LangGraph vagy n8n a fejlesztési feladatok automatizálására? Más-más problémát oldanak meg. A LangGraph az ügynök gondolatmenetét explicit lépésekbe szervezi, állapottal és jóváhagyási pontokkal, míg az n8n triggerekkel és műveletekkel köti össze a rendszereket. Sok csapat az n8n-nel indítja és irányítja a munkát, magát az ügynököt pedig LangGraph-fal vagy közvetlen modell-API-hívásokkal valósítja meg. ## Induljon ki az igényéből - [AI kkv-knak](https://sdk.enterprises/hu/ai-for-smes) ## Kapcsolódó szolgáltatások - [AI-ügynökök](https://sdk.enterprises/hu/services/ai-agents)